UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor schwendinger
Visitor
857 Views
Registered: ‎04-20-2017

Design passes timing analysis but fails in lab!

Jump to solution

We have some weird problems with the implementation of an SPI Slave in our design (fully constrained synchronous design). We did a successful compilation run (ISE reports no timing violations), however for this compilation the design does not work probably in hardware!

For further investigation we fixed placement and routing via direct routing constraints, added some probes with the FPGA Editor and an ILA debug core to watch the signals.

Our investigations showed that the SPI slave receives the correct data in its input shift register but latching to the parallel registers (same clock domain) fails.

If we cool down the FPGA this behavior disappears and the SPI slave works correctly.  We assume there is a hold time violation between two synchronous FF’s (not reported by the Timing Analyzer).

Furthermore we checked:

  • Supply Voltages (3V3, 1V2)
  • Signal Integrity of SCLK, SS, SDI

and found no discrepancies

 

Do you have suggestions for what we might have missed? What else can lead to a design that meets all timing constraints, but the hardware implementation obviously fails?

 

  • Device:                    XC6SLX100T
  • Package:                 FFG484
  • Speed:                     -2
  • Release Version:     ISE 14.7 (lin64)
  • Application Version: P.20131013
0 Kudos
1 Solution

Accepted Solutions
685 Views
Registered: ‎01-22-2015

Re: Design passes timing analysis but fails in lab!

Jump to solution

Andreas,

     The problem is solved and the design works as expected. BUT…..
Congratulations!   I understand the “BUT…”.

     Are there some known issues where the ISE timing analyzer has difficulties calculating timing correctly?
