Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
On Tue, 11 Apr 2017 21:09:52 -0400, krw@notreal.com wrote:
On Mon, 10 Apr 2017 20:06:57 -0700, John Larkin
jjlarkin@highlandtechnology.com> wrote:
On Mon, 10 Apr 2017 22:15:50 -0400, krw@notreal.com wrote:
On Mon, 10 Apr 2017 18:13:13 -0700, John Larkin
jjlarkin@highland_snip_technology.com> 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.
Why not? Don't bother with the output frequency, just vary the number
of flops wiggling.
That would work too. Maybe have a 2-bit heat control word, to get
coarse steps of power dissipation, 4 groups of flops. I suppose a
single on-off bit could be a simple bang-bang thermostat.
The PLL thing would be elegant, proportional control of all the flops
in the distributed heater array.
You can do the same thing with the flops. Use a shift register to
enable flops in a "thermometer code" sort of thing. Too low - shift
right. Wait. Still to low - shift right. Wait. Too high - shift
left...
There are all sorts of algorithms that can be built into spare flops.
I'm thinking we could reduce the overall effect of ambient temp
changes by some healthy factor, 4:1 or 10:1 or something.
Seems reasonable. IBM used to add heater chips for the same purpose
(bipolar circuits run faster at high temperature).
CMOS is slower at high temps. Somewhere between about 1000 and 3000
PPM/K prop delay.
On 2017/04/11 7:26 PM, John Larkin wrote:
On Tue, 11 Apr 2017 21:09:52 -0400, krw@notreal.com wrote:
On Mon, 10 Apr 2017 20:06:57 -0700, John Larkin
jjlarkin@highlandtechnology.com> wrote:
On Mon, 10 Apr 2017 22:15:50 -0400, krw@notreal.com wrote:
On Mon, 10 Apr 2017 18:13:13 -0700, John Larkin
jjlarkin@highland_snip_technology.com> 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.
Why not? Don't bother with the output frequency, just vary the number
of flops wiggling.
That would work too. Maybe have a 2-bit heat control word, to get
coarse steps of power dissipation, 4 groups of flops. I suppose a
single on-off bit could be a simple bang-bang thermostat.
The PLL thing would be elegant, proportional control of all the flops
in the distributed heater array.
You can do the same thing with the flops. Use a shift register to
enable flops in a "thermometer code" sort of thing. Too low - shift
right. Wait. Still to low - shift right. Wait. Too high - shift
left...
There are all sorts of algorithms that can be built into spare flops.
I'm thinking we could reduce the overall effect of ambient temp
changes by some healthy factor, 4:1 or 10:1 or something.
Seems reasonable. IBM used to add heater chips for the same purpose
(bipolar circuits run faster at high temperature).
CMOS is slower at high temps. Somewhere between about 1000 and 3000
PPM/K prop delay.
Do you use that property of CMOS (slower the warmer it gets) as an
automatic negative feedback loop for your heater?
On 4/15/2017 12:21 PM, John Robertson wrote:
On 2017/04/11 7:26 PM, John Larkin wrote:
On Tue, 11 Apr 2017 21:09:52 -0400, krw@notreal.com wrote:
On Mon, 10 Apr 2017 20:06:57 -0700, John Larkin
jjlarkin@highlandtechnology.com> wrote:
On Mon, 10 Apr 2017 22:15:50 -0400, krw@notreal.com wrote:
On Mon, 10 Apr 2017 18:13:13 -0700, John Larkin
jjlarkin@highland_snip_technology.com> 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.
Why not? Don't bother with the output frequency, just vary the
number
of flops wiggling.
That would work too. Maybe have a 2-bit heat control word, to get
coarse steps of power dissipation, 4 groups of flops. I suppose a
single on-off bit could be a simple bang-bang thermostat.
The PLL thing would be elegant, proportional control of all the flops
in the distributed heater array.
You can do the same thing with the flops. Use a shift register to
enable flops in a "thermometer code" sort of thing. Too low - shift
right. Wait. Still to low - shift right. Wait. Too high - shift
left...
There are all sorts of algorithms that can be built into spare flops.
I'm thinking we could reduce the overall effect of ambient temp
changes by some healthy factor, 4:1 or 10:1 or something.
Seems reasonable. IBM used to add heater chips for the same purpose
(bipolar circuits run faster at high temperature).
CMOS is slower at high temps. Somewhere between about 1000 and 3000
PPM/K prop delay.
Do you use that property of CMOS (slower the warmer it gets) as an
automatic negative feedback loop for your heater?
That would likely not work nearly as well as directly measuring the
temperature of the die. Notice he said the chip has a built in
thermometer. The only issue with using the thermometer is the
temperature across the die will vary. Using the delay to control the
heater might work well in concept, but would be hard to measure and
still only work for the output being measured. Any other outputs will
be spread around the die and so not isothermal. But mostly the timing
would be hard to measure.
He has an oven/refrigerator. He could measure the change in timing over
temperature for some number of samples. This would give him an idea of
how much spread is involved. There are multiple sources of timing
spread and he can control one and sort of control another. He wants an
idea of how much timing spread is left.
As an example - Common/Ground designs in early arcade games were not
always at their best. A number of early electronic pinball games used to
burn up driver transistors and coils at random until I traced the
problem - which was a design error where all the commons (MPU, Audio,
Solenoids, Lamps) came together at the regulator board through several
different pins, and as each pin connection oxidized slightly it allowed
ground potential differences between the MPU and the solenoid logic
grounds, leading to the transistors being slightly biased on...
And this game logic had been designed by Rockwell.
John
What is the best choice for use with an XC4000XL FPGA: synchronous or
asynchronous SRAM? What's the advantage of synchronous SRAM, anyway?
I know how to make binary up/down counters and LFSR-based counters in
verilog, but does anyone know of an algorithmic/equation-based way to
make grey-code counters?
The only examples I've seen are from old PAL application notes, and they
are for 4-bit grey counters that are described as 16-state state
machines, which is ok if you are keeping the counter at 4-bits, but
impractical if you are going to much wider bit widths.
--
==============================
William Lenihan
lenihan3weNOSPAM@earthlink.net
.... remove "NOSPAM" when replying
==============================
Here is a generic VHDL gray counter function.
http://www.vlsiip.com/intel/vhdlf.html
Hope you can convert it into verilog
Kr,
Avi.
On Wednesday, January 10, 2001 at 9:25:22 AM UTC, Bill Lenihan wrote:
I know how to make binary up/down counters and LFSR-based counters in
verilog, but does anyone know of an algorithmic/equation-based way to
make grey-code counters?
The only examples I've seen are from old PAL application notes, and they
are for 4-bit grey counters that are described as 16-state state
machines, which is ok if you are keeping the counter at 4-bits, but
impractical if you are going to much wider bit widths.
--
==============================
William Lenihan
lenihan3weNOSPAM@earthlink.net
.... remove "NOSPAM" when replying
==============================
I have an async signal, call it TRIG, inside a Zynq 7020.
At the rising edge of TRIG, I want to make an async one-shot. It will
leave the chip as RX and reset some outboard ecl logic. Anything from,
say, 2 ns to 10 ns width would work.
The board is built, and we can't easily add more connections to the
FPGA or hack in glue logic. Well, it would be ugly.
Here are some ideas:
https://www.dropbox.com/s/4azi5hzkqzsyeiy/FPGA_OneShots.JPG?raw=1
We could play with i/o cell slew rates and drive strengths to tune the
timing. And use as many delay stages (circuit B) as we like... there
are tons of unused balls.
Or maybe use some internal delay path, if we can find one that is
reasonably repeatable.
The compiler will probably let us do circuit A or B without whining
much, but might object to the third one.
I grew up on async hairball logic, so this seems reasonable to me, but
my FPGA guys are horrified. We don't want to spin up a 250 MHz PLL
here and do it synchronously, for various reasons.
An internal passive pullup resistor charging an i/o pin capacitance
would be fun, but I don't think we could make a short enough blip.
Any other ideas or comments?
On Wed, 13 Dec 2017 19:43:20 -0800, John Larkin
jjlarkin@highlandtechnology.com> wrote:
I have an async signal, call it TRIG, inside a Zynq 7020.
At the rising edge of TRIG, I want to make an async one-shot. It will
leave the chip as RX and reset some outboard ecl logic. Anything from,
say, 2 ns to 10 ns width would work.
The board is built, and we can't easily add more connections to the
FPGA or hack in glue logic. Well, it would be ugly.
Here are some ideas:
https://www.dropbox.com/s/4azi5hzkqzsyeiy/FPGA_OneShots.JPG?raw=1
How about (A) *AND* not(A), with an external delay, or capacitor on
not(A)?
I have an async signal, call it TRIG, inside a Zynq 7020.
At the rising edge of TRIG, I want to make an async one-shot. It will
leave the chip as RX and reset some outboard ecl logic. Anything from,
say, 2 ns to 10 ns width would work.
The board is built, and we can't easily add more connections to the
FPGA or hack in glue logic. Well, it would be ugly.
Here are some ideas:
https://www.dropbox.com/s/4azi5hzkqzsyeiy/FPGA_OneShots.JPG?raw=1
We could play with i/o cell slew rates and drive strengths to tune the
timing. And use as many delay stages (circuit B) as we like... there
are tons of unused balls.
Or maybe use some internal delay path, if we can find one that is
reasonably repeatable.
The compiler will probably let us do circuit A or B without whining
much, but might object to the third one.
I grew up on async hairball logic, so this seems reasonable to me, but
my FPGA guys are horrified. We don't want to spin up a 250 MHz PLL
here and do it synchronously, for various reasons.
An internal passive pullup resistor charging an i/o pin capacitance
would be fun, but I don't think we could make a short enough blip.
Any other ideas or comments?
I have an async signal, call it TRIG, inside a Zynq 7020.
At the rising edge of TRIG, I want to make an async one-shot. It will
leave the chip as RX and reset some outboard ecl logic. Anything from,
say, 2 ns to 10 ns width would work.
The board is built, and we can't easily add more connections to the
FPGA or hack in glue logic. Well, it would be ugly.
Here are some ideas:
https://www.dropbox.com/s/4azi5hzkqzsyeiy/FPGA_OneShots.JPG?raw=1
We could play with i/o cell slew rates and drive strengths to tune the
timing. And use as many delay stages (circuit B) as we like... there
are tons of unused balls.
Or maybe use some internal delay path, if we can find one that is
reasonably repeatable.
The compiler will probably let us do circuit A or B without whining
much, but might object to the third one.
I grew up on async hairball logic, so this seems reasonable to me, but
my FPGA guys are horrified. We don't want to spin up a 250 MHz PLL
here and do it synchronously, for various reasons.
An internal passive pullup resistor charging an i/o pin capacitance
would be fun, but I don't think we could make a short enough blip.
Any other ideas or comments?
I have an async signal, call it TRIG, inside a Zynq 7020.
At the rising edge of TRIG, I want to make an async one-shot. It will
leave the chip as RX and reset some outboard ecl logic. Anything from,
say, 2 ns to 10 ns width would work.
The board is built, and we can't easily add more connections to the FPGA
or hack in glue logic. Well, it would be ugly.
Here are some ideas:
https://www.dropbox.com/s/4azi5hzkqzsyeiy/FPGA_OneShots.JPG?raw=1
We could play with i/o cell slew rates and drive strengths to tune the
timing. And use as many delay stages (circuit B) as we like... there are
tons of unused balls.
Or maybe use some internal delay path, if we can find one that is
reasonably repeatable.
The compiler will probably let us do circuit A or B without whining
much, but might object to the third one.
I grew up on async hairball logic, so this seems reasonable to me, but
my FPGA guys are horrified. We don't want to spin up a 250 MHz PLL here
and do it synchronously, for various reasons.
An internal passive pullup resistor charging an i/o pin capacitance
would be fun, but I don't think we could make a short enough blip.
Any other ideas or comments?
The placement and routing is quite easy to control from your favourite
HDL, once you know how. This is important to get right as otherwise the
results will not be repeatable.
The main reason why your FPGA guys are reacting in horror is because they
know what a royal PITA it will be to learn the tools well enough to make
all this happen.
John Larkin wrote on 12/13/2017 10:43 PM:
I have an async signal, call it TRIG, inside a Zynq 7020.
At the rising edge of TRIG, I want to make an async one-shot. It will
leave the chip as RX and reset some outboard ecl logic. Anything from,
say, 2 ns to 10 ns width would work.
The board is built, and we can't easily add more connections to the
FPGA or hack in glue logic. Well, it would be ugly.
Here are some ideas:
https://www.dropbox.com/s/4azi5hzkqzsyeiy/FPGA_OneShots.JPG?raw=1
We could play with i/o cell slew rates and drive strengths to tune the
timing. And use as many delay stages (circuit B) as we like... there
are tons of unused balls.
Or maybe use some internal delay path, if we can find one that is
reasonably repeatable.
The compiler will probably let us do circuit A or B without whining
much, but might object to the third one.
I grew up on async hairball logic, so this seems reasonable to me, but
my FPGA guys are horrified. We don't want to spin up a 250 MHz PLL
here and do it synchronously, for various reasons.
An internal passive pullup resistor charging an i/o pin capacitance
would be fun, but I don't think we could make a short enough blip.
Any other ideas or comments?
The variation in delay in an FPGA for any given route aren't all that bad,
about the same as with regular logic.
I assume Xilinx still has a manual
chip editing tool. It will give you delays of routes. So you can do a run
of the chip and manually reroute the one delay path to get your time delay.
There are ways to force placement of the FF with attributes in your source
code. So as long as the routes you need are not used it would be a simple
matter to hand route the same path each time. Getting a 2 ns minimum pulse
width shouldn't be hard at all.
You seem to be thinking you can tune the loop with I/O pad delays, but that
will still require manual work in the chip editor to make adjustments each
time you get a different route on the delay path and so need different I/O
pad slew rates.
One other thought is to use some number of LUTs as the main delay element,
there are ways to force the use of such a component in HDL source. By
constraining the placement to cells that are in the same logic block you
will get consistent route delays and routing variation should go away. I
believe it is the inter-logic cell routes that have lots of variation.
The main reason why your FPGA guys are reacting in horror is because they
know what a royal PITA it will be to learn the tools well enough to make all
this happen.
On Thu, 14 Dec 2017 02:10:06 -0500, rickman <gnuarm@gmail.com> wrote:
John Larkin wrote on 12/13/2017 10:43 PM:
I have an async signal, call it TRIG, inside a Zynq 7020.
At the rising edge of TRIG, I want to make an async one-shot. It will
leave the chip as RX and reset some outboard ecl logic. Anything from,
say, 2 ns to 10 ns width would work.
The board is built, and we can't easily add more connections to the
FPGA or hack in glue logic. Well, it would be ugly.
Here are some ideas:
https://www.dropbox.com/s/4azi5hzkqzsyeiy/FPGA_OneShots.JPG?raw=1
We could play with i/o cell slew rates and drive strengths to tune the
timing. And use as many delay stages (circuit B) as we like... there
are tons of unused balls.
Or maybe use some internal delay path, if we can find one that is
reasonably repeatable.
The compiler will probably let us do circuit A or B without whining
much, but might object to the third one.
I grew up on async hairball logic, so this seems reasonable to me, but
my FPGA guys are horrified. We don't want to spin up a 250 MHz PLL
here and do it synchronously, for various reasons.
An internal passive pullup resistor charging an i/o pin capacitance
would be fun, but I don't think we could make a short enough blip.
Any other ideas or comments?
The variation in delay in an FPGA for any given route aren't all that bad,
about the same as with regular logic.
It's higher in FPGAs since the wires are longer (higher capacitance),
though distance between gates may (or may not) be similar. The wires
in an FPGA are "fixed" length, where they are only as long as needed
in an ASIC. There is also a lot of capacitance from all of the muxes
(pass gates) hanging off the wire. The higher magnitude will mean a
higher variation, too.
I assume Xilinx still has a manual
chip editing tool. It will give you delays of routes. So you can do a run
of the chip and manually reroute the one delay path to get your time delay.
There are ways to force placement of the FF with attributes in your source
code. So as long as the routes you need are not used it would be a simple
matter to hand route the same path each time. Getting a 2 ns minimum pulse
width shouldn't be hard at all.
A very poor way of doing things but it may be the only way to make
such a kludge.
You seem to be thinking you can tune the loop with I/O pad delays, but that
will still require manual work in the chip editor to make adjustments each
time you get a different route on the delay path and so need different I/O
pad slew rates.
One other thought is to use some number of LUTs as the main delay element,
there are ways to force the use of such a component in HDL source. By
constraining the placement to cells that are in the same logic block you
will get consistent route delays and routing variation should go away. I
believe it is the inter-logic cell routes that have lots of variation.
The main reason why your FPGA guys are reacting in horror is because they
know what a royal PITA it will be to learn the tools well enough to make all
this happen.
Not to mention the maintenance of this kludge for the life of the
product.