Gate Level Synthesis: Signals

[Altera_Forum]

Hi, 

 I'm facing a mismatch between my design's functional simulation and the synthesized circuit, so I thought gate level simulation would be a good start! The difficulty that I'm facing is that due to synthesis, all the signals are either renamed, or removed due to optimization. Well, beside the ones that are removed, is there any way to refer to a bundle of renamed signals as if they were composing the original signal/vector? Like I have a 32 bit wide register, which is broken down in bits, lots of duplicates etc. Adding all into the waveform is quite a pain, also confusing which one is in which bit position! Any help is appreciated,  Thanks.

[Altera_Forum]

Unless you restrict synthesis, the signals found in gate level logic can't be expected to be identical to RTL. The only signals that surely survive are at the external pins. This should be sufficient to validate logic behaviour. But if you want to understand, why the behaviour is possibly different from RTL functional simulation, you may want to access internal signals. That's not so easy generally, but the equivalency of gate level and RTL is recognizable though, I think.

[Altera_Forum]

I find fewer and fewer designers doing gate-level simulations. Although it can catch design flaws, it is only a specific subset of flaws. (Gate-level sims were always done by ASIC designers because they were willing to sacrifice a LOT of time doing verification in order to avoid re-spins). 

Often I see users doing RTL sims(and spending a lot of time doing putting together a comprehensive testbench). Since RTL sims are often the fastest(no place and route), and quickly identify functional bugs, it's usually worth the effort. After that, rather than doing timing sims, they make sure their Static Timing Analysis is correct. The nice thing about STA is it puts bounds on your signals, i.e. it says a path will work as long as the delays are bounded by some range of values, i.e. a 100MHz clock generally has data delays that must be more than 0ns and less than 10ns, including clock skew. That's an easy example, but it can get more complicated, especially with I/O timing. Once a design passes STA, the timing simulation shouldn't reveal much more.  (Timing Simulations have a single delay value, like 7ns, where STA covers a range. Also gate sims don't flag errors except for micro setup and hold violations. For example, if the data delay were 13ns in your 100MHz domain, there would be no warning in the simulation that something was wrong, your data would just get there a clock later, and if that caused a functional problem you would see it later and have to back-track to figure it out.)  Finally, once RTL sims and STA are done, SignalTap and other in-system debug tools become crucial. They help identify anything you missed, anything you got wrong(like you may have incorrect I/O timing requirements), or anything you didn't cover in your original testbench. This is slower than RTL simulations, but is absolutely critical because it identifies real bugs, not just simulated bugs. It's being recommended more and more to prepare for this up-front. (E.g. populate a few boards with a larger device, when possible, so that you have more internal logic and RAM to run larger SignalTap runs...)

[Altera_Forum]

For me signal tap usage became less important with recent designs, since a) the speeds are too high to be able to sample, b) the number of clock domains increase thus errors appear elsewhere than expexted, and signal tap sampled c) Signal Tap usage modified the design strongly or made it even impossible to fit. 

 I more and more prefere a design technique, where test features are included in the full design, e.g. temporary results are stored into additional RAMs (therefore, using prototyping boards with larger divices is a good recommendation) or or forged to pipe lined output. These "trace logic" parts become a fixed part of the design and could later be used to trace errors of the complete system too, e.g. supporting the process optimization at the customer's plant ...  Refering to RTL Simulation : Since most of the deisgn somehow are check in a complete environment (when possible) a more or less complete test bench with models is present anyway. So there is not much worl to do to compile the *vho an invoke an over night simulation of some micro seconds of the design.  If necessary, I keep design parts switchable and bridgeable to shun large algorithmic sections in a design, which could cause the simulator to become too slow. So I am simulation the full design but can concentrate on clock boundaries, IO-sampling issues and such.  And yes, I allready found some misbehaviour in design, caused by wrong contraints or misunderstandings of delays in data sheets.

[Altera_Forum]

I agree with the commentary so far that gate-level sims are pretty painful and often not necessary. Did you do your functional simulation in Quartus II or did you simulate the HDL in Modelsim or some other third-party simulator? If you simulated with Quartus II, then there are two possibilities. 1) There's an actual synthesis bug in the software 2) Your design needs more timing constraints. Quartus II actually functionally simulates the initial netlist coming from elaboration but prior to any fancy optimizations and technology mapping. So it must be at least partially correct.  

 If you're starting with third-party functional sim of the HDL, then both possibilities apply again. I'd usually start by functionally simulating the design in Quartus II. If it passed, I'd look for timing problems first, then start pointing fingers at the software. Did you enable any crazy optimizations? As with software compiler optimizations, the scarier the hardware optimization, the more likely it's not 100% correct. I'd do a very vanilla compile on a couple different families and speed grades.   You can always add preserve attributes to important registered signals and keep attributes to important non-registered signals. These attributes should preserve those points in your design.   Well, good luck!

[Altera_Forum]

Good thread. Some more thoughts... 

 SignalTap should work at almost all speeds the fabric works at. Since it directly registers the signals you're tapping, and does so in parallel, it shouldn't be a bottleneck. (Figuring out triggers and what signals to tap and how they relate back to the design can take some time though...)  I tend to worry about synthesis issues(where the synthesized circuit doesn't behave as the RTL sim) as a very last resort, and something that should be picked up by in-circuit debugging. Not that there haven't been cases where synthesis is wrong, but they're so seldom that you'd be wasting a lot of time if you didn't trust RTL sims. More often than not, I've seen users complain that something "must be getting synthesized wrong", and when we final debug the issue, it was a problem in the original RTL, just a case that hadn't been simulated or fully understood(like crossing asynchronous clock domains...)

[Altera_Forum]

I agree that the difference most of the times originates from a design issue not synthesis. In my case in fact it was a cross domain issue, but I never considered it as the boundary was Avalon, so I though it should be fine. 

 I've asked this in another forum too, but haven't got any answer yet, thought maybe I can ask it here too. Well, instead of using SignalTap, I though I can store my trace data in a memory module (like SDRAM) and then look at it offline. But I couldn't find a tool to easily dump a memory module's data. Is there any?! Or a function included in the nios debugger?! Thanks,  Kaveh

[Altera_Forum]

Have a look at system console (http://nioswiki.jot.com/wikihome/systemconsole) (new with 8.0). It definitely offers what you need....and more. 

 Cheers,  - uraslacker

[Altera_Forum]

Thanks a lot, I'll look into that then, 

 Cheers,

[Altera_Forum]

--- Quote Start ---  But I couldn't find a tool to easily dump a memory module's data.   --- Quote End ---    I use a small "core" with a LAIC connected to a serial interface. I use pseudo-DS to get out of the fpga and connect to another aveal board with a differential OP input to access the ram. If you have a eval board with a large ram, you can also program retriggered shots or pipe line read out.  Thus it is mostly possible to interface to nearly all plants. I already had been able to install such a battery powered eval board into a plant, let it remotely aquire (no persons allowed during operation due to radio beam) and got it out of the plant after operation to read it out in my office. The was no other way to scan the bus behaviour-:p