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: 
Visitor guwaiting
Visitor
9,831 Views
Registered: ‎05-23-2012

Driving BUFIO with IDELAYE2 in Zynq7045 FPGA

Hi Guys,

I'm using Zynq7045.

In my design I need a reconfigurable DELAY.

Connection is shown like this: PAD<-->IOBUF-->IDELAYE2-->some combinatorial logic-->BUFIO-->IDDR.

 

But Place&Route fails. Report shows that some combinatorial logic-->BUFIO is unroutable.

 

UG472 says:

BUFIOs are driven by:
• SRCCs and MRCCs in the same clock region
• MRCCs in an adjacent clock region using BUFMRs
• MMCMs clock outputs 0-3 driving the HPC in the same clock region
• General interconnect

In my understanding, output from internal Slices is General interconnect.

 

Now my question is:

1, How this happens? Why BUFIO can not be driven by IDELAYE2-->some combinatorial logic?

2, What is the alternative solution?

 

thx

John.

 

0 Kudos
11 Replies
Scholar trenz-al
Scholar
9,829 Views
Registered: ‎11-09-2013

Re: Driving BUFIO with IDELAYE2 in Zynq7045 FPGA

just read a bit more:)

 

 xx >>> logic > BUFMR >> BUFIO >> IDDR

 

this works, only limit is that all your BUFIO must be in 3 vertically adjacent bansk any you lock the BUFMR in the middle.

 

we are testing our dual DAC9739 IP Core where one clock input is spread into 3 banks between 2 DACs and we sure have to sure BUFIO clocked from SINGLE source. BUFMR works.

0 Kudos
Visitor guwaiting
Visitor
9,818 Views
Registered: ‎05-23-2012

Re: Driving BUFIO with IDELAYE2 in Zynq7045 FPGA

trenz-al,thx
I'll try it.
Since all the IOs are in the same bank. BUFR may be OK.
0 Kudos
Scholar trenz-al
Scholar
9,812 Views
Registered: ‎11-09-2013

Re: Driving BUFIO with IDELAYE2 in Zynq7045 FPGA

BUFMR!!

 

BUFMR can drive BUFR and BUFIO

 

BUFMR allows logic to enter BUFR and BUFIO

0 Kudos
Historian
Historian
9,804 Views
Registered: ‎01-23-2009

Re: Driving BUFIO with IDELAYE2 in Zynq7045 FPGA

You are right that the documentation says that it can be driven by general interconnect... But...

 

You really don't want to do that. If you are trying to capture a hight speed input (and I am inferring that you do since you are playing with the IDELAY), then you need to use a clocking scheme that reliably captures the interface. To do this, you need to stay entirely in dedicated clocking resources. That means using

 

CCIO -> IBUF -> IDELAY -> BUFIO -> IDDR.CLK

                                             -> BUFR -> {fabric logic receiving data from the IDDR}

 

I/O ->  IBUF     -> IDELAY                  -> IDDR.D

 

 

 

These are all dedicated connections and will yield the best and reproducible timing. Taking a "side trip" into general interconnect will totally mess up timing; you will get different timing characteristics from run to run.

 

My suggestion to you is, rather than trying to figure a way to make this connection legal, is to figure a way to do without it. I see that you said IOBUF (rather than IBUF), so I guess that at some times this is not an input clock, but is something else, and I presume your "some combinatorial logic" is to only clock the IDDR when the clock is a valid input clock.

 

Perhaps a better way is to always capture the data in the IDDR (even when the CLK is not a valid clock), but just not use the data captured by the IDDR during clock periods where the clock is not a clock.

 

Avrum

Scholar trenz-al
Scholar
9,797 Views
Registered: ‎11-09-2013

Re: Driving BUFIO with IDELAYE2 in Zynq7045 FPGA

there are cases where you need

 

BUFIO clocks in different banks, all PHASE aligned

 

but with NO PHASE rquirement to he clock input, then 

 

some clock > fabric > BUFMR > BUFIO and BUFR in 3 clock regions is totally valid and OK

 

the random delay from clock in to BUFMR input does not matter, from BUFMR >> there is all in phase

0 Kudos
Historian
Historian
9,794 Views
Registered: ‎01-23-2009

Re: Driving BUFIO with IDELAYE2 in Zynq7045 FPGA

the random delay from clock in to BUFMR input does not matter, from BUFMR >> there is all in phase

 

The BUFMR is also a dedicated clock resource, and is co-located with the CCIO/BUFIO/BUFR. While there is a small additional delay penalty to going though the BUFMR, which has a (correspondingly) small impact on the setup/hold requirement of the captured inputs, it is a valid connection.

 

