[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: Icarus Verilog with Xilinx simprims...

On Mar 17, 2007, at 7:56 PM, CSB wrote:

Wow, thanks for the quick responses !

Does iverilog support SDF backannotation?  The SDF has the delay
information.

Ah ! Now you mention it, I remember removing a $sdf_annotate line
from the generated verilog file. It was causing an error with vvp,
so I just removed the offending line and quickly forgot about it... The
error is: "$sdf_annotate: This task is not defined by any modules."
I just found a topic about iSDF in this mailing list; I will see what
I can do with that.

Ah! Now that you mention it, I remember running into $sdf_annotate issues with ModelSim, too, and the problem was how the Xilinx tools generated the Verilog timing sim source. The trick was to delete the $sdf_annotate line in the Verilog source, and then tell ModelSim to use the correct SDF through the GUI (there's also a command-line switch for it). Then it all worked. The Xilinx WebCase I opened about this was handled in the usual Xilinx manner ("we'll fix it in a later revision of the tools"). Now that I'm back on the VHDL side of the fence, I haven't paid attention to this.

Any specific reason why you're running a post-fit simulation?  The
RTL simulation tells you if your logic is functionally correct, and
the static timing analyzer (using your timing constraints) tells you
if you've met timing.  If both are good, there's no need to run a
post-fit simulation.


Well, that's where I'm most confused. I followed some instructions
that explained how to use TestBencher (part of ISE). Is that what
you are referring to? What I saw of it didn't impress me much...
For my design, I didn't specify any timing constraints since I'm not
concerned so much about speed as correct operation. Also, the amount
of specify-able stuff was overwhelming, so I decided to skip that
part 8~)

The simplest timing constraint is simply clock frequency. That covers 99% of most designs. The other basic constraints deal with input and output delays through the I/O pins; basically, you specify what you need the input set-up and hold to be so you can correctly capture incoming synchronous signals, and you can specify what you'd like the maximum clock-to-out time based on an external synchronous device's requirements. Look for OFFSET IN and OFFSET OUT.

If you're doing an asynchronous design, then you're on your own! Current CPLD and FPGA methodologies don't lend themselves well to async design.

My reasoning was that I would run a post-fit simulation, and see if
there were any glitches, or unusual operation. Mostly, I was thinking
about timing hazards.
But your comment makes me ask: does the fitted design guarantee
a glitch-free operation ? (the only remaining issue would be speed,
hence the timing constraints)

I should also add that I'm fairly new to digital design, so I might
be missing the point entirely.

Certainly the fitted design will have glitches, as delays through various paths will be different. The point of synchronous design is that you can ignore those glitches; all you care about is if the inputs to all of your registers are settled by the setup time before the clock edge. And for each clock, that is what the static timing analyzer tells you -- the length of all paths through all registers. As long as the prop delay from register A through logic to the D input of register B is less than the clock period, you win. The timing analyzer accounts for register clock-to-out delay and register input setup and hold.

If your design is purely combinatorial, then of course you will have glitches, and remember that a post-fit timing simulation will show you these glitches for the particular routing the tools just used, which may change for each place-and-route run as you tweak the design. The delays are worst-case (high temperature, low supply voltage, wrong phase of the moon), which means that your design will probably be "better" (path delays not as long). How much "Better" is not defined, and anyways you should never rely on datasheet "typical" values.

One final comment: Rather than staring at a screen full of logic traces looking for set-up and hold failures, read up about Verilog's $setup and $hold and other timing-check functions that you can use in your test bench. Computers are good at this sort of tedious checking!

-a


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user