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 29825

Article: 29825
Subject: Re: Spartan-II Evaluation Board
From: Franck Pissotte <franck.pissotte@free.fr>
Date: Mon, 12 Mar 2001 21:06:35 GMT
Links: << >>  << T >>  << A >>
Simon a écrit :
 
> llandre wrote:
> >
> > > I'm looking for an evaluation board for Xlininx Spartan-II FPGAs. Does
> > > any body know where to get a eval board that is not too expensive.
...
> The best I've found is the BurchEd board (XCS200 for $120 US, works
> with WebPack). Found no problems :-))

an web address, please?
-- 
http://www.pascaland.org/ compilateurs, sources et liens langage pascal, delphi



Article: 29826
Subject: Re: Configuration devices
From: Brian Goudy <briangoudy@earthlink.net>
Date: Mon, 12 Mar 2001 21:37:16 GMT
Links: << >>  << T >>  << A >>
jschneider@cix.CEEOWE.EWEKAY wrote:
> 
> I was a little bit staggered on getting a price for Altera EPC2
> configuration devices (£25 in one off).
> 
> If they can't make/sell flash at a reasonable price why don't their
> devices configure from normal serial flash ? It would be cheaper to
> put a small microcontroller down and use that to do the
> configuration. Is this just a clever way for them to get more money ?
> 
> There are obviously various application notes from the various vendors
> describing ways to configure devices. If I genuinely want to replace
> an ASIC with a low cost FPGA (low end Spartan II perhaps) but that
> might be reprogrammed at little or no hardware cost and in the absense
> of a micro on board, what methods are best ?
> 
> I know I can work it out in theory but getting quotes out of
> distributors is a long painful process over here - believe me.
> 
>         Jon

I usually get around this by using a jtag port and byte blaster
cable to configure the FPGA during development. When the design
is functional I get a cheap EPC1441 or EPC1.

Brian Goudy

Article: 29827
Subject: Re: Spartan-II Evaluation Board
From: Simon <simon@unique-id.com>
Date: Mon, 12 Mar 2001 22:22:01 +0000
Links: << >>  << T >>  << A >>
Franck Pissotte wrote:
> 
> Simon a écrit :
> 
> > llandre wrote:
> > >
> > > > I'm looking for an evaluation board for Xlininx Spartan-II FPGAs. Does
> > > > any body know where to get a eval board that is not too expensive.
> ...
> > The best I've found is the BurchEd board (XCS200 for $120 US, works
> > with WebPack). Found no problems :-))
> 
> an web address, please?

Well, typing 'burched' into google would give the URL, and it is also 
mentioned in this thread, but to make life easy :-)

	http://www.burched.com.au

Simon.

-- 
Freedom ? What's that ? (see http://www.domesday.co.uk/ )

Article: 29828
Subject: Re: Again Spartan II power
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Mon, 12 Mar 2001 14:46:30 -0800
Links: << >>  << T >>  << A >>
Curious,

We were unable to verify this claim of power supply sequence dependency in the
lab.  It may have had something to do with their configuration solution.

Austin

Andrej Jancura wrote:

> Hi,
>
> I design now an board with XC2S150, and still have some unsureness about the
> choice of this type.
> Its my first design with FPGA and reading all topics about power-up trouble
> makes some dark nights now...
>
> I would like to know, how to design the power supply. I plane to use REG1117
> on board.
>
> Andrej
>
> "R Sefton" <rsefton@home.com> schrieb im Newsbeitrag
> news:LEZq6.24124$o7.803765@news1.rdc1.sdca.home.com...
> > We had intermittent power-related start-up problems with a Spartan
> > II device and it took us a couple of weeks to fix it. We abided by
> > all of the data sheet power requirements, but eventually delaying
> > 2.5V startup in relation to the 3.3V supply eliminated the problem
> > (i.e., Vccint/Vcco sequencing DID matter). We had an XC2S150 and
> > XC2S200 on the same board (and same power supplies). The XC2S200 was
> > not affected, but the XC2S150 failed to configure 5-10% of the time.
> > The device would not respond to PROG/ (INIT/ would stay high).
> >
> > Bob S.
> >
> >
> > "Austin Lesea" <austin.lesea@xilinx.com> wrote in message
> > news:3AA5AAD6.55B0F0A9@xilinx.com...
> > > Falk,
> > >
> > > We do not test every single part for any power on ramp exceeding
> > 50 ms.
> > >
> > > We have done characterization which shows you may have problems
> > with ramps
> > > longer than 100 ms because you can not keep the voltage generally
> > increasing
> > > through the critical power on trip point (POR).
> > >
> > > Spartan II has no Vccint vs. Vcco sequence issues (either can be
> > before the
> > > other, and outputs remain tristate, and no current results on the
> > Vcco).
> > >
> > > Virtex E MUST have Vccint before Vcco to operate properly.  This
> > is not true
> > > of Virtex, or Spartan II.
> > >
> > > I would work closely with your Xilinx FAE to characterize your
> > application
> > > to be sure you will have a reliable design across all corners.
> > >
> > > We are in the midst of a respecification of Spartan II right now.
> > >
> > > I have heard: longer ramps, current vs ramp rate, sequence issues,
> > > non-linear ramps, and current vs device size all requested.
> > >
> > > Have I missed anything?????
> > >
> > > Thank you,
> > >
> > > Austin
> > >
> > > Falk Brunner wrote:
> > >
> > > > Please dont cry folks ;-)
> > > >
> > > > I ran through the preveous thread and have still some questions.
> > > > We have a hot-swapable card and to prevent big surge currents we
> > have to
> > > > use a very slow powerup ramp (250ms are planned).
> > > > Is this a problem for the Spartan II?? The powersupply can
> > delviver far
> > > > more than 500mA but not that fast as required in the datasheet
> > (50ms).
> > > > Another question is about the Vcoo and Vcint timing relation.
> > > > How critical is it (Vcoo must be above 1V when Vcint crosses
> > 1.6V (POR)
> > > > ).
> > > >
> > > > --
> > > > MFG
> > > > Falk
> > >
> >


