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: 
Adventurer
Adventurer
12,352 Views
Registered: ‎11-12-2010

Spartan-6, IODELAY - ISERDES in DIFF_PHASE_DETECTOR mode, bit alignment problems

Jump to solution

Happy New Year community!!

 

To start 2013 I share with you a strange problem about deserialization. I hope that your experience help us to solve it.

 

System description

It's composed by a image sensor board attached to a Spartan-6 board.

Image sensor provide 17 high speed differential channels (16 data + 1 control) synchronous to a 360Mbps clock generated from the FPGA to sensor. These 17 HS diff channels are sampled in Spartan using IODELAY + ISERDES primitives.

 

Our sampling code is based in serdes_1_to_n_data_s16_diff.vhd example of XAPP1064. Bit alignment task is performed by DIFF_PHASE_DETECTOR feature of IODELAY + ISERDES. Word alignment task is performed by an iterative FSM searching for a word pattern (0x055 for data channels and 0x200 for control channel).

 

Problem description

In production, we have detected a 5% of units with bit alignment problems in different states. The rest of 95% of production work fine.

Next we show some image samples in some steps taken during bug investigation.

 

Step 1: Power-up, reset and first alignment

After power-up, reset and image sensor setup, is launched the word alignment FSM. Bit alignment task is taken place automatically by DIFF_PHASE_DETECTOR feature.

In most of the production units all these tasks are OK, but in problematics units some channels do not bit align. Next a image  example of noisy channels. Sensor do no have a lens to show a clear image, so the aligned channels show a grey color.

 

Align1.jpg

 

Here a screen capture of chipScope testbench of previous image. Please note that we have found very noisy waveforms with other fail sensor boards. You can see in failing channels the pattern 0x28A, that is 0x055 right shifted 3 positions. Seems that during word alignment FSM do not have found the correct training pattern.


Align1ChSc.jpg

 

This align scene is maintained indefinitely, now you can make a lot of image captures with the same results.

 

Step 2: New alignment procedure

At this step we can think about a routing or impedance problem in PCB traces but using our debugging resources we can launch a new alignment procedure, with next results. Now only two channels remain noisy (number and position of failing channels vary between fail units). Gray color is OK, no lens is attached to image sensor.


Align2.jpg

 

The alignment procedure is showed in next ChipScope capture

 

Align2ChSc.jpg

 

Note the word alignment process (basically BITSLIP operations) of every channel and the spurious data of failing channels. In channel 14 data start to move during the bitsliping of other channels. In other cases we have notice these kind of behavior.

After re-alignment these situation is maintained in all captured frames.

 

Step 3: Additional re-alignments

In some failing units, launching three, four or more times the alignment FSM we can obtain a good result for all channels, capturing perfect images. Is not the case of this unit that persist in fail channels 4 and 14.

Next another chipScope capture of the eighth word alignment process of this case. Note channel 14 data movement.

 

Align8ChSc.jpg

 

 

Actions history


To solve this issue we have trying some actions.

 

  • First we have think about a PCB issue, but misaligned channels are not fixed, so not seems a PCB problem. We have made some scopes of incoming diff signals from sensor. Our oscilloscope is 400MHz and we have a 1GHz active single-ended probe. Our equipment is limited to see a 360Mbps diff signal, but we have been able to visualize coherent waveforms and data eyes in bad channels.
  • We have verified any timing issues related with IODELAY and ISERDES control inputs.
  • We have made some minor changes in code as recommended by Xilinx support team. Symptoms remain the same.
  • Designed a world alignment comparator by channel. Symptoms remain the same.

 

Additional route from IOB diff driver

Our last action, recommended by Xilinx support. We have routed a line from the IOB driver output of a fail channel to a unused single ended pin to scope it with our single ended probe trying to obtain a very good oscilloscope waveform view.


But when using the new bitstream with this additional route we found that the channel align correctly!! and another good channel becomes bad. So I can't scope a failing channel through this indirect routing.

 

