RE: [ecc] I NEED VHADL IMPORTANT FACTS FOR SYNTHESIS

["AJ Sahagun" <aj@asti.dost.gov.ph>]

> Hi guys!

> My name is yefreed Ditta, i´m finishing my degree project for get my
> bachelor degree on electronic engineering..

Hi, Yefreed!  The problem you are having is a very common problem among VLSI
designers, and that is what we call "synthesis-simulation mismatch".  It
usually occurs when the synthesizer infers hardware that produces glitches
and/or introduces significant propagation delay that affects the way the
circuit performs.  Some VHDL constructs infer hardware that are not really
"desirable".  Additionally, some VHDL constructs are badly interpreted, or
do not synthesize at all.

This is a very broad topic and I'm sure there are many sources out there on
this, but let me give you some advice which I do remember (most of which
come from experience):

* Never use signal/variable initializations because these constructs are
never synthesized.
* If you minimize combinational hardware in your design, you'd have less
problems with propagation delay.
* "For" loops within a process infer large amounts of combinational
hardware.  The amount of hardware it infers depends on the number of
iterations.
* As much as possible, a process should have only one main "If" block.
Synthesizers only "remember" and synthesize the last evaluation of an
expression.  Having only one "If" block minimizes the risk involved with
this.
* Example, when implementing asynchronous reset, code something like "If
(reset='0')... elsif (clk'event and clk='1')... end if".
* "If" statements infer multiplexers, so avoid too many nested "If" blocks
to avoid introducing propagation delays.
* Always remember that although VHDL looks like a programming language, it
isn't.  Always "think hardware" when designing.




> - Why if i have one block that works perfectly alone when i join it to
> another blocks the design presents problems?

I'm not sure, but it may be in the way your synthesizer "minimizes" your
gates.  If you have the luxury of having 2 FPGA's, try downloading the two
blocks in separate FPGA's and see if they'd work.  You may also want to try
setting the synthesizer to perform the least number of optimizations, just
to see if the problem lies there.

There could also be a lot of other causes, such as internal glitches,
problems in clock distribution, fan out, etc.  What is usually done is to
revise the code a bit to get different synthesized hardware, then testing if
the modification worked.  Sadly, at my level of experience, I am still at
this "trial and error" stage.  Perhaps if you could give more detail to your
problem, the VLSI gurus here could help you more with their wisdom and
experience.




> - what is better: high active resets or low active resets?

I think it's all a matter of what's needed specifically by your design, but
I'd go for active low reset (reset on zero), since in this scheme, your
system will stop functioning whenever there is a problem with your reset
input (say, a power failure).  If the reset was active high (reset on one),
the system wouldn't know whether there is a hardware problem with the reset
input.  Anyway, this is a matter of safety and not functionality, so it's
still your call.




> - Is recommneded to reset the different blocks with a reset coming from
> another block, or is better to uese external reset?

I'd use a global reset.  if the reset signal was propagated through the
blocks, the delay might be enough to cause problems.  If you want, you could
provide separate "start" signals for your blocks.  What would happen is that
"reset" would initialize the variables and signals, and "start" would signal
the block to start working.




________________________________________________
"Alcohol and Calculus don't mix.  Never drink and derive."

Engr. Jonathan A. Sahagun
Science Research Specialist
Advanced Science & Technology Institute
CP Garcia Ave., UP Diliman Technopark
Quezon City, Philippines
http://www.asti.dost.gov.ph

--
To unsubscribe from ecc mailing list please visit http://www.opencores.org/mailinglists.shtml