FPGA one-shot

Started by John Larkin December 13, 2017
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?


-- 

John Larkin         Highland Technology, Inc

lunatic fringe electronics 

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)?
> >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.
That's going to be difficult without a low-level editing tool (and even with, is _highly_ not recommended).
> >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 22:57:40 -0500, krw@notreal.com wrote:

>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 could do all sorts of stuff if I could access some FPGA balls, but I can't. I brought out some test points, but we used them for another hack! And kluging parts onto the board is second-best to doing something invisible like this. -- John Larkin Highland Technology, Inc lunatic fringe electronics
On 12/13/17 10:43 PM, John Larkin 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 > > 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 big issue with trying to do this sort of stuff asynchronously in an FPGA is that timing is tremendously dependent on routing and placement, including at times things that you really can't control at the typical programming level. It is quite different from the old days of using discrete chips where the gates were the slow part, and the wires were mostly negligible. Inside the FPGA, the wires are significant part of timing, and the tools and chip designs go to a LOT of work to make synchronous stuff work. My guess is that the most repeatable method would be to build a delay line by instancing a buffer, with the synthesis directives to force the system to not optimize/remove the buffer, and force it at one end of the FPGA, and then have that drive a similar buffer which you have forced to be on the other side of the chip, and so on back and forth until you have built up enough delay.
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. -- Rick C Viewed the eclipse at Wintercrest Farms, on the centerline of totality since 1998
On Wed, 13 Dec 2017 19:43:20 -0800, John Larkin 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 > > 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?
"Some internal delay mechanism" on your block diagram could be an IDELAY (or IODELAY), which gives you a calibrated delay that will be independent of PVT. Of course, it's independent of PVT because you give it (actually an IDELAY_CTRL) a reference clock at 200MHz (or some other, higher frequencies). Max delay is a few ns, delay resolution is some tens of ps, and jitter is some tens of ps as well. I recently ran some ring oscillator experiments in the same FPGA family. I used LUTs as delay elements and when coded (in VHDL) such that all elements were in the same slice and the routing was all in the local switchbox, I measured a frequency of 945MHz for a 3 element ring. That should give you some idea of the achievable delays. 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. Watch the minimum pulse widths on the FF clear input. This will be specified in the datasheet somewhere. I'm guessing you want an IOB FF rather than a CLB flip flop though. The IOB FF are described in the "SelectIO Logic Resources" chapter of UG471. They should be as fast as the internal FF. Maybe faster, as they are designed for superior metastability resolution. [Assuming the trig input is on a pin.] You also have the option of using special IO clocking resources to get the clock from a pin to the FF clock input with much less delay / delay variation / jitter than you would get through the global clock networks. (These are the clocking resources that are used for DDR3 data clocks, etc. so they have to have low, predictable delays.) This will only work if you put the trig input on the correct pin (as not all pins can be used as clock inputs this way), but hey, of course you picked that up at the schematic design review. Allan
On Thu, 14 Dec 2017 10:49:41 +0000, Allan Herriman wrote:


> 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.
This Xilinx forum thread gives some examples of placement and routing in VHDL: https://forums.xilinx.com/t5/UltraScale-Architecture/Gated-ring-oscillator/m-p/808774/highlight/true#M5557 Regards, Allan
In comp.arch.fpga rickman <gnuarm@gmail.com> wrote:
> 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.
Is this a mature product, or one which is likely to see frequent updates? That may direct your strategy. If it's mature, it might be feasible to use the ECO tools to manually add cells to an existing design. If it's still in flux, you probably need to understand how to direct the tool that this piece of logic needs special treatment and should be constructed like so. This means it will persist over respins of the rest of the logic. You will likely still need to verify over a number of respins that it does in fact persist, given that it's hard to get this right. Theo
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.
krw@notreal.com wrote on 12/14/2017 9:12 AM:
> 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.
Something like this was done in test equipment from a major manufacturer. They needed to mux a clock and the delay through the chip needed to be minimal. I don't recall if the LUT was hand placed or not, but the routing was done by hand in the chip editor. I found out about it because we had to touch the chip. My boss was the guy who had originally done this and not documented a single thing on it. He gave a demonstration on how to do the hand mod to few of us and that was how he passed the torch, by oral tradition. lol -- Rick C Viewed the eclipse at Wintercrest Farms, on the centerline of totality since 1998