# Timing warnings for functional model

I am writing a controller for a low power/mobile DDR module on my FPGA. To allow debugging, I use a functional model written in Verilog. In it, the setup and hold time for some signal is set to 1.5 ns. If I understand everything correctly, this means that the signal can not change 'within' 1.5 ns of a rising clock edge.

However, the RTL that I've written does not include timing, so the signal appears to change instantly, yielding hold time warnings.

On the one hand, I am not too concerned; I'm only getting warnings, and I think that during a project for my university, we were told to simply ignore these errors.

On the other, I don't like to ignore warnings. The manufacturer would not have implemented these warnings if they have no purpose. Since Xilinx ISE is able to check timing constraints, I feel like it should be possible to route and map my design, and use the generated timings somehow (but maybe I'm making things too simple here).

I'm sure there are more people with the same problem. What is the proper way to deal with these warnings?

Edit: On this page, I found some more information. You can generate a post-map or post-place-and-route simulation model. I suspect this includes the timings. However, it seems only modelsim can actually perform the simulation.

Clarification: Ideally, I would be able to synthesize (or at least get as far in the process of generating the layout as possible) my part of the design (I have the RTL and I have specified the board, so I think this should be possible), then combine it in a testbench with the functional model to test if my design has the proper timing delays. However, I can't make this work in Xilinx ISE 14.7.

As dave_59 pointed out, timing checks on RTL are not very meaningful. That said, here are 4 possible approaches:

1. Don't compile the timing checks with RTL
2. Use a compiler directive macro (ifdef ... endif) around your timing checks; timing checks disabled with RTL
3. Inject hold time into RTL behavior by changing all flop assignments (<=) to <= D, where D is a your delay (ex define D #2)
• Idea from NBA with Delays, by Cliff Cummings
• For synthesise define D as empty (aka `define D)
\$setuphold( D, CLK &&& actiming_enable, tSETUP, tHOLD);
• But if I have the RTL and know which FPGA I am going to map to (I can produce the bitstream), essentially the whole layout is known. Shouldn't I be able to generate the timings, since I have all the necessary information? – Ruben Aug 2 '16 at 19:29
• Synthesis is one of the steps to get that information. You could run simulation with synthesized gates with SDF annotation, but that is not an RTL simulation. RTL simulation is for validating logic. Verilog gate simulation is a sanity check for timing and logical-equivalence (there are dedicated tools for each that do a more comprehensive job than gate simulation) – Greg Aug 2 '16 at 20:28

Setup and hold timing checks only make sense with post-layout information. A century ago, you could do timing analysis without layout structural information because the the device delays were overwhelming compared to routing delays. You can no longer do accurate timing analysis with RTL code.

Some models are written to be used in both RTL and structural simulations, so you can ignore these warnings. Even better would be to turn of the timing checks which improves RTL simulation performance (maybe not relevant on your project, but that what people do in industry).

• This isn't really true. There are very accurate timing models generated all the time without final layout information. This is how MCU's are generated. Each block is timed independently and each I/O characterized in terms of setup/hold/delay/load/slew rates. Otherwise it would cost billions of dollars just to iterate on a chip. Since he is programming an FPGA, there must be some way to tell it to synthesize his RTL into a physical board mapping. From here R/C is very predictable in a proven FPGA technology. – jbord39 Jul 30 '16 at 16:13
• @jbord39 for larger/faster FPGAs, you can't get accurate timing for RTL because it is so heavily dependent on routing. The same design in one part of an FPGA can meet timing, but a slightly different routing/placement can lead to additional routing delay and failing timing - even if the RTL in both is identical. – Tom Carpenter Jul 30 '16 at 16:18
• @TomCarpenter: I didn't mean to imply otherwise, routing is going to drive delay as technologies get smaller. But the software should be able to do a trial placement from the RTL. From here it knows how far the wires will need to go, and the fanout of each gate (along w/ drive power). It should also be able to estimate the resistance/capacitance of each wire. Once it has a trial placement it should be able to accurately estimate almost all of the parameters. If the timing is bad, it can restart and place again. But there may be some reasons this is not possible that I'm not thinking of. – jbord39 Jul 30 '16 at 16:26
• @jbord39 R-C of each route isn't entirely useful. All of the routing switches (which are basically just SRAM) account for quite a lot. The timing models nowadays typically contain the delay for every segment of every path, and typical delays of every multiplexer so the total path delay can be calculated once you know the path. But doing a "trial placement" is pretty much no different from just doing a full design synthesis/fitting/routing and then doing the simulation with a post-fit netlist (rather than RTL). – Tom Carpenter Jul 30 '16 at 23:40
• @TomCarpenter: Well, trial placement and timing with estimated parasitics is much faster than full layout extraction (and is necessary to get you in the right ballpark most of the time). I mean, 5 minutes for a 500 gate trial place+route+timing compared to maybe 10 hours otherwise. Tools can handle delay changes due to switching noise too (signal integrity). Modern CPU's are not even timed all together. Each piece is characterized into some format (library) and these are timed at the top level using the libraries. Spice might be used on the lower level pieces but not the top level block. – jbord39 Aug 1 '16 at 16:13

There should be some way to input a timing delay.

This could be done a couple ways I can think of (maybe more):

• Modify the launching flip flop to have a clock->out delay which is greater than the hold time of the capture flip flop.
• Modify the flip flop model to have a -.1ns hold time.
• Modify any gate (like a buffer) to have a fixed delay of 1.6ns and put this before each capture flip flop.
• Shift the clock signal at the capture flip flop (second flop which experiences the hold violation) by at least 1.5ns relative to the launch clock (goes to first flip flop).

Most of these will involve modifying the representation of some gate or buffer to include a delay. If you are using .libs for the characterization, you could just set the entire load/slew/delay table to a default value of 2ns.

• How did you come up with these timings? Can I be sure they are accurate? I'd rather use an automated process that provides timing estimates for me (to make it harder for me to screw up). – Ruben Aug 1 '16 at 11:45
• @Ruben: It depends, you need to look at which model you are using to find out. But, since you are saying there is zero delay through logic gates, and a flat 1.5ns setup and hold time on the latches, I can tell you they are NOT accurate. Every logic gate should have a delay associated with it (flat delay at a minimum). More accurate delay models for PnR are characterized using a load/slope table. – jbord39 Aug 1 '16 at 16:09