Forum Discussion

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

Modeling constraints for asynchronous outputs in TimeQuest

Hello everyone.

I'm a beginner when it comes to TimeQuest, but I did go through the online course, read the corresponding Quartus cookbook chapter and a few Altera resource pages... unfortunately, I never found an example similar to what I need to do. I either can't figure it out or I'm simply looking at it the wrong way!

Essentially, my Nios communicates with an ethernet controller (LAN91C111) asynchronously (all my outputs are registered by a 54MHz clock, but the controller itself uses an asynchronous protocol). In its datasheet, there are several timing conditions I must uphold. For example, my data lines (let's call them DATA) must be active at least 2ns before my "read" (let's call it RD) line is asserted.

Now, if the controller used its own clock to get the signals, I'd create a virtual clock representing it and start constraining from there... but since it works asynchronously, I have no idea how to do it! How do I tell TimeQuest "Hey, do whatever you want, but make sure DATA arrives at the FPGA output ports least 2ns before RD does" ?

It seems Altera has made an extension to the set_output_delay command by adding the -reference_pin clause, but I've only found one small example using it and I'm not sure that's what I need.

Thanks!

2 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Synchronous generally means a clock, but it can also be thought of as a repeated relationship. So in your case, put a generated clock on RD, where the -source is whatever clock feeds it. To say that the same edge sending the data is capturing it based on RD, do a "set_multicycle_path -setup 0 -to [get_clocks RD_CLK]" where RD_CLK is the name of the generated clock you applied to RD.

    You basically said the same edge sending your edge is latching it, i.e. it's a 0ns setup relationship. So if your DATA delay is 1ps before the RD output, you'll make timing. So do a "set_outptu_delay -clock RD_CLK -max 2.0 [get_ports DATA*]" and you've made an external data delay of 2ns, so now DATA has to leave 2ns before RD_CLK.

    Of course, that all assumes the same clock drives data off RD as drives DATA. Your other option, which is probably better, is to have another output of the PLL drive RD, and phase-shift it by ~2.5ns, i.e. enough that if the delays are all matched it will meet timing. In this case, your default setup relationship is 2.5ns, so you don't need the multicycle. The set_output_delay requirement is the same though.

    Hope that helps.