In this point I decide to route a additional route from IOB diff driver from ALL the channels to dummy logic. I get absolutely surprised with the results of this measure. 3 of 4 testing fail sensor boards align correctly all the channels in first launch of alignment procedure.

 

I thought that I found the "solution" to the bug, but when I have tested this new version in verified systems we have found that half of these boards do not align some channels. That is, when repaired failing boards, some good boards fail.

 

Conclusions

I have not a clear idea about what is happening, but I'm thinking about impedance matching of the line or the impedance matching in the IOB to the FPGA fabric. New ideas about are welcome!

 

Seems that impedance matching in differential lines are correct, because data can be obtained in most of cases, without this "strange solution".

 

Other hypothesis is that bit alignment of DIFF_PHASE_DETECTOR system is dependent of external factors, maybe power noise or clock jitter or temperature.

 

And my last idea is that maybe 17 ISERDES + 1 OSERDES (clock generator) IOBs working at 360MHz in a Spartan-6 system need additional measures to work fine.

 

Please help!!

I write to the forum to obtain new points of view of these issues from the community.

 

We are thinking about to rent a High Frequency oscilloscope to verify the data eye of incoming signals. What is the minimum oscilloscope frequency to scope correctly a 360MHz signal? 1GHz is enough?

 

 

Thank you to the community, I hope this discussion will be useful for everybody.

 

Best regards

 

David Quiñones

0 Kudos
1 Solution

Accepted Solutions
Adventurer
Adventurer
16,082 Views
Registered: ‎11-06-2011

Re: Spartan-6, IODELAY - ISERDES in DIFF_PHASE_DETECTOR mode, bit alignment problems

Jump to solution

Hi David,

I'm familiar with the image sensor you are using, I use several variants of the same sensor.  In the earlier mask versions of

these parts, their internal PLL wasn't operational, and it was necessary to provide the higher speed external LVDS clock for their output LVDS, as you are doing. With the newer masks, that is no longer necessary, the internal PLL has been fixed.

 

In any case, based on your description, I would say you are doing just what I did at first, which was to use an FPGA internal clock sychronous to the output clock, to drive the receiver circuitry, rather than recover the clock they return.  I'm basing this both on your results, and the fact that you didn't describe the LVDS clock output they provide.

 

I did this as an expediant measure in early board debug, which seemed feasible because I was supplying the clock, so it was more of a system synchronous arrangement, and I was thinking the diff phase detector would adjust to account for the board routing.  This mostly worked, just as it has for you.  The problem is that the diff phase detector has a limited range of adjustment, and the imagers have temperature/process variations, that cause just the problem you are seeing.  So I had about the same results you are having, it worked on some units, but would exhibit alignment failure on some channels on some units.

 

The solution, assuming I'm correct in my assumptions about your issue, is to use a proper source synchronous interface, recover the clock the imager provides, and use that in your receiver circuitry.  Then the clock to data relationship can be properly handled by the diff phase detector.  I'm using the verilog version of same data receiver circuitry you mentioned (serdes_1_to_n_data_s16_diff.v), and I'm using the serdes_1_to_n_clk_pll_s16_diff.v circuitry for the clock, which has been working quite reliably.  Since implementing this, these channel alignment issues were completely resolved, both over temperature and over many units.

 

I'm also using this up to the maximum speed of the imager which is 480 Mbps, and have also overclocked it to 500 Mbps quite reliably.  For reference, I'm using -3 speed parts, LX45 and LX100, and they are Mask D.

The Mask level is critical at the higher rates, the older masks had issues in the diff phase detector above 400 Mbps.  At your rates it wouldn't matter. (For background on this, see AR38408, AR41083, EN148, and XCN11012).

 

Note that you were mixing rate descriptions.  The clock that you provide (360 MHz) generates a clock to you at 180 MHz for the DDR data at 360 Mbps.

 

Hope this helps.

Bill

 

22 Replies
Adventurer
Adventurer
16,083 Views
Registered: ‎11-06-2011

Re: Spartan-6, IODELAY - ISERDES in DIFF_PHASE_DETECTOR mode, bit alignment problems

