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
2017JanFebMarApr2017

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 159800

Article: 159800
Subject: Re: temperature sense diodes in Xilinx 7 series
From: John Larkin <jjlarkin@highlandtechnology.com>
Date: Wed, 08 Mar 2017 22:00:21 -0800
Links: << >>  << T >>  << A >>
On 05 Mar 2017 10:41:05 GMT, Allan Herriman
<allanherriman@hotmail.com> wrote:

>On Sat, 04 Mar 2017 09:29:14 -0800, John Larkin wrote:
>
>> On 04 Mar 2017 10:52:06 GMT, Allan Herriman <allanherriman@hotmail.com>
>> wrote:
>> 
>>>On Fri, 03 Mar 2017 14:00:17 -0800, John Larkin wrote:
>>>
>>>> On Fri, 03 Mar 2017 13:34:58 -0800, John Larkin
>>>> <jjlarkinxyxy@highlandtechnology.com> wrote:
>>>> 
>>>>>Has anybody used these?
>>>>>
>>>>>We have two FPGAs on a board, a Zynq and an Artix7. We want to use the
>>>>>internal ADCs to read chip temperatures. We have been advised to
>>>>>ground the temp sense diode pins DXP and DXN "if they are not being
>>>>>used".
>>>>>
>>>>>Unless the XADC has a separate temp sense diode, seems to me that
>>>>>shorting the external diode pins might kill our ability to acquire
>>>>>temperature internally.
>>>>>
>>>>>I don't see any big downside to not grounding those pins.
>>>> 
>>>> After too much research, it seems that there are independent temp
>>>> sensors, the external-pin one and another inside the XADC.
>>>
>>>And they recommend grounding DXP and DXN to improve the ESD rating. 
>>>IIRC there's no functional issue caused by leaving them open.
>>>
>>>Regards,
>>>Allan
>> 
>> Right, the esd thing makes no sense at all.
>
>Why do you say it makes no sense?  A lot of devices have an improved ESD 
>rating when their more sensitive pins are connected to low impedance 
>sources (as opposed to being open).
>
>Of course, if those pins are on a via-less pad under a BGA on a PCB with 
>good planes, the difference may be hard to measure.
>
>Regards,
>Allan

Do you ground every unused pin on every FPGA? 


-- 

John Larkin         Highland Technology, Inc

lunatic fringe electronics 


Article: 159801
Subject: Analog to digital converters
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Thu, 9 Mar 2017 01:46:10 -0800 (PST)
Links: << >>  << T >>  << A >>
I don't know where to ask this, so I'll try here.

Are analog to digital converters fundamentally, in their core inner
design, basically tiny systems which operate like 555 timers, with a
series of resistors and capacitors designed to sample ranges, essentially
counting ticks per fixed units of time, resulting in the digital data
necessary to perform an indexed lookup from the inner sampler
that's in range, to produce an output bit patfern?  With then
some tail logic to prevent jitter beyond an expected operating
range / frequency?

Thank you,
Rick C. Hodgin

Article: 159802
Subject: Re: temperature sense diodes in Xilinx 7 series
From: Allan Herriman <allanherriman@hotmail.com>
Date: 09 Mar 2017 10:00:30 GMT
Links: << >>  << T >>  << A >>
On Wed, 08 Mar 2017 22:00:21 -0800, John Larkin wrote:

> On 05 Mar 2017 10:41:05 GMT, Allan Herriman <allanherriman@hotmail.com>
> wrote:
> 
>>On Sat, 04 Mar 2017 09:29:14 -0800, John Larkin wrote:
>>
>>> On 04 Mar 2017 10:52:06 GMT, Allan Herriman
>>> <allanherriman@hotmail.com>
>>> wrote:
>>> 
>>>>On Fri, 03 Mar 2017 14:00:17 -0800, John Larkin wrote:
>>>>
>>>>> On Fri, 03 Mar 2017 13:34:58 -0800, John Larkin
>>>>> <jjlarkinxyxy@highlandtechnology.com> wrote:
>>>>> 
>>>>>>Has anybody used these?
>>>>>>
>>>>>>We have two FPGAs on a board, a Zynq and an Artix7. We want to use
>>>>>>the internal ADCs to read chip temperatures. We have been advised to
>>>>>>ground the temp sense diode pins DXP and DXN "if they are not being
>>>>>>used".
>>>>>>
>>>>>>Unless the XADC has a separate temp sense diode, seems to me that
>>>>>>shorting the external diode pins might kill our ability to acquire
>>>>>>temperature internally.
>>>>>>
>>>>>>I don't see any big downside to not grounding those pins.
>>>>> 
>>>>> After too much research, it seems that there are independent temp
>>>>> sensors, the external-pin one and another inside the XADC.
>>>>
>>>>And they recommend grounding DXP and DXN to improve the ESD rating.
>>>>IIRC there's no functional issue caused by leaving them open.
>>>>
>>>>Regards,
>>>>Allan
>>> 
>>> Right, the esd thing makes no sense at all.
>>
>>Why do you say it makes no sense?  A lot of devices have an improved ESD
>>rating when their more sensitive pins are connected to low impedance
>>sources (as opposed to being open).
>>
>>Of course, if those pins are on a via-less pad under a BGA on a PCB with
>>good planes, the difference may be hard to measure.
>>
>>Regards,
>>Allan
> 
> Do you ground every unused pin on every FPGA?

