Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

[SOLVED] Problem in deserializing data on xilinx xc7z045-1-fbg676 device

Status
Not open for further replies.
P

punit1053

Newbie level 6
Joined
Jun 29, 2015
Messages
13
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
143
Hi,
I am working on a custom board which is having xilinx xc7z045-1-fbg676 device. I am trying to receive data serially through 16 channel through IO ports where the frame clock is 20M and data clock is 160M DDR. The problem is that in behavioral and PAR simulation I am getting the proper results, even I constrained the design properly and it met all timings but while probing the received data through CHIPSCOPE I found that through 13 channels only I am able to receive proper data not all 16 channel. I am not able to figure out what went wrong.

One more thing, I was getting warning that the BUFG site for data clock and data clock pin site are not same. To quit this warning I used CLOCK DEDICATED ROUTE = FALSE constrain. The pins are already connected to the device I can't change sites.
 

Post the exact warning given by the tools not your interpretation of the warning.

You likely have an uncompensated insertion delay in the clock due to the clock pin used or you used the wrong clock buffer type (if instantiated) to connect the clock to the DDR input registers and the input logic. As the clock is not using the dedicated route you may have 3 of the channels with abnormally large skew as they may be routed using fabric resources instead of the clock network.

To really help, you'll have to supply the code, pinout of the interface and the constraints.

Also the frame clock and data clock you mention may be a problem as you never mention if they are being used synchronous to each other or if there is actual synchronization going on. Having two clocks on an interface is usually a bad idea. One clock and perhaps a signal (synchronous) to the clock that frames the signal is normal. So a protocol of the interface might be useful too.
 

Hi ads-ee,

Thanks a lot for the quick reply. Here is the warning and the deserialization codes are attached

Place:1399 - A clock IOB / BUFGCTRL clock component pair have been found that are not placed at an optimal clock IOB / BUFGCTRL site pair. The clock IOB component <afe2_fclkp> is placed at site <W18>. The corresponding BUFGCTRL component <Afe2_Fclk_BUFG> is placed at site <BUFGCTRL_X0Y22>. Theclock IO can use the fast path between the IOB and the Clock Buffer if the IOB is placed on a Clock Capable IOB site that has dedicated fast path to BUFGCTRL sites in its half of the device (TOP or BOTTOM). You may want to analyze why this problem exists and correct it. This is normally an ERROR but the CLOCK_DEDICATED_ROUTE constraint was applied on COMP.PIN <afe2_fclkp.PAD> allowing your design to continue. This constraint disables all clock placer rules related to the specified COMP.PIN. The use of this override is highly discouraged as it may lead to very poor timing results. It is recommended that this error condition be corrected in the design.

Place:1399 - A clock IOB / BUFGCTRL clock component pair have been found that are not placed at an optimal clock IOB / BUFGCTRL site pair. The clock IOB component <afe1_fclkp> is placed at site <AE20>. The corresponding BUFGCTRL component <Afe1_Fclk_BUFG> is placed at site <BUFGCTRL_X0Y14>. The clock IO can use the fast path between the IOB and the Clock Buffer if the IOB is placed on a Clock Capable IOB site that has dedicated fast path to BUFGCTRL sites in its half of the device (TOP or BOTTOM). You may want to analyze why this problem exists and correct it. This is normally an ERROR but the CLOCK_DEDICATED_ROUTE constraint was applied on COMP.PIN <afe1_fclkp.PAD> allowing your design to continue. This constraint disables all clock placer rules related to the specified COMP.PIN. The use of this override is highly discouraged as it may lead to very poor timing results. It is recommended that this error condition be corrected in the design.
Click to expand...
Regarding two clocks i.e frame clock and data clock, they are synchronous. within one frame clock I have either receive 8 or 7 bits depending on ADC setting. Also at the interface I am having differential clocks (both data and frame). I am using differential clock(both p and n clock) to deserialize data and converting the differential frame clock into single ended clock. The ucf is :

Code dot - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

