the FPGA one-shot

I finally got a test case for my FPGA async one-shot idea, hacked into a build for something else.

I got 17 different one-shots, with various pin locations and speed/drive strength settings.

formatting link

Most of the outputs look like this, with remarkably consistent timing, edges within a few hundred ps. This is typical:

formatting link

This one has minimum pin speed and drive strength, and was driving another chip on the board:

formatting link

So, it looks like it will be safe to do this. I need to reset some ECL counters when an async event happens, and don't want to spin up a 500 MHz clock to do it.

The Xilinx tools didn't approve of us doing this.

--
John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  
 Click to see the full signature
Reply to
John Larkin
Loading thread data ...

John - did you force any special LOCs or other physical contraints within the implementation? Since the FF has an async clr, I don't think it can go in the IOB (the input trigger pin nor the output one shot). So, the FF is within the fabric. Any special constraints on the CLR signal route?

Regards,

Mark

Reply to
gtwrek

Ok, the last one that is driving across the board I wouldn't consider reliable. The other looks good, why don't they allow this? Don't they allow ring oscillators?

Unorthodox tricks are the most fun in electronics design.

--
Regards, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

That's no surprise. My guess is that any tweak of the process could throw this off, too, but maybe not enough to cause you grief.

Jon

Reply to
Jon Elson

I didn't code this, but I'll ask. The flop is in the i/o block, but the clear path had to run through a nearby switchbox.

The trigger is from a regular global clock net.

--
John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  
 Click to see the full signature
Reply to
John Larkin

The last one was slowest i/o cell speed and 4 mA drive strength. It's grunting to drive the trace capacitance and a chip pin.

10 layer boards can have a lot of trace capacitance.

The tools pitch hissy-fits when you do async stuff, like ring oscillators. We are offending The Church Of Synchronous Design.

--
John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  
 Click to see the full signature
Reply to
John Larkin

I have that a lot with RF parts. "Can you guys furnish SPICE data?" ... "No, only S-parameters" ... "I want to used it to pulse something" ... "It's an RF part, you aren't supposed to do that".

Like when I use my mountain bike to rush a package to the Fedex depot because I can let some air out of the rear shock and then it glides like a Lincoln, over a very dilapidated stretch of the old Lincoln Highway. I even mounted a cargo platform to it. A Lycra-clad pro biker looked at me in disgust "You do WHAT with it?"

--
Regards, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

Exactly. I asked Mini-Circuits "Does that MMIC invert the signal?" and they didn't know. The RF boys just slosh stuff around by the bucket full.

PHEMT DC transfer function? Rds-on? Leakage? C-V curve? Ha!

I know more about a lot of "RF" parts than the makers do.

The Lincoln Highway was cool. In Truckee it is now Donner Pass Road. It was the first coast-to-coast auto highway, starting in Times Square in Manhattan and ending in Lincoln Park (now a golf course) in San Francisco. 3389 miles long.

I drive it to get to Sugar Bowl. It's spectacular.

formatting link

formatting link

formatting link

--
John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  
 Click to see the full signature
Reply to
John Larkin

[...]

In our area it looks more like this and that's the smoother part:

formatting link

On a road bike it can be bone-jarring but the mountian bike rides very smoothly.

--
Regards, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

Am 16.03.2018 um 22:01 schrieb John Larkin:

The s-parameters answer that question better than yes or no. :-)

Reply to
Gerhard Hoffmann

Almost 50% of the time!

--
John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  
 Click to see the full signature
Reply to
John Larkin

On 3/16/2018 1:18 PM, John Larkin wrote: > I finally got a test case for my FPGA async one-shot idea, hacked into > a build for something else. > > I got 17 different one-shots, with various pin locations and > speed/drive strength settings. > >

formatting link
> > > The Xilinx tools didn't approve of us doing this. > This was the circuit I used to generate 'synchronous' write enables for the LUT RAMs in the XC4000 family. This was the first Xilinx FPGA family that allowed the LUTs to be used as RAMs. The LUT RAM operation was all async, including the write enable, and I needed the RAM writes to occur in a single clock cycle.

This was for a proof-of-concept (non-production) system and it worked flawlessly.

Reply to
Paul Urbanus

Was that all internal to the FPGA, or did you loop through a pin?

--
John Larkin         Highland Technology, Inc 

lunatic fringe electronics
 Click to see the full signature
Reply to
John Larkin

All internal, with the feedback routing being spatially local.

Had some discussions with Xilinx engineering about this and whether the reset pulse would be too short to effect a reliable write if the LUT RAMs were slow. The concern was with the variation in timing due to process variation across the die. However, in this design the RAMs were close to the write pulse one-shot. The consensus was that since the write pulse generator and RAMs were relatively close together, process variation over that small area of (one-shot + LUT RAMS) was negligible. Thus a short/fast one-shot pulse was likely to be driving neighboring RAMs which were correspondingly fast.

This was a video formatting application and the absence of artifacts on the display was deemed implicit confirmation of correction functionality.

Reply to
Paul Urbanus

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.