Quick question regarding post PAR simulation. What can be done to retain sensible signal names when doing post place-and-route (timing) simulation in ModelSim?
Behavioural simulation retains the nice hierarchical structure of all instances and their respective signal names, and I would like to find out whether this is possible for timing simulation, or what is the closest setup that can be achieved. I have "Retain Hierarchy" selected under the Simulation Model Properties, and my Simulation Model Target is ModelSimXE (VHDL). Am using Xilinx ISE 7.1 (SP2) and MXE6.0.
It ain't ModelSim's fault. The simulator is simulating the signal names it found in the code it was given. Synthesis typically builds lots of new signals, changes the names of things, optimises things away and so forth. Sometimes you can control some of this. Most times, most of it will change :-)
It hardly "retains" it - as I said, the simulator simulates what it's given. In the case of behavioural (pre-synthesis) simulation, what it's given is exactly your source code.
Now I'm a little out of my depth, as I don't know ISE all that well. It sounds as though you are doing all the sensible things.
Sometimes you can set "don't touch" or similar attributes on objects such as registers.
Note that synthesis usually flattens all VHDL structures to either single bit std_logics or to one-dimensional std_logic_vectors, so if you've used any records or two-dimensional arrays then their names will almost certainly disappear. Also, if you have made any parameterised entities using VHDL generics, the actual instances after synthesis will probably have component names that are in some way decorated with the actual values of the generic - so, for example,
MyInstance : MyComponent generic map (N=>5) port map...
might appear after synthesis as an instance of a component called "MyComponent_5" or suchlike.
Sorry to be so unhelpful, but it's a problem! I guess some ISE experts will chime in to give you some more specific suggestions.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services
Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
It looks like there is no nice way of doing this - although ChipScope is capable or relating the PAR'ed netlist to originally defined signal names in the behavioural model - so I was hoping a similar capability would be available for timing simulation.
One way that I can see might be to connect all signals of interest to a port on the top level entity as the port names are retained after synthesis and PAR. One could then simulate and view the ports, but this would introduce additional routing delay and I/O buffer delay - I'd like to hear your thoughts on this. The I/O buffer delay would be the same for all signals (a constant delay offset if you like) so the only unknown would be the routing delay.
Do you think this is sensible?
What magnitude of delay (range) would be typically introduced? I guess there would be a min and max value corresponding to the port being placed at an I/O site close to the source component and at the furthest possible site, respectively.
I have a design where the highest clock speed is 100 MHz, and I'd like to know if the above approach would give useful results for debugging glitches and timing violations.
-- Kind regards and thanks again for your insight.
This wouldn't be a reasonable way to find most timing violations. Remember that the routing has a very significant variation between two routes of almost the same design. The only way to be reasonably sure that timing will be correct on the next route of the design is to have constraints that check all paths. For a design with a single clock, that means Period, Setup to clock for all inputs and inouts, Clock to output for all outputs and inouts. There should be no gated clocks, and nothing other than the clock should be connected to the clock input of FFs or RAM. There should be no asynchronous resets or presets. When needing multiple clocks, it gets harder.
How many clocks do you have?
Do you have full static timing constraints?
Timing simulation is useful for only when reasonably sure isn't good enough. I've found exactly two real problems in the past decade of doing FPGA designs by doing timing simulations. One of them was a problem in the tools, and the other was my mistake. I know the tools have gotten better, and I hope that I have as well.
-- Phil Hays Phil-hays at posting domain (- .net + .com) should work for email
I have about a dozen clocks, and I do have non-clock signals connected to clk inputs of FFs (not RAM), and only one asynchronous reset which is not part of the problem which I'm trying to resolve. I'm very confident my gated clocks are not a cause of the problem - they are not part of the datapath where I'm seeing glitches.
I do have muxed clock using a bit-MUX (not using a BUFGMUX), but chipscope is telling me the events around the mux'ed clock are fine. Specifically, the mux'ed clock is used to control the input and output of a shift register - across two clock domains (synchronous but of different frequencies). The shift register feeds the coefficient input (LD_DIN) port of the DA FIR v9.0 core, and I need to load it at a slower rate than the filter core clock frequency. I'm trying to determine the cause of the glitches on the FIR output - I'm loading a new set of coefficients every few output samples.
I do not have full static timing constraints - only two clock period constraints on my highest frequency clocks (both approx. 100 MHz). The FIR runs at 100 MHz, with 8 clock cycles per output sample.
Where would you suggest to include static timing constraints? Any hints in this area would be greatly appreciated.
Using the ISE 7.1i tools, you can preserve any hierarchy in the design and all associated port names around it for timing simulation and other verification by specifying the KEEP_HIERARCHY attribute for each instance in the design you wish to retain. The reason for this mechanism is that when you retain hierarchy for verification purposes, it can limit the optimization the tools can do for both area and timing around these boundaries and thus you should only keep the hierarchy which you need for verification, not necessarily all hierarchy in the design. Since you say you are using VHDL, the way to do this is to add to your VHDL code that is instantiating the hierarchies you wish to retain two lines in the architecture before the begin statement that look like:
attribute KEEP_HIERARCHY : string; attribute KEEP_HIERARCHY of : label is "TRUE";
When you do this, you are telling the synthesis tool (XST) and the ISE tools to preserve that hierarchy and you should be able to see it and the associated port names in the timing simulation. You can also instruct ISE to write out each hierarchy in a different file using the
-mhf switch (Generate Multiple Files) and you can simulate just that sub-level of hierarchy if you choose.
More info on this can be found in the Synthesis and Verification design Guide:
I'm going to guess that the wrong coefficients are loaded sometimes because of the clock domain crossing. It will probably take you a while to show that this is what is happening, and where and when, or if this guess is wrong, to find out exactly what is happening.
If this guess is correct, rather than muxing the clock, I'd suggest using a clock enable for the slower clock domain, so you can run both using the same (faster) clock. Make the clock enable pulse high for exactly one faster clock period at the rate of the slower clock. With all the logic on this path on one low skew clock net, this path should work much better.
To make sure the design works, not just once on the bench, but for every part at every temperature and voltage, even after design changes, you need full static timing constraints.
This is what I would do. Open up a shell (command window) where the .ncd file is generated. Type the following command:
trce -v 100 -u 1000 {your_file.ncd}
Then look at the report file is generated by this command: {your_file.twr}
There will be groups of unconstrained signals in the report. Most of these are realistic paths that will need constraints. I suspect that there will be a lot of constraints needed. I would add these constraints to the user constraint file, {your_file.ucf}, along with comments that explain the path, and outline the calculation of the numbers chosen.
-- Phil Hays Phil-hays at comcast.com (remove com and add net) should work for email
I'll definitely get rid of the clock mux and see what happens to the output. I've tested the re-loading of coefficients by applying an unit pulse input and could see that the filter output (impulse response) was as expected, ie. out came the coefficient set which was loaded in. So I'd clearly expect the loading of coefficients to be identical under conditions where the input was a sine wave, but something is clearly wrong somewhere. So I'm willing to resort to re-designing using good techniques, and clearly clock muxing is not one of them, even if chipscope seems to be telling me that things are ok. If this fails then I will look at the constraints issues.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.