Jump to solution

Hi David,

I'm familiar with the image sensor you are using, I use several variants of the same sensor.  In the earlier mask versions of

these parts, their internal PLL wasn't operational, and it was necessary to provide the higher speed external LVDS clock for their output LVDS, as you are doing. With the newer masks, that is no longer necessary, the internal PLL has been fixed.

 

In any case, based on your description, I would say you are doing just what I did at first, which was to use an FPGA internal clock sychronous to the output clock, to drive the receiver circuitry, rather than recover the clock they return.  I'm basing this both on your results, and the fact that you didn't describe the LVDS clock output they provide.

 

I did this as an expediant measure in early board debug, which seemed feasible because I was supplying the clock, so it was more of a system synchronous arrangement, and I was thinking the diff phase detector would adjust to account for the board routing.  This mostly worked, just as it has for you.  The problem is that the diff phase detector has a limited range of adjustment, and the imagers have temperature/process variations, that cause just the problem you are seeing.  So I had about the same results you are having, it worked on some units, but would exhibit alignment failure on some channels on some units.

 

The solution, assuming I'm correct in my assumptions about your issue, is to use a proper source synchronous interface, recover the clock the imager provides, and use that in your receiver circuitry.  Then the clock to data relationship can be properly handled by the diff phase detector.  I'm using the verilog version of same data receiver circuitry you mentioned (serdes_1_to_n_data_s16_diff.v), and I'm using the serdes_1_to_n_clk_pll_s16_diff.v circuitry for the clock, which has been working quite reliably.  Since implementing this, these channel alignment issues were completely resolved, both over temperature and over many units.

 

I'm also using this up to the maximum speed of the imager which is 480 Mbps, and have also overclocked it to 500 Mbps quite reliably.  For reference, I'm using -3 speed parts, LX45 and LX100, and they are Mask D.

The Mask level is critical at the higher rates, the older masks had issues in the diff phase detector above 400 Mbps.  At your rates it wouldn't matter. (For background on this, see AR38408, AR41083, EN148, and XCN11012).

 

Note that you were mixing rate descriptions.  The clock that you provide (360 MHz) generates a clock to you at 180 MHz for the DDR data at 360 Mbps.

 

Hope this helps.

Bill

 

Adventurer
Adventurer
12,309 Views
Registered: ‎11-12-2010

Re: Spartan-6, IODELAY - ISERDES in DIFF_PHASE_DETECTOR mode, bit alignment problems

Jump to solution

Hello Bill

I'm happy to view your reply.

You are right. Due to PLL problems we must to modify our sensor PCB to drive the LVDS clock input of image sensor and sample data with internal clock of FPGA. That is, we do not sample data with a source synchronous clock with data.

Unfortunately, the PCB modification was the substitution of the route of source synchronous data clock by the route of LVDS clock input. We haven't more pins in the PCB socket to route the source synchronous clock.

 

 

By the other hand, I'm wondering about the strange phenomenon about routing a dummy line from input driver of incoming LVDS input in FPGA and fail sensor boards work fine and some good boards fail. Add this connections a additional delay to input?

 

 

Also, I'm thinking about an alternative method to DIFF_PHASE_DETECTOR with more adjustment range. Is this possible using manual methods?

 

Best regards.

0 Kudos
Adventurer
Adventurer
12,302 Views
Registered: ‎11-06-2011

Re: Spartan-6, IODELAY - ISERDES in DIFF_PHASE_DETECTOR mode, bit alignment problems

Jump to solution

Hi David,

If you can't modify your board/connector arrangement, then perhaps the best solution would be to obtain the v3 imagers, which have the PLL working correctly.  Then you can go back to using the source synchronous clock.  We are using v3 parts in both 2M and 4M, and the PLL works in both.

 

If you designed the imager board, then I'd say in the future, always try to allow for all possible connections to a device like this, it can save you headaches.

 

I'm not sure about the effect you observed when you added the test connections, but it probably did effect the timing,

