Constraning an asynchronous design

[shaiko]

Hello,

Consider the following design:

FPGA #1 is connected to FPGA #2 via a synchronous (SPI like) bus. FPGA #1 is the master - therefore it's the SCLK and MOSI generator, and FPGA #2 is the MISO generator.
MOSI and MISO data is propagated on the rising edge of the SCLK and sampled on the falling.

The master's system clock (FPGA #1) is 240MHz and it's used to generate a 40MHz SCLK by means of counter division.

FPGA #2 also has a 240MHz system clock. which is used to sample the incoming 40MHz SCLK.
The falling edge of the SCLK is detected, and used to sample the incoming MOSI data.
Similarly, the master samples the MISO.

My thoughts: MOSI and SCLK are asynchronous to FGPA #2 while MISO is asynchronous to FPGA #1.

Questions:
What SDC constraints will you write for FPGA #1 ?
What SDC constraints will you write for FPGA #2 ?

 

[ads-ee]

The SPI interface as describe is not a synchronous interface, so don't even think of it that way, just consider it to be asynchronous and treat the signals that come from one FPGA and go to the other as asynchronous (i.e. you run it through 2 FFs before looking at the output of the second FF).

I would put simple set_max_delay constraints on SCK-MOSI to syncFF and on MISO to syncFF for FPGA #2 and FPGA #1 respectively. If you ensure the first sync FF is in the I/O then you won't even need the set_max_delay (except to verify the tools didn't inadvertently put them in the fabric FFs)

 

[shaiko]

I would put simple set_max_delay constraints on SCK-MOSI to syncFF and on MISO to syncFF for FPGA #2 and FPGA #1 respectively.

By SCK-MOSI and MISO you mean the FPGA pins and by syncFF you mean the first DFF in the chain?

 

[ads-ee]

By SCK-MOSI and MISO you mean the FPGA pins and by syncFF you mean the first DFF in the chain?

Yes, that's exactly what I meant.

 

[vGoodtimes]

Sampling MISO on the falling edge of SCK may not be viable in this design. The synchronizer may cut into the turn-around time significantly. It looks like MISO could be transitioning at/after the falling edge of SCK, under certain assumptions on output registers and round-trip delays.

 

[shaiko]

The SPI interface as describe is not a synchronous interface, so don't even think of it that way, just consider it to be asynchronous and treat the signals that come from one FPGA and go to the other as asynchronous (i.e. you run it through 2 FFs before looking at the output of the second FF).

I would put simple set_max_delay constraints on SCK-MOSI to syncFF and on MISO to syncFF for FPGA #2 and FPGA #1 respectively. If you ensure the first sync FF is in the I/O then you won't even need the set_max_delay (except to verify the tools didn't inadvertently put them in the fabric FFs)

ads-ee,
What about the outputs ?

Wouldn't you want to ensure that FPGA #1 has as little delay possible between the rising edge of SCLK and the propagation of MOSI ?

Wouldn't you want to ensure that FPGA #2 has as little delay possible between a rise detection of SCLK and the propagation of MISO ?

Sampling MISO on the falling edge of SCK may not be viable in this design. The synchronizer may cut into the turn-around time significantly. It looks like MISO could be transitioning at/after the falling edge of SCK, under certain assumptions on output registers and round-trip delays.

