Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 160325

Article: 160325
Subject: Re: grey code counters
From: David Brown <david.brown@hesbynett.no>
Date: Tue, 14 Nov 2017 14:29:11 +0100
Links: << >>  << T >>  << A >>
On 14/11/17 11:34, aviralmittal@gmail.com wrote:
> Here is a generic VHDL gray counter function.
> http://www.vlsiip.com/intel/vhdlf.html
> Hope you can convert it into verilog
> Kr,
> Avi.
> 

Please look at the date of that question - it was asked nearly 18 years
ago.  It's great that you want to help people, but do you /really/ think
this guy has spend 18 years trying to figure out how to make a grey code
counter?

My advice to you is that if you want to use Usenet, drop the crappy
Google Groups interface.  Get a proper newsreader, and a proper
newserver (both are free), and then you join the newsgroups that
interest you.  You get a vastly better interface, and become part of a
living community instead of talking to ghosts.


> 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
>> ==============================
> 


Article: 160326
Subject: Re: additional fpga forums
From: "" <1@FPGARelated>
Date: Mon, 20 Nov 2017 07:28:43 -0600
Links: << >>  << T >>  << A >>
>suggestions for alternative fpga-related forums ?

https://www.fpgarelated.com/forums
---------------------------------------
Posted through http://www.FPGARelated.com

Article: 160327
Subject: Re: additional fpga forums
From: Andy Bennet <andyb@andy.com>
Date: Mon, 20 Nov 2017 14:36:35 +0000
Links: << >>  << T >>  << A >>
On 20/11/2017 13:28, 1@FPGARelated wrote:
>> suggestions for alternative fpga-related forums ?
>
> https://www.fpgarelated.com/forums
> ---------------------------------------
> Posted through http://www.FPGARelated.com
>

https://www.reddit.com/r/FPGA/

Article: 160328
Subject: Re: graphics for FPGA design
From: vijayvithal <jvs@dyumnin.com>
Date: Sat, 25 Nov 2017 16:02:40 +0000 (UTC)
Links: << >>  << T >>  << A >>
Xfig

On 2017-10-30, o pere o <me@somewhere.net> wrote:
> On 26/10/17 12:59, john wrote:
>> 
>> does anyone have a set of symbols that can help with fpga documentation?
>> (Something for dia perhaps or coreldraw maybe)
>> preferably not visio
>> 
>> Or does everyone do this manually all the time?
>> Clearly it's not that complex but what do you all use?
>> 
>
> For drawing I use inkscape. It is quite easy to draw some symbols and 
> reuse them everywhere.
>
> Pere

Article: 160329
Subject: Re: FPGA motherboard for 80386 CPU
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Tue, 12 Dec 2017 12:10:55 -0800 (PST)
Links: << >>  << T >>  << A >>
On Friday, November 10, 2017 at 10:35:44 AM UTC-5, Rick C. Hodgin wrote:
> The 80386DX CPU had 132 pins:
> 
>     80386DX and 80386SX pinouts:
>     http://www.rfwireless-world.com/images/80386-pin-diagram.jpg
>     https://image.slidesharecdn.com/salientfeatursof80386-140822084001-phpapp02/95/salient-featurs-of-80386-14-638.jpg?cb=1408709884
> 
>     General architecture:
>     http://www.nptel.ac.in/courses/Webcourse-contents/IISc-BANG/Microprocessors%20and%20Microcontrollers/pdf/Teacher_Slides/mod8/M8L1.pdf
> 
> Of these pins on the DX variant:
> 
>     32 pins -- data
>     30 pins -- address
>      4 pins -- byte enables in 32-bit writes
>      1 pin  -- Read/write
>      1 pin  -- Data/Control
>      1 pin  -- Memory/IO
>      1 pin  -- Bus mastering lock issued by CPU
>      1 pin  -- Bus16 size (16-bit when asserted, normally 32-bit)
>      1 pin  -- Next address (for pipelining)
>      1 pin  -- Address valid signal
>     --
>     73 pins -- For basic I/O
> 
>      3 pins -- Math-coprocessor support
>      1 pin  -- Ready (or Wait, for bus cycles to complete)
>      2 pins -- Hold and Hold Acknowledge (for bus mastering)
>      2 pins -- Interrupt and Non-masktable Interrupt
>     --
>      8 pins -- General coordination with external peripherals
> 
>      1 pin  -- Reset
>      1 pin  -- Double-pumped clock
>     --
>      2 pins -- System input
> 
> The rest of the pins are unused, go to VSS or VCC.  This means that for a
> full 80386 "motherboard" only 83 pins are required to fully support its
> operation, 67 of which are address, data, and data type, leaving really
> only 15 pins of complex operation for a state machine.
> 
> -----
> Would anybody be able to help me create this 80386 motherboard using an
> AMD Am386 CPU, which is a static CPU operating from 0 to 40 MHz?  I would
> like to get it working with a single-step operation for design validation,
> and then to begin ramping it up.
> 
> I figure I'll have an area of ROM which the CPU boots to load, which is a
> tiny real mode program, which begins computing something that can be exam-
> ined by the FPGA to test successful operation.  And then move on to more
> complex operations, including a custom microkernel.

