Re: gEDA-user: Icarus Verilog with Xilinx simprims...
When they said warnings and your on your own that means when you make something just barely function and have no safety margin logically coming form the spec sheet of the parts you used, you do not know when it will or won't work, at which temperature, or on which individual part from the factory. Yes, I took good note of the warnings. That won't prevent me from trying some stuff, though. Not because I think I can do better than anybody (I don't), but because I find it's a good way to learn. Besides, I'm doing this purely for fun, with no job/employer/school constraints. Thanks Christian -- CSB [EMAIL PROTECTED] -- http://www.fastmail.fm - mmm... Fastmail... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Icarus Verilog with Xilinx simprims...
Günter Dannoritzer wrote: Andy Peters wrote: Does iverilog support SDF backannotation? The SDF has the delay information. Here are some information about that and a link to a previous discussion: http://iverilog.wikia.com/wiki/Graffiti#SDF_support I added a section to your entry covering the reasons for doing timing simulations (same URL). Haven't quite got the hang of this wiki yet. I tried to add it as a second-level heading under 'SDF support', but it's gone in as a main heading... Evan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Icarus Verilog with Xilinx simprims...
Evan Lavelle wrote: Günter Dannoritzer wrote: [...] Here are some information about that and a link to a previous discussion: http://iverilog.wikia.com/wiki/Graffiti#SDF_support I added a section to your entry covering the reasons for doing timing simulations (same URL). Haven't quite got the hang of this wiki yet. I tried to add it as a second-level heading under 'SDF support', but it's gone in as a main heading... Thanks Evan, Those are great information. I think the 'SDF support' headline was already a second-level == headline ==. To get it underneath you would need to make it a third-level === headline ===. Cheers, Guenter ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Icarus Verilog with Xilinx simprims...
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. 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. Hmm. My design is a bit wacky... it's mostly clock-based, but also has a combinatorial part. I'll test what I have with a real CPLD, see if it'll work (or not). Good thing they're erasable, I feel it's not the last time I'm going to re-write it ! http://iverilog.wikia.com/wiki/Graffiti#SDF_support Quite interesting, thank you for the link. Thanks to all for the information, Christian -- CSB [EMAIL PROTECTED] -- http://www.fastmail.fm - A fast, anti-spam email service. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Icarus Verilog with Xilinx simprims...
CSB wrote: 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. Hmm. My design is a bit wacky... it's mostly clock-based, but also has a combinatorial part. I'll test what I have with a real CPLD, see if it'll work (or not). Good thing they're erasable, I feel it's not the last time I'm going to re-write it ! When they said warnings and your on your own that means when you make something just barely function and have no safety margin logically coming form the spec sheet of the parts you used, you do not know when it will or won't work, at which temperature, or on which individual part from the factory. John G ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Icarus Verilog with Xilinx simprims...
Andy Peters wrote: Does iverilog support SDF backannotation? The SDF has the delay information. Here are some information about that and a link to a previous discussion: http://iverilog.wikia.com/wiki/Graffiti#SDF_support Cheers, Guenter ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
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@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Icarus Verilog with Xilinx simprims...
Hi all, I am trying to use Iverilog along with xilinx's SIMPRIMS. Well, I managed, but I am getting strange results with simulations. I'll try to explain how I'm doing this (I'm new to CPLDs, Verilog and Icarus...) First, I generate the post-fit verilog module from Xilinx ISE project navigator. This is the .v file containing all the nets and gates, for example X_AND2, etc... If I'm correct, those are defined in the *.v files of the XILINX/verilog/src/simprims/ directory, one file for each module. They all contain timing information, which is what I'm after. So, I add -y%XILINX%/verilog/src/simprims/ to my iverilog command, and it generates no error. Then, I run vvp, and generate a VCD from my testbench. So far, so good. I open the VCD, but it seems like the timing information hasn't been simulated. For example, there is no delay between a clock event and a counter update, etc. The levels are all OK, states are the same as the pre-synthesis simulation, so I really have no clue of what's wrong. One thing I've noticed is that the SIMPRIMS modules all have a `timescale directive, the glbl.v file has a different one, and my testbench is again different... could it be that some timing gets rounded off ? Thanks for any info, Christian -- CSB [EMAIL PROTECTED] -- http://www.fastmail.fm - Email service worth paying for. Try it for free ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Icarus Verilog with Xilinx simprims...
On Mar 17, 2007, at 3:15 PM, CSB wrote: Hi all, I am trying to use Iverilog along with xilinx's SIMPRIMS. Well, I managed, but I am getting strange results with simulations. I'll try to explain how I'm doing this (I'm new to CPLDs, Verilog and Icarus...) First, I generate the post-fit verilog module from Xilinx ISE project navigator. This is the .v file containing all the nets and gates, for example X_AND2, etc... If I'm correct, those are defined in the *.v files of the XILINX/verilog/src/simprims/ directory, one file for each module. They all contain timing information, which is what I'm after. So, I add -y%XILINX%/verilog/src/simprims/ to my iverilog command, and it generates no error. Then, I run vvp, and generate a VCD from my testbench. So far, so good. I open the VCD, but it seems like the timing information hasn't been simulated. For example, there is no delay between a clock event and a counter update, etc. The levels are all OK, states are the same as the pre-synthesis simulation, so I really have no clue of what's wrong. One thing I've noticed is that the SIMPRIMS modules all have a `timescale directive, the glbl.v file has a different one, and my testbench is again different... could it be that some timing gets rounded off ? Thanks for any info, Christian Does iverilog support SDF backannotation? The SDF has the delay information. 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. -a ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Icarus Verilog with Xilinx simprims...
Andy Peters wrote: 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. Dr. Deming told us that the Asian focus on direction of most closely approaching perfection is a better goal than arbitrarily chosen accept/reject criteria American style. Perhaps he was thinking orientally? Anyway, that wasn't his question. He asked how to get the timing info into iverilog. John Griessen PS No specific knowledge of Xilinx, can't help, CSB. (If I'm correct, those are defined in the *.v files of the XILINX/verilog/src/simprims/ directory, one file for each module.) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Icarus Verilog with Xilinx simprims...
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. 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~) 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. Dr. Deming told us that the Asian focus on direction of most closely approaching perfection is a better goal than arbitrarily chosen accept/reject criteria American style. Perhaps he was thinking orientally? While I tend to agree with the oriental principle, I can't pretend to be looking for perfection for the moment. Functionality would be a good start ! Perfection can come later; I need to walk before I can run... Thanks for your time, Christian -- CSB [EMAIL PROTECTED] -- http://www.fastmail.fm - Same, same, but different ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