resulting in the behavior change.  I don't think you mentioned testing temperature, but you probably would see additional channel alignment disruptions with a heat gun and/or freeze spray.

 

One of the nice features of the diff_phase_detector is that it operates continously without disturbing the live data.

Perhaps there is another way to do this in the Spartan-6, maybe someone else can suggest a method that operates in that manner, I'm not aware of an equivalent method.  The timing loop that you currently have, from the clock you provide to the imager, to the data coming back to the FPGA, has enough variability over process/temperature, that there needs to be adjustments made as the product warms up. If you have the luxury of allowing the product to acheive a stable temperature (if such a temperature even exists with your product) before calibrating the eye detection, and/or you don't care about disrupting the data periodically, perhaps you can use another eye centering algorithm.

 

Regards,

Bill

 

 

0 Kudos
Adventurer
Adventurer
12,282 Views
Registered: ‎11-12-2010

Re: Spartan-6, IODELAY - ISERDES in DIFF_PHASE_DETECTOR mode, bit alignment problems

Jump to solution

Hello Bill

 

Use of v3 imagers is in our plans, and old PCB design allow us to use the source synchronous clock. That's the good news.

But we use a NIR enhanced version of imager that will be available in some months.

 

 

About temperature effects, I can appreciate small differences with a freeze spray in channels that are not absolutely misaligned (not the noisy channels showed in pictures). But when I relaunch the alignment procedure some channels align and one or two misalign. Seems a lottery. I think it exist a relationship between IODELAYs of adjacent IOBs, maybe related to the power rail.

 

Best regards

 

David

0 Kudos
Highlighted
Visitor grenie00
Visitor
11,778 Views
Registered: ‎08-22-2013

Re: Spartan-6, IODELAY - ISERDES in DIFF_PHASE_DETECTOR mode, bit alignment problems

Jump to solution

Hi David, I have the same problem. What I did is to get rid of the 16 data delays and only doing the word alignment. I know it's not recommended by the manufacturer to do that but we are working at low speed (150MHz instead of 480MHz maximum). So now, I'm trying to put back the delay and understand why it's not working well with this delay added on all 17 channels. Hope it will help you.

 

I think we us the same image sensor. I tried the rev 2 and rev 3 and they do the same thing even if I synchronize the data from the LVDS clock from the sensor. Maybe you started you design with the code provided by the manufacturer as I did. It's was written for the Virtex4. I use instead also the Spartan 6. The delay is little more complicated and I think that either the algorithm is not optimized for the S6 delay (IODELAY2) or it's should be thanked other way to make it run in S6. Did you experiment the same thing?

 

Best regards,

grenie00

Tags (1)
image with delay allignment.jpg
0 Kudos
Historian
Historian
11,766 Views
Registered: ‎02-25-2008

Re: Spartan-6, IODELAY - ISERDES in DIFF_PHASE_DETECTOR mode, bit alignment problems

Jump to solution

@grenie00 wrote:

Hi David, I have the same problem. What I did is to get rid of the 16 data delays and only doing the word alignment. I know it's not recommended by the manufacturer to do that but we are working at low speed (150MHz instead of 480MHz maximum). So now, I'm trying to put back the delay and understand why it's not working well with this delay added on all 17 channels. Hope it will help you.

 

I think we us the same image sensor. I tried the rev 2 and rev 3 and they do the same thing even if I synchronize the data from the LVDS clock from the sensor. Maybe you started you design with the code provided by the manufacturer as I did. It's was written for the Virtex4. I use instead also the Spartan 6. The delay is little more complicated and I think that either the algorithm is not optimized for the S6 delay (IODELAY2) or it's should be thanked other way to make it run in S6. Did you experiment the same thing?

 

Best regards,

grenie00


I did a design based on that sensor, and didn't use the vendor's suggested code. In fact, I don't understand why they provide the source-synchronous clock with the data and then not use it in their own design, but there it is.

 

Anyways, I used the source-synchronous clock for the sensor data. I measured it and it was asserted pretty much dead nuts on with the data. I also did the design using a non-Xilinx FPGA, using nothing more than input DDR flops, and basically I just inserted a delay on the incoming clock line and tuned it until the timing analyzer told me I won.

 