Now that the intrusion appears to be over, would anybody like to help me
in preparation for this project?

Specifically, I'd like some help in guiding me toward the type of board
and sockets I'll need.  I think I know what to do, but without someone
to say "yay" or "nay" I'm just guessing.

It will need a 132-pin PGA, a custom board which connects into the
three parallel 40-pin adapter board I have for my FPGA.  In that way,
the 80386 chip will ride right above the FPGA, with traversing the main
40-pin-to-FPGA connection, and the 80386 board-to-40-pin connection.

                          80386
                        =========
                        |||||||||
                      ===========================
                                       ||  ||  || <=== 3x 40-pin
                          =======================
                            |||| <=== Proprietary 120+pin adapter
  =====[ FPGA ]==================

The FPGA I have is about 6" square, with the adapter board being about
2" x 3".  The custom board I'll build will be about 3" x 3".  The total
distance from FPGA to CPU will be about 9".

The Am386 CPU I plan to use is a static part able to run between 0 MHz
and 40 MHz inclusive.  I plan to run around 1 MHz to start.

Please offer any advice.  Thank you.

-- 
Rick C. Hodgin

Article: 160330
Subject: FPGA one-shot
From: John Larkin <jjlarkin@highlandtechnology.com>
Date: Wed, 13 Dec 2017 19:43:20 -0800
Links: << >>  << T >>  << 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?


-- 

John Larkin         Highland Technology, Inc

lunatic fringe electronics 


Article: 160331
Subject: Re: FPGA one-shot
From: krw@notreal.com
Date: Wed, 13 Dec 2017 22:57:40 -0500
Links: << >>  << T >>  << A >>
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?

Article: 160332
Subject: Re: FPGA one-shot
From: John Larkin <jjlarkin@highlandtechnology.com>
Date: Wed, 13 Dec 2017 20:02:08 -0800
Links: << >>  << T >>  << A >>
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 


Article: 160333
Subject: Re: FPGA one-shot
From: Richard Damon <Richard@Damon-Family.org>
Date: Wed, 13 Dec 2017 23:29:28 -0500
Links: << >>  << T >>  << A >>
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.

Article: 160334
Subject: Re: FPGA one-shot
From: rickman <gnuarm@gmail.com>
Date: Thu, 14 Dec 2017 02:10:06 -0500
Links: << >>  << T >>  << A >>
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

Article: 160335
Subject: Re: FPGA one-shot
From: Allan Herriman <allanherriman@hotmail.com>
Date: 14 Dec 2017 10:49:41 GMT
Links: << >>  << T >>  << A >>
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

Article: 160336
Subject: Re: FPGA one-shot
From: Allan Herriman <allanherriman@hotmail.com>
Date: 14 Dec 2017 11:39:31 GMT
Links: << >>  << T >>  << A >>
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

Article: 160337
Subject: Re: FPGA one-shot
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 14 Dec 2017 11:44:34 +0000 (GMT)
Links: << >>  << T >>  << A >>
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

Article: 160338
Subject: Re: FPGA one-shot
From: krw@notreal.com
Date: Thu, 14 Dec 2017 09:12:09 -0500
Links: << >>  << T >>  << A >>
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.

Article: 160339
Subject: Re: FPGA motherboard for 80386 CPU
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Thu, 14 Dec 2017 06:29:29 -0800 (PST)
Links: << >>  << T >>  << A >>
On Tuesday, December 12, 2017 at 3:11:01 PM UTC-5, Rick C. Hodgin wrote:
> It will need a 132-pin PGA, a custom board which connects into the
> three parallel 40-pin adapter board I have for my FPGA.  In that way,
> the 80386 chip will ride right above the FPGA, with traversing the main
> 40-pin-to-FPGA connection, and the 80386 board-to-40-pin connection.
> 
>                           80386
>                         =========
>                         |||||||||
>                       ===========================
>                                        ||  ||  || <=== 3x 40-pin
>                           =======================
>                             |||| <=== Proprietary 120+pin adapter
>   =====[ FPGA ]==================

I had the thought I can build it this way to have a one-sided board:

             ==================================== 
              |||||||                 ||  ||  || <=== 3x 40-pin 
               80386      ======================= 
                            |||| <=== Proprietary 120+pin adapter 
  =====[ FPGA ]================== 