vGoodtimes,
This is very true - and in the "real" design the master makes things safer by sampling as late as possible (just before it issues the next rising edge.
While posting - I wanted to keep things simple and adhered to a normal SPI working mode.

I want the focus to be on design constrains.
So lets assume the master MUST sample on the falling edge - this makes timing closure more challenging (which is good for the sake of learning).

 

[FvM]

Round trip delay is a valid point. It's also no always so that you have a sufficient fast oversampling clock available. Alternatively, you may want to run the shift register from SPI SCK ("SCLK") and implement domain crossing logic for the parallel data.

 

[vGoodtimes]

@shaiko,
This is more challenging. For a practical application, your original approach seems reasonable. However it might take the MIIM/MDIO model. The Tcko of many PHY's MIIM MDIO line is spec'd as > 1/2 cycle at max rate. An oversampled interface can simply choose to sample at a valid time even if it isn't a clock edge. When applied to SPI, this limits the impact of latency to just turn-around padding. Eg, you can't swap chip selects until the second FPGA's data is reliably received, which might be 1-2 SCK cycles later.

For a high speed SPI-like interface, it is reasonable to force added latency for reads, or to have backpressure as needed.

Added latency means the SPI controller issues the read command, then shifts 1+ bits of data while ignoring the values, then reads the actual value. The amount of latency will likely be 1,2, or 8 bits.

backpressure would mean the SPI controller would need to see a specific bit/byte before data becomes valid. This is more common on devices like sdcards, where data might not be available for several cycles.

 

[shaiko]

Round trip delay is a valid point. It's also no always so that you have a sufficient fast oversampling clock available. Alternatively, you may want to run the shift register from SPI SCK ("SCLK") and implement domain crossing logic for the parallel data.

Again,
I'm aware of the potential problems - and surely it's easier to avoid problems then try to deal with the ill effects.
But please treat the design as a given fact. - a learning exercise.
A bad engineer designed it and now a good engineer has to constrain it.

Please refer to ads-ee's answer in post #2 and my following questions to him in post #6.

Thanks

 

[FvM]

But please treat the design as a given fact. - a learning exercise.

O.K., we can do, despite of reasonability considerations. But I think, the "given" design isn't completely specified yet. It's clear that you have a SCLK synchronizer to the FPGA #2 240 MHz domain. But how is MISO being sent? Set on the synchronized rising edge? This means that MISO arrives at FPGA #1 most likely after the falling SCLK edge as seen by FPGA #1. MISO will be further delayed by the FPGA #1 synchronizer. You'll end up with sampling a valid synchronized MISO e.g. at the next falling SCLK edge.

You can sketch a MISO sampling window considering synchronizer delay, arbitrary FPGA #2 system clock phase, IO delay and delay skew, hoping for a positive window width.

Constraints can be used to limit the delay skew and push the IO delay towards its lower bound. But due to the involved absolute round trip delay, you can't write valid constraints without either studying the detailed FPGA specifications or evaluating feasible numbers by an iterative trial and error process. Typically you'll share the delay skew equally between both FPGAs.

 

[shaiko]

Constraints can be used to limit the delay skew and push the IO delay towards its lower bound.

Is the set_max_delay constraint always defined with reference to the system clock?
Or can the reference point be any other signal?

 

[K-J]

Is the set_max_delay constraint always defined with reference to the system clock?
Or can the reference point be any other signal?

I'm pretty sure that any SDC delays are always relative to the clock that actually generates the output signal. If you specify a delay from some other signal that is not the generating clock, the constraint gets flagged as an ignored constraint.

Kevin Jennings

 

[shaiko]

I'm pretty sure that any SDC delays are always relative to the clock that actually generates the output signal. If you specify a delay from some other signal that is not the generating clock, the constraint gets flagged as an ignored constraint.

Hello Kevin,

After posting #11, I continued to search for the answer myself...
**broken link removed**
Please see page 46:

# Apply a 2ns max delay for an input port (TSU)
set_max_delay -from [get_ports in[*]] -to [get_registers *] 2.000

I see no reference to a clock here...are you saying that it would be ignored?

 

[K-J]

I see no reference to a clock here...are you saying that it would be ignored?

What you asked in #11 was "Or can the reference point be any other signal?" and my answer is 'No', the reference point must be from a signal that actually generates the output signal.

Now in #13, you're listing a constraint from a wildcarded reference. That constraint will be accepted, but that does not imply you will be adding the constraint that I think you actually want to add. I *think* your question is that if you generate an output from a flip flop that is clocked by some system clock (call it 'Clock'), is there a way to add a timing constraint on that output signal and some other signal (the 'Spi_Clock') and I don't think there is such a way. Similarly, I don't think there is a way to add a setup constraint on an input signal to 'Spi_Clock' unless that input signal is actually received by a flip flop that is clocked by 'Spi_Clock'. If that input is instead clocked by the system clock, the constraint you add relative to 'Spi_Clock' will be ignored and reported as an ignored constraint. You might like to add constraints between 'Spi_Clock' and 'Mosi/Miso', but I don't think you can.

Presuming that both 'Spi_Clock' and 'Spi_Mosi' outputs are both outputs of clocks that are clocked by the system clock, then on FPGA #1 you define a min/max delay requirement from that system clock. The difference between the min/max of those two will be the amount of input delay you will need to set on FPGA #2. The reason is that within the min/max constraints that you set, you're basically defining a window of time within which you don't know which signals comes first which translates into an input delay that needs to be spec'ed for the receiver.

Kevin Jennings

 

[FvM]

A good explanation how to apply input and output constraints is given in the "TimeQuest User Guide" by Ryan Scoville, see .

 

[vGoodtimes]

Round trip delay is a valid point. It's also no always so that you have a sufficient fast oversampling clock available. Alternatively, you may want to run the shift register from SPI SCK ("SCLK") and implement domain crossing logic for the parallel data.

This might be an issue too. If the SCK doesn't connect to an IO designed for clocking resources, there may be a potentially large delay within the clock network.

Again,
I'm aware of the potential problems - and surely it's easier to avoid problems then try to deal with the ill effects.

This phrase works both ways. You may find it is easier to avoid the problems of difficult/impossible constraints than deal with the ill effects of padding/latency.

 

[shaiko]

This might be an issue too. If the SCK doesn't connect to an IO designed for clocking resources, there may be a potentially large delay within the clock network.

But we'll now about it...
Everything inside the FPGA is synchronous and makes an effort to obey the frequency of the created clock.
If it does - the tool will tell us.

 

[vGoodtimes]

My point was more that you may end up not having a choice. This depends on the system. It is possible that neither using the SCK directly nor oversampling it will meet requirements. You have to compute the external factors to generate the constraint anyways.

edit -- it also makes sense to consider the clocking in the good case. If the tools choose a default global clock, it might be possible to switch to regional clocking instead. This applies to the non-oversampled case.

 

[shaiko]

BTW,
ads-ee

About the double synchronizer you mentioned in post #2.

With a lower SCLK frequency - for example: 10MHz instead of the nominal 40MHz.
The only signal that will require double sampling is the SCLK on FPGA #2.
Neither MOSI (incoming towards FPGA #2) nor MISO (incoming towards FPGA #1) require double sampling. By protocol definition they're stable when we require their value (falling egde of SCLK).

 

[vGoodtimes]

This is certainly true for MOSI, although it still need to be registered because SCK is registered. By using the delayed MOSI, you can determine the value of MOSI at the falling edge of SCK. (vs 1/3rd cycle later).

MISO is safe if it it safe. That is likely very hard or impossible to ensure, but if you ensure it then it will be ensured as well.