Of course not, but I do ground pins that the manufacturer says to ground.

Last century (using QFP packages) I would sometimes ground extra IO pins 
to help with ground bounce on IO banks that had more O than I.

Allan

Article: 159803
Subject: Re: Analog to digital converters
From: David Wade <g4ugm@dave.invalid>
Date: Thu, 9 Mar 2017 10:59:25 +0000
Links: << >>  << T >>  << A >>
On 09/03/2017 09:46, Rick C. Hodgin wrote:
> I don't know where to ask this, so I'll try here.
>
> Are analog to digital converters fundamentally, in their core inner
> design, basically tiny systems which operate like 555 timers, with a
> series of resistors and capacitors designed to sample ranges, essentially
> counting ticks per fixed units of time, resulting in the digital data
> necessary to perform an indexed lookup from the inner sampler
> that's in range, to produce an output bit patfern?  With then
> some tail logic to prevent jitter beyond an expected operating
> range / frequency?
>
> Thank you,
> Rick C. Hodgin
>
There are several designs. Why not start with the obvious place...

https://en.wikipedia.org/wiki/Analog-to-digital_converter

for an over view of the varios techniques..

Dave

Article: 159804
Subject: Re: Analog to digital converters
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Thu, 9 Mar 2017 04:31:37 -0800 (PST)
Links: << >>  << T >>  << A >>
Thank you.

I like to figure things out.  And as these ideas occur to me, I like to
see if I'm correct.  Wikipedia locks up my Dolphin web browser. :-(

Thank you,
Rick C. Hodgin

Article: 159805
Subject: Re: Analog to digital converters
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Thu, 9 Mar 2017 05:46:07 -0800 (PST)
Links: << >>  << T >>  << A >>
On Thursday, March 9, 2017 at 5:59:27 AM UTC-5, David Wade wrote:
> On 09/03/2017 09:46, Rick C. Hodgin wrote:
> > Are analog to digital converters fundamentally, in their core inner
> > design, basically tiny systems which operate like 555 timers, with a
> > series of resistors and capacitors designed to sample ranges, essentially
> > counting ticks per fixed units of time, resulting in the digital data
> > necessary to perform an indexed lookup from the inner sampler
> > that's in range, to produce an output bit patfern?  With then
> > some tail logic to prevent jitter beyond an expected operating
> > range / frequency?
>
> There are several designs. Why not start with the obvious place...
> 
> https://en.wikipedia.org/wiki/Analog-to-digital_converter
> 
> for an over view of the varios techniques..

I was able to look at it on my desktop computer.  Thank you for the
assistance. :-)

Thank you,
Rick C. Hodgin

Article: 159806
Subject: Re: Analog to digital converters
From: David Brown <david.brown@hesbynett.no>
Date: Thu, 09 Mar 2017 14:57:56 +0100
Links: << >>  << T >>  << A >>
On 09/03/17 14:46, Rick C. Hodgin wrote:
> On Thursday, March 9, 2017 at 5:59:27 AM UTC-5, David Wade wrote:
>> On 09/03/2017 09:46, Rick C. Hodgin wrote:
>>> Are analog to digital converters fundamentally, in their core inner
>>> design, basically tiny systems which operate like 555 timers, with a
>>> series of resistors and capacitors designed to sample ranges, essentially
>>> counting ticks per fixed units of time, resulting in the digital data
>>> necessary to perform an indexed lookup from the inner sampler
>>> that's in range, to produce an output bit patfern?  With then
>>> some tail logic to prevent jitter beyond an expected operating
>>> range / frequency?
>>
>> There are several designs. Why not start with the obvious place...
>>
>> https://en.wikipedia.org/wiki/Analog-to-digital_converter
>>
>> for an over view of the varios techniques..
> 
> I was able to look at it on my desktop computer.  Thank you for the
> assistance. :-)
> 

You can see there are many methods - none of which fits very well with
the description you wrote, as far as I can see.