I also don't clock the thing at full speed, but that's not the problem you have, I think.

----------------------------Yes, I do this for a living.
0 Kudos
Visitor grenie00
Visitor
11,752 Views
Registered: ‎08-22-2013

Re: Spartan-6, IODELAY - ISERDES in DIFF_PHASE_DETECTOR mode, bit alignment problems

Jump to solution

Tks for the quick answer. I will try this for the input clock.

 

http://www.youtube.com/watch?v=galWNVWbB4c

 

It seems to be very sensible to the phase shift...

0 Kudos
Adventurer
Adventurer
11,734 Views
Registered: ‎11-12-2010

Re: Spartan-6, IODELAY - ISERDES in DIFF_PHASE_DETECTOR mode, bit alignment problems

Jump to solution

Hello


The first Intention of sensor manufacter was generate the high-speed data clock with a PLL embedded in image sensor, so designer only must provide a slow clock (max 48MHz) and sample data with the synchronous high speed clock provided from the sensor.

 

Unfortunatelly the this PLL is buggy, and is not recommended in v1 and v2 versions of the sensor. This bug was resolved in V3 sensor.

 

The fact is that we must sample the data with a synchronous clock incoming from the same source (the sensor).

 

The Virtex4 example works with a evaluation board and V4 ISERDES is very different from Spartan6.

Virtex4 example include a manual bit alignment and word alignment. In Spartan6 bit alignment is automatic if is properly configured, but the two operations (bit align and word align) must be made continously to compensate temperature and other issues.

 

Best regards.

0 Kudos
Historian
Historian
11,728 Views
Registered: ‎02-25-2008

Re: Spartan-6, IODELAY - ISERDES in DIFF_PHASE_DETECTOR mode, bit alignment problems

Jump to solution

@david.quinones wrote:

Hello


The first Intention of sensor manufacter was generate the high-speed data clock with a PLL embedded in image sensor, so designer only must provide a slow clock (max 48MHz) and sample data with the synchronous high speed clock provided from the sensor.

 

Unfortunatelly the this PLL is buggy, and is not recommended in v1 and v2 versions of the sensor. This bug was resolved in V3 sensor.

 

The fact is that we must sample the data with a synchronous clock incoming from the same source (the sensor).


Right -- in the older versions of the chip, the PLL works so the fast LVDS clock from the FPGA to the sensor is necessary, and the sensor generates the output LVDS clock (which is source-synchronous with the sensor output data) from that fast input clock. The v3 part has a working PLL, so that clock from the FPGA to the sensor is not necessary.

 

In either case, you still capture sensor data on the clock from the sensor to the FPGA, and that's not what the vendor's example code does.

 

NB that the larger versions of that sensor still require the fast LVDS clock input because the PLL doesn't work/isn't implemented.

----------------------------Yes, I do this for a living.
0 Kudos
Visitor grenie00
Visitor
9,249 Views
Registered: ‎08-22-2013

Re: Spartan-6, IODELAY - ISERDES in DIFF_PHASE_DETECTOR mode, bit alignment problems

Jump to solution

Yes, I understand that the ISERDES is quite different in Spartan 6 compare to the Vitex 4. In the S6, there is an ISERDES2 primitive bloc that I do not use. I adapted the vendor code to the IODELAY (S6) instead of IDELAY (V4). The taps are different. In Virtex 4 there is 64 taps. In the Spartan 6, there is 256 taps. I found last week that the IODELAY2 could have "Single Data Bit Corruption in IDELAY and ODELAY Modes" according to the errata EN148 below :

http://www.xilinx.com/support/documentation/errata/en148.pdf

 

So now I'm trying to add a delay less than the maximum suggested in the table 4 but I still have bit corruptions... According to the table 4, I should not have bit corruption if I respect the maximum delay value??? So, I try to figure out where it could come from, my VHDL code or the IODEALY2 primitive...

 

