Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20693 Discussions

Synchronous Design Timing (VHDL)

Altera_Forum
Honored Contributor II
1,570 Views

Hi All, 

 

I am very new to VHDL and working with hardware so I'm hoping this forum can fill in some of the giant holes in my knowledge. 

 

My current question relates to timing in synchronous designs: Let's say I'm working with a component (e.g. a FIFO) that uses the same clock as mine. If that component does everything on the rising edge of the clock, then when should I make changes to its inputs and read its output to ensure that I get the expected result.  

 

Specific Example: I want to use one of the FIFOs (SCFIFO/DCFIFO) provided by the MegaWizard. In order to perform a read operation, I need to assert the 'rdreq' line and then the next data in the queue will be made available on the FIFO's output lines. Those FIFOs work on the positive clock edge, so what is the proper timing for this? (i.e. when should I assert 'rdreq' and when do I read from the output lines) 

 

Should I: 

 

a). Assert 'rdreq' on the rising edge and read on the next rising edge? 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. 

 

b). Assert 'rdreq' on the falling edge and read the output lines on the next falling edge? 

 

c). ??? 

 

Sorry if this is a basic (or stupid) question. I'm hoping to find out what the 'best practice' in this scenario to ensure that I always get the proper result. 

 

Thanks!
0 Kudos
6 Replies
Altera_Forum
Honored Contributor II
669 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
669 Views

 

--- 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.
0 Kudos
Altera_Forum
Honored Contributor II
669 Views

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!
0 Kudos
Altera_Forum
Honored Contributor II
669 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
669 Views

 

--- 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.
0 Kudos
Altera_Forum
Honored Contributor II
669 Views

 

--- 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!
0 Kudos
Reply