Article: 29829
Subject: VirtexE LVPECL I/O Ports? experience?
From: "Theron Hicks (Terry)" <hicksthe@egr.msu.edu>
Date: Mon, 12 Mar 2001 21:11:17 -0500
Links: << >>  << T >>  << A >>
Has anyone out there used the VirtexE series devices with the LVPECL I/O
ports?  I am considering using the VirtexE devices for a  project which
has a substantial amount of _very_ high speed logic (Clock is 2.488 GHz)
going on.  I know that the VirtexE won't run anywhere near that fast.
The external high speed stuff will be implemented using either LVPECL or
posibly LVECL or some combination of the two.  As a result, I can save a
substantial number of level translators if I use the LVPECL i/o to talk
between the FPGA and the external ECL logic.  Are there any potential
problems to look out for?  If I recall correctly the VirtexE LVPECL i/o
require differential logic signals.  Is that so?  Are the logic levels
standard to match 100K logic series devices?  Are there any good ap
notes out there for this i/o type?

The system consists largely of two counters with ECL front ends with ECL
enables.  The toggle rate that I would like to get out of the VirtexE is
about 350MHz.  Is that easily within the reach of the VirtexE chip?

By the way, I could not even consider the VirtexII for my application if
Xilinx were giving them away.  The reason is that they are not available
in a package that I can solder.  I can handle fine pin pitch but I
cannot handle BGA type packages.  Xilinx, can you take a hint?  Give the
small guys a package we can handle.

Thanks,
Theron Hicks


Article: 29830
Subject: Re: VirtexE LVPECL I/O Ports? experience?
From: Phil Hays <spampostmaster@home.com>
Date: Tue, 13 Mar 2001 04:54:46 GMT
Links: << >>  << T >>  << A >>
"Theron Hicks (Terry)" wrote:

> By the way, I could not even consider the VirtexII for my application if
> Xilinx were giving them away.  The reason is that they are not available
> in a package that I can solder.

Do you have a toaster oven?


-- 
Phil Hays

Article: 29831
Subject: Re: Again Spartan II power
From: "R Sefton" <rsefton@home.com>
Date: Tue, 13 Mar 2001 05:18:15 GMT
Links: << >>  << T >>  << A >>
Austin -

