EDAboard.com | EDAboard.eu | EDAboard.de | EDAboard.co.uk | RTV forum PL | NewsGroups PL

EDK : FSL macros defined by Xilinx are wrong

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - FPGA - EDK : FSL macros defined by Xilinx are wrong

Goto page Previous  1, 2, 3 ... 356, 357, 358


Guest

Wed Apr 12, 2017 8:29 pm   



Den onsdag den 12. april 2017 kl. 05.37.07 UTC+2 skrev John Larkin:
Quote:
On Tue, 11 Apr 2017 09:29:03 -0700 (PDT), Kevin Neilson
kevin.neilson_at_xilinx.com> wrote:

On Monday, April 10, 2017 at 7:13:23 PM UTC-6, John Larkin wrote:
We have a ZYNQ whose predicted timing isn't meeting decent margins.
And we don't want a lot of output pin timing variation in real life.

We can measure the chip temperature with the XADC thing. So, why not
make an on-chip heater? Use a PLL to clock a bunch of flops, and vary
the PLL output frequency to keep the chip temp roughly constant.

I'm confused by the concept. Doesn't timing get *worse* as temp increases?

Prop delays get slower.

How would a higher temperature help?

High temperature is an unfortunate fact of life some times. I'm after
constant temperature, to minimize delay variations as ambient temp and
logic power dissipations change.

By "output pin timing variation" do you mean that there are combinatorial output paths? I think the best best is to stay as cool as possible and keep all outputs registered.

All our critical outputs are registered in the i/o cells. Xilinx tools
report almost a 3:1 delay range from clock to outputs, over the full
range of process, power supply, and temperature. Apparently the tools
assume the max specified Vcc and temperature spreads for the part and
don't let us tease out anything, or restrict the analysis to any
narrower ranges.


If you really need to control output delay you can use the IODELAY block, possibly along with a copper trace feedback line.


Our output data-valid window is predicted by the tools to be very
narrow relative to the clock period. We figure that controlling the
temperature (and maybe controlling Vcc-core vs temperature) will open
up the timing window. The final analysis will have to be experimental.

We can't crank in a constant delay to fix anything; the problem is the
predicted variation in delay.


that is basically what the IDELAY/ODELAY blocks are for, you instantiate an IDELAYCTRL and feed it a ~200MHz clock and it uses that a reference to
reduce the effects of process, voltage, and temperature on the iodelay

Kevin Neilson
Guest

Wed Apr 12, 2017 9:37 pm   



Quote:
If you really need to control output delay you can use the IODELAY block, possibly along with a copper trace feedback line.


Our output data-valid window is predicted by the tools to be very
narrow relative to the clock period. We figure that controlling the
temperature (and maybe controlling Vcc-core vs temperature) will open
up the timing window. The final analysis will have to be experimental.

We can't crank in a constant delay to fix anything; the problem is the
predicted variation in delay.


I still think the IODELAY could help you. The output goes through an adjustable IODELAY, then you route the output back in through a pin, adjust the input IODELAY to figure out where the incoming edge is, and then use a feedback loop to keep the output delay constant. It's a technique used for deskewing DRAM data. I think the main clock would also have to be deskewed with a BUFG so you have a good reference for the input. Or, if you characterized the delay-vs-temp in the lab, you could run in open-loop mode by adjusting the IODELAY tap based on the temperature you read.

Yes, the tools are definitely pessimistic. They're only useful for worst-case. I'm pretty sure you can put in the max temperature when doing PAR, so you could isolate the effects of just that, but it will still probably be worse variation than in reality.

John Larkin
Guest

Wed Apr 12, 2017 10:20 pm   



On Wed, 12 Apr 2017 12:37:59 -0700 (PDT), Kevin Neilson
<kevin.neilson_at_xilinx.com> wrote:

Quote:
If you really need to control output delay you can use the IODELAY block, possibly along with a copper trace feedback line.


Our output data-valid window is predicted by the tools to be very
narrow relative to the clock period. We figure that controlling the
temperature (and maybe controlling Vcc-core vs temperature) will open
up the timing window. The final analysis will have to be experimental.

We can't crank in a constant delay to fix anything; the problem is the
predicted variation in delay.


I still think the IODELAY could help you. The output goes through an adjustable IODELAY, then you route the output back in through a pin, adjust the input IODELAY to figure out where the incoming edge is, and then use a feedback loop to keep the output delay constant. It's a technique used for deskewing DRAM data. I think the main clock would also have to be deskewed with a BUFG so you have a good reference for the input. Or, if you characterized the delay-vs-temp in the lab, you could run in open-loop mode by adjusting the IODELAY tap based on the temperature you read.