grenie00

0 Kudos
Adventurer
Adventurer
9,232 Views
Registered: ‎11-12-2010

Re: Spartan-6, IODELAY - ISERDES in DIFF_PHASE_DETECTOR mode, bit alignment problems

Jump to solution

Hello Grenie

 

So, you are using IODELAY in a manual mode and you change the taps of IODELAY primitive. I remenber you that this action must be executed periodically.


Have you tried the DIFF_PHASE_DETECTOR mode?

This mode automatically find the data eye, and you save a FSM to find it, and the desing work of coordinate this action with a data pause.

 

With your work frequency ISERDES2 is optional, but can be useful also.

 

Best regards.

0 Kudos
Visitor grenie00
Visitor
9,215 Views
Registered: ‎08-22-2013

Re: Spartan-6, IODELAY - ISERDES in DIFF_PHASE_DETECTOR mode, bit alignment problems

Jump to solution

Hi David,

 

..."So, you are using IODELAY in a manual mode and you change the taps of IODELAY primitive. I remenber you that this action must be executed periodically."

 

Yes, I'm using the IODELAY2 in a manual mode and using the FSM written by the sensor manufacturer. I adapted this last one to be compatible with the IODELAY2 for the Spartan 6 FPGA we use.

 

..."Have you tried the DIFF_PHASE_DETECTOR mode?"

 

No, I did not try the DIFF_PHASE_DETECTOR mode and I do not use an ISERDES2 primitive. It's amually done in VHDL code. I'm not sure to understand this mode for IODELAY2 cause they say that it's for a special mode when we cascade delays if I understand well the description. By the way, I do not cascade IODELAY2s in my design See below :

 

UG615 (V 13.4) page 132 :

"DIFF_PHASE_DETECTOR is a special mode where the master and slave IODELAY2s are cascaded."

 

Maybe I could try, but I'm not sure I could fix the problem Xilinx have with this primitive? See below:

 

http://www.xilinx.com/support/documentation/errata/en170.pdf

 

With this following link, we could read :

http://www.xilinx.com/support/answers/38408.html

 

"Risk 
The overall failure rate is very low, and is relative to data rate and number of IODELAY2 elements used. "

 

I use may of them (18 primitives).

What is the meaning of "Low"? Here is the question...

 

grenie00

0 Kudos
Participant bgw_bogdan
Participant
9,178 Views
Registered: ‎07-26-2013

Re: Spartan-6, IODELAY - ISERDES in DIFF_PHASE_DETECTOR mode, bit alignment problems

Jump to solution

Hi,

First I'm not sure may be I should post new topic, but my question and my problem are closely related with the sensor your are talking about and Spartan 6.

I'm using the same sensor and Spartan6SLX100 with -2I grade with ISE 13.4.For implementation of DSP functions we are using Sysgen tool. For data synchronization I'm using reference design files from xapp1064.pdf and it works fine to all my boards.

 

Also we are using internal PLL from the sensor. 

 

I have some strange problems with my design. 

First I have noticed that temperature has huge influence to my design but I solved that problem with a stronger timing constrains (instead of 240MHz  I use 280MHz). I'm using only period constrains for high speed LVDS clock form sensor. 

I have a design that works just fine. All functions, everything, on all boards. But now, if I add something to my design, for example one signal to the ChipScope, nothing works. Sometimes there is no clock form the image sensor. sometimes there is a clock, but there is no valid data (instead 200 on control line, we have some values that have no sense, on data lines also).

 

Am I using right timing constrains? My only constrain related to LVDS reciver block is period constrain for high speed clock form the image sensor. like

TIMESPEC .......= PERIOD ....... 280 MHz HIGH 50%;, nothing else???

 

Are there some other problems? 

0 Kudos
Historian
Historian
9,161 Views
Registered: ‎02-25-2008

Re: Spartan-6, IODELAY - ISERDES in DIFF_PHASE_DETECTOR mode, bit alignment problems

Jump to solution

@bgw_bogdan wrote:

 

I have some strange problems with my design. 

