Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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, delphiArticle: 29826
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 GoudyArticle: 29827
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
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
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 HicksArticle: 29830
"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 HaysArticle: 29831
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
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 AlfkeArticle: 29833
>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
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
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.comArticle: 29836
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
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? - ReinoudArticle: 29838
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 PartnerArticle: 29839
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
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 FrederiksenArticle: 29841
"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: 29842I 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 FooArticle: 29843
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! > EricArticle: 29844
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.comArticle: 29845
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>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
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
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 AlfkeArticle: 29849
"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:
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