Do I need to connect all Vref in a bank together?

J

Jan Panteltje

Guest
Spartan 2 datasheet says Vrefs are internally connected, but must also be
externally connected.
Is this really needed if you only use one input?
 
Jan Panteltje wrote:
Spartan 2 datasheet says Vrefs are internally connected, but must also be
externally connected.
Is this really needed if you only use one input?
Click to expand...
Howdy Jan,

The wording about Vrefs is a little awkward. When they say they are
"internally connected", they do not necessarily mean "internally
connected TOGETHER". I believe you only need to connect to the Vrefs on
the bank with your single input.

Here is a quote from the Xilinx web site:
<<Some of the I/O standards require VCCO and/or VREF voltages. These
voltages externally are connected to device pins that serve groups of
IOBs, called banks. Consequently, restrictions exist about which I/O
standards can be combined within a given bank. Eight I/O banks result
from separating each edge of the FPGA into two banks. Each bank has
multiple VCCO pins, all of which must be connected to the same voltage.
This voltage is determined by the output standards in use.

In TQ144 and PQ208 packages, all VCCO pins are bonded together
internally, and consequently the same VCCO voltage must be connected to
all of them. In the CS144 package, bank pairs that share a side are
interconnected internally, permitting four choices for VCCO. In both
cases, the VREF pins remain internally connected as eight independent
banks.>>

As you can see, they qualify the term "internally connected" with "eight
independent banks." Hence, the "internally connected" indicates that
the lines are connected to the die, not that all the Vrefs of the device
are tied together.

Have fun,

Marc
 
Jan,

Yes, they are all internally connected on the die (once the IOB is programmed
as a Vref).

Since these are also general purpose IOBs, there is no bypass cap in the
package, nor on the internal Vref line, so all external Vref pins must be
externally individually bypassed to ground with bypass caps as close as
possible to the Vref pins AND connected to the Vref supply to get the lowest
noise Vref possible.

Austin

Jan Panteltje wrote:

Spartan 2 datasheet says Vrefs are internally connected, but must also be
externally connected.
Is this really needed if you only use one input?
Click to expand...
 
On a sunny day (Mon, 17 Nov 2003 07:39:03 -0800) it happened Austin Lesea
<Austin.Lesea@xilinx.com> wrote in <3FB8EB97.5DA6720F@xilinx.com>:

Jan,

Yes, they are all internally connected on the die (once the IOB is programmed
as a Vref).
That explains why I measure OC with an Ohm meter.
Click to expand...

Since these are also general purpose IOBs, there is no bypass cap in the
package, nor on the internal Vref line, so all external Vref pins must be
externally individually bypassed to ground with bypass caps as close as
possible to the Vref pins AND connected to the Vref supply to get the lowest
noise Vref possible.
hehe, I am using Vref as video input, trying to use the thing as AD.
Click to expand...
On the other input of the comparator is an r2r ladder.
The verilog does successive approximation.
I ran into problems because indeed now Vref is 75 Ohm impedance to ground,
and this pin is very sensitive.
Connecting all Vrefs makes little difference.
But I do have video (via second r2r ladder out again), but some spikes are at
some places for example if you put in a sine wave.
Seems I will have to sample and hold first too...
Still some instability in that input comparator, if sh does not fix it I will
try using external comparator.
Also it works to digitize audio it seems.
It is just for play....
Thanx
Jan
 
Jan,

If you want to play with the Vref as a video input, you can place an input buffer
on each of the other Vref pins, which will give your warnings, but the device will
still get a bitstream which now disconnects the Vref bus internally from the other
Vref pins (the ones that you used by breaking the rules).

Austin

Jan Panteltje wrote:

On a sunny day (Mon, 17 Nov 2003 07:39:03 -0800) it happened Austin Lesea
Austin.Lesea@xilinx.com> wrote in <3FB8EB97.5DA6720F@xilinx.com>:

Jan,

Yes, they are all internally connected on the die (once the IOB is programmed
as a Vref).
That explains why I measure OC with an Ohm meter.

Since these are also general purpose IOBs, there is no bypass cap in the
package, nor on the internal Vref line, so all external Vref pins must be
externally individually bypassed to ground with bypass caps as close as
possible to the Vref pins AND connected to the Vref supply to get the lowest
noise Vref possible.
hehe, I am using Vref as video input, trying to use the thing as AD.
On the other input of the comparator is an r2r ladder.
The verilog does successive approximation.
I ran into problems because indeed now Vref is 75 Ohm impedance to ground,
and this pin is very sensitive.
Connecting all Vrefs makes little difference.
But I do have video (via second r2r ladder out again), but some spikes are at
some places for example if you put in a sine wave.
Seems I will have to sample and hold first too...
Still some instability in that input comparator, if sh does not fix it I will
try using external comparator.
Also it works to digitize audio it seems.
It is just for play....
Thanx
Jan
Click to expand...
 