Yes, the tools are definitely pessimistic. They're only useful for worst-case. I'm pretty sure you can put in the max temperature when doing PAR, so you could isolate the effects of just that, but it will still probably be worse variation than in reality.


My FPGA guy says that the ZYNQ does not have adjustable delay after
the i/o block flops. We can vary drive strength in four steps, and we
may be able to do something with that.


--

John Larkin Highland Technology, Inc
picosecond timing precision measurement

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

rickman
Guest

Wed Apr 12, 2017 10:27 pm   



On 4/12/2017 4:20 PM, John Larkin wrote:
Quote:
On Wed, 12 Apr 2017 12:37:59 -0700 (PDT), Kevin Neilson
kevin.neilson_at_xilinx.com> wrote:

If you really need to control output delay you can use the IODELAY block, possibly along with a copper trace feedback line.


Our output data-valid window is predicted by the tools to be very
narrow relative to the clock period. We figure that controlling the
temperature (and maybe controlling Vcc-core vs temperature) will open
up the timing window. The final analysis will have to be experimental.

We can't crank in a constant delay to fix anything; the problem is the
predicted variation in delay.


I still think the IODELAY could help you. The output goes through an adjustable IODELAY, then you route the output back in through a pin, adjust the input IODELAY to figure out where the incoming edge is, and then use a feedback loop to keep the output delay constant. It's a technique used for deskewing DRAM data. I think the main clock would also have to be deskewed with a BUFG so you have a good reference for the input. Or, if you characterized the delay-vs-temp in the lab, you could run in open-loop mode by adjusting the IODELAY tap based on the temperature you read.

Yes, the tools are definitely pessimistic. They're only useful for worst-case. I'm pretty sure you can put in the max temperature when doing PAR, so you could isolate the effects of just that, but it will still probably be worse variation than in reality.

My FPGA guy says that the ZYNQ does not have adjustable delay after
the i/o block flops. We can vary drive strength in four steps, and we
may be able to do something with that.


That's also not adjustable in real time though.

I believe what the others are talking about is a real time adjustable
delay that is built into the clocking module. I don't know about the
Zynq, but Xilinx has what they call a delay locked loop which sounds
exactly like what you need. I believe it works by syncing the output
signal to the clock signal. There will be some signal path in the
feedback loop which will still cause timing variation with temperature
and I suppose voltage, but the variation in process can be compensated.

--

Rick C

Gabor
Guest

Wed Apr 12, 2017 11:16 pm   



On Wednesday, 4/12/2017 4:27 PM, rickman wrote:
Quote:
On 4/12/2017 4:20 PM, John Larkin wrote:
On Wed, 12 Apr 2017 12:37:59 -0700 (PDT), Kevin Neilson
kevin.neilson_at_xilinx.com> wrote:

If you really need to control output delay you can use the IODELAY
block, possibly along with a copper trace feedback line.


Our output data-valid window is predicted by the tools to be very
narrow relative to the clock period. We figure that controlling the
temperature (and maybe controlling Vcc-core vs temperature) will open
up the timing window. The final analysis will have to be experimental.

We can't crank in a constant delay to fix anything; the problem is the
predicted variation in delay.


I still think the IODELAY could help you. The output goes through an
adjustable IODELAY, then you route the output back in through a pin,
adjust the input IODELAY to figure out where the incoming edge is,
and then use a feedback loop to keep the output delay constant. It's
a technique used for deskewing DRAM data. I think the main clock
would also have to be deskewed with a BUFG so you have a good
reference for the input. Or, if you characterized the delay-vs-temp
in the lab, you could run in open-loop mode by adjusting the IODELAY
tap based on the temperature you read.

Yes, the tools are definitely pessimistic. They're only useful for
worst-case. I'm pretty sure you can put in the max temperature when
doing PAR, so you could isolate the effects of just that, but it will
still probably be worse variation than in reality.

My FPGA guy says that the ZYNQ does not have adjustable delay after
the i/o block flops. We can vary drive strength in four steps, and we
may be able to do something with that.

That's also not adjustable in real time though.

I believe what the others are talking about is a real time adjustable
delay that is built into the clocking module. I don't know about the
Zynq, but Xilinx has what they call a delay locked loop which sounds
exactly like what you need. I believe it works by syncing the output
signal to the clock signal. There will be some signal path in the
feedback loop which will still cause timing variation with temperature
and I suppose voltage, but the variation in process can be compensated.


In the 7-series what you want is the MMCM, which has the ability to
adjust the output phase in steps of 1/56 of the VCO period. This
adjustment can be applied to a subset of the MMCM outputs, so you
can for example vary the outgoing clock phase while keeping the
data phase constant with respect to the clock driving the MMCM.