First I have noticed that temperature has huge influence to my design but I solved that problem with a stronger timing constrains (instead of 240MHz  I use 280MHz). I'm using only period constrains for high speed LVDS clock form sensor. 


You must also use OFFSET IN constraints, as well as input delay elements, to ensure that the incoming data are captured correctly. Tightening the PERIOD constraint on the clock does not help.

----------------------------Yes, I do this for a living.
0 Kudos
Participant bgw_bogdan
Participant
9,158 Views
Registered: ‎07-26-2013

Re: Spartan-6, IODELAY - ISERDES in DIFF_PHASE_DETECTOR mode, bit alignment problems

Jump to solution

Thanks for your replay,

Can you please give me some example for OFFSET IN constrain for my case? I have DDR clock, for example clk_p and clk_n (250MHz DDR) and data_in_p(15 downto 0) and data_in_n(15 downto 0).  I'm a little bit confused with ug612 and example given for this example, so I want to be sure. Thanks a lot :)

My data clock is synchronous with data, because I receive clock and data from the image sensor. 

 

Kind regards, 

Bogdan

0 Kudos
Adventurer
Adventurer
9,127 Views
Registered: ‎11-12-2010

Re: Spartan-6, IODELAY - ISERDES in DIFF_PHASE_DETECTOR mode, bit alignment problems

Jump to solution

Hello Bogdan

 

The reference design xapp1064 include example files, including UCF with recomended constraints.

XAPP1064 have some variants (see figures 4, 5, 6 and 7 ) each of them have her example files, including UCF. I you have used these examples, the use of IDELAY-ISERDES makes unnecessary the use of OFFSET IN constraint.

 

Assuming that the version of your sensor is V3, so the incoming clock is OK, I think it exist other problem.

 

Have you verified the timings results after adding chipscope to your desing?

 

Best regards

 

 

0 Kudos
Participant bgw_bogdan
Participant
9,121 Views
Registered: ‎07-26-2013

Re: Spartan-6, IODELAY - ISERDES in DIFF_PHASE_DETECTOR mode, bit alignment problems

Jump to solution

Hello,

 

I have used ucf file from xapp1064 and timing constrains example. And it doesn't work.

 
When I increase timing period constrain, my design simply works better.
For example, if I use 280 MHz period constrain I'm getting data from the the image sensor, but there are some errors. I use cooling fan for Spartan. Without cooling fan there is no data (sometimes there is no valid data, but I have clock, sometimes there is no data at all, because there is no clock
 from the image sensor).
If I use 300 MHz period constrain and cooling fan, everything works fine. But my timing score is not 0, something about 3000...and it works???
 
If I remove DSP part of the design, and use Spratan just to transfer received data from the image sensor to the next part of the system, there are no errors, everything works fine.
 
When I decrease working frequency of the image sensor from 48 MHz to 40 MHz, there is no need for the cooling fan, and I can use real timing constrains (200MHz DDR for input clock to FPGA).  
 
Does anyone have experience with such kind of strange behavior of FPGA design? :) :D :)
 
regards,

 

0 Kudos
Participant bgw_bogdan
Participant
9,119 Views
Registered: ‎07-26-2013

Re: Spartan-6, IODELAY - ISERDES in DIFF_PHASE_DETECTOR mode, bit alignment problems

Jump to solution

david.quinones wrote:

Have you verified the timings results after adding chipscope to your desing?


Yes,  I have checked and it seems to be OK.

0 Kudos
Adventurer
Adventurer
9,105 Views
Registered: ‎11-12-2010

Re: Spartan-6, IODELAY - ISERDES in DIFF_PHASE_DETECTOR mode, bit alignment problems

Jump to solution
Seems that your system work fine.

If the DSP part have a high frequency clock maybe your system is getting too hot.

Have you used a power estimator to verify if you are working in a safe temperature zone?

High frequency I/Os are especially power hungry!, Note this sensor use 3.3V for IOs.

Best regards.
0 Kudos
Historian
Historian
7,131 Views
Registered: ‎02-25-2008

