Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
16 years ago

Second opinion on timequest constraints

Hi,

I was constraining an interface between a stratix II device and a digital to analog converter. Trying to close timing gave me quite a few problems. I now have a timing report free of warnings and I wanted to give a brief outline of what I have done and perhaps someone can comment and tell me if I am on the right track (as I have done one or 2 things which I hadn´t tried before).

Basically a clock from the DAC of 150MHz enters the FPGA, this clock is used to clock the rdclk pin of a DCFIFO, so the idea is that on every rising edge a new word will be clocked out to the parallel data bus of the DAC from the FIFO.

The DAC can be configured to latch the data on either the rising or falling edge of this same clock, I have elected to use the falling edge in order to give me some extra time.

To constrain the interface, I defined a virtual clock of the same frequency as the main clock coming from the DAC but inverted due to the fact that the DAC will latch the data on the bus on the falling edge.

create_clock -name {DAC_PLLLOCK} -period 6.666 -waveform { 0.000 3.333 } [get_ports {DAC_PLLLOCK}]

create_clock -name {PLLLOCK_Virtual} -period 6.666 -waveform { 3.333 6.666 }

The DAC data bus requires a setup time of 0.5ns and a hold time of 1.5ns, therefore I put in place the following set_output_delay constraints:

set_output_delay -clock { PLLLOCK_Virtual } -max 0.5 [get_ports {DAC_D*}]

set_output_delay -clock { PLLLOCK_Virtual } -min 1.5 [get_ports {DAC_D*}]

After running a timing report, on the slow model setup failed by around 6ns so I figured this was due to the fact that I was reading the data from the FIFO and placing it on the databus on the rising edge while timequest assumed that the DAC would latch it on the falling edge 3.3ns later. To overcome this I set a multicycle path between the 2 clocks as follows:

set_multicycle_path -from [get_clocks {DAC_PLLLOCK}] -to [get_clocks {PLLLOCK_Virtual}] -setup -start 2

Now after running the timing anaylsis I meet timing just about.

I would be very grateful if someone could let me know if I am on the right track with how I have constrained this interface? Is the placing of the multicycle the correct thing to do? or does it have an adverse affect that I have failed to see? Is it ok to do it with a virtual clock?

Please let me know of any other oversights on my part in constraining this interface that you may think of.

Many thanks once again for any suggestions

14 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    You've got a 10ns and 13.333ns period clock. TimeQuest will try to go with the tightest constraint of 3.333ns. Personally I think that is good, and would limit all transfers to be register to register, so that it can easily meet timing. This nicely transfers the whole bus with everything arriving on the same edge. The problem, and this occurs with any solution, is you can't transfer data at the full clock rate, since it's either too fast or too slow than the other clock rate.

    If you add a multicycle, you're now potentially passing through multiple edges. You need to know if/when this occurs, and handle it properly. It can get complex quickly. It's definitely do-able, but you need to really plan it out correctly and account for all possible transfers. (And it's hard to say how it will work up front without knowing the data rates, which way you're talking, etc.) But the fact that the clocks are "semi-synchronous" can defeinitely be used to your advantage.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Thanks again, Rysc, for your clear explanation. I looked again at the example I mentioned - a project I inherited. The designer used

    set_multicycle_path -setup -start -from [get_clocks clk_a] -to [get_clocks get_clocks clk_b] 2

    set_multicycle_path -hold -start -from [get_clocks clk_a] -to [get_clocks get_clocks clk_b] 2

    I did could not figure it out at the time, and worked around it with handshaking instead. Perhaps you see some sense it which I could not.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Run report_timing with -setup and -hold between the two clocks to see what the setup and hold requirements are with these multicycles. Naturally, this is what the original designer wanted the paths to be analyzed at. The difficult question is if the design actually behaves this way.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I will explore that again for the sake of the learning curve. In the mean time the handshaking scheme is working fine, though. You've been very helpful, thanks.