Forum Discussion

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

Async IO Constraints

Hello, I need some guidance in figuring out how to specify my IO constraints.

I have a CPU mapping the FPGA as a memory device. The CPU provides these signals:

address - CPU --> FPGA

read - CPU --> FPGA

write - CPU --> FPGA

data - Bidirectional CPU <--> FPGA

My complication is that I did not route the 100MHz CPU clock to the FPGA, so I use a 200MHz FPGA clock to over-sample and CDC the CPU signals. The immediate issue I have is that when the FPGA is driving data out, data arrives late at the CPU -- I can also confirm that in signaltap.

I am getting stuck in figuring out how to define the virtual clock (100MHz) and how that relates to the FPGA clock (200MHz)

Thank you so much!

8 Replies

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

    I'd say there is no relation between those two clocks, unless they happen to be derived from the same oscillator.

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

    I agree. One thought I had was to create a 200MHz virtual clock and use that for my constraints. To account for the lack of sync, I could pad the values by 5ns - worst case of a 200MHz sampling miss. Does this make sense?

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

    If the two clocks are in effect unrelated, i.e. each one has its own oscillator, there is no way out. Except increasing the FPGA clock until the CDC circuitry and the RAM block return data in time. How fast are the CPU signals?

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

    The CPU clock is 100MHz. this is why I am using a 200MHz clk to sample the signals.

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

    --- Quote Start ---

    The CPU clock is 100MHz. this is why I am using a 200MHz clk to sample the signals.

    --- Quote End ---

    I should have been more precise: what is the width of the read pulse and how much is the setup time required for read data by the CPU? A timing diagram will help even better.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Here is the read waveform with the timing included.

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

    With these timings your approach of CDC with 200 MHz should work. You would need 4 clocks before the data gets output from internal ram (5 if you register that output). It should be possible to meet the set-up requirement. The output delay from RAM to pin may be a bit too high, so you may have to crank that clock up a little.

    But as there is no relation between the 100 MHz CPU clock and the 200 MHz FPGA clock you cannot define an SDC constraint for this. So you would have to verify the 'correctness by design and inspection'.

    I would be pleased to find someone learn us how this can be expressed in SDC-constraints.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    what you said seems to work. here is what I did - i don't know if it is right though.

    - create virtual_cpu_clk of 200MHz with 0 shift from the FPGA 200MHz clk used for sampling.

    - set_output_delay -clock virtual_cpu_clk -max 12.6 [get_port cpu_data

    [*]]

    - set_output_delay -clock virtual_cpu_clk -min -7.2 [get_port cpu_data

    [*]]

    - set multi-cycle of 4

    this seems to improve the propagation delay within the FPGA and makes things work. I do output the data 4 cycles before it is needed. I did not add any board delays since they are not significant here. I still wonder if I should pad the numbers with 5 ns, so that the 12.6 become 17.6. This should account for worst case.

    I too did search for anything that comes close to explaining how this could be constrained to no avail.

    thanks for the help so far - it is helping.