On the other hand, the whole point of a source synchronous interface
is to just need low skew between outputs - not low skew between the
input clock and the outputs. Typically just placing the outputs in
the IOB and using the same clock resource is good enough. Skew
between outputs is much lower than the variance in output delay.

--
Gabor

--
Gabor

rickman
Guest

Wed Apr 12, 2017 11:37 pm   



On 4/12/2017 5:16 PM, Gabor wrote:
Quote:
On Wednesday, 4/12/2017 4:27 PM, rickman wrote:
On 4/12/2017 4:20 PM, John Larkin wrote:
On Wed, 12 Apr 2017 12:37:59 -0700 (PDT), Kevin Neilson
kevin.neilson_at_xilinx.com> wrote:

If you really need to control output delay you can use the IODELAY
block, possibly along with a copper trace feedback line.


Our output data-valid window is predicted by the tools to be very
narrow relative to the clock period. We figure that controlling the
temperature (and maybe controlling Vcc-core vs temperature) will open
up the timing window. The final analysis will have to be experimental.

We can't crank in a constant delay to fix anything; the problem is the
predicted variation in delay.


I still think the IODELAY could help you. The output goes through
an adjustable IODELAY, then you route the output back in through a
pin, adjust the input IODELAY to figure out where the incoming edge
is, and then use a feedback loop to keep the output delay constant.
It's a technique used for deskewing DRAM data. I think the main
clock would also have to be deskewed with a BUFG so you have a good
reference for the input. Or, if you characterized the delay-vs-temp
in the lab, you could run in open-loop mode by adjusting the IODELAY
tap based on the temperature you read.

Yes, the tools are definitely pessimistic. They're only useful for
worst-case. I'm pretty sure you can put in the max temperature when
doing PAR, so you could isolate the effects of just that, but it
will still probably be worse variation than in reality.

My FPGA guy says that the ZYNQ does not have adjustable delay after
the i/o block flops. We can vary drive strength in four steps, and we
may be able to do something with that.

That's also not adjustable in real time though.

I believe what the others are talking about is a real time adjustable
delay that is built into the clocking module. I don't know about the
Zynq, but Xilinx has what they call a delay locked loop which sounds
exactly like what you need. I believe it works by syncing the output
signal to the clock signal. There will be some signal path in the
feedback loop which will still cause timing variation with temperature
and I suppose voltage, but the variation in process can be compensated.


In the 7-series what you want is the MMCM, which has the ability to
adjust the output phase in steps of 1/56 of the VCO period. This
adjustment can be applied to a subset of the MMCM outputs, so you
can for example vary the outgoing clock phase while keeping the
data phase constant with respect to the clock driving the MMCM.

On the other hand, the whole point of a source synchronous interface
is to just need low skew between outputs - not low skew between the
input clock and the outputs. Typically just placing the outputs in
the IOB and using the same clock resource is good enough. Skew
between outputs is much lower than the variance in output delay.


Yeah, well, it's not like we really know the true and full problem. We
just know he doesn't like the timing range reported by the tools.

--

Rick C


Guest

Thu Apr 13, 2017 12:09 am   



Den onsdag den 12. april 2017 kl. 22.20.19 UTC+2 skrev John Larkin:
Quote:
On Wed, 12 Apr 2017 12:37:59 -0700 (PDT), Kevin Neilson
kevin.neilson_at_xilinx.com> wrote:

If you really need to control output delay you can use the IODELAY block, possibly along with a copper trace feedback line.


Our output data-valid window is predicted by the tools to be very
narrow relative to the clock period. We figure that controlling the
temperature (and maybe controlling Vcc-core vs temperature) will open
up the timing window. The final analysis will have to be experimental.

We can't crank in a constant delay to fix anything; the problem is the
predicted variation in delay.


I still think the IODELAY could help you. The output goes through an adjustable IODELAY, then you route the output back in through a pin, adjust the input IODELAY to figure out where the incoming edge is, and then use a feedback loop to keep the output delay constant. It's a technique used for deskewing DRAM data. I think the main clock would also have to be deskewed with a BUFG so you have a good reference for the input. Or, if you characterized the delay-vs-temp in the lab, you could run in open-loop mode by adjusting the IODELAY tap based on the temperature you read.

Yes, the tools are definitely pessimistic. They're only useful for worst-case. I'm pretty sure you can put in the max temperature when doing PAR, so you could isolate the effects of just that, but it will still probably be worse variation than in reality.

My FPGA guy says that the ZYNQ does not have adjustable delay after
the i/o block flops. We can vary drive strength in four steps, and we
may be able to do something with that.


you are right the 7010 and 7020 only have high range IO so no odelay