NET "clk_100M"              LOC =   AC14    |   IOSTANDARD  =   "LVCMOS18";
        
    NET "afe1_fclkp"            LOC =   W18 |   IOSTANDARD  =   "DIFF_HSTL_II_18";
    NET "afe1_fclkn"            LOC =   W19 |   IOSTANDARD  =   "DIFF_HSTL_II_18";
    NET "afe1_dclkp"            LOC =   AA24    |   IOSTANDARD  =   "DIFF_HSTL_II_18";
    NET "afe1_dclkn"            LOC =   AB24    |   IOSTANDARD  =   "DIFF_HSTL_II_18";
    NET "afe1_datain_p_ch1" LOC =   AB26    |   IOSTANDARD  =   "DIFF_HSTL_II_18";
    NET "afe1_datain_n_ch1" LOC =   AC26    |   IOSTANDARD  =   "DIFF_HSTL_II_18";
    
    NET "afe_sdout"             LOC =   AA15    |   IOSTANDARD  =   "LVCMOS18";
    
    NET "afe1_dataout<0>"       LOC     =   AD13    |   IOSTANDARD  =   "LVCMOS18";
    NET "afe1_dataout<10>"      LOC     =   AD10    |   IOSTANDARD  =   "LVCMOS18";
    NET "afe1_dataout<1>"       LOC     =   AC13    |   IOSTANDARD  =   "LVCMOS18";
    NET "afe1_dataout<11>"      LOC     =   AE10    |   IOSTANDARD  =   "LVCMOS18";
    NET "afe1_dataout<2>"       LOC     =   AD11    |   IOSTANDARD  =   "LVCMOS18";
    NET "afe1_dataout<12>"      LOC     =   AA13    |   IOSTANDARD  =   "LVCMOS18";
    NET "afe1_dataout<3>"       LOC     =   AC12    |   IOSTANDARD  =   "LVCMOS18";
    NET "afe1_dataout<13>"      LOC     =   AA12    |   IOSTANDARD  =   "LVCMOS18";
    NET "afe1_dataout<4>"       LOC     =   AF13    |   IOSTANDARD  =   "LVCMOS18";
    NET "afe1_dataout<14>"      LOC     =   W13 |   IOSTANDARD  =   "LVCMOS18";
    NET "afe1_dataout<5>"       LOC     =   AE13    |   IOSTANDARD  =   "LVCMOS18";
    NET "afe1_dataout<15>"      LOC     =   AB10    |   IOSTANDARD  =   "LVCMOS18";
    NET "afe1_dataout<6>"       LOC     =   AF10    |   IOSTANDARD  =   "LVCMOS18";
    NET "afe1_dataout<7>"       LOC     =   AE11    |   IOSTANDARD  =   "LVCMOS18";
    NET "afe1_dataout<8>"       LOC     =   AF12    |   IOSTANDARD  =   "LVCMOS18";
    NET "afe1_dataout<9>"       LOC     =   AE12    |   IOSTANDARD  =   "LVCMOS18";
    
    NET "test_fclk"  LOC = W16  |   IOSTANDARD  =   "LVCMOS18";
    NET "test_dclkp" LOC = W15  |   IOSTANDARD  =   "LVCMOS18";
    NET "valid_out"  LOC = Y15  |   IOSTANDARD  =   "LVCMOS18";
    NET "ser_data"    LOC = W17 |   IOSTANDARD  =   "LVCMOS18";
#   NET "reset"       LOC = C12 |   IOSTANDARD  =   "LVCMOS18";
    
    NET "Afe1_Fclk" TNM_NET = "Afe1_Fclk";
    TIMESPEC TS_Afe1_Fclk  = PERIOD "Afe1_Fclk" 50 ns HIGH 50 %;
    
    NET "Afe1_Dclkp" TNM_NET = "Afe1_Dclkp";
    TIMESPEC TS_Afe1_Dclkp  = PERIOD "Afe1_Dclkp" 6.25 ns HIGH 50 %;
    
    NET "Afe1_Dclkn" TNM_NET = "Afe1_Dclkn";
    TIMESPEC TS_Afe1_Dclkn  = PERIOD "Afe1_Dclkn" 6.25 ns HIGH 50 %;
    
    NET "Clk_40M" TNM_NET = "Clk_40M";
    TIMESPEC TS_Clk_40M  = PERIOD "Clk_40M" 25 ns HIGH 50 %;
    
    NET "Clk_20M" TNM_NET = "Clk_20M";
    TIMESPEC TS_Clk_20M  = PERIOD "Clk_20M" 50 ns HIGH 50 %;
    
    NET "Clk_10M" TNM_NET = "Clk_10M";
    TIMESPEC TS_Clk_10M  = PERIOD "Clk_10M" 100 ns HIGH 50 %;
    
    NET "afe1_fclkp" CLOCK_DEDICATED_ROUTE = FALSE;
    NET "afe1_fclkn" CLOCK_DEDICATED_ROUTE = FALSE;
    NET "afe1_dclkp" CLOCK_DEDICATED_ROUTE = FALSE;
    NET "afe1_dclkn" CLOCK_DEDICATED_ROUTE = FALSE;
 