Jan Panteltje wrote:
On a sunny day (Mon, 17 Nov 2003 07:39:03 -0800) it happened Austin Lesea
Austin.Lesea@xilinx.com> wrote in <3FB8EB97.5DA6720F@xilinx.com>:

Jan,

Yes, they are all internally connected on the die (once the IOB is programmed
as a Vref).
That explains why I measure OC with an Ohm meter.

Since these are also general purpose IOBs, there is no bypass cap in the
package, nor on the internal Vref line, so all external Vref pins must be
externally individually bypassed to ground with bypass caps as close as
possible to the Vref pins AND connected to the Vref supply to get the lowest
noise Vref possible.
hehe, I am using Vref as video input, trying to use the thing as AD.
On the other input of the comparator is an r2r ladder.
The verilog does successive approximation.
I ran into problems because indeed now Vref is 75 Ohm impedance to ground,
and this pin is very sensitive.
Connecting all Vrefs makes little difference.
But I do have video (via second r2r ladder out again), but some spikes are at
some places for example if you put in a sine wave.
Seems I will have to sample and hold first too...
Still some instability in that input comparator, if sh does not fix it I will
try using external comparator.
Also it works to digitize audio it seems.
It is just for play....
Click to expand...
You could also try a Tracking ADC, rather than SAR - SAR is sensitive
to
noise, and have 'noise gain' which means large OP impulse errors can
come from small IP errors. (which is what you are seeing)
Tracking ADCs are better behaved, and would suit the faster speed /
but not analog-optimised resource in the FPGA.

- jg
 
hehe, I am using Vref as video input, trying to use the thing as AD.
On the other input of the comparator is an r2r ladder.
Click to expand...
Have you tried LVDS or other differential input modes?

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.
 
"Jan Panteltje" <pNaonStpealmtje@yahoo.com> wrote in message
news:1069103320.807101@evisp-news-01.ops.asmr-01.energis-idc.net...
hehe, I am using Vref as video input, trying to use the thing as AD.
On the other input of the comparator is an r2r ladder.
Click to expand...
Hi Jan,

All this discussion about how tough it is to do stuff
with Vref just gave me an idea...

How about doing the SA A/D just a little differently...
Instead of putting video on comparator Vref and DAC output
on Vin, why not ADD video+DAC (analogue summation) and
apply it to Vin, and leave Vref at a constant level?
(Yes, I realise there are some AC coupling issues to
worry about. But you already know all about clamping
on sync tips, so that should not be too hard.)
Obviously the successive approximation will "go
the wrong way" and finally give you an inverted result,
but that's easy to deal with. And your input comparator
is always working about the same Vref so you can apply
lots of bypass caps. Analogue addition is trivially
achieved by connecting the "tail" of the R2R ladder to
video instead of ground. Make sure you bypass Vref to
the same ground that's used by the DAC output buffers.

Just a thought.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
On a sunny day (Tue, 18 Nov 2003 02:52:59 -0000) it happened
hmurray@suespammers.org (Hal Murray) wrote in
<vrj2cbc1s36e44@corp.supernews.com>:

hehe, I am using Vref as video input, trying to use the thing as AD.
On the other input of the comparator is an r2r ladder.

Have you tried LVDS or other differential input modes?
Tried them all, very little difference I see.
Click to expand...
I got rid of the instability using Austin Lesea's suggestion,
no more spikes.
Also changed some delay half a clock... so it is sampled a bit
later, to make sure the DA ladder has settled.
Seems fine on audio now, but with real fast clock still strange
things happen in video.
Timing is everything....
Also added nice sample and hold with a dual gate MOSFET,
most problems I have with webpack, unexpected things happen
not sure it is creating the same circuit I intended every time.
This is the biggest time factor getting this to work perhaps.
For example I changed some timing by going from an @posedge
to an @negedge trigger in verilog, then it stopped working
altogether, then I brought out that pin to be able to scope what happens,
and then it worked, so something changed.....
These thing are for me a hurdle to take to use FPGA.
Jan
 
On a sunny day (Tue, 18 Nov 2003 09:28:27 -0000) it happened "Jonathan
Bromley" <jonathan.bromley@doulos.com> wrote in
<bpcoob$o62$1$8302bc10@news.demon.co.uk>:

"Jan Panteltje" <pNaonStpealmtje@yahoo.com> wrote in message
news:1069103320.807101@evisp-news-01.ops.asmr-01.energis-idc.net...
hehe, I am using Vref as video input, trying to use the thing as AD.
On the other input of the comparator is an r2r ladder.

Hi Jan,

All this discussion about how tough it is to do stuff
with Vref just gave me an idea...