A little more information if it helps. The 2.5V supply ramp-up was
very fast (a few hundred microseconds. The 3.3V ramp-up was muuuuch
slower. From the traces we captured on the scope before and after
the fix, the biggest thing that changed was the level of the 3.3V
supply when 2.5V reached nominal. Before the fix 3.3V was ~1V, after
the fix it was ~1.5V. The general shape of the 2.5V ramp did not
change much. The fix was to change a cap value on the 5V to 2.5V
switcher to slow regulator startup.

I know the 2.5V rise was much faster than the 2ms min recommended in
the datasheet, but my understanding was that the fast rise would
increase current draw but cause no other problems. Is that true
assuming the 2.5V regulator can handle it?

We were using slave parallel configuration, but other than the mode
pin settings that could not have made a difference because
configuration never started. The XC2S150 was simply brain dead. It
would not respond to PROG/ no matter how long after powerup we
waited, how many times we asserted it, or how long we kept it
asserted. INIT/ stayed high throughout. I can't remember off the top
of my head what DONE was doing.

I would love to know what was going on in that part when it hung.
Any chance you can share some details of the Spartan II
configuration state machine logic and venture a guess as to what
would cause this?

Bob Sefton


"Austin Lesea" <austin.lesea@xilinx.com> wrote in message
news:3AAD51C6.2E10F86@xilinx.com...
> Curious,
>
> We were unable to verify this claim of power supply sequence
dependency in the
> lab.  It may have had something to do with their configuration
solution.
>
> Austin
>



Article: 29832
Subject: Re: VirtexE LVPECL I/O Ports? experience?
From: Peter Alfke <palfke@earthlink.net>
Date: Tue, 13 Mar 2001 07:21:39 GMT
Links: << >>  << T >>  << A >>


Phil Hays wrote:

> "Theron Hicks (Terry)" wrote:
>
> > By the way, I could not even consider the VirtexII for my application if
> > Xilinx were giving them away.  The reason is that they are not available
> > in a package that I can solder.
>
> Do you have a toaster oven?
>

More seriously, I met with a local small manufacturer, and it soon became
obvious that the days of hand-soldering are over. But - at least here in the
Valley - such contract assembler are available and do the job for you.  I
have been suggesting a hobby-friendlier package for the smallest Virtex-II
device, but that is a difficult business proposition. Please excuse the word
"hobby", it also applies to professors at universities.  I grew up as a
short-wave ham radio builder and operator, and I still feel the itch to
build, and I love the smell of solder resin, and even the feel of burnt
finger tips. Those were the days. Nostalgia...

Peter Alfke



Article: 29833
Subject: Re: VirtexE LVPECL I/O Ports? experience?
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Tue, 13 Mar 2001 07:53:57 -0000
Links: << >>  << T >>  << A >>
>More seriously, I met with a local small manufacturer, and it soon became
>obvious that the days of hand-soldering are over. But - at least here in the
>Valley - such contract assembler are available and do the job for you.  I
>have been suggesting a hobby-friendlier package for the smallest Virtex-II
>device, but that is a difficult business proposition. Please excuse the word
>"hobby", it also applies to professors at universities.  I grew up as a
>short-wave ham radio builder and operator, and I still feel the itch to
>build, and I love the smell of solder resin, and even the feel of burnt
>finger tips. Those were the days. Nostalgia...

I'd probably say "low volume" rather than "hobby".  Or "very" low
volum, 1 or 3 vs 10s or 100s.

The othere half of the problem is that you need a serious PCB
in order to do anything useful with modern FPGAs.

There are a couple of companies now in the business of making
low volume multilayer PBs.  I'll bet similar services will
become available for soldering BGAs - there is interest/demand.  

-- 
These are my opinions, not necessarily my employeers.  I hate spam.


Article: 29834
Subject: Re: clock divider by 1.5
From: goran <goran_metlic@yahoo.com>
Date: Tue, 13 Mar 2001 00:48:57 -0800
Links: << >>  << T >>  << A >>
to bertram geiger
You are wright about clock but it is not the only clock i need to extract so i thought to do it by dividing in couple segments so that it will be easier to get other clocks.As i wrote earlier im novice in vhdl so if you can help me with mod counter i will be thankfull.(im learning while working so all information is more than wellcome)

Article: 29835
Subject: 64 simultan A/D Converters in an SPARTAN-II
From: "Manfred Kraus" <newsreply@cesys.com>
Date: Tue, 13 Mar 2001 09:50:17 +0100
Links: << >>  << T >>  << A >>
My application requires the sampling of an 64 by 64 array of resistors (a
4096 sensor array). The classical approach needs a huge amount of analog
switches and OpAms. I have got the analog prototype from my customer. It is
about 10" x 15". The production and testing must be a horror story, as he
told me. Could an FPGA be the solution to simplify the board ?
Has anybody tried do realize something similar in an FPGA ?

My idea is: apply a logical high to the row to be scanned and start 64
8-bit counters. Stop each counter individually by its coloumn signal.  The
coloumn signals will be delayd by an RC network where the R component is the
array resistor. I know it will work in principle. But will I get 8 bits out
of it ? Will it work in an reasonable temp. range ? Do I need external
comparators or are the thresholds of the FPGA inputs precise enough ?

The array resistor values are between 1R and 1 MEG. The range around 100k
Ohm is most important.  Resolution should be 8 Bit and needs not be linear.
Total scan time must be below 3 ms. Gain adjustments may be made by varying
the count frequency. To adjust offset there may be a wait time before
starting the counters after applying the  row stimulation signal.


Any comment is highly appreciated.


Manfred Kraus
mkrausnews@cesys.com






Article: 29836
Subject: Re: sample code for JTAG configuration of Virtex, Spartan II?
From: "Jaan Sirp" <jaan.sirp@mail.ee>
Date: Tue, 13 Mar 2001 01:12:43 -0800
Links: << >>  << T >>  << A >>
Hi Eric,
 
The JTAG configuration of FPGAs is so frequently needed task, I'm sure, somebody has the code for it. You have no answers because your message is interpreted as 'give me sample code for nothing'. Offer $500-$1000 and you probably get it.

I think, even a very good programmer needs 2-3 weeks to write and test this code. Assuming $80 000 - $100 000 salary (at least in adds are bid such numbers), buying is much cheaper, than writing it.

Jaan

> Does anyone have any sample code (perhaps in C?) for JTAG configuration
of Virtex or Spartan II parts?

Article: 29837
Subject: Low volume users (was: Re: VirtexE LVPECL I/O Ports? experience?)
From: Reinoud <dus@wanabe.nl>
Date: Tue, 13 Mar 2001 11:40:06 +0100
Links: << >>  << T >>  << A >>
Hal Murray wrote:
> 
> >More seriously, I met with a local small manufacturer, and it soon became
> >obvious that the days of hand-soldering are over. But - at least here in the
> >Valley - such contract assembler are available and do the job for you.  I
> >have been suggesting a hobby-friendlier package for the smallest Virtex-II
> >device, but that is a difficult business proposition. Please excuse the word
> >"hobby", it also applies to professors at universities.  I grew up as a
> >short-wave ham radio builder and operator, and I still feel the itch to
> >build, and I love the smell of solder resin, and even the feel of burnt
> >finger tips. Those were the days. Nostalgia...
> 
> I'd probably say "low volume" rather than "hobby".  Or "very" low
> volum, 1 or 3 vs 10s or 100s.
> 
> The othere half of the problem is that you need a serious PCB
> in order to do anything useful with modern FPGAs.
> 
> There are a couple of companies now in the business of making
> low volume multilayer PBs.  I'll bet similar services will
> become available for soldering BGAs - there is interest/demand.

BGA parts are practically inaccessible for low volume / experimental
designs for many of us (like at theuniversity - where I work).
Yes, it's possible to get (very) low volume multilayer PCBs and
have BGAs mounted on them.  However, for such low volumes, it's
a major PITA to design a PCB, have it fabbed, send it to some
specialty assembly shop far away, only to discover that the somewhat
rushed one-off PCB design - done by not too experienced designers
-  has a bug.  Which often can't be fixed, not having access to
the (BGA) pins.

Probably the most practical solution for ultra-low-volume users would
be an adapter board (e.g. BGA -> PGA) with decent power decoupling
on board.  It would be easiest if preassembled adapters were
commercially available, but having just the boards (or gerbers)
available would go a long way.  Xilinx?  XUP?

- Reinoud

Article: 29838
Subject: Any advice about Visual IP
From: Laurent Gauch <laurent.gauch@amontec.com>
Date: Tue, 13 Mar 2001 11:47:32 +0100
Links: << >>  << T >>  << A >>
Dear all,

I am searching people using Visual IP ( from Innoveda). I am interested 
in this tool, but I want to receive some advices.
Let me know your email, if you use it!

Thank you in advance.

Laurent

Laurent Gauch
Amontec
www.amontec.com
laurent.gauch@amontec.com
_________________________
Your FPGA design Partner


Article: 29839
Subject: Re: Leonardo 'renames' in- and outputs.
From: Rienk van der Scheer <R.van.der.Scheer@nospam.3t.nl>
Date: Tue, 13 Mar 2001 13:01:22 +0100
Links: << >>  << T >>  << A >>
Is it an internal or external bus?
Anyhow, you could try using the 'keep' attribute in VHDL.
Something like:
   attribute KEEP:string;
   attribute KEEP OF address_bus:SIGNAL IS "KEEP";

Regards,

Rienk

Harjo Otten wrote:
> 
> Hi,
> 
> I'm having a little problem with my CPLD design in Leonardo Spectrum.
> When I use FPGA express for the synthesis, everything is OK, but when I try
> to use Leonardo, It seems as if Leonardo is renaming my adres-bus. This
> means I cannot use my 'old' UCF anymore. Has anybody got an idea on how to
> tell Leonardo not to rename my ports ?
> 
> Thanx,
> 
> H.

Article: 29840
Subject: Re: Questions about Xilinx Web Pack ISE
From: "frederik" <fnf.nospam@novi.dk>
Date: Tue, 13 Mar 2001 15:22:41 GMT
Links: << >>  << T >>  << A >>
I use to place the pins in the place-and-route process after my design has
been synthesised. I don't know how the Web Pack works but in the Foundation
tool a ucf-file is either made in the constraints editor or in an ascii
editor.

The components (i.e. BUFGB) is used to configure a deidicated buffer to that
input or output pin. Say you want a 12 mA output you need to configure this
in some way. Opening the library for a specific device shows the available
components. And read the device data sheet carefully.

Finn Frederiksen



Article: 29841
Subject: Re: 64 simultan A/D Converters in an SPARTAN-II
From: "Erik Widding" <widding@birger.com>
Date: Tue, 13 Mar 2001 12:05:06 -0500
Links: << >>  << T >>  << A >>
"Manfred Kraus" <newsreply@cesys.com> wrote in message
news:98kmqn$2d9ss$1@ID-22088.news.dfncis.de...
> My application requires the sampling of an 64 by 64 array of resistors (a
> 4096 sensor array). The classical approach needs a huge amount of analog
> switches and OpAms. I have got the analog prototype from my customer. It
is
> about 10" x 15". The production and testing must be a horror story, as he
> told me. Could an FPGA be the solution to simplify the board ?
> Has anybody tried do realize something similar in an FPGA ?
>
> My idea is: apply a logical high to the row to be scanned and start 64
> 8-bit counters. Stop each counter individually by its coloumn signal.  The
> coloumn signals will be delayd by an RC network where the R component is
the
> array resistor. I know it will work in principle. But will I get 8 bits
out
> of it ? Will it work in an reasonable temp. range ? Do I need external
> comparators or are the thresholds of the FPGA inputs precise enough ?

The important thing to think about is how to calibrate the design at
manufacturing time.  Even if manufacturing only means one unit.  One of the
big problems that you will face is trying to get the 64 channels to be the
same.  There is no such thing as an affordable and accurate capacitor.  So
rather than using 64 separate capacitors, you would probably want to convert
your 64 channels to 64 voltages, and compare them all to a single voltage
ramp.

There are many ways in which you could produce a repeatable ramp across
temperatures, but it is important to note that capacitors vary in capacity
with respect to temperature.  This said, I will leave this as an exercise
for the reader.

For each column you will need one comparator and one precision resistor.
For each row you will need one logic level NFET, and a resistor for the
gate.  Tie one terminal of every array resistor in any given row through a
fet to ground.  Tie the other terminal of every array resistor in any given
column to a comparator input, and one terminal of a precision resistor.  TIe
the remaining terminals of the precision resistors to the positive rail.  By
putting a logic high on any given fet-gate, you select the row of interest.

BOM:
    64 precision resistors
    64 resistors
    64 nfets (low current)
    64 comparators
    One voltage ramp (current source, capacitor and fet)

Minimal calibration at manufacturing time, and a very simple PCB layout.

> The array resistor values are between 1R and 1 MEG. The range around 100k
> Ohm is most important.  Resolution should be 8 Bit and needs not be
linear.
> Total scan time must be below 3 ms. Gain adjustments may be made by
varying
> the count frequency. To adjust offset there may be a wait time before
> starting the counters after applying the  row stimulation signal.

These are reasonable ideas for how to account for gain/offset adjustment,
but it is always better if you have fewer "knobs" to adjust.  So, if you can
find a solution where you apply these adjustments once for all channels,
instead of individually for each channel, you are better off.

In the described circuit, you shouldn't need to adjust for channel to
channel differences.  So you would need one 8bit counter, and 64 8bit
capture registers, and 64 synchronizers (2 LC) for the comparator outputs,
for a total of 640 cells plus the state machine logic for the ramp control
and row selection.  Given the need for 130+ IO for the circuit without even
getting out the data, you need an XC2S50, in which you will use less than
half of the available logic.

> Any comment is highly appreciated.
>
> Manfred Kraus
> mkrausnews@cesys.com


Regards,
Erik Widding.

--
Birger Engineering, Inc.  --------------------------------  781.481.9233
38 Montvale Ave #260; Stoneham, MA 02180  -------  http://www.birger.com




Article: 29842
Subject: JBits drivers for XESS boards
From: "Simon Y. Foo" <foo@eng.fsu.edu>
Date: Tue, 13 Mar 2001 12:41:51 -0500
Links: << >>  << T >>  << A >>
I would like to know if anyone has experience with using the Xilinx
JBits 2.5 software to drive the XESS XSV-800 boards.  I noticed that
JBits do not provide drivers for the XESS boards by default.
Please repond to me directly at foo@eng.fsu.edu.  I'll post a summary if

I received enough responses.

Thanks,
  Simon Foo


Article: 29843
Subject: Re: sample code for JTAG configuration of Virtex, Spartan II?
From: Tim Jaynes <tim.jaynes@xilinx.com>
Date: Tue, 13 Mar 2001 09:46:03 -0800
Links: << >>  << T >>  << A >>
Hi Eric,
If you haven't already you should check out xapp 058:
http://support.xilinx.com/xapp/xapp058.pdf
It has the C code to create an svf player which can program a Virtex via
jtag.
Regards,
Tim Jaynes
CAE

Eric Smith wrote:

> Does anyone have any sample code (perhaps in C?) for JTAG configuration
> of Virtex or Spartan II parts?
>
> Thanks!
> Eric


Article: 29844
Subject: Re: 64 simultan A/D Converters in an SPARTAN-II
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Tue, 13 Mar 2001 09:59:36 -0800
Links: << >>  << T >>  << A >>
Before you get into implementation details, here is a warning:
If your 4K resistors are connected between 64 rows and 64 columns, you will have
a hard time measuring any individual resistor, since there are many sneak paths
that destroy your accuracy.
Unless there is some nonlinearity (like a diode), I do not see how you can
isolate the individual resistors.
Just my $0.02 worth.

Peter Alfke
=======================
Erik Widding wrote:

> "Manfred Kraus" <newsreply@cesys.com> wrote in message
> news:98kmqn$2d9ss$1@ID-22088.news.dfncis.de...
> > My application requires the sampling of an 64 by 64 array of resistors (a
> > 4096 sensor array). The classical approach needs a huge amount of analog
> > switches and OpAms. I have got the analog prototype from my customer. It
> is
> > about 10" x 15". The production and testing must be a horror story, as he
> > told me. Could an FPGA be the solution to simplify the board ?
> > Has anybody tried do realize something similar in an FPGA ?
> >
> > My idea is: apply a logical high to the row to be scanned and start 64
> > 8-bit counters. Stop each counter individually by its coloumn signal.  The
> > coloumn signals will be delayd by an RC network where the R component is
> the
> > array resistor. I know it will work in principle. But will I get 8 bits
> out
> > of it ? Will it work in an reasonable temp. range ? Do I need external
> > comparators or are the thresholds of the FPGA inputs precise enough ?
>
> The important thing to think about is how to calibrate the design at
> manufacturing time.  Even if manufacturing only means one unit.  One of the
> big problems that you will face is trying to get the 64 channels to be the
> same.  There is no such thing as an affordable and accurate capacitor.  So
> rather than using 64 separate capacitors, you would probably want to convert
> your 64 channels to 64 voltages, and compare them all to a single voltage
> ramp.
>
> There are many ways in which you could produce a repeatable ramp across
> temperatures, but it is important to note that capacitors vary in capacity
> with respect to temperature.  This said, I will leave this as an exercise
> for the reader.
>
> For each column you will need one comparator and one precision resistor.
> For each row you will need one logic level NFET, and a resistor for the
> gate.  Tie one terminal of every array resistor in any given row through a
> fet to ground.  Tie the other terminal of every array resistor in any given
> column to a comparator input, and one terminal of a precision resistor.  TIe
> the remaining terminals of the precision resistors to the positive rail.  By
> putting a logic high on any given fet-gate, you select the row of interest.
>
> BOM:
>     64 precision resistors
>     64 resistors
>     64 nfets (low current)
>     64 comparators
>     One voltage ramp (current source, capacitor and fet)
>
> Minimal calibration at manufacturing time, and a very simple PCB layout.
>
> > The array resistor values are between 1R and 1 MEG. The range around 100k
> > Ohm is most important.  Resolution should be 8 Bit and needs not be
> linear.
> > Total scan time must be below 3 ms. Gain adjustments may be made by
> varying
> > the count frequency. To adjust offset there may be a wait time before
> > starting the counters after applying the  row stimulation signal.
>
> These are reasonable ideas for how to account for gain/offset adjustment,
> but it is always better if you have fewer "knobs" to adjust.  So, if you can
> find a solution where you apply these adjustments once for all channels,
> instead of individually for each channel, you are better off.
>
> In the described circuit, you shouldn't need to adjust for channel to
> channel differences.  So you would need one 8bit counter, and 64 8bit
> capture registers, and 64 synchronizers (2 LC) for the comparator outputs,
> for a total of 640 cells plus the state machine logic for the ramp control
> and row selection.  Given the need for 130+ IO for the circuit without even
> getting out the data, you need an XC2S50, in which you will use less than
> half of the available logic.
>
> > Any comment is highly appreciated.
> >
> > Manfred Kraus
> > mkrausnews@cesys.com
>
> Regards,
> Erik Widding.
>
> --
> Birger Engineering, Inc.  --------------------------------  781.481.9233
> 38 Montvale Ave #260; Stoneham, MA 02180  -------  http://www.birger.com


Article: 29845
Subject: Re: 64 simultan A/D Converters in an SPARTAN-II
From: "Erik Widding" <widding@birger.com>
Date: Tue, 13 Mar 2001 13:17:12 -0500
Links: << >>  << T >>  << A >>
I received two replies through email that should be included for
completeness:

>From Peter Afke:
   Before you get into implementation details, here is a warning:
   If your 4K resistors are connected between 64 rows and 64 columns, you
will have
   a hard time measuring any individual resistor, since there are many sneak
paths
   that destroy your accuracy.
   Unless there is some nonlinearity (like a diode), I do not see how you
can
   isolate the individual resistors.
   Just my $0.02 worth.

>From Larry Doolittle:
   When I have worked with an array like this, it was important to tie
   each column to a virtual ground, otherwise the columns "talked" to
   each other.  Also, if Manfred's resistors really can vary down to
   1 Ohm, you need something other than a "low current nfet" to drive
   the rows.
      - Larry Doolittle   <LRDoolittle@lbl.gov>


Both are extremely valid points, that should be considered by someone
actually designing this circuit...
This is only one of many areas in my post that should be considered "over
simplified".  One can not do this sort of design without understanding
exactly what the tolerance requirements are, and then doing the analysis to
see if they are met.  I should have put more of a disclaimer in the original
post.

The two implied points in my post are:
   1. Try to eliminate calibration issues.
   2. Simplify, simplify, simplify.

The point that Peter and Larry point out was missing:
   3. There are a few limitations in the simplest solution, and further work
is still necessary.


Regards,
Erik Widding.

--
Birger Engineering, Inc.  --------------------------------  781.481.9233
38 Montvale Ave #260; Stoneham, MA 02180  -------  http://www.birger.com


"Erik Widding" <widding@birger.com> wrote in message
news:98lk6p$as9$1@paxfeed.eni.net...
> "Manfred Kraus" <newsreply@cesys.com> wrote in message
> news:98kmqn$2d9ss$1@ID-22088.news.dfncis.de...
> > My application requires the sampling of an 64 by 64 array of resistors
(a
> > 4096 sensor array). The classical approach needs a huge amount of analog
> > switches and OpAms. I have got the analog prototype from my customer. It
> is
> > about 10" x 15". The production and testing must be a horror story, as
he
> > told me. Could an FPGA be the solution to simplify the board ?
> > Has anybody tried do realize something similar in an FPGA ?
> >
> > My idea is: apply a logical high to the row to be scanned and start 64
> > 8-bit counters. Stop each counter individually by its coloumn signal.
The
> > coloumn signals will be delayd by an RC network where the R component is
> the
> > array resistor. I know it will work in principle. But will I get 8 bits
> out
> > of it ? Will it work in an reasonable temp. range ? Do I need external
> > comparators or are the thresholds of the FPGA inputs precise enough ?
>
> The important thing to think about is how to calibrate the design at
> manufacturing time.  Even if manufacturing only means one unit.  One of
the
> big problems that you will face is trying to get the 64 channels to be the
> same.  There is no such thing as an affordable and accurate capacitor.  So
> rather than using 64 separate capacitors, you would probably want to
convert
> your 64 channels to 64 voltages, and compare them all to a single voltage
> ramp.
>
> There are many ways in which you could produce a repeatable ramp across
> temperatures, but it is important to note that capacitors vary in capacity
> with respect to temperature.  This said, I will leave this as an exercise
> for the reader.
>
> For each column you will need one comparator and one precision resistor.
> For each row you will need one logic level NFET, and a resistor for the
> gate.  Tie one terminal of every array resistor in any given row through a
> fet to ground.  Tie the other terminal of every array resistor in any
given
> column to a comparator input, and one terminal of a precision resistor.
TIe
> the remaining terminals of the precision resistors to the positive rail.
By
> putting a logic high on any given fet-gate, you select the row of
interest.
>
> BOM:
>     64 precision resistors
>     64 resistors
>     64 nfets (low current)
>     64 comparators
>     One voltage ramp (current source, capacitor and fet)
>
> Minimal calibration at manufacturing time, and a very simple PCB layout.
>
> > The array resistor values are between 1R and 1 MEG. The range around
100k
> > Ohm is most important.  Resolution should be 8 Bit and needs not be
> linear.
> > Total scan time must be below 3 ms. Gain adjustments may be made by
> varying
> > the count frequency. To adjust offset there may be a wait time before
> > starting the counters after applying the  row stimulation signal.
>
> These are reasonable ideas for how to account for gain/offset adjustment,
> but it is always better if you have fewer "knobs" to adjust.  So, if you
can
> find a solution where you apply these adjustments once for all channels,
> instead of individually for each channel, you are better off.
>
> In the described circuit, you shouldn't need to adjust for channel to
> channel differences.  So you would need one 8bit counter, and 64 8bit
> capture registers, and 64 synchronizers (2 LC) for the comparator outputs,
> for a total of 640 cells plus the state machine logic for the ramp control
> and row selection.  Given the need for 130+ IO for the circuit without
even
> getting out the data, you need an XC2S50, in which you will use less than
> half of the available logic.
>
> > Any comment is highly appreciated.
> >
> > Manfred Kraus
> > mkrausnews@cesys.com
>
>
> Regards,
> Erik Widding.
>
> --
> Birger Engineering, Inc.  --------------------------------  781.481.9233
> 38 Montvale Ave #260; Stoneham, MA 02180  -------  http://www.birger.com
>
>
>



Article: 29846
Subject: Re: 64 simultan A/D Converters in an SPARTAN-II
From: "Manfred Kraus" <newsreply@cesys.com>
Date: Tue, 13 Mar 2001 19:46:26 +0100
Links: << >>  << T >>  << A >>
>From Peter Afke:
> If your 4K resistors are connected between 64 rows and 64 columns, you
> will have a hard time measuring any individual resistor, since there are
many sneak
> paths that destroy your accuracy.
> Unless there is some nonlinearity (like a diode), I do not see how you
> can  isolate the individual resistors.


I think there is a need to "tri-state" 63 rows and apply a stimulus voltage
to the row that is to be scanned.The current of each coloumn will be the sum
of 63 times zero (tristate) plus the current caused by the scanned row. This
current is measured as a voltage between the pins of a known resistor.
Eriks idea to use an FPGA-controlled ramp voltage and 64 comparators seems
robust and easy to me.


>From Larry Doolittle:
>   When I have worked with an array like this, it was important to tie
>   each column to a virtual ground, otherwise the columns "talked" to
>   each other.  Also, if Manfred's resistors really can vary down to
>   1 Ohm, you need something other than a "low current nfet" to drive
>   the rows.
>      - Larry Doolittle   <LRDoolittle@lbl.gov>


Larry, I think you mean "tristate" instead of ground !??  If not, please
explain it again. I would like to understand your thoughts fully.

The resistor values of the array will vary between 5k and 1M. The range
between 8k and 100k is to be measured. Of course, you are right: 1 Ohm would
cause trouble.






Article: 29847
Subject: Re: 64 simultan A/D Converters in an SPARTAN-II
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Tue, 13 Mar 2001 11:49:18 -0800
Links: << >>  << T >>  << A >>
I don't think that 3-stating the 63 unused rows is any help.
Just analyze the sneak paths in a 3 x 3 array with nine resistors.
Pulse one row High, while the other two rows are 3-stated.
Now look at all the paths that can drive current into the column that is being
measured...
It just doesn't work.
I have been in that trap when designing core memories many years ago.
Diodes in series solve the sneak path problem, but introduce their own errors.

Peter Alfke
===============================
Manfred Kraus wrote:

> >From Peter Afke:
> > If your 4K resistors are connected between 64 rows and 64 columns, you
> > will have a hard time measuring any individual resistor, since there are
> many sneak
> > paths that destroy your accuracy.
> > Unless there is some nonlinearity (like a diode), I do not see how you
> > can  isolate the individual resistors.
>
> I think there is a need to "tri-state" 63 rows and apply a stimulus voltage
> to the row that is to be scanned.The current of each coloumn will be the sum
> of 63 times zero (tristate) plus the current caused by the scanned row. This
> current is measured as a voltage between the pins of a known resistor.
> Eriks idea to use an FPGA-controlled ramp voltage and 64 comparators seems
> robust and easy to me.
>
> >From Larry Doolittle:
> >   When I have worked with an array like this, it was important to tie
> >   each column to a virtual ground, otherwise the columns "talked" to
> >   each other.  Also, if Manfred's resistors really can vary down to
> >   1 Ohm, you need something other than a "low current nfet" to drive
> >   the rows.
> >      - Larry Doolittle   <LRDoolittle@lbl.gov>
>
> Larry, I think you mean "tristate" instead of ground !??  If not, please
> explain it again. I would like to understand your thoughts fully.
>
> The resistor values of the array will vary between 5k and 1M. The range
> between 8k and 100k is to be measured. Of course, you are right: 1 Ohm would
> cause trouble.


Article: 29848
Subject: Re: 64 simultan A/D Converters in an SPARTAN-II
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Tue, 13 Mar 2001 11:52:48 -0800
Links: << >>  << T >>  << A >>


Erik Widding wrote:

> I received two replies through email that should be included for
> completeness:
>
> The two implied points in my post are:
>    1. Try to eliminate calibration issues.
>    2. Simplify, simplify, simplify.
>
> The point that Peter and Larry point out was missing:
>    3. There are a few limitations in the simplest solution, and further work
> is still necessary.
>

The "few limitations" are that the concept inherently does not work.
Some "limitation"!

Peter Alfke


Article: 29849
Subject: Re: JBits drivers for XESS boards
From: Phil James-Roxby <phil.james-roxby@xilinx.com>
Date: Tue, 13 Mar 2001 13:28:46 -0700
Links: << >>  << T >>  << A >>
"Simon Y. Foo" wrote:
> 
> I would like to know if anyone has experience with using the Xilinx
> JBits 2.5 software to drive the XESS XSV-800 boards.  I noticed that
> JBits do not provide drivers for the XESS boards by default.
> Please repond to me directly at foo@eng.fsu.edu.  I'll post a summary if
> 
> I received enough responses.
> 
> Thanks,
>   Simon Foo

Please wait for the JBits 2.6 release, then we will be providing
interface and dll files that will enable you to run JBits software on
the XESS XSV boards.
2.6 is scheduled to be released in about a week to all our registered
users.  To become one, send an email to jbits@xilinx.com
Phil


-- 
---------------------------------------------------------------------
 __
/ /\/  Dr Phil James-Roxby         Direct Dial: 303-544-5545
\ \    Staff Software Engineer     Fax: Unreliable use email :-)
/ /    Loki/DARPA                  Email: phil.james-roxby@xilinx.com
\_\/\  Xilinx Boulder                 
---------------------------------------------------------------------



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