And I may be able to build it this way:

                          =======================
                            ||||         |||||||
  =====[ FPGA ]==================         80386

Where the 80386 plugs directly into the proprietary 120+pin adapter.

This would give me a framework where I can create the custom board
to use the appropriate GPIO pins, and +3.3 and GND pins, to provide
power to the CPU.  My goal then is to generate the double-pumped
clock at 2 MHz, and respond to the bus signals with a state machine,
and provide a memory controller for the actual instructions.

Will anybody help me?

-- 
Rick C. Hodgin

Article: 160340
Subject: Re: FPGA one-shot
From: rickman <gnuarm@gmail.com>
Date: Thu, 14 Dec 2017 10:02:25 -0500
Links: << >>  << T >>  << A >>
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

Article: 160341
Subject: Re: FPGA one-shot
From: rickman <gnuarm@gmail.com>
Date: Thu, 14 Dec 2017 10:18:25 -0500
Links: << >>  << T >>  << A >>
Allan Herriman wrote on 12/14/2017 6:39 AM:
> 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

When you say "routing", it doesn't appear to deal with the actual routing. 
He does mention that the attributes assign specific I/Os on the LUTs and so 
which pin is connected to which is determined.  But the routing 
interconnects still need to be wired up in the chip editor I believe.

-- 

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

Article: 160342
Subject: Re: FPGA one-shot
From: krw@notreal.com
Date: Thu, 14 Dec 2017 10:35:57 -0500
Links: << >>  << T >>  << A >>
On Thu, 14 Dec 2017 10:02:25 -0500, rickman <gnuarm@gmail.com> wrote:

>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

What a wonderful way to run a company.  I assume they're no longer in
business?


Article: 160343
Subject: Re: FPGA one-shot
From: John Larkin <jjlarkin@highlandtechnology.com>
Date: Thu, 14 Dec 2017 08:54:10 -0800
Links: << >>  << T >>  << A >>
On 14 Dec 2017 11:44:34 +0000 (GMT), Theo Markettos
<theom+news@chiark.greenend.org.uk> wrote:

>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

The virtue of putting most of the delay into i/o cells is that they
will behave the same independent of compiles. And the slew/drive
strength params can be set without any hand routing or fighting the
tools to do something they don't want to do. We can hang timing
constraints on the presumably short runs to the dflop to keep that
uncertainty low.

