02-19-2010 01:02 AM - edited 02-19-2010 01:31 AM
I have seen that netgen offers an option to introduce path pulse buffers when generating vhd-files for simulation.
I was just wondering, if a simulation is more realistic if pp_buffers are actived or deactivated.
The documentation says that pp_buffers are filtering very short glitches.
Does this mean that when no pp_buffers are used, even the shortest glitches are propagated through the design? This would not be very realistic and would introduce more activity than there is in reality, I suppose.
The documentation says:
The –insert_pp_buffers option controls whether path pulse buffers are inserted into the
output netlist to eliminate pulse swallowing. Pulse swallowing is seen on signals in backannotated
timing simulations when the pulse width is shorter than the delay on the input
port of the component. For example, if a clock of period 5 ns (2.5 ns high/2.5 ns low) is
propagated through a buffer, but in the SDF, the PORT or IOPATH delay for the input port
of that buffer is greater than 2.5 ns, the output will be unchanged in the waveform window
(e.g., if the output was "X" at the start of simulation, it will remain at "X").
Does that mean that the primitives of the FPGA are treated with transport delay, when the option is false and as inertial delay when the option is set to true?
What is the option, which is recommended for a realistic low-level simulation?
Thanks for helpful information.
02-19-2010 10:38 AM
The correct behavior is with -insert_pp_buffers true. This is what is needed to avoid pulse swallowing.
We have changed the default to be true in the 11.x release and the reason why we have this option is in case you see unexpected behavior and you need a WA. Any time you need to turn this off, there is a bug and a case must be opened with Xilinx Tech Support.
02-23-2010 02:51 AM
thank you for your answer. It is very nice, that the Xilinx tools have so many options for the user.
When I read you answer I ran into another questions:
If I use the insert_pp_buffers=true option there are some signals in the resulting vcd-file which are named e.g. nlwbuffersignal_X_X_obuf_i.
Are these signals just there for the simulation or are they also existing when the design is on the FPGA. I am asking because I want to know how many active signals are in a design.
02-23-2010 08:53 AM
This is a very good question. The way in which we solve the pulse swalllowing issue is to insert these additional buffers to annotate some of the route delays. In this case, you will get extra buffers then what is actually going to be on the FPGA.
In general netgen may put additional buffers to make simulation work and so this is not always going to be 1 to 1 mapping for the number of buffers in your HW. Although I dont think this should impact the number of active signals. The number of active signals in netgen output and the FPGA HW should be the same.
03-01-2010 12:08 AM
thanks again for your answer. I just want to explain my problem with a small example.
I place a registerless component (a 2-bit adder for example) between two registers (in vhdl). Now I use netgen to create the time_sim.vhd of this design. I have a look at this structural low-level vhdl-file and I search for the adder component. It contains two lookup-tables (not all inputs of those LUTs are used). When I set insert_pp_buffers to true five additional nlw_buffersignal-components (one for each LUT-input which is used) are added to the structural description. Since this structural component is placed between two registers, it does not have a direct connection to the real IOBs of the FPGA. But maybe some buffers are used to drive the LUT.
Since I want to count how many signals my component has, it is important for me whether these introduced buffers are on the FPGA or not. I declare a signal as a small connection (wire) between two components. So: If there is a buffer before the LUT, there is a signal from the input to the buffer and from the buffer to the LUT. If there is no buffer, this should be counted only once.
I hope that my description is not too hard to understand.