Re: Spartan-6, IODELAY - ISERDES in DIFF_PHASE_DETECTOR mode, bit alignment problems

Jump to solution

@bgw_bogdan wrote:

I have used ucf file from xapp1064 and timing constrains example. And it doesn't work.


What "doesn't work?" Specifically. Please, we are trying to help. Are constraints failing?


When I increase timing period constrain, my design simply works better.

For example, if I use 280 MHz period constrain I'm getting data from the the image sensor, but there are some errors.


You shouldn't have to overconstrain. Your main issue is ensuring that the input data are captured properly in the first place, hence the suggestion to use OFFSET IN constraints and the IODELAYs.


I use cooling fan for Spartan. Without cooling fan there is no data (sometimes there is no valid data, but I have clock, sometimes there is no data at all, because there is no clock from the image sensor).


We've found that Spartan 6 can be a real firebreather. Without proper heatsinking, the running FPGA falls down.

No clock from the image sensor sounds like a different problem. If you are using the sensor's PLL, it depends on the low-frequency clock input. If that clock stops, the PLL can't work so the LVDS data clock to the FPGA stops too.

Perhaps when the design overheats, the FPGA clocking (DCM, PLL) stops so the output clock to the sensor stops.


If I use 300 MHz period constrain and cooling fan, everything works fine. But my timing score is not 0, something about 3000...and it works???


You fail to meet the worst-case timing constraints at 300 MHz, but since you are cooling the chip, the die temperature is much better than the worst case, so the design in that case "could" work. If you backed off your timing constraints to the actual requirement -- 240 MHz -- and you meet that requirement (as well as meeting OFFSET IN timing) and if you provide cooling, your design will work.


If I remove DSP part of the design, and use Spratan just to transfer received data from the image sensor to the next part of the system, there are no errors, everything works fine.


The DSP logic is power hungry. You're reducing the die temperature by removing that logic, which means that you could be working in an area where the design actually works. No guarantees, though, without proper constraints.


When I decrease working frequency of the image sensor from 48 MHz to 40 MHz, there is no need for the cooling fan, and I can use real timing constrains (200MHz DDR for input clock to FPGA).


You're dealing with CMOS logic -- the lower the switching frequency, the lower the power consumption, and thus the die temperature is lower, too. This should not be a surprise whatsoever.

Plus lowering the frequency means that you might meet timing. You failed at 240 MHz, perhaps the design can run comfortably at 225 MHz, you're running at 200 MHz, so you win. PROPER CONSTRAINTS WILL TELL YOU.


Does anyone have experience with such kind of strange behavior of FPGA design? :) :D :) 


it's not strange at all. It's entirely understandable. Please, read carefully what I wrote. It should all make sense.

----------------------------Yes, I do this for a living.
Participant bgw_bogdan
Participant
7,090 Views
Registered: ‎07-26-2013

Re: Spartan-6, IODELAY - ISERDES in DIFF_PHASE_DETECTOR mode, bit alignment problems

Jump to solution

Hi,

thank you for your response to my questions. 
 
There is no falling constrains in my design. I know I shouldn't have over-constrained my system, but it seems it works better.  
 
Can somebody explain to me how to use OFFSET IN constrain for this case? please...
I use reference files from xapp1064.pdf for data and clock receivingMy input DDR clock is synchronous with data. .Is it necessary to use this constrains for my case? 

 

0 Kudos
Adventurer
Adventurer
5,533 Views
Registered: ‎11-12-2010

Re: Spartan-6, IODELAY - ISERDES in DIFF_PHASE_DETECTOR mode, bit alignment problems

Jump to solution

Hello Bill

 

I'm actually updating our product to sensor version 3 and I have found a small problem concerning the phase difference between system clock and paralleled data from ISERDES infraestructure.

 

This phase difference is random and I would like to make it fix or at least know this difference.

I need to know it because paralleled data is passed to system clock domain.

 

Do you know any mechanism to sinchonize these two clocks.

 

Best regards.

 

David QM

0 Kudos