Synchronous Design Timing (VHDL)

Implement your logic to operate on the rising-edge of the clock.

The FIFO Megafunction guide comes with some examples.

Learn how to use the Modelsim simulator, and write a testbench to test your logic. If you are not sure how to write a testbench. Explain to me what you want to do with the FIFO. I have some FIFO testbenches that I can modify to show you how they work.

This testbench would be used with Modelsim, and would be in VHDL, so you can use the Altera-Edition. Download it and go through the Modelsim tutorials if you have never used it before.

Cheers,

Dave

--- Quote Start ---

a). Assert 'rdreq' on the rising edge and read on the next rising edge?

--- Quote End ---

Yes.

--- Quote Start ---

If we're both working on the rising edge, am I guaranteed that my signal changes will be in effect when the FIFO processes its input? I'm worried about timing/delays.

--- Quote End ---

Short answer: Yes.

Slightly longer answer:

You need to set proper timing constraints. Ie, set the clock's period. Take a look at TimeQuest's user guide.

If you set you timing constraints properly, the tools will take care of all the delays within the FPGA and try (very hard) to ensure that the timings are met while syntethizing your VHDL/Verilog code.

If they aren't able to, the tools will tell you that timing constraints were not met.

Thanks a bunch for the responses. I had some time to play around with ModelSim and the DCFIFO and I've noticed that there's a one cycle delay from when the simulator wave shows a change in the signal and when my component can see that change.

Example as seen from ModelSim:

-After adding a byte to the FIFO, 'fifo_e' goes to '0' (i.e. no longer empty)

-One cycle later my VHDL code sees that change and sets 'rdreq' to '1'.

-One cycle later DCFIFO sees my request and outputs the next word.

-One cycle later that word is now finally visible to my VHDL piece.

So it seems that after I assert 'rdreq', I need to wait two cycles before reading from the FIFO's data out.

Does that sound correct? So: "Changes made to a signal on the rising edge by component A aren't noticed until the next rising edge of component B".

That makes sense to me at least (as it avoids the race condition thoughts that pop into my head). I haven't had a chance to look at the TimeQuest stuff yet, so if I'm way off in the above statements, then that might clear everything up.

Thanks again!

Now that you have had a play with the components, go back and read the FIFO megacore users guide.

There are two FIFO read-modes; legacy mode and show-ahead mode. In legacy mode, rdreq acts as a read-request, with data changing in the clock after its asserted. In show-ahead mode, the signal is a read-acknowledge.

Try both modes so that you can understand the slight difference in timing of the data at the FIFO output.

Cheers,

Dave

--- Quote Start ---

Thanks a bunch for the responses. I had some time to play around with ModelSim and the DCFIFO and I've noticed that there's a one cycle delay from when the simulator wave shows a change in the signal and when my component can see that change.

Example as seen from ModelSim:

-After adding a byte to the FIFO, 'fifo_e' goes to '0' (i.e. no longer empty)

-One cycle later my VHDL code sees that change and sets 'rdreq' to '1'.

-One cycle later DCFIFO sees my request and outputs the next word.

-One cycle later that word is now finally visible to my VHDL piece.

So it seems that after I assert 'rdreq', I need to wait two cycles before reading from the FIFO's data out.

Does that sound correct? So: "Changes made to a signal on the rising edge by component A aren't noticed until the next rising edge of component B".

That makes sense to me at least (as it avoids the race condition thoughts that pop into my head). I haven't had a chance to look at the TimeQuest stuff yet, so if I'm way off in the above statements, then that might clear everything up.

Thanks again!

--- Quote End ---

What you describe sounds like normal operation. Be careful when looking at timing diagrams in modelsim. If it is a functional simulation, you wont see any setup time - I get the feeling you're thinking that because you're seeing rdreq rise at the same time as the clock, it should be seen elsewhere sooner. You have to remember that on real hardware it takes some time after a clock to set up a value. Here are the two diagrams I think you are seeing - is the first one what you see in modelsim?

clock ____----____----____----
          |       |
rdreq ____--------____________
REALITY:
clock ____----____----____----
          |       |
rdreq ______--------____________
          

In modelsim, everything will happen as if it is setup in the second diagram, even though it looks like the first.

--- Quote Start ---

Here are the two diagrams I think you are seeing - is the first one what you see in modelsim?

--- Quote End ---

Yes, in ModelSim everything looks instantaneous, but you're right that it's behaving as if it's not (like your 2nd picture) - which is good!

Thanks!