Attachments

  • deserialization.rar
    9.4 KB · Views: 57
Last edited by a moderator:

W18 is not a clock capable pin, therefore the warning/error is correct and the delay from that pin can't be properly compensated. You will likely have problems with that interface on every build. Also you may end up having issues with timing over PVT.

Who ever decided the pinout screwed up by not reading Xilinx's documentation, otherwise they would have realized that the clocks should all be on SRCC or MRCC pins only.

You have two choices, reduce the clock frequency to increase margins and clock the inputs mid-bit or respin the board. Other options will be more expensive in the long run as they would require tuning each and every board across PVT by adjusting the timing of the inputs using the IODELAY.

You might get away with using input and output constraints on all your I/O on the interface, but that still might result in PVT problems as the clock path delay is not compensated.

I suggest you re-spin the board, you're only asking for trouble if you stick with the current pinout. I would only keep the current pinout if the person doing the work is an FPGA expert, who can use directed routing, placement, and timing constraints to limit the variations between builds. And furthermore knows how to use the IODELAY to adjust the input timing of the serial streams to compensate for any variations or possibly design a circuit to auto calibrate the delays.
 
Finally took a look at your code. I'm not sure why you are using _n and _p versions of the clock, a differential input should result in one single ended clock internally, as an ibufgds will be implemented.

So are you specifying a differential standard for the IO but using the clocks as separate internal _n and _p (180 phase) clocks? I'm surprised the tools didn't give a warning or an error for that too.
 

I've had to deal with a similar issue in the past, though it was a Virtex5 design and used UCF. This was for RGMII (250MHz). It's been a while, so I don't recall the exact details.

The key things to do are:
1.) Have timing constraints for the inputs.
2.) Have a directed routing constraint for the clock.
3.) If needed, add IOdelays for data/clock.
4.) If needed, add autocalibration for this. This part is harder, so do the other parts first.

#1 and #2 are critical. As the design gets larger, the clock routing changes with each build. Better to start from a minimal design and lock down the best route first. #1 is your backup to warn you if this fails. Also #1 is needed for #3 as the delays can be confusing. #4 is more difficult and application specific.

To get the DiRT constraint, load the design into the FPGA editor, find the route, and then export it to a constraint. I don't recall the exact menu items as I did it once.

This basically mirrors what Ads-ee says. I just wanted to relay my personal experience with this type of issue and emphasize the value/rationale behind the DiRT and input constraints.
 
Last edited:
vGoodtimes said:
The key things to do are:
1.) Have timing constraints for the inputs.
2.) Have a directed routing constraint for the clock.
3.) If needed, add IOdelays for data/clock.
4.) If needed, add autocalibration for this. This part is harder, so do the other parts first.

I just wanted to relay my personal experience with this type of issue and emphasize the value/rationale behind the DiRT and input constraints.
Click to expand...
I've done the same thing in the past that is why I suggest that the OP not do this and just respin the board. 2-4 are not exactly beginner topics and as the OP has a board that does not have the clock in the right location, I'm assuming they are not an advanced FPGA user.

It's great you took the time to document the salient points, it certainly makes the thread more useful for someone stuck in the same situation.
 

ads-ee said:
Finally took a look at your code. I'm not sure why you are using _n and _p versions of the clock, a differential input should result in one single ended clock internally, as an ibufgds will be implemented.

So are you specifying a differential standard for the IO but using the clocks as separate internal _n and _p (180 phase) clocks? I'm surprised the tools didn't give a warning or an error for that too.
Click to expand...

First I tried with the IBUFDS (not IBUFGDS as it was throwing error) buffer and used single ended clock to shift in data at posedge and negedge(as I already told that the serial data is coming at DDR rate) but it was giving me some timing issues. Then I used IBUFDS_DIFF_OUT buffer to bring differential clocks and shift in data into separate registers on every posedge of the _p and _n clocks and the timing issues were gone.
And Yes as you said in your last post ... I am not an advance FPGA user :), just a beginner, a first year Graduate student and it is my first time exposer to FPGAs and I will always remain thankful to you people for help.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top