FPGARelated.com
Forums

the FPGA one-shot

Started by John Larkin March 16, 2018
On Sat, 17 Mar 2018 00:50:33 +0100, Gerhard Hoffmann
<gerhard@hoffmann-hochfrequenz.de> wrote:

>Am 16.03.2018 um 22:01 schrieb 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". >> >> Exactly. I asked Mini-Circuits "Does that MMIC invert the signal?" and >> they didn't know. > > The s-parameters answer that question better than yes or no. :-)
Almost 50% of the time! -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
:}&#4294967295;&#1519;&#4294967295;&#4294967295;_5&#4294967295;&#4294967295;&#4294967295;&&#4294967295;g-&#4294967295;&#4294967295;|+&#4294967295;&#1480;~)&#1686;\&#4294967295;&#4294967295;&#1453;z&#4294967295;\j&#479;&#4294967295;&#4294967295;&#4294967295;&#4294967295;j&#807;r&#4294967295;&#1970;-&#4294967295;&#1498;&#4294967295;&#4294967295;$y&#1575;&#4294967295;&#4294967295;&#4294967295;&#4294967295;)]~&#4294967295;&#4294967295;g&#4294967295;&#4294967295;)&#4294967295;z["
-&#1527;b}&#4294967295;&#4294967295;z{h&#4294967295;&#4294967295;!&#4294967295;&#4294967295;0&#4294967295;&#4294967295;oj&#4294967295;&#4294967295;&#4294967295;&#4294967295;b&#4294967295;Zj&#1576;&#4294967295;&#423;v&#4294967295;^y&#4294967295;&#1902;+&#1970;&#4294967295;&#1950;a&#4294967295;&#4294967295;m&#4294967295;x,&#4294967295;&#4294967295;i&#4294967295;&#4294967295;&#4294967295;&#4294967295;k&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;kn&#27002;`&#4294967295;&#4294967295;<`KRO&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#10647;&#4294967295;N&#4294967295;&#4294967295;X&#4294967295;&#4294967295;&#4294967295;(&#4294967295;&#4294967295;bv{Z&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;h&#4294967295;x-&#4294967295;+&#4294967295;+0j&#4294967295;ay&#555;r&#4294967295;"&#4294967295;v&#4294967295; zw&#4294967295;j&#1516;&#4294967295;w!&#4294967295;&#4294967295;&#4294967295;&#4294967295;+&#4294967295;&#1502;&#4294967295;&#4294967295;&#4294967295;z&#4294967295;&#4294967295;&#4294967295;^-D&#4294967295;&#4294967295;"&#4294967295;&#4294967295;^\.4&#4294967295;G&#1690;)rN&#4294967295;&#4294967295;&#4294967295;-&#4294967295;&#4294967295;&#4294967295;&#4294967295;W&#4294967295;X&#4294967295;&#4294967295;S&#4294967295;&#4294967295;&#4294967295;&#4294967295;\&#4294967295;&#4294967295;&#4294967295;Z&#4294967295;Z0y&#4294967295;ax&#4294967295;&#4294967295;&#4294967295;z&#4294967295;u&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;M&#4294967295;&#4294967295;&#4294967295;j&#1576;&#4294967295;&#4294967295;jYZ&#4294967295;)&#1802;w%&#4294967295;&#1575;&#4294967295;&#4294967295;^&cedil;&#4294967295;y&#4294967295;&#4294967295;nW&#4294967295;&#4294967295;&#4294967295;'y&#4294967295;^v&#4294967295;^D0&#4294967295;+^&#4294967295;&#4294967295;(q&#747;&#4294967295;v&#4294967295;&#4294967295;x%y&#4294967295;hrG2rW&#4294967295;&#4294967295;+0j&#4294967295;&#35690;k&#4294967295;&#4294967295;&#4294967295;}&#4294967295;'q&#4294967295;m&#4294967295;&#4294967295;&#39815;nr&#1576;&#4294967295;&#812;&#4294967295;&#38557;&#1581;&#138;&#4294967295;y&#4294967295;&#4294967295;k	^&#4294967295;&#4294967295;r
On Thu, 22 Mar 2018 06:00:38 -0500, Paul Urbanus <urb@urbonix.com>
wrote:

>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. > > > > https://www.dropbox.com/s/4hxena27mpbpg54/FPGA_OS_1.JPG?raw=1 > > <snipped> > > > > 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. >
Was that all internal to the FPGA, or did you loop through a pin? -- John Larkin Highland Technology, Inc lunatic fringe electronics
On 3/22/2018 8:52 AM, John Larkin wrote:
> On Thu, 22 Mar 2018 06:00:38 -0500, Paul Urbanus <urb@urbonix.com> > wrote: > >> 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. >>> >>> https://www.dropbox.com/s/4hxena27mpbpg54/FPGA_OS_1.JPG?raw=1 >>> <snipped> >>> >>> 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. >> > > Was that all internal to the FPGA, or did you loop through a pin? > >
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.