are you just trying to keep a fixed alignment between clock and data output?

you can do tricks with DDR output flops, data out with a DDR with both inputs
as data, clock out with a DDR with 0,1 as input

-Lasse

Kevin Neilson
Guest

Thu Apr 13, 2017 12:22 am   



Quote:
My FPGA guy says that the ZYNQ does not have adjustable delay after
the i/o block flops. We can vary drive strength in four steps, and we
may be able to do something with that.


Hmm. I've used a real-time-adjustable ODELAY block, but that wasn't in a Zynq.

If you can add more hardware to the board, you could re-register the data in some external 74LS flops.

You could use unregistered outputs and make your own delay line with a carry chain, which you can create with behavioral code.

John Larkin
Guest

Thu Apr 13, 2017 1:21 am   



On Wed, 12 Apr 2017 15:22:25 -0700 (PDT), Kevin Neilson
<kevin.neilson_at_xilinx.com> wrote:

Quote:
My FPGA guy says that the ZYNQ does not have adjustable delay after
the i/o block flops. We can vary drive strength in four steps, and we
may be able to do something with that.


Hmm. I've used a real-time-adjustable ODELAY block, but that wasn't in a Zynq.

If you can add more hardware to the board, you could re-register the data in some external 74LS flops.


We are exactly trying to drive external flops, some 1 ns CMOS parts.
They are clocked by the same clock that is going into the ZYNQ, and
the FPGA needs to set up their D inputs reliably. We can't use a PLL
or DLL inside the FPGA.

So the problem is that the Xilinx tools are reporting a huge (almost
3:1) spread in possible prop delay from our applied clock to the iob
outputs. The tools apparently assume the max process+temperature+power
supply limits, without letting us constrain these, and without
assigning any specific blame.


Quote:

You could use unregistered outputs and make your own delay line with a carry chain, which you can create with behavioral code.


I think that has even higher uncertainty, probably more than a full
clock period, so we couldn't reliably load those external flops.


--

John Larkin Highland Technology, Inc
picosecond timing precision measurement

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

rickman
Guest

Thu Apr 13, 2017 1:41 am   



On 4/12/2017 7:21 PM, John Larkin wrote:
Quote:
On Wed, 12 Apr 2017 15:22:25 -0700 (PDT), Kevin Neilson
kevin.neilson_at_xilinx.com> wrote:

My FPGA guy says that the ZYNQ does not have adjustable delay after
the i/o block flops. We can vary drive strength in four steps, and we
may be able to do something with that.


Hmm. I've used a real-time-adjustable ODELAY block, but that wasn't in a Zynq.

If you can add more hardware to the board, you could re-register the data in some external 74LS flops.

We are exactly trying to drive external flops, some 1 ns CMOS parts.
They are clocked by the same clock that is going into the ZYNQ, and
the FPGA needs to set up their D inputs reliably. We can't use a PLL
or DLL inside the FPGA.

So the problem is that the Xilinx tools are reporting a huge (almost
3:1) spread in possible prop delay from our applied clock to the iob
outputs. The tools apparently assume the max process+temperature+power
supply limits, without letting us constrain these, and without
assigning any specific blame.



You could use unregistered outputs and make your own delay line with a carry chain, which you can create with behavioral code.

I think that has even higher uncertainty, probably more than a full
clock period, so we couldn't reliably load those external flops.


The way you have constrained the design I think you will need to design
your own chip. I would say you need to find a way to relax one of your
many constraints. Not using the PLL/DLL is a real killer. That would
be a good one to fix.

I haven't use the Xilinx tools in a long time, but I seem to recall
there was a way to work with a single temperature. It may have been the
hot number or the cold number, but not an arbitrary value in between.
But that may have been the post layout simulation timing. Simulation is
not a great way to verify timing in general, but it could be made to
work for your case. I'd say get a Xilinx FAE involved.

--

Rick C

Goto page Previous  1, 2, 3 ... 356, 357, 358

elektroda.net NewsGroups Forum Index - FPGA - EDK : FSL macros defined by Xilinx are wrong

Ask a question - edaboard.com

Arabic versionBulgarian versionCatalan versionCzech versionDanish versionGerman versionGreek versionEnglish versionSpanish versionFinnish versionFrench versionHindi versionCroatian versionIndonesian versionItalian versionHebrew versionJapanese versionKorean versionLithuanian versionLatvian versionDutch versionNorwegian versionPolish versionPortuguese versionRomanian versionRussian versionSlovak versionSlovenian versionSerbian versionSwedish versionTagalog versionUkrainian versionVietnamese versionChinese version
RTV map EDAboard.com map News map EDAboard.eu map EDAboard.de map EDAboard.co.uk map