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

Spartan 2 datasheet says Vrefs are internally connected, but must also be externally connected. Is this really needed if you only use one input?

Reply to
Jan Panteltje
Loading thread data ...

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:

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

Reply to
Marc Randolph

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.

Aust> Spartan 2 datasheet says Vrefs are internally connected, but must also be

Reply to
Austin Lesea

On a sunny day (Mon, 17 Nov 2003 07:39:03 -0800) it happened Austin Lesea wrote in :

That explains why I measure OC with an Ohm meter.

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

Reply to
Jan Panteltje

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).

Aust> On a sunny day (Mon, 17 Nov 2003 07:39:03 -0800) it happened Austin Lesea

Reply to
Austin Lesea

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

Reply to
Jim Granville

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
 Click to see the full signature
Reply to
Hal Murray

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: snipped-for-privacy@doulos.com Fax: +44 (0)1425 471573 Web:

formatting link

The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.

Reply to
Jonathan Bromley

On a sunny day (Tue, 18 Nov 2003 02:52:59 -0000) it happened snipped-for-privacy@suespammers.org (Hal Murray) wrote in :

Tried them all, very little difference I see. 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

Reply to
Jan Panteltje

On a sunny day (Tue, 18 Nov 2003 09:28:27 -0000) it happened "Jonathan Bromley" wrote in :

Ooops this feels like a thousand questions in 4 minutes, 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

Reply to
Jan Panteltje

On a sunny day (Tue, 18 Nov 2003 09:28:27 -0000) it happened "Jonathan Bromley" wrote in :

Your system has also an other advantage, because the comparator always works at the same volatage level, any non-linearity due to moving within the common mode range is eliminated. Jan

Reply to
Jan Panteltje

On a sunny day (Tue, 18 Nov 2003 12:35:19 +1300) it happened Jim Granville wrote in :

Interesting, how (in priciple0 would you realize a 'tracking ADC'? 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

Reply to
Jan Panteltje

:

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

Reply to
Jim Granville

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.