> 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.
Reply by John Larkin●March 22, 20182018-03-22
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 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
Reply by Gerhard Hoffmann●March 16, 20182018-03-16
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. :-)
> 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.
>
Reply by Joerg●March 16, 20182018-03-16
On 2018-03-16 14:01, John Larkin wrote:
> On Fri, 16 Mar 2018 13:00:14 -0700, Joerg <news@analogconsultants.com>
> wrote:
>
[...]
>> 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?"
>
>
> 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.
>
> https://www.dropbox.com/s/5hsohvy2ogacmbf/CW_Donner_Lake.jpg?raw=1
>
> https://www.dropbox.com/s/5x685s2vb5xtxvd/Rainbow_Bridge.jpg?raw=1
>
> https://en.wikipedia.org/wiki/Lincoln_Highway
>
On Fri, 16 Mar 2018 13:00:14 -0700, Joerg <news@analogconsultants.com>
wrote:
>On 2018-03-16 12:17, John Larkin wrote:
>> On Fri, 16 Mar 2018 11:43:54 -0700, Joerg <news@analogconsultants.com>
>> wrote:
>>
>>> On 2018-03-16 11:18, 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
>>>>
>>>>
>>>> Most of the outputs look like this, with remarkably consistent timing,
>>>> edges within a few hundred ps. This is typical:
>>>>
>>>> https://www.dropbox.com/s/f6a3a66kxjfm776/DIV_RESET.JPG?raw=1
>>>>
>>>> This one has minimum pin speed and drive strength, and was driving
>>>> another chip on the board:
>>>>
>>>> https://www.dropbox.com/s/8sdm8dz36um7b1p/GD4.JPG?raw=1
>>>>
>>>> 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.
>>>>
>>>
>>> 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?
>>
>> 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.
>>
>>>
>>> Unorthodox tricks are the most fun in electronics design.
>>
>> The tools pitch hissy-fits when you do async stuff, like ring
>> oscillators. We are offending The Church Of Synchronous Design.
>>
>
>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 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.
>
>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?"
> On Fri, 16 Mar 2018 11:43:54 -0700, Joerg <news@analogconsultants.com>
> wrote:
>
>> On 2018-03-16 11:18, 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
>>>
>>>
>>> Most of the outputs look like this, with remarkably consistent timing,
>>> edges within a few hundred ps. This is typical:
>>>
>>> https://www.dropbox.com/s/f6a3a66kxjfm776/DIV_RESET.JPG?raw=1
>>>
>>> This one has minimum pin speed and drive strength, and was driving
>>> another chip on the board:
>>>
>>> https://www.dropbox.com/s/8sdm8dz36um7b1p/GD4.JPG?raw=1
>>>
>>> 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.
>>>
>>
>> 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?
>
> 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.
>
>>
>> Unorthodox tricks are the most fun in electronics design.
>
> The tools pitch hissy-fits when you do async stuff, like ring
> oscillators. We are offending The Church Of Synchronous Design.
>
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 by John Larkin●March 16, 20182018-03-16
On Fri, 16 Mar 2018 11:43:54 -0700, Joerg <news@analogconsultants.com>
wrote:
>On 2018-03-16 11:18, 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
>>
>>
>> Most of the outputs look like this, with remarkably consistent timing,
>> edges within a few hundred ps. This is typical:
>>
>> https://www.dropbox.com/s/f6a3a66kxjfm776/DIV_RESET.JPG?raw=1
>>
>> This one has minimum pin speed and drive strength, and was driving
>> another chip on the board:
>>
>> https://www.dropbox.com/s/8sdm8dz36um7b1p/GD4.JPG?raw=1
>>
>> 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.
>>
>
>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?
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.
>
>Unorthodox tricks are the most fun in electronics design.
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
jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com
Reply by John Larkin●March 16, 20182018-03-16
On Fri, 16 Mar 2018 18:30:50 -0000 (UTC), gtwrek@sonic.net (gtwrek)
wrote:
>In article <7d1oadljinht0pjm5scgih4n5eou1uqv9u@4ax.com>,
>John Larkin <jjlarkin@highland_snip_technology.com> 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
>>
>>
>>Most of the outputs look like this, with remarkably consistent timing,
>>edges within a few hundred ps. This is typical:
>>
>>https://www.dropbox.com/s/f6a3a66kxjfm776/DIV_RESET.JPG?raw=1
>>
>>This one has minimum pin speed and drive strength, and was driving
>>another chip on the board:
>>
>>https://www.dropbox.com/s/8sdm8dz36um7b1p/GD4.JPG?raw=1
>>
>>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 - 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
>
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
jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com