How about doing the SA A/D just a little differently...
Instead of putting video on comparator Vref and DAC output
on Vin, why not ADD video+DAC (analogue summation) and
apply it to Vin, and leave Vref at a constant level?
(Yes, I realise there are some AC coupling issues to
worry about. But you already know all about clamping
on sync tips, so that should not be too hard.)
Obviously the successive approximation will "go
the wrong way" and finally give you an inverted result,
but that's easy to deal with. And your input comparator
is always working about the same Vref so you can apply
lots of bypass caps. Analogue addition is trivially
achieved by connecting the "tail" of the R2R ladder to
video instead of ground. Make sure you bypass Vref to
the same ground that's used by the DAC output buffers.

Just a thought.
--
Jonathan Bromley, Consultant
Ooops this feels like a thousand questions in 4 minutes,
Click to expand...
just got a load of complicated email questions about something.
Let's see, if you add video + the da, yes, you need to substract
in the verilog the two, is theoretically the same thing.
Clever idea, I will try this (weekend hey).
Jan
 
On a sunny day (Tue, 18 Nov 2003 09:28:27 -0000) it happened "Jonathan
Bromley" <jonathan.bromley@doulos.com> wrote in
<bpcoob$o62$1$8302bc10@news.demon.co.uk>:
Just a thought.
--
Jonathan Bromley, Consultant
Your system has also an other advantage, because the comparator always works
Click to expand...
at the same volatage level, any non-linearity due to moving within the common
mode range is eliminated.
Jan
 
On a sunny day (Tue, 18 Nov 2003 12:35:19 +1300) it happened Jim Granville
<jim.granville@designtools.co.nz> wrote in <3FB95B37.5E2@designtools.co.nz>:

You could also try a Tracking ADC, rather than SAR - SAR is sensitive
to
noise, and have 'noise gain' which means large OP impulse errors can
come from small IP errors. (which is what you are seeing)
Tracking ADCs are better behaved, and would suit the faster speed /
but not analog-optimised resource in the FPGA.

- jg
Interesting, how (in priciple0 would you realize a 'tracking ADC'?
Click to expand...
This is what I do now (sort of pseudo code):

// signal output from comparator is in inbit

reg [3:0] position; // bit position
reg [7:0] temp; // temp
always ....
begin
if(position > 0)
begin
temp[position] = 1 - comparator;

if(comparator == 0)
da_output[7:0] = da_output[7:0] + substractor[7:0];
else
da_output[7:0] = da_output[7:0] - substractor[7:0];

position = position - 1;

substractor = substractor >> 1;
ready = 1'b0;
end
else // bit 0
begin
ready = 1'b1;
substractor = 8'd64;
da_output = 8'd128;
position = 8'd7;
output = temp;
end

end // always

I left out the trigger (conversion request) and reset.
I start with the r2r DA at 128 (half of 255 8 bit range),
and the substractor at 64 (half of remaining range.
One clock later I check the comparator output, and store
the bit.
If the value was bigger I go to 128 + 64 and compare again..
if smaller to 128 - 64...


decrement the bit, and have teh substractor value.
When bit zero comes, I copy the temp result and set ready.

The real routine is bigger and does things on pos and neg edge clock.

How would you write a 'tracking' one?
It should not use more steps.... if possible?
Jan
 
"Jan Panteltje" <pNaonStpealmtje@yahoo.com> wrote in message
news:1069193901.982088@evisp-news-01.ops.asmr-01.energis-idc.net...
On a sunny day (Tue, 18 Nov 2003 12:35:19 +1300) it happened Jim Granville
jim.granville@designtools.co.nz> wrote in
3FB95B37.5E2@designtools.co.nz>:

You could also try a Tracking ADC, rather than SAR - SAR is sensitive
to
noise, and have 'noise gain' which means large OP impulse errors can
come from small IP errors. (which is what you are seeing)
Tracking ADCs are better behaved, and would suit the faster speed /
but not analog-optimised resource in the FPGA.

- jg
Interesting, how (in priciple0 would you realize a 'tracking ADC'?
Click to expand...

I left out the trigger (conversion request) and reset.
I start with the r2r DA at 128 (half of 255 8 bit range),
and the substractor at 64 (half of remaining range.
One clock later I check the comparator output, and store
the bit.
If the value was bigger I go to 128 + 64 and compare again..
if smaller to 128 - 64...
Click to expand...
This is SAR, as you mentioned.

Tracking ADCs have a saturating Up/Dn counter, and INC/DEC based on the
comparitor result. They have a finite slew rate, but the counting
clock speed can be higher than the read-out rate.
Their advantage is the inherent low pass/noise filtering nature of the
feedback
so in a 'less than ideal' environment like a FPGA Comparitor/DAC, they could
help.

They can be made adaptive, so the INC/DEC size increases
if many INC/DECs occur in the same direction (as in ADPCM), to
improve the step response.
-jg
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top