Rob here suggested that an adder/carry chain might have a more
consistent internal delay (it's a fixed structure) than routing
delays, which might change every compile. Maybe a MAC?

I'll ask my folks to add a couple of experiments to the next compile.
We are iterating the design to add and test features once or twice a
week. This thing is maybe 20x as complex as our average design, which
is our excuse for not thinking out everything in advance.




-- 

John Larkin         Highland Technology, Inc

lunatic fringe electronics 


Article: 160344
Subject: Re: FPGA one-shot
From: rickman <gnuarm@gmail.com>
Date: Thu, 14 Dec 2017 12:39:11 -0500
Links: << >>  << T >>  << A >>
John Larkin wrote on 12/14/2017 11:54 AM:
> On 14 Dec 2017 11:44:34 +0000 (GMT), Theo Markettos
> <theom+news@chiark.greenend.org.uk> wrote:
>
>> 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
>
> The virtue of putting most of the delay into i/o cells is that they
> will behave the same independent of compiles. And the slew/drive
> strength params can be set without any hand routing or fighting the
> tools to do something they don't want to do. We can hang timing
> constraints on the presumably short runs to the dflop to keep that
> uncertainty low.
>
> Rob here suggested that an adder/carry chain might have a more
> consistent internal delay (it's a fixed structure) than routing
> delays, which might change every compile. Maybe a MAC?
>
> I'll ask my folks to add a couple of experiments to the next compile.
> We are iterating the design to add and test features once or twice a
> week. This thing is maybe 20x as complex as our average design, which
> is our excuse for not thinking out everything in advance.

There is nothing inherent in the IOBs that makes their delay more consistent 
than any other internal logic component.  The issue is the routing 
*changing* when you recompile the design.  *That* will give widely varying 
timing unless you lock the placement of each component so there is a direct 
route available between them.  I have not studied the routing flow of the 
newer families of Xilinx devices, but I believe if you stay within a local 
block of logic the routing resources have very direct paths, so the timing 
with not change appreciably on different passes.  This location constraint 
can be relative so it simply puts the logic in the same block but allows the 
block to "float" anywhere in the device.  If you also want to minimize the 
delay from the leading edge of the trigger pulse you need to further 
constrain the logic to be adjacent to the IOB which should again be able to 
use dedicated routing for adjacent blocks.

The adder carry chain has a defined delay just like any other block of 
logic, but the delays are very short per bit, I recall around 200 ps, but 
may be less in the newer devices.  Again, no advantage other than being able 
to customize the pulse width with very high resolution which you appear to 
have indicated is not important.

The way to reduce variation in the pulse width is to use logic block local 
routing which will have much less potential variation.  In all cases you 
will have PVT variation in timing which you can't do anything about.  It is 
not clear if the delay time (trigger to leading edge of pulse) is important. 
  If it is you will likely still need to deal with widely varying routing 
delays between blocks (IOB and logic).  The delay from trigger input to the 
FF can be constrained I believe although I've never used this.  So the 
routing from the FF to the output should be optimized through placement.

-- 

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

Article: 160345
Subject: Re: FPGA one-shot
From: rickman <gnuarm@gmail.com>
Date: Thu, 14 Dec 2017 12:50:30 -0500
Links: << >>  << T >>  << A >>
krw@notreal.com wrote on 12/14/2017 10:35 AM:
> On Thu, 14 Dec 2017 10:02:25 -0500, rickman <gnuarm@gmail.com> wrote:
>
>> 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
>
> What a wonderful way to run a company.  I assume they're no longer in
> business?

Ever hear of TTC?  I was interviewed with TTC but came on board Acterna. 
TTC merged with Dynatech and WWG along with nearly a billion in debt which 
ultimately sunk the company, not anything about their designs.  I believe 
TTC was very well respected in the test equipment world.  I don't know who 
bought the pieces.

-- 

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

Article: 160346
Subject: Re: FPGA one-shot
From: John Larkin <jjlarkin@highland_snip_technology.com>
Date: Thu, 14 Dec 2017 10:31:29 -0800
Links: << >>  << T >>  << A >>
On 14 Dec 2017 10:49:41 GMT, Allan Herriman
<allanherriman@hotmail.com> wrote:

>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.

IDELAY sounds ideal for setting my pulse width, because it's
calibrated and tweakable. We'll look into that.

>
>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.

I did a ring oscillator to measure chip temperature, on a part that
didn't have an internal sensor.

https://www.dropbox.com/s/hq595kyhlhx5f1y/ESM_Ring_Oscillator.jpg?raw=1



-- 

John Larkin         Highland Technology, Inc
picosecond timing   precision measurement 

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


Article: 160347
Subject: Re: FPGA one-shot
From: rickman <gnuarm@gmail.com>
Date: Thu, 14 Dec 2017 14:06:02 -0500
Links: << >>  << T >>  << A >>
John Larkin wrote on 12/14/2017 1:31 PM:
> On 14 Dec 2017 10:49:41 GMT, Allan Herriman
> <allanherriman@hotmail.com> wrote:
>
>> 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.
>
> IDELAY sounds ideal for setting my pulse width, because it's
> calibrated and tweakable. We'll look into that.

It still has to be routed to the logic.  So you haven't worked around the 
problem of wildly variable routing delays which add to your pulse width.

As usual John is trying to work with things he doesn't understand by 
applying methods he has used on totally unrelated designs.  Sit down and 
draw a block diagram showing not just the delay you wish to control, but the 
delays on every bit of wire in the design.  Then maybe the picture will emerge.

-- 

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

Article: 160348
Subject: Re: FPGA one-shot
From: Jon Elson <jmelson@wustl.edu>
Date: Thu, 14 Dec 2017 13:49:51 -0600
Links: << >>  << T >>  << A >>
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.
> 
This signal is generated within the FPGA and sent out?  And, you just want 
to stretch it?  Make a counter with a few bits, set it to zero when TRIG 
occurs, and count up at the available clock rate, and generate RX.  When the 
counter reaches the max, turn off RX and don't increment the counter again.

This is so simple, I must be misunderstanding what you want to do.

Jon

Article: 160349
Subject: Re: FPGA one-shot
From: krw@notreal.com
Date: Thu, 14 Dec 2017 21:59:59 -0500
Links: << >>  << T >>  << A >>
On Thu, 14 Dec 2017 12:50:30 -0500, rickman <gnuarm@gmail.com> wrote:

>krw@notreal.com wrote on 12/14/2017 10:35 AM:
>> On Thu, 14 Dec 2017 10:02:25 -0500, rickman <gnuarm@gmail.com> wrote:
>>
>>> 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
>>
>> What a wonderful way to run a company.  I assume they're no longer in
>> business?
>
>Ever hear of TTC?

No.  I think I know why.

>I was interviewed with TTC but came on board Acterna. 
>TTC merged with Dynatech and WWG along with nearly a billion in debt which 
>ultimately sunk the company, not anything about their designs.  I believe 
>TTC was very well respected in the test equipment world.  I don't know who 
>bought the pieces.

Makes complete sense.  Knowledge locked up in someone's head =>
company in pieces.



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search