CCIO -> IBUF -> IDELAY -> BUMR -> BUFIO -> IDDR.CLK

                                                              -> BUFR -> {fabric logic receiving data from the IDDR}

                                                              -> BUFIO -> {IDDR.CLK (in adjacent clock regions}

                                                              -> BUFR -> {fabric logic receiving data from the IDDR in adjacent clock regions}

 

 

I/O ->  IBUF     -> IDELAY                  -> IDDR.D

 

These are the most common use case for the BUFMR/BUFIO/BUFR on a source synchronous input interface (either using an IDDR or an ISERDES).

 

There are other valid drivers of the BUFMR - notably the first four outputs of an MMCM in the same clock region of the BUFMR. This is most often used for a source synchronous output interface (where the forwarded clock is generated using an ODDR)

 

Coming from the fabric is never an ideal solution. While it does work in the case of a clock forwarded output interface, the resulting clock will have an unknown phase (which isn't necessarily a problem for a forwarded interface), but also will have more jitter than a clock coming directly from an MMCM.

 

Avrum

0 Kudos
Visitor guwaiting
Visitor
9,788 Views
Registered: ‎05-23-2012

Re: Driving BUFIO with IDELAYE2 in Zynq7045 FPGA

Yes, BUFMR works now.

All the path are routed.

0 Kudos
Visitor guwaiting
Visitor
9,785 Views
Registered: ‎05-23-2012

Re: Driving BUFIO with IDELAYE2 in Zynq7045 FPGA

All your inferring about my design is correct. Thx

 

1)CCIO -> IBUF -> IDELAY -> BUMR -> BUFIO -> IDDR.CLK

                                                                  -> BUFR -> {fabric logic receiving data from the IDDR}

                                                                  -> BUFIO -> {IDDR.CLK (in adjacent clock regions}

                                                                  -> BUFR -> {fabric logic receiving data from the IDDR in adjacent clock regions}

 

 

2)I/O ->  IBUF     -> IDELAY                  -> IDDR.D

 

Now both cases works.

Case2 is my prior solution. Comparing with case1, delay introduced is smaller.

As a freshman, I think IDDR drived by BUFIO can get better performance. Is it right? That's why I'm trying BUFIO.

 

Target frequency for my design is 200MHz, do you think case2 can meet the requirement?

0 Kudos
Scholar trenz-al
Scholar
9,777 Views
Registered: ‎11-09-2013

Re: Driving BUFIO with IDELAYE2 in Zynq7045 FPGA

is your incoming bitclock only 200mhz ? that is not at all problem :) when you do it ALL REALLY CORRECTLY.

 

a very good starting point is XAPP524, there are however errors and issues with it also.

 

https://wiki.trenz-electronic.de/display/IP/LVDS_ADC

 

we will soon publish our LVDS ADC IP core, I am currently testing it at moderate 250mhz bit clock, that is 500mbit/s per bitlane speeds.

 

NOTE, FPGA delays are there! comparable or larger the PCB track delays and FPGA package delays, it is good to compare in your head FPGA internal delays to PCB track length:

 

IDELAY with delay 0 = 300 millimeters, 30 cm

BUFIO = 150 millimeter, 15 cm

BUFIO routing to destination = 50 mm, 5 cm

 

If you look at those DELAYS converted to PCB track length then it is clear HOW important proper design is.

 

good luck!

0 Kudos
Historian
Historian
5,750 Views
Registered: ‎01-23-2009

Re: Driving BUFIO with IDELAYE2 in Zynq7045 FPGA

All your inferring about my design is correct. Thx

 

I am not sure you understood what I said. The two portions of the connectivity, which you have labelled 1) and 2) are not two different options, but part of the same design. The part marked 1) is the path the clock must take to get to the IDDR capture flip-flops, and the part marked 2) is the path the data must take to get to the IDDR flip-flops. Both parts are required for a complete solution.

 

There are two options for the clock part; the one outlined in my earlier post, which can use an SRCC or MRCC clock capable input and a single BUFIO/BUFR pair, which is sufficient for an interface that is contained in one I/O bank, or the one outlined in my 2nd post, which uses an MRCC clock capable input, the BUFMR and multiple BUFIO/BUFR pairs in adjacent I/O banks/clock regions.

 

Avrum

0 Kudos
Visitor asharapov
Visitor
1,113 Views
Registered: ‎01-31-2013

Re: Driving BUFIO with IDELAYE2 in Zynq7045 FPGA

Dear Avrum,

 

I have the similar problem.

 

You mentioned the next clocking scheme:

 

CCIO -> IBUF -> IDELAY -> BUFIO -> IDDR.CLK

                                             -> BUFR -> {fabric logic receiving data from the IDDR}

 

I/O ->  IBUF     -> IDELAY                  -> IDDR.D

 

XAPP524 specified the same

 

bufio.PNG

 

But it cause a placement error. BUFR does not such problems.

 

The first message from P&R:

 

[Vivado 12-1411] Cannot set LOC property of ports, Illegal to place instance ..../inst/io_inst on site TIEOFF_X0Y40. The location site type does not match the instance type. Instance ..../inst/io_inst belongs to a shape with reference instance ..../inst/iob_clk_in/IBUFDS. Shape elements have relative placement respect to each other. The invalid location might results from a constraint on any of the instance in the shape. ["..../constrs_1/new/pins.xdc":1]

 

Could you comment?

 

Thank you,

Alex

 

0 Kudos