process timing on FPGA

Question

I'm new to fpgas, and there are some timing subtleties that I'm not sure I understand: if all my synchronous processes are triggered on the same edge, then that means my inputs are 'captured' on one rising edge, and my outputs change on.. the same edge? the next rising edge?

if I have two modules, where the output of one flows into the inputs of the next, there could arise the situation where the inputs to my module (the outputs of a previous module) are changing at the same time as they are captured.

The marker at 205ns shows what I'm talking about, op and data_write being my inputs. Everything seems to "just work" in this test case, but in the simulation it's not clear exactly what is being captured when. Is the data_write="0001..." being captured at 205ns or (205ns + 1 clock cycle)? Is there a way to get more detailed waveforms in ISim that show setup and hold times?

Thanks.

Answer 1

There's always some propagation delay through the flip-flop. It's often called "clock-to-Q" delay.

That means your inputs are captured on the edge, and you outputs change on the same edge, but just a few nanoseconds later. This few nanoseconds delay is enough (if your flip-flops are designed with "zero hold time" as they are in most FPGAs) that the changes don't affect any downstream flip-flops until the next clock edge.

In functional or RTL simulation (which is probably what you're doing to generate your result) the delay won't be simulated as lasting nanoseconds. In VHDL, it will be a single delta cycle of the simulator clock, which is technically no time at all. This makes it impossible to see the delay in the simulator output. Nonetheless for the simulated-as-ideal flip-flops, it is enough that the output changes don't affect downstream flip-flops.

If you do post-place-and-route simulation, it should be able to include appropriate delays so you see these effects clearly, at the cost of increased simulation effort.

Answer 2

At the desired clock edge (rising or falling) the input at D appears at output Q. This takes a finite amount of time (Clock to Q delay) and assuming there are no timing violations, D will only pass through one FF at a time (i.e if there is another FFs input connected to Q, the second FF will pass the FF1 Q value before it changes.

To include timings in your simulation, you need to synthesize and place and route your design, then run a post place and route simulation. This will have all the combinational, clock to Q delays, etc included. The HDL simulation does not have any of these timings, so it's only useful for testing basic operation, not timing limits. You will also get a timing report, which will tell you the speed limits of a particular clock domain, let you know if there are any timing violations, and show you the timing slack for various paths. You can use this info to figure out where chnages may need to be made, or rules added to tell the software the violation is not a problem (e.g. for things like multi-cycle paths or cross clock paths)

Answer 3

This is meant as an addition to the previous answers, from whcih I believe you get the idea.

These matters can indeed be a bit tricky in the beginning when simulation RTL designs since one can find it difficult to see what is the cause and what is the effect in ideal/functional/RTL simulations (=no propagation delays).

With the right simulator, the delta delays can actually be visualised. ISim doesn't it do it, but in e.i. ModelSim, you can enable delta expansion around the clock edges. Below is an example screenshot from a buggy 3rd-party IP that I trouble-shooted.

c is the clock signal, and the +1 etc. are the delta cycles, visualized as time.

If a design is simulated where both the simulation and the design is truly ideal and synchronous, with no delays simulated, you can, in principle, view all signal changes on a specific clock flank as happening slightly after that clock flank. In your example, therefore, at 205 ns, data_write = 0000... is what is being captured. Some other logic in the first unit is changing the signal data_write to 0001... on the same flank, and that signal appears on data_write slightly after the clock flank. This "slightly after" would be one or several simulation deltas in an ideal simulation (your example) (not visible in ISim, but in e.g. ModelSim with delta expansion), or some ps/ns later in the real world.

On a side note: One important thing with RTL design is to make sure that inputs are always sampled on the clock flank - even one delta cycle later is too late. The input might not be valid one delta later. Or in other words: "don't mess with the clock path".