2
\$\begingroup\$

I have designed an MMC slave on an FPGA that will interface with many different MMC masters with many different trace lengths, etc.

Most of the timing constraint documentation on how to constrain FPGAs involve needing to know the trace lengths, however, not knowing what they will be, how do I go about constraining the FPGA?

I have read a bit about constraining FPGAs in terms of system centric or FPGA centric, but with the FPGA centric the max. skew needs to be known. The MMC specification does not provide this information, only setup and holds.

enter image description here

\$\endgroup\$
10
  • \$\begingroup\$ Typically you have a connector and you care about matching timing specs at that connector, and the timing inside the system it's plugged into is the problem of whoever designed that system. \$\endgroup\$
    – user253751
    Aug 9, 2022 at 18:57
  • 1
    \$\begingroup\$ If your FPGA goes onto many different boards, then you can only guarantee the timing up to the FPGA pins, and you have to leave enough allowance for the board designer to get it right. \$\endgroup\$
    – user253751
    Aug 9, 2022 at 19:08
  • \$\begingroup\$ I read that if the system outside the FPGA is unknown then it is possible to use the skew to set the max input delay and min input delay, however, without skew given I'm not sure how to go about properly constraining the system. What I am thinking is that I'll just have to use the trace lengths from the FPGA to the connector, the setup and hold times specified, to calculate the max/min input and output delays. \$\endgroup\$
    – huskerwr38
    Aug 9, 2022 at 23:37
  • 1
    \$\begingroup\$ Regarding trace delays, you are the one who decides it to a sane value. You would say something like "I expect trace delay to be [xmin xmax] so that the timing is satisfied in this path, I would expect PCB designer to meet this requirement while routing" \$\endgroup\$
    – Mitu Raj
    Aug 10, 2022 at 7:18
  • 1
    \$\begingroup\$ @MituRaj Yes I'm sampling the data with the clock (writing it to a asynchronous fifo). The clock frequency is max 52MHz. \$\endgroup\$
    – huskerwr38
    Aug 11, 2022 at 15:47

1 Answer 1

2
\$\begingroup\$

Source-synchronous signals {clock, data} have to be routed with minimal line-to-line skew. You can specify a window on allowed skew variation between these two traces and prove the timing on FPGA. Adhering to this specified timing window would be the board designer's job. Constraining source synchronous interface can get complex and confusing as there are different approaches to it. Since you are working at SDR (Single Data Rate) at very slow clock of around 50 MHz, you can ignore the impact of the minimal difference in trace delays to make constraints simpler. I have used FPGA-centric approach as that's what you are interested in.

To constrain the input source-synchronous interface at FPGA:

You have to first create and constrain the \$52 \text{ MHz}\$ clock at input port clk_in:

set clk_period 19.20
create_clock -name clk_in -period $clk_period [get_ports clk_in]

If you check the waveform in the datasheet, data comes out centre-aligned with the next clock edge (second edge, not the launching edge) from the source. Assuming the alignment is maintained at the FPGA input, you can capture the data on the second edge of the source clock. In that case, setup \$t_{OSU}\$ and hold \$t_{OH}\$ times given in the datasheet can be used model the requirement at FPGA side.

enter image description here

Add some margin on setup and hold timing to allow some amount of skew difference on data line and narrower eye width (data valid window). I have added a margin of \$5\%\$.

#  External circuit parameters
set todly 13.70 
set tosu  [expr $clk_period - $todly]
set toh   2.50

# Setup Hold requirement
set tsu [expr $tosu - 1.00]
set th  [expr $toh  - 1.00] 

# Max Min delay constraints
set_input_delay -max [expr $clk_period - $tsu] -clock [get_clocks clk_in] [get_ports data_in]
set_input_delay -min $th -clock [get_clocks clk_in] [get_ports data_in]

Similarly to constrain the output source-synchronous interface at FPGA:

You have to first create and constrain a \$52 \text{ MHz}\$ generated clock at output port clk_out:

create_generated_clock -name clk_out -divide_by 1 -source [get_pins <source_pin>] [get_ports clk_out]

The setup \$t_{ISU}\$ and hold \$t_{IH}\$ times in the datasheet can be used to model the requirement at FPGA side, and generate data as center aligned to next clock edge (sampling clock edge at the destination chip). Add some margin on setup and hold timing to allow some amount of skew difference on data line and larger eye width (data valid window). I have added a margin of \$5\%\$.

#  External circuit parameters    
set tisu  3.00
set tih   3.00

# Setup Hold requirement
set tsu [expr $tisu + 1.00]
set th  [expr $tih  + 1.00] 

# Max Min delay constraints
set_output_delay -max $tsu -clock [get_clocks clk_out] [get_ports data_out]
set_output_delay -min -$th -clock [get_clocks clk_out] [get_ports data_out]
\$\endgroup\$
4
  • \$\begingroup\$ How about output delay constraints since it is bi-directional? I have: Output max delay = max trace delay for data+ tSU - minimum trace delay for clock and for Output min delay = min trace delay for data - tH - max trace delay for clock \$\endgroup\$
    – huskerwr38
    Aug 13, 2022 at 17:42
  • \$\begingroup\$ Yep, that's right. See the updated answer. @huskerwr38 \$\endgroup\$
    – Mitu Raj
    Aug 13, 2022 at 20:54
  • 1
    \$\begingroup\$ This really helped, thank you! \$\endgroup\$
    – huskerwr38
    Aug 15, 2022 at 16:37
  • \$\begingroup\$ No probs. You can mark the answer as solution, if it solved your problem. @huskerwr38 \$\endgroup\$
    – Mitu Raj
    Aug 15, 2022 at 17:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.