Yes!  Avrum has often said [1] [2] [3] that ISE cannot properly do hold time analysis for FPGA output interfaces – and that Vivado is generally much better overall at doing timing analysis. However, you suspect timing analysis problems for a FPGA input interface. So, I’m not sure where this leaves us. 

     In some designs, it may not be possible to route the various clock signals of all implemented interfaces (e.g. several SPI’s and SPORT’s, etc.) over global lines. Are there some design rules to avoid such problems? (e.g. use local clocks only if fanout max is less than xx? max allowed clock net skew?
UG382 says that the Spartan-6 has 32 regional clock buffers (BUFIO2) plus global clock buffers (BUFG). So, I suspect that you won’t run out of buffers and clock tree space for all your FPGA IO. For doing FPGA I/O, the BUFIO2 are a better choice than the BUFG – since your SCLKs only need to be routed regionally (to the dinReg and dinLatchedReg) – and not throughout the entire FPGA. Fanout and skew are not a problem that you need worry about during your design – just keeps your clocks in the clock tree and not in the FPGA fabric. Timing analysis will tell you if fanout and skew are a problem – and then you can worry about them.

     Is it possible that we have to change some Timing analyzer settings? Maybe other analyzer settings will lead to failing timing paths.
Be sure you have written constraints for SCLK and SDI properly. Also, be careful using the set_false_path and set_clock_groups constraints since they can prevent large parts of your design from undergoing timing analysis (see Avrum’s classic post <here>).

This is a good time for me to again mention the oversampled interface method as an option to the traditional method for handling FPGA slow input. In theory, your FPGA needs only one fast clock to handle all your SPI slow interfaces. Further, with the oversampled interface method, you ensure that the interface meets timing by design – rather than relying solely on ISE timing analysis to tell you that the design passes timing.

     This register is passed to the FPGA clock domain (asynchron). In the current compilation the path between din3 and dinLatchedReg4 fails. E.g. Master send data is 0x0008 à Received data dinLatchedReg is 0x0018
You say “path between din3 and dinLatchedReg4 fails”, which suggests a timing problem between din3 and dinLatchedReg4. I don’t think we can conclude this is happening. Rather, I think we can only say that dinLatchedReg4 is not receiving the value that you expect. This problem could be caused by timing problems anywhere upstream of dinLatchedReg4. For example, this could be caused by a timing problem with the SDI data coming into your dinReg.  So again, be sure you have written constraints for SCLK and SDI properly.

Mark

 

0 Kudos
8 Replies
814 Views
Registered: ‎01-22-2015

Re: Design passes timing analysis but fails in lab!

Jump to solution

@schwendinger

I’ve forgotten most of what I knew about ISE.  However, in Vivado we can (and must) specify jitter of the FPGA main clock (ie. the clock input to the FPGA from which all internal FPGA clocks are derived).  Can you increase the jitter you have specified to ISE for your main clock - and see if this results in a design that both passes timing analysis and works better on the bench?  If this happens, then perhaps your main clock is not meeting the manufacturer’s jitter specification.

Recently we had a FPGA main clock that supposedly met jitter specifications but had a high 2nd harmonic. Just like you, our design passed Vivado timing analysis but was visibly failing timing analysis on the bench. After filtering off the 2nd harmonic of the main clock (before it reached the FPGA), the design worked properly.

You said your design was fully synchronous. However, I'll mention that improperly constrained/designed synchronizers can cause metastability (ie. timing analysis failures) at clock-crossings.  For example, in Vivado we must place the ASYNC_REG=TRUE property on each register used in a synchronizer.  This property causes the registers to be placed physically near each other, which is a requirement for the synchronizer to work properly.  If you have forgotten to use the ISE-equivalent of ASYNC_REG or if the synchronizer registers are being pushed apart for other reasons, then the resulting metastability could show up during your bench testing.

Cheers,
Mark

0 Kudos
Visitor schwendinger
Visitor
789 Views
Registered: ‎04-20-2017

Re: Design passes timing analysis but fails in lab!

Jump to solution

Hello Mark,

thank you for your help.

Can you increase the jitter you have specified to ISE for your main clock - and see if this results in a design that both passes timing analysis and works better on the bench?

Increasing the specified jitter results in a design that still passes timing analysis. The design does not work probably in hardware either.

 

…that improperly constrained/designed synchronizers can cause metastability (ie. timing analysis failures) at clock-crossings.  For example, in Vivado we must place the ASYNC_REG=TRUE property on each register used in a synchronizer.

The ASYNC_REG property is also supported by ISE, but our problem is not the clock crossing. To illustrate the problem, have a look at the following simplified block diagram:

ACL_Debug.png 

SDI (MSB first) is latched into a 15 bit input-shift register (dinReg) with the falling-edge of SCLK. With the last falling-edge of SCLK the 15 bit of the input-shift register (dinReg) and the current value of SDI are latched to a parallel 16 bit register (dinLatchedReg).

This register is passed to the FPGA clock domain (asynchron). In the current compilation the path between din3 and dinLatchedReg4 fails. E.g. Master send data is 0x0008 à Received data  dinLatchedReg is 0x0018

 

SCLK input buffer is IBUFDS à Clock signal is routed via local lines which results in a high clock net skew (11,073 ns) and max delay (14.914 ns). Might this be a problem?

 

Thank you very much for your efforts.

Regrads,

Andreas

0 Kudos
Voyager
Voyager
783 Views
Registered: ‎08-16-2018

Re: Design passes timing analysis but fails in lab!

Jump to solution

"If we cool down the FPGA this behavior disappears"

That looks to me like a clue. Things get worse with temperature. 

0 Kudos
765 Views
Registered: ‎01-22-2015

Re: Design passes timing analysis but fails in lab!

Jump to solution

Andreas,

     The design does not work probably in hardware either.
In general, if you give ISE a too-low number for jitter of the main-clock then the design could pass ISE timing analysis but fail timing during bench testing. 

     SCLK input buffer is IBUFDS à Clock signal is routed via local lines...
Improvements to your architecture can be made, which we will discuss... 

...but first, a few questions:

  1. I understand that SDI and SCLK are both inputs to your FPGA – and not bidirectional IO?  That is, your FPGA is acting only as a SPI Slave/Receiver?
  2. What is the maximum frequency of SCLK?
  3. What constraints have you written into the UCF file for SDI and SCLK (eg. in Vivado we would use set_input_delay and create_clock)?

Mark

0 Kudos
Visitor schwendinger
Visitor
743 Views
Registered: ‎04-20-2017

Re: Design passes timing analysis but fails in lab!

Jump to solution

Hello Mark,

In all my investigations placement and routing (dinReg, dinLatchedReg, SCLK, SDI) were fixed by direct routing constraints.

  • In general, if you give ISE a too-low number for jitter of the main-clock then the design could pass ISE timing analysis but fail timing during bench testing. 

I tried different settings for the input jitter (upto 10 ns!?). However, these changes did not affect the outcome of the timing analysis and the bench testing.   

  • I understand that SDI and SCLK are both inputs to your FPGA – and not bidirectional IO?  That is, your FPGA is acting only as a SPI Slave/Receiver?

Yes, the FPGA is a Slave/Receiver. SDI and SCLK are only inputs to the FPGA.

  •  What is the maximum frequency of SCLK?

For this design the maximum frequency of SCLK is 10 MHz

  • What constraints have you written into the UCF file for SDI and SCLK (eg. in Vivado we would use set_input_delay and create_clock)?

# Period

NET "SCLK" TNM_NET = "TN_SCLK";

TIMESPEC TS_ SCLK = PERIOD "TN_SCLK " 100 ns HIGH 50% INPUT_JITTER 500 ps;

 

# Setup 15ns, Hold 15ns

OFFSET = IN 15 VALID 30 BEFORE "SCLK" FALLING;

 

Cheers,

Andreas

0 Kudos
729 Views
Registered: ‎01-22-2015

Re: Design passes timing analysis but fails in lab!

Jump to solution

Andreas,

Thanks for answering my questions.

     SCLK input buffer is IBUFDS à Clock signal is routed via local lines which results in a high clock net skew (11,073 ns) and max delay (14.914 ns). Might this be a problem?
Yes, let’s talk about this.  I will try to use ISE terminology, but might slip into Vivado terminology – sorry.

Your SPI input falls into the general category of Source Synchronous Input to the FPGA. That is, the transmitter is sending both data (SDI) and a clock (SCLK) to the FPGA. Since the maximum speed for your SCLK is fairly slow (10MHz), it should be easy to make this interface work properly.  Also because of the slow SCLK, you have at least two methods for designing this interface:

The traditional method:

  1. Bring SCLK into FPGA via dedicated clock-input pins
  2. Route SCLK to clock-buffer or clock-module to place it in the FPGA clock-tree
  3. Use SCLK from FPGA clock-tree to clock a register that captures SDI
  4. Write constraints for SCLK and SDI
  5. Run timing analysis
  6. Use clock-module to shift SCLK relative to SDI until the interface passes timing analysis

Over-sampled interface method:

  1. Create a fast clock inside the FPGA (for this example let’s use 100MHz and call it CLK100)
  2. Bring your interface signals (SCLK and SDI) into the FPGA via synchronizers that pass both signals into the CLK100 domain.
  3. Do something (eg. write constraints) that places (and keeps) the synchronizers near the FPGA pins for SCLK and SDI.
  4. With this over-sampled interface method, you are basically sampling SCLK and SDI and making decisions based on these sampled values.
  5. For example, for your SPI, you could simply wait to see a falling-edge on SCLK and then store the next sample from SDI.
  6. In some SPI (where SCLK and SDI are shifted with respect to each other) you might need a different decision strategy. For example, wait to see a falling-edge on SCLK then skip 3 samples of SDI and save the 4th sample.
  7. The whole idea of these decision strategies is to place the SCLK sampling-edge in the middle of the SDI data-eye (ie. we want to sample SDI halfway between the times when SDI is changing).

We can talk more about either or both of these methods (if you want). However, you are close to implementing the traditional method.

So, you might first try routing SCLK through the BUFIO2 as shown in the Figure below from UG382.  You will need to use the I_INVERT attribute for BUFIO2 (see Table 1-19 in UG382) since you are capturing SDI data on the falling-edge of SCLK. Send your SDI data to the D-pin of the FDRSE shown in the Figure.  All your shift-registers and latch-registers need to be clocked by the version of SCLK that comes out of the BUFIO2. This improved routing for SCLK should get rid of the large clock skew that is caused by your routing of SCLK through the FPGA fabric.  
ug382_fig1p12.jpg

     This register is passed to the FPGA clock domain (asynchron). In the current compilation the path between din3 and dinLatchedReg4 fails. E.g. Master send data is 0x0008 à Received data dinLatchedReg is 0x0018
The improved routing for SCLK (as described above) should fix this problem.

Mark

0 Kudos
Visitor schwendinger
Visitor
714 Views
Registered: ‎04-20-2017

Re: Design passes timing analysis but fails in lab!

Jump to solution

Mark,

 I would prefer the traditional approach

 

1. Bring SCLK into FPGA via dedicated clock-input pins

The pinning of the SPI interface is determined by the circuit board design. SCLK is locked to pin “H12” which is IO_L35P_GCLK17_0 à OK

 

2.  Route SCLK to clock-buffer or clock-moduleto place it in the FPGA clock-tree

To force placement and routing of the SCLK to a global clock tree we did the following:

ib_sclk_in : IBUFG                                  ib_sclk_bufio : BUFG

PORT MAP   (I    => SCLK,                   PORT MAP   (I          => sclk_ibufg,

                      O    => sclk_ibufg                                 O             => sclk_bufg

                 );                                                                );

                                                    

3. Use SCLK from FPGA clock-tree to clock a register that captures SDI

sclk_bufg clocks all SPI input registers (dinReg, dinLatchedReg) à OK

 

4. Write constraints for SCLK and SDI

# Period

NET "SCLK" TNM_NET = "TN_SCLK";

TIMESPEC TS_ SCLK = PERIOD "TN_SCLK " 100 ns HIGH 50% INPUT_JITTER 500 ps;

 

# Setup 15ns, Hold 15ns

OFFSET = IN 15 VALID 30 BEFORE "SCLK" FALLING;

 

5. Run timing analysis

Timing analysis passed à reduced clock net skew (0,144 ns) and max delay (1.806 ns).

The problem is solved and the design works as expected. BUT…..

 

To get back to our original problem…

Our design passed timing analysis but was not working as expected in hardware. We did not find any hardware issues (supply voltage, signal integrity,…) but could identify a potential weak spot in our vhdl design (local clock routing resulting in a high clock net skew and clock max delay). Once again timing analysis showed that all constraints were met. To say it a bit exaggerated, we cannot trust the timing analysis. Is it possible that in some corner cases (which we don’t know) timing analysis shows unreliable results?

 

So, our questions are:

  1. Are there some known issues where the ISE timing analyzer has difficulties calculating timing correctly?
  2. In some designs, it may not be possible to route the various clock signals of all implemented interfaces (e.g. several SPI’s and SPORT’s, etc.) over global lines. Are there some design rules to avoid such problems? (e.g. use local clocks only if fanout max is less than xx? max allowed clock net skew?
  3. Is it possible that we have to change some Timing analyzer settings? Maybe other analyzer settings will lead to failing timing paths.

 

Thanks a lot and have a nice weekend.

Best regards

Andreas

0 Kudos
686 Views
Registered: ‎01-22-2015

Re: Design passes timing analysis but fails in lab!

Jump to solution

Andreas,

     The problem is solved and the design works as expected. BUT…..
Congratulations!   I understand the “BUT…”.

     Are there some known issues where the ISE timing analyzer has difficulties calculating timing correctly?
Yes!  Avrum has often said [1] [2] [3] that ISE cannot properly do hold time analysis for FPGA output interfaces – and that Vivado is generally much better overall at doing timing analysis. However, you suspect timing analysis problems for a FPGA input interface. So, I’m not sure where this leaves us. 

     In some designs, it may not be possible to route the various clock signals of all implemented interfaces (e.g. several SPI’s and SPORT’s, etc.) over global lines. Are there some design rules to avoid such problems? (e.g. use local clocks only if fanout max is less than xx? max allowed clock net skew?
UG382 says that the Spartan-6 has 32 regional clock buffers (BUFIO2) plus global clock buffers (BUFG). So, I suspect that you won’t run out of buffers and clock tree space for all your FPGA IO. For doing FPGA I/O, the BUFIO2 are a better choice than the BUFG – since your SCLKs only need to be routed regionally (to the dinReg and dinLatchedReg) – and not throughout the entire FPGA. Fanout and skew are not a problem that you need worry about during your design – just keeps your clocks in the clock tree and not in the FPGA fabric. Timing analysis will tell you if fanout and skew are a problem – and then you can worry about them.

     Is it possible that we have to change some Timing analyzer settings? Maybe other analyzer settings will lead to failing timing paths.
Be sure you have written constraints for SCLK and SDI properly. Also, be careful using the set_false_path and set_clock_groups constraints since they can prevent large parts of your design from undergoing timing analysis (see Avrum’s classic post <here>).

This is a good time for me to again mention the oversampled interface method as an option to the traditional method for handling FPGA slow input. In theory, your FPGA needs only one fast clock to handle all your SPI slow interfaces. Further, with the oversampled interface method, you ensure that the interface meets timing by design – rather than relying solely on ISE timing analysis to tell you that the design passes timing.

     This register is passed to the FPGA clock domain (asynchron). In the current compilation the path between din3 and dinLatchedReg4 fails. E.g. Master send data is 0x0008 à Received data dinLatchedReg is 0x0018
You say “path between din3 and dinLatchedReg4 fails”, which suggests a timing problem between din3 and dinLatchedReg4. I don’t think we can conclude this is happening. Rather, I think we can only say that dinLatchedReg4 is not receiving the value that you expect. This problem could be caused by timing problems anywhere upstream of dinLatchedReg4. For example, this could be caused by a timing problem with the SDI data coming into your dinReg.  So again, be sure you have written constraints for SCLK and SDI properly.

Mark

 

0 Kudos