Successive approximation ADC's are the most common for general purpose
ADCs.  Flash (direct conversion) ADC's are used for very high speed, and
Sigma-Delta is the usual method for high resolution (such as audio ADC's).




Article: 159807
Subject: Re: designing a fpga
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Thu, 09 Mar 2017 13:46:42 -0500
Links: << >>  << T >>  << A >>
On Sat, 25 Feb 2017 09:37:46 -0500, Rick C. Hodgin  
<rick.c.hodgin@gmail.com> wrote:

> I've been considering designing my own fpga to go with my Logician
> tool.  I would call it Si-Block ("sigh-block," or SiB for short).  It  
> would
> allow unlimited logic with a decreasing performance level the more
> complex it got, running on a saturating clock that fires maximally
> at frequency, but otherwise only when each cycle completes fully.
> It would be inexpensive, with full debug abilities, and room to
> expand.
>
> Stack:
>
>     0: [SiB hardware]
>     1: [Logician, simulation + SiB compiler]
>     2: [HLL Compilers, able to also output to Logician]
>     3: [IDE / text editors, express in some language]
>     4: [Human ideas]

I have continued this idea with some development toward what I'm
probably going to start calling an I/O CPU.  It is built around
a cell core, which has the ability to process in a myriad of
ways around a 64-bit piece of data.  It can communicate with its
North, South, East, West neighbors, and retrieve from their 64-
bit data as well.  Eight 8-bit cores exist in each cell, which
are able to operate independently, or in ganged mode, allowing
for a wide range of processing models.  An executive manager
sits atop each cell, and is coordinated with it via a parallel
instruction stream which has some general purpose computing,
as well as being able to coordinate reads and writes to other
system buses, including masked reads/writes to fixed I/O data
pins which are sampled independently and copied onto the main
bus available data input and output.

An array of 3x3 of these cells operate, and you can see some
of the preliminary work here.  I am calling it Arlina FPGA,
but that name will soon be changed to Arlina I/O CPU:

     http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/arlina

You can see my previous L1 cache design here:

     http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/arxoda/core/cache_l1/cache1__4read_4write_poster.png

It is an 8-bit cache cell, which is aggregated up to a 128-
bit cache row, which is aggregated up to 16KB instruction,
and 32KB data, supporting 40-bit data and 40- to 44-bit
addresses.

Thank you,
Rick C. Hodgin

Article: 159808
Subject: Re: Analog to digital converters
From: GaborSzakacs <gabor@alacron.com>
Date: Thu, 09 Mar 2017 16:05:37 -0500
Links: << >>  << T >>  << A >>
David Brown wrote:
> On 09/03/17 14:46, Rick C. Hodgin wrote:
>> On Thursday, March 9, 2017 at 5:59:27 AM UTC-5, David Wade wrote:
>>> On 09/03/2017 09:46, Rick C. Hodgin wrote:
>>>> Are analog to digital converters fundamentally, in their core inner
>>>> design, basically tiny systems which operate like 555 timers, with a
>>>> series of resistors and capacitors designed to sample ranges, essentially
>>>> counting ticks per fixed units of time, resulting in the digital data
>>>> necessary to perform an indexed lookup from the inner sampler
>>>> that's in range, to produce an output bit patfern?  With then
>>>> some tail logic to prevent jitter beyond an expected operating
>>>> range / frequency?
>>> There are several designs. Why not start with the obvious place...
>>>
>>> https://en.wikipedia.org/wiki/Analog-to-digital_converter
>>>
>>> for an over view of the varios techniques..
>> I was able to look at it on my desktop computer.  Thank you for the
>> assistance. :-)
>>
> 
> You can see there are many methods - none of which fits very well with
> the description you wrote, as far as I can see.
> 
> Successive approximation ADC's are the most common for general purpose
> ADCs.  Flash (direct conversion) ADC's are used for very high speed, and
> Sigma-Delta is the usual method for high resolution (such as audio ADC's).
> 
> 
> 

Single or Dual-slope integrating ADCs (very slow) are more like the
555 timer approach (if I understand the OP correctly).  These are
used where speed of conversion is not important, but high resolution
and noise immunity are.  You might find them in a digital multimeter.
I used one in a blood chemistry analyzer.  Single-slope is less common.
Dual slope works by integrating up on a reference input (constant up
slope), then down using the input signal (variable down slope.  The
time to integrate down to the low threshold is measured to give the
ADC output.  The up integration time is fixed (there is no high
threshold).  This allows the output value to be independant of the
integrating capacitor value as long as the cap is large enough to
prevent saturation during ramp up.

-- 
Gabor

Article: 159809
Subject: Re: Analog to digital converters
From: GaborSzakacs <gabor@alacron.com>
Date: Thu, 09 Mar 2017 16:17:39 -0500
Links: << >>  << T >>  << A >>
GaborSzakacs wrote:
> David Brown wrote:
>> On 09/03/17 14:46, Rick C. Hodgin wrote:
>>> On Thursday, March 9, 2017 at 5:59:27 AM UTC-5, David Wade wrote:
>>>> On 09/03/2017 09:46, Rick C. Hodgin wrote:
>>>>> Are analog to digital converters fundamentally, in their core inner
>>>>> design, basically tiny systems which operate like 555 timers, with a
>>>>> series of resistors and capacitors designed to sample ranges, 
>>>>> essentially
>>>>> counting ticks per fixed units of time, resulting in the digital data
>>>>> necessary to perform an indexed lookup from the inner sampler
>>>>> that's in range, to produce an output bit patfern?  With then
>>>>> some tail logic to prevent jitter beyond an expected operating
>>>>> range / frequency?
>>>> There are several designs. Why not start with the obvious place...
>>>>
>>>> https://en.wikipedia.org/wiki/Analog-to-digital_converter
>>>>
>>>> for an over view of the varios techniques..
>>> I was able to look at it on my desktop computer.  Thank you for the
>>> assistance. :-)
>>>
>>
>> You can see there are many methods - none of which fits very well with
>> the description you wrote, as far as I can see.
>>
>> Successive approximation ADC's are the most common for general purpose
>> ADCs.  Flash (direct conversion) ADC's are used for very high speed, and
>> Sigma-Delta is the usual method for high resolution (such as audio 
>> ADC's).
>>
>>
>>
> 
> Single or Dual-slope integrating ADCs (very slow) are more like the
> 555 timer approach (if I understand the OP correctly).  These are
> used where speed of conversion is not important, but high resolution
> and noise immunity are.  You might find them in a digital multimeter.
> I used one in a blood chemistry analyzer.  Single-slope is less common.
> Dual slope works by integrating up on a reference input (constant up
> slope), then down using the input signal (variable down slope.  The
> time to integrate down to the low threshold is measured to give the
> ADC output.  The up integration time is fixed (there is no high
> threshold).  This allows the output value to be independant of the
> integrating capacitor value as long as the cap is large enough to
> prevent saturation during ramp up.
> 

Oops!  I got that backwards.  Up slope is fixed time but rate is
based on the input signal.  Down slope is fixed rate set by a reference
and time is measured to get ADC value.  The way I originally described
it would end up with a 1/x factor in the conversion value.  In either
case, the circuitry is quite simple since the control logic is mostly
a big counter.  The timing is generally provided externally, as
is the integrating capacitor, which can be quite large and generally
wants to be polypropylene or similar dielectric to reduce effects
of surface charge storage (rebound).

   Last time I used one of these was back in the early 1980's.

-- 
Gabor

Article: 159810
Subject: Re: Analog to digital converters
From: GaborSzakacs <gabor@alacron.com>
Date: Thu, 09 Mar 2017 16:49:44 -0500
Links: << >>  << T >>  << A >>
GaborSzakacs wrote:
> GaborSzakacs wrote:
>> David Brown wrote:
>>> On 09/03/17 14:46, Rick C. Hodgin wrote:
>>>> On Thursday, March 9, 2017 at 5:59:27 AM UTC-5, David Wade wrote:
>>>>> On 09/03/2017 09:46, Rick C. Hodgin wrote:
>>>>>> Are analog to digital converters fundamentally, in their core inner
>>>>>> design, basically tiny systems which operate like 555 timers, with a
>>>>>> series of resistors and capacitors designed to sample ranges, 
>>>>>> essentially
>>>>>> counting ticks per fixed units of time, resulting in the digital data
>>>>>> necessary to perform an indexed lookup from the inner sampler
>>>>>> that's in range, to produce an output bit patfern?  With then
>>>>>> some tail logic to prevent jitter beyond an expected operating
>>>>>> range / frequency?
>>>>> There are several designs. Why not start with the obvious place...
>>>>>
>>>>> https://en.wikipedia.org/wiki/Analog-to-digital_converter
>>>>>
>>>>> for an over view of the varios techniques..
>>>> I was able to look at it on my desktop computer.  Thank you for the
>>>> assistance. :-)
>>>>
>>>
>>> You can see there are many methods - none of which fits very well with
>>> the description you wrote, as far as I can see.
>>>
>>> Successive approximation ADC's are the most common for general purpose
>>> ADCs.  Flash (direct conversion) ADC's are used for very high speed, and
>>> Sigma-Delta is the usual method for high resolution (such as audio 
>>> ADC's).
>>>
>>>
>>>
>>
>> Single or Dual-slope integrating ADCs (very slow) are more like the
>> 555 timer approach (if I understand the OP correctly).  These are
>> used where speed of conversion is not important, but high resolution
>> and noise immunity are.  You might find them in a digital multimeter.
>> I used one in a blood chemistry analyzer.  Single-slope is less common.
>> Dual slope works by integrating up on a reference input (constant up
>> slope), then down using the input signal (variable down slope.  The
>> time to integrate down to the low threshold is measured to give the
>> ADC output.  The up integration time is fixed (there is no high
>> threshold).  This allows the output value to be independant of the
>> integrating capacitor value as long as the cap is large enough to
>> prevent saturation during ramp up.
>>
> 
> Oops!  I got that backwards.  Up slope is fixed time but rate is
> based on the input signal.  Down slope is fixed rate set by a reference
> and time is measured to get ADC value.  The way I originally described
> it would end up with a 1/x factor in the conversion value.  In either
> case, the circuitry is quite simple since the control logic is mostly
> a big counter.  The timing is generally provided externally, as
> is the integrating capacitor, which can be quite large and generally
> wants to be polypropylene or similar dielectric to reduce effects
> of surface charge storage (rebound).
> 
>   Last time I used one of these was back in the early 1980's.
> 

Here's a data sheet link for a more recent dual-slope ADC chip.
It's a bit fancier than the one we had in the 1980's but the
main idea is the same:

http://ww1.microchip.com/downloads/en/DeviceDoc/21456D.pdf

-- 
Gabor

Article: 159811
Subject: Re: Analog to digital converters
From: rickman <gnuarm@gmail.com>
Date: Thu, 9 Mar 2017 18:20:14 -0500
Links: << >>  << T >>  << A >>
On 3/9/2017 4:49 PM, GaborSzakacs wrote:
> GaborSzakacs wrote:
>> GaborSzakacs wrote:
>>> David Brown wrote:
>>>> On 09/03/17 14:46, Rick C. Hodgin wrote:
>>>>> On Thursday, March 9, 2017 at 5:59:27 AM UTC-5, David Wade wrote:
>>>>>> On 09/03/2017 09:46, Rick C. Hodgin wrote:
>>>>>>> Are analog to digital converters fundamentally, in their core inner
>>>>>>> design, basically tiny systems which operate like 555 timers, with a
>>>>>>> series of resistors and capacitors designed to sample ranges,
>>>>>>> essentially
>>>>>>> counting ticks per fixed units of time, resulting in the digital
>>>>>>> data
>>>>>>> necessary to perform an indexed lookup from the inner sampler
>>>>>>> that's in range, to produce an output bit patfern?  With then
>>>>>>> some tail logic to prevent jitter beyond an expected operating
>>>>>>> range / frequency?
>>>>>> There are several designs. Why not start with the obvious place...
>>>>>>
>>>>>> https://en.wikipedia.org/wiki/Analog-to-digital_converter
>>>>>>
>>>>>> for an over view of the varios techniques..
>>>>> I was able to look at it on my desktop computer.  Thank you for the
>>>>> assistance. :-)
>>>>>
>>>>
>>>> You can see there are many methods - none of which fits very well with
>>>> the description you wrote, as far as I can see.
>>>>
>>>> Successive approximation ADC's are the most common for general purpose
>>>> ADCs.  Flash (direct conversion) ADC's are used for very high speed,
>>>> and
>>>> Sigma-Delta is the usual method for high resolution (such as audio
>>>> ADC's).
>>>>
>>>>
>>>>
>>>
>>> Single or Dual-slope integrating ADCs (very slow) are more like the
>>> 555 timer approach (if I understand the OP correctly).  These are
>>> used where speed of conversion is not important, but high resolution
>>> and noise immunity are.  You might find them in a digital multimeter.
>>> I used one in a blood chemistry analyzer.  Single-slope is less common.
>>> Dual slope works by integrating up on a reference input (constant up
>>> slope), then down using the input signal (variable down slope.  The
>>> time to integrate down to the low threshold is measured to give the
>>> ADC output.  The up integration time is fixed (there is no high
>>> threshold).  This allows the output value to be independant of the
>>> integrating capacitor value as long as the cap is large enough to
>>> prevent saturation during ramp up.
>>>
>>
>> Oops!  I got that backwards.  Up slope is fixed time but rate is
>> based on the input signal.  Down slope is fixed rate set by a reference
>> and time is measured to get ADC value.  The way I originally described
>> it would end up with a 1/x factor in the conversion value.  In either
>> case, the circuitry is quite simple since the control logic is mostly
>> a big counter.  The timing is generally provided externally, as
>> is the integrating capacitor, which can be quite large and generally
>> wants to be polypropylene or similar dielectric to reduce effects
>> of surface charge storage (rebound).
>>
>>   Last time I used one of these was back in the early 1980's.
>>
>
> Here's a data sheet link for a more recent dual-slope ADC chip.
> It's a bit fancier than the one we had in the 1980's but the
> main idea is the same:
>
> http://ww1.microchip.com/downloads/en/DeviceDoc/21456D.pdf

One of the advantages of dual slope conversion is that zero input gives 
a zero reading.  Or do they have a separate offset circuit for this?  I 
know many tout such in their designs.

-- 

Rick C

Article: 159812
Subject: Re: Analog to digital converters
From: GaborSzakacs <gabor@alacron.com>
Date: Fri, 10 Mar 2017 09:28:50 -0500
Links: << >>  << T >>  << A >>
rickman wrote:
> On 3/9/2017 4:49 PM, GaborSzakacs wrote:

[snip]

>> Here's a data sheet link for a more recent dual-slope ADC chip.
>> It's a bit fancier than the one we had in the 1980's but the
>> main idea is the same:
>>
>> http://ww1.microchip.com/downloads/en/DeviceDoc/21456D.pdf
> 
> One of the advantages of dual slope conversion is that zero input gives 
> a zero reading.  Or do they have a separate offset circuit for this?  I 
> know many tout such in their designs.
> 

The MicroChip part in the link has an additional "auto-zero phase"
that removes any offset.  See section 3.1.1 in the data sheet.

Another advantage for DC measurement is that the conversion is taken
on the integral of the input voltage over some fixed time period.
This makes it easy to filter out AC noise including power line noise.
The the blood chemistry analyzer we used a multiple of the line
period (50 or 60 Hz) as the integration time.  A sampling time of
0.1 second would remove line-frequency noise from 50 or 60 Hz power.
This is useful in a handheld multimeter, where the leads are long
and can pick up noise easily.

-- 
Gabor

Article: 159813
Subject: Re: Analog to digital converters
From: John Larkin <jjlarkin@highlandtechnology.com>
Date: Sat, 11 Mar 2017 14:57:42 -0800
Links: << >>  << T >>  << A >>
On Thu, 09 Mar 2017 14:57:56 +0100, David Brown
<david.brown@hesbynett.no> wrote:

>On 09/03/17 14:46, Rick C. Hodgin wrote:
>> On Thursday, March 9, 2017 at 5:59:27 AM UTC-5, David Wade wrote:
>>> On 09/03/2017 09:46, Rick C. Hodgin wrote:
>>>> Are analog to digital converters fundamentally, in their core inner
>>>> design, basically tiny systems which operate like 555 timers, with a
>>>> series of resistors and capacitors designed to sample ranges, essentially
>>>> counting ticks per fixed units of time, resulting in the digital data
>>>> necessary to perform an indexed lookup from the inner sampler
>>>> that's in range, to produce an output bit patfern?  With then
>>>> some tail logic to prevent jitter beyond an expected operating
>>>> range / frequency?
>>>
>>> There are several designs. Why not start with the obvious place...
>>>
>>> https://en.wikipedia.org/wiki/Analog-to-digital_converter
>>>
>>> for an over view of the varios techniques..
>> 
>> I was able to look at it on my desktop computer.  Thank you for the
>> assistance. :-)
>> 
>
>You can see there are many methods - none of which fits very well with
>the description you wrote, as far as I can see.
>
>Successive approximation ADC's are the most common for general purpose
>ADCs.  Flash (direct conversion) ADC's are used for very high speed, and
>Sigma-Delta is the usual method for high resolution (such as audio ADC's).
>
>

Pure flash ADCs are rare these days; they need too many power-hungry
comparators. Most fast ADCs are pipeline architectures with radical
levels of digital calibrations.


-- 

John Larkin         Highland Technology, Inc

lunatic fringe electronics 


Article: 159814
Subject: Lattice Semiconductor XP2 Brevia 2 help on keyboard controller
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 15 Mar 2017 09:57:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
I have an IBM Model-F capacitive keyboard.  I would like to design my
own keyboard controller for it.  I understand logically how to do it,
but I need help with the mechanics.

Would somebody be interested in helping me?

I have a mod which makes the layout more like traditional keyboards,
except I replaced the single enter key on the numpad with two keys
as there were capacitive sensors there on both key slots.  There are
also additional capacitive sensors between the arrow keys to the
left of the numpad where the white casing exists presently.  It was
a very nice keyboard, and it still works mechanically and is in
good condition.

The keyboard controller was bad.  I bought a replacement and in the
process of soldering it up damaged it.  I decided to create my own
keyboard controller with the Lattice XP2 Brevia 2 board, and I've
found some wiring information on the keyboard:

    Modified keyboard layout:
    https://deskthority.net/resources/ibm-model-f-122-with-a-revamped-model-m-layout-the-top-row/22243

    Information on the physical board's wiring (page 3 in pdf):
    http://downloads.cornall.co/ibm-capsense-usb/
    http://downloads.cornall.co/ibm-capsense-usb/installation_model_f.pdf

Thank you in advance.

Thank you,
Rick C. Hodgin

Article: 159815
Subject: Re: Lattice Semiconductor XP2 Brevia 2 help on keyboard controller
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Fri, 17 Mar 2017 09:30:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, March 15, 2017 at 12:58:03 PM UTC-4, Rick C. Hodgin wrote:
> I have an IBM Model-F capacitive keyboard.  I would like to design my
> own keyboard controller for it.  I understand logically how to do it,
> but I need help with the mechanics.
> 
> Would somebody be interested in helping me?

Here's where I'm beginning:

    https://deskthority.net/w-a-n-t-t-o-b-u-y-f59/ibm-5576-001-3479-ja4-or-ibm-1397000-t10948-30.html#p362667

Thank you,
Rick C. Hodgin

Article: 159816
Subject: Re: Lattice Semiconductor XP2 Brevia 2 help on keyboard controller
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Sun, 19 Mar 2017 18:16:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, March 17, 2017 at 12:30:47 PM UTC-4, Rick C. Hodgin wrote:
> On Wednesday, March 15, 2017 at 12:58:03 PM UTC-4, Rick C. Hodgin wrote:
> > I have an IBM Model-F capacitive keyboard.  I would like to design my
> > own keyboard controller for it.  I understand logically how to do it,
> > but I need help with the mechanics.
> > 
> > Would somebody be interested in helping me?
> 
> Here's where I'm beginning:
> 
>     https://deskthority.net/w-a-n-t-t-o-b-u-y-f59/ibm-5576-001-3479-ja4-or-ibm-1397000-t10948-30.html#p362667

I've had some ideas about keyboard arrangements I'd like to see made in a
Model-F-like capacitance design:

    http://www.libsf.org:8990/projects/LIB/repos/libsf/raw/king/keyboard_designs.png

They are 256-key, 207-key, 191-key, 167-key designed for developers and
content creators (F1 to F24, and lots of macro and general purpose key
assignments pace), along with 135-key and 115-key keyboards for general
purpose use.

I would appreciate any feedback. Thank you in advance.

Thank you,
Rick C. Hodgin

Article: 159817
Subject: Re: Lattice Semiconductor XP2 Brevia 2 help on keyboard controller
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Mon, 20 Mar 2017 09:21:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
There's a new thread I've started on deskthority.net, which will relate
to the development of these products:

    https://deskthority.net/keyboards-f2/ibm-model-f-like-keyboard-designs-t16169.html

Current design.  I've changed the key orientation along the left, and
added the red and blue square buttons previously only on the 256-key
keyboard to all of them:

    http://www.libsf.org:8990/projects/LIB/repos/libsf/raw/king/keyboard_designs.png

Thank you,
Rick C. Hodgin

Article: 159818
Subject: Re: FPGA LABVIEW programming
From: gyansorova@gmail.com
Date: Mon, 20 Mar 2017 20:35:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, October 17, 2016 at 7:10:07 AM UTC+13, Kevin Neilson wrote:
> > I can look at a schematic and tell a circuit is a shift register, I can
> > look at VHDL/Verilog code and see a shift register, but that mess of
> > LabView crud they hade on the screen looked NOTHING like a shift
> > register.  I know this is pretty much version 1 of their FPGA software,
> > but it will take much more work before it is ever usefull as a design
> > tool.
> > 
> > I can't see how this will ever catch on for LabView...
> 
> That's been my impression of any "high-level" tool I've used, especially any graphical ones.  They are possible in theory, but in practice they are generally terrible.

How wrong can you be!! It's a fantastic tool.

Article: 159819
Subject: Re: Xilinx Virtex4 Outputs for Camera Link
From: powermail787@gmail.com
Date: Wed, 22 Mar 2017 04:11:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, October 31, 2006 at 5:27:42 AM UTC+5:30, Will Dean wrote:
> "Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message 
> news:12kcsm5kh166g4a@corp.supernews.com...
> >
> > Pin count and input/output flexibility.
> 
> Pin-count is a good one - I hadn't thought of that.  Does the Virtex design 
> track nicely to the 3M connectors?
> 
> Cheers,
> 
> Will


Article: 159820
Subject: Re: Go to church on Sunday
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 22 Mar 2017 08:32:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
I will leave this newsgroup.  I do not receive help here because I have
posted about Jesus Christ being the way to eternal life.  And I have
left a solid witness here for anyone seeking to find Christ.

I wish you all well, and that you would come to faith in Jesus Christ.
I would like to see you in Heaven.

Thank you,
Rick C. Hodgin

Article: 159821
Subject: Simulation of PCIe at TLP level
From: Svenn Are Bjerkem <svenn.bjerkem@gmail.com>
Date: Fri, 24 Mar 2017 02:23:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,
has anybody simulated PCIe at TLP level? I would like to feed a 1x PCIe endpoint interface with data as if it was inserted into a host PCIe slot.

I need some pointers to documents or code describing what I have to do to make a simplem memory read and memory write.

-- 
Svenn

Article: 159822
Subject: Re: Master Xilinx FPGA like Jtag bridge.
From: jelloaman@gmail.com
Date: Fri, 24 Mar 2017 04:16:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, February 26, 2017 at 4:21:49 PM UTC+6, rickman wrote:
> On 2/26/2017 2:27 AM, abirov@gmail.com wrote:
> > On Saturday, February 25, 2017 at 3:22:21 PM UTC+6, rickman wrote:
> >> On 2/25/2017 12:33 AM, abirov@gmail.com wrote:
> >>> On Saturday, February 25, 2017 at 11:21:13 AM UTC+6, abi...@gmail.com=
 wrote:
> >>>> How to make master FPGA to connect to many FPGAs ?
> >>>>
> >>>> Two FPGAs connected by serial  TDI - TDO, and two fpgas  TMS TCK TDO=
 and TDI connect to master fpga, master fpga has TMS TDI TDO TCK connected =
and working to pc normally, it need to make connection JTAG of two fpgas to=
 other 4 ports or somehow can connect to master's jtag port ?
> >>>
> >>> |   |---------|-TMS----|------------|-TMS----
> >>> |   | FPGA 0  |-TCK----|            |-TCK----
> >>> |   |         |-TDO----|            |-TDO----
> >>> |   |---------|        |            |-TDI----
> >>> |       |              |            |
> >>> |      TDI             |            |
> >>> |       |              |            |
> >>> |       |              | MASTER FPGA|
> >>> |       |              |            |
> >>> |      TDO             |            |
> >>> |       |              |            |
> >>> |   |---------|-TMS----|            |
> >>> |   | FGPA 1  |-TCK----|            |
> >>> |   |         |-TDI----|            |
> >>> |   |---------|        |------------|
> >>>
> >>
> >> Why do you want the master FPGA to control the others rather than
> >> loading them all in one chain?  Connect all TMS and TCK lines in
> >> parallel and connect all TDI and TDO in one big daisy chain.  If the
> >> slave FPGAs are loaded by the master, where will the data come from?
> >>
> >> --
> >>
> >> Rick C
> >
> > It is reverse engineering, someone did this but i just want reuse board=
 only
>=20
> The JTAG signals to the master chip, do they connect to general I/Os as=
=20
> well as to the FPGA JTAG signals?  Or just JTAG or just I/Os?
>=20
> You didn't say where you expect the data to come from to program the=20
> chained slave FPGAs.  Is it supposed to come from the main JTAG port as=
=20
> if it was talking to the slave chain?  Or will the master FPGA have a=20
> separate interface from an MCU or a Flash chip?
>=20
> What is your overall plan?
>=20
> --=20
>=20
> Rick C

Hi, i am also doing same thing and also have same question )))). I think fi=
rst need program master FPGA and then normal masters JTAG can be used as JT=
AG for other tributary fpgas . may be/

Article: 159823
Subject: Re: Master Xilinx FPGA like Jtag bridge.
From: jelloaman@gmail.com
Date: Fri, 24 Mar 2017 04:30:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, February 26, 2017 at 4:21:49 PM UTC+6, rickman wrote:
> On 2/26/2017 2:27 AM, abirov@gmail.com wrote:
> > On Saturday, February 25, 2017 at 3:22:21 PM UTC+6, rickman wrote:
> >> On 2/25/2017 12:33 AM, abirov@gmail.com wrote:
> >>> On Saturday, February 25, 2017 at 11:21:13 AM UTC+6, abi...@gmail.com=
 wrote:
> >>>> How to make master FPGA to connect to many FPGAs ?
> >>>>
> >>>> Two FPGAs connected by serial  TDI - TDO, and two fpgas  TMS TCK TDO=
 and TDI connect to master fpga, master fpga has TMS TDI TDO TCK connected =
and working to pc normally, it need to make connection JTAG of two fpgas to=
 other 4 ports or somehow can connect to master's jtag port ?
> >>>
> >>> |   |---------|-TMS----|------------|-TMS----
> >>> |   | FPGA 0  |-TCK----|            |-TCK----
> >>> |   |         |-TDO----|            |-TDO----
> >>> |   |---------|        |            |-TDI----
> >>> |       |              |            |
> >>> |      TDI             |            |
> >>> |       |              |            |
> >>> |       |              | MASTER FPGA|
> >>> |       |              |            |
> >>> |      TDO             |            |
> >>> |       |              |            |
> >>> |   |---------|-TMS----|            |
> >>> |   | FGPA 1  |-TCK----|            |
> >>> |   |         |-TDI----|            |
> >>> |   |---------|        |------------|
> >>>
> >>
> >> Why do you want the master FPGA to control the others rather than
> >> loading them all in one chain?  Connect all TMS and TCK lines in
> >> parallel and connect all TDI and TDO in one big daisy chain.  If the
> >> slave FPGAs are loaded by the master, where will the data come from?
> >>
> >> --
> >>
> >> Rick C
> >
> > It is reverse engineering, someone did this but i just want reuse board=
 only
>=20
> The JTAG signals to the master chip, do they connect to general I/Os as=
=20
> well as to the FPGA JTAG signals?  Or just JTAG or just I/Os?
>=20
> You didn't say where you expect the data to come from to program the=20
> chained slave FPGAs.  Is it supposed to come from the main JTAG port as=
=20
> if it was talking to the slave chain?  Or will the master FPGA have a=20
> separate interface from an MCU or a Flash chip?
>=20
> What is your overall plan?
>=20
> --=20
>=20
> Rick C

Slave FPGAs connects to USER I/O ports. for example:
TMS of salve FPGA chip connects to user i/o pin  CC
TDI of slave FPGA chip connects to user i/0 pin  VRP
TCK of slave FPGA ship connects to user i/o pin  CC

Article: 159824
Subject: Re: Master Xilinx FPGA like Jtag bridge.
From: rickman <gnuarm@gmail.com>
Date: Fri, 24 Mar 2017 11:21:46 -0400
Links: << >>  << T >>  << A >>
On 3/24/2017 7:30 AM, jelloaman@gmail.com wrote:
> On Sunday, February 26, 2017 at 4:21:49 PM UTC+6, rickman wrote:
>> On 2/26/2017 2:27 AM, abirov@gmail.com wrote:
>>> On Saturday, February 25, 2017 at 3:22:21 PM UTC+6, rickman wrote:
>>>> On 2/25/2017 12:33 AM, abirov@gmail.com wrote:
>>>>> On Saturday, February 25, 2017 at 11:21:13 AM UTC+6, abi...@gmail.com wrote:
>>>>>> How to make master FPGA to connect to many FPGAs ?
>>>>>>
>>>>>> Two FPGAs connected by serial  TDI - TDO, and two fpgas  TMS TCK TDO and TDI connect to master fpga, master fpga has TMS TDI TDO TCK connected and working to pc normally, it need to make connection JTAG of two fpgas to other 4 ports or somehow can connect to master's jtag port ?
>>>>>
>>>>> |   |---------|-TMS----|------------|-TMS----
>>>>> |   | FPGA 0  |-TCK----|            |-TCK----
>>>>> |   |         |-TDO----|            |-TDO----
>>>>> |   |---------|        |            |-TDI----
>>>>> |       |              |            |
>>>>> |      TDI             |            |
>>>>> |       |              |            |
>>>>> |       |              | MASTER FPGA|
>>>>> |       |              |            |
>>>>> |      TDO             |            |
>>>>> |       |              |            |
>>>>> |   |---------|-TMS----|            |
>>>>> |   | FGPA 1  |-TCK----|            |
>>>>> |   |         |-TDI----|            |
>>>>> |   |---------|        |------------|
>>>>>
>>>>
>>>> Why do you want the master FPGA to control the others rather than
>>>> loading them all in one chain?  Connect all TMS and TCK lines in
>>>> parallel and connect all TDI and TDO in one big daisy chain.  If the
>>>> slave FPGAs are loaded by the master, where will the data come from?
>>>>
>>>> --
>>>>
>>>> Rick C
>>>
>>> It is reverse engineering, someone did this but i just want reuse board only
>>
>> The JTAG signals to the master chip, do they connect to general I/Os as
>> well as to the FPGA JTAG signals?  Or just JTAG or just I/Os?
>>
>> You didn't say where you expect the data to come from to program the
>> chained slave FPGAs.  Is it supposed to come from the main JTAG port as
>> if it was talking to the slave chain?  Or will the master FPGA have a
>> separate interface from an MCU or a Flash chip?
>>
>> What is your overall plan?
>>
>> --
>>
>> Rick C
>
> Slave FPGAs connects to USER I/O ports. for example:
> TMS of salve FPGA chip connects to user i/o pin  CC
> TDI of slave FPGA chip connects to user i/0 pin  VRP
> TCK of slave FPGA ship connects to user i/o pin  CC

What do you connect the user I/O of the master to internally?  If you 
try using the JTAG on the master it will control the master, no?

-- 

Rick C



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
2017JanFebMarApr2017

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