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
I've been using the Excel pinout spreadsheet for the XC2S200 (pin_2s200.xls) from the Xilinx web site to build a PCB part and noticed that some pins are duplicated for the PQ208 package, when I found I had 216 pins, instead of 208! The offending signals are amongst the GND and VCCO pins. For instance, P208 (VCCO) is repeated. I haven't checked the other packages or parts. I've emailed the person responsible. Name withheld to protect the guilty! Leon -- Leon Heller, G1HSM leon_heller@hotmail.com http://www.geocities.com/leon_hellerArticle: 50726
Look at the Xilinx Virtex2 Pro line. They have a 4 or more dedicated
serial blocks, each containing the serdes, 8b/10b and PLL.
Masoud Naderi wrote:
> Hi,
> I want to design a board with HDMP-1022/24 (fiber
> driver/receiver)chip. This IC is from Agilent and has a
> serializer/deserializer, 8b/10b coder and PLL inside. Now I want to
> know is it possible to design an FPGA that work COMPLETELY instead of
> HDMP-1022/24? Do you have any experiences on this or know any
> resources?
> With best regards
> Masoud Naderi
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 50727Hi Bill, Just to add to what Allan said: my $0.02 worth. The external stuff you need to implement a decent sigma- delta converter (reference, switch etc) outside an FPGA will consume at least as much space and money as an external ADC. For your level of speed and accuracy, a regular successive-approximation ADC will be far more appropriate. Sadly I don't think any of the parts with a serial digital interface will be fast enough (another example of the digital technology on analog parts being, in the nature of things, a bit primitive). So you will need a part with a fair number of pins on it. :-( Binning and related histogramming things are dead easy in FPGAs, as Allan said. With the right synthesis tools you don't even need to instantiate the blockRAM explicitly - if you're careful about your HDL coding style, the tools will infer a RAM for you. -- 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.Article: 50728
nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) wrote in message news:<atnm26$15m2$1@agate.berkeley.edu>... > In article <65edfa70.0212170408.1d1ad3d8@posting.google.com>, > Erwan <lebrase@yahoo.fr> wrote: > >Hi, > > > >working for a software MPEG company that want to provide now hardware > >solutions as well, I would like to have your opinion about how > >implementing this new configuration. We found that a DSP only solution > >would not provide enough power. > >Something like a board with DSP plus FPGA(s) should be better. > >What is the process to go from evaluation to specification and then > >implementation of such a system ? We already have source code and > >technical knowledge in MPEG and DSP. > > You would probably do better with FPGA only, or FPGA and uP (something > more conventionally programmable), although it depends on the area and > cost model. > > >From your point of view, is hiring FPGA specialized engineer mandatory > >? I guess many of you would answer yes :) , but using consulting is an > >option too, and eventually learning ourselves (?). > > It depends on performance. Hiring an expert (like Ray Andraka) tends > to get about a 4x improvement in area/delay product, which probably > has about a 10x improvement in cost. However, that costs money, so > factor that in as NRE vs part cost. > > >Is mixing C code (on DSP) and hardware optimized functions (on FPGA) a > >good choice for speed ? (versus C only on DSP) > > You might want to think of the split differently, as the communication > costs between the two will be high. Hi, You will definately get a lot of performance gains using an FPGA as a coprocessor for video coding. If you already have a decent DSP solution you just need to target the worst performing algorithms (in this case undoubtedly motion esitmation/DCT) and implement them in the FPGA. If you do it yourself I think you will find the learning curve very, very steep to start with. You can optionally get in some experts or simply license in some IP of which you will find masses on the web. I dont really agree that doing it all in an FPGA is the best idea. My experience is that the CODEC must be very flexible in order to meet everyones expectations and hardware can be very difficult/costly to make _really_ flexible. I have found implementing a system split between simple (but intensive) hardware functions and more complex control software a good one. Further implementing full hardware "systems" can take a lot of time to debug and optimise. The issue mentioned of memory bandwidth is a very important one and should be factored into your design. It is probably necessary to have a separate memory bank for the FPGA to work out of as it is going to be a real hog. Hope all goes well with the project, AndymanArticle: 50729
Have you tried the Analyze Power (Xpower) tool built right into ISE 4.2i and 5.2i See http://toolbox.xilinx.com/docsan/xilinx5/help/xpower/xpower.htm for details. XPower is a post-route (FPGA) and post-fit (CPLD) analysis tool that enables you to interactively and automatically analyze power consumption for Xilinx FPGAs and CPLDs. XPower includes both GUI (xpower) and batch (xpwr) applications. XPower is the first power-analysis software available for programmable logic design. Earlier in the design flow than ever, you can analyze total device power, power per-net, routed, partially routed or unrouted designs, all driven from a comprehensive graphic interface or command-line driven batch-mode. XPower also reads VCD simulation data from the ModelSim family of HDL simulators to set estimation stimulus, reducing setup time, as well as from the additional simulators listed in Simulator Support. Xefteris Stefanos wrote: > Hello, > My problem in a few words is this: I have done toggling activity > estimation and now I want to use this to apply power estimation on my > design.But,I havent yet found the way to incorporate the toggling > estimation in my power estimation.Article: 50730
hai, I would like to know the BIST structures for Xilinx FPGAs for on-line functional test. Please let me know if there are some specific configurable BIST structures for any generic logic/Arithmetic logic. Thanks, Dasari.Article: 50731
hai, Does LUT architecture consists of Addesss decoder or not? I mean for a 4 to 1 LUT, there are 16 memory elements + a 16 to 1 Mux is required. In some books, it is shown address decoder too. What is the use of address decoder in LUT, bcos I think configuration of FPGA happens serially!!! Thanks for ur time, Dasari.Article: 50732
Hi, for developing an audio application, I need a way to display a bus signal as a "real" waveform, not a number. I want to see the actual waveform that goes out to the DAC (sine, triangle or whatever). For example, for an 8bit bus, 00 would be a line at the bottom, 80 would be in the middle and FF would be at the top of the wave display. Can you recommend a software that does this? I'm using WebPack with ModelSimXE so far. Thanks, KevinArticle: 50733
> For example, for an 8bit bus, 00 would be a line at the bottom, 80 > would be in the middle and FF would be at the top of the wave display. > > Can you recommend a software that does this? I'm using WebPack with > ModelSimXE so far. Full-spec versions of ModelSim allow you to display any waveform in analogue format. In the left-hand (signal names) panel of the wave viewer, right click on your signal and choose Signal Properties. In the properties dialog, pick the Format tab and enjoy. Alternatively, get your VHDL/Verilog test bench to write out comma-separated values to a text file and use a spreadsheet to view your waveforms. -- 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.Article: 50734
I have an ACEX1k30 together with an EPC2 in JTAG multichain configuration. The pair is prgrammeable with the Byteblaster adapter, plus the relevant pins TMS, TDI, TDO and TCK of the adapter are connected to a microcontroller (AVR), tristated while not used. This to keep the normal way of programming. Before decoding the Byteblaster stream, I went to have a look at the various application notes. To little avail. They were AN116, AN111, AN100, AN88, AN95 Since the *.pof and the *.sof appear to require interpretation by MaxPlus2 or Quartus2, the preferred format would be *.rbf it appears. But is the created rbf sufficient for the ACEX as well as for the configuration flash ? Since *.pof and *.sof are not identical, I assume I require two different files too. I tend to think the subject is far simpler than I now look at. Any hints ? -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 50735
lebrase@yahoo.fr (Erwan) wrote in message news:<65edfa70.0212170408.1d1ad3d8@posting.google.com>... > Hi, > > working for a software MPEG company that want to provide now hardware > solutions as well, I would like to have your opinion about how > implementing this new configuration. We found that a DSP only solution > would not provide enough power. > Something like a board with DSP plus FPGA(s) should be better. > What is the process to go from evaluation to specification and then > implementation of such a system ? We already have source code and > technical knowledge in MPEG and DSP. > From your point of view, is hiring FPGA specialized engineer mandatory > ? I guess many of you would answer yes :) , but using consulting is an > option too, and eventually learning ourselves (?). > Is mixing C code (on DSP) and hardware optimized functions (on FPGA) a > good choice for speed ? (versus C only on DSP) > How long (man/month) should it take in this situation ? This is not > the case, but suppose that the encoder is MPEG-4 video with > DCT/IDCT/Motion Est/ and perhaps interpolation in FPGA. > And as a starting point what would you recommend ? > > thanks, > > Erwan You might want to also call Celoxica, at DAC a yr or so ago, they were showing a demo where they claim to take MPEG4 std C code IIRC and with little modification compile it to ? (EDIF I'd guess). Anyway since I'm not an MPEG guy can't say it was legit, but I have seen some nice demos on their booth. Also if any C to HDL is going to work, it would be HandelC since its based on Occam and CSP and is provably formally thread safe since .....get the picture. Anyways, I'm more partial to this one than any of the other C to HDL punters because of the "Occam inside". It might well be good for a quick prototype.Article: 50736
Shareef Jalloq <sjalloq@REMOVEarm.com> wrote in message news:<3E003EDD.4E4450F@REMOVEarm.com>... > We've had the same problems with gated clocks and got round it by > instantiating BUFGs on the outputs of the gated clocks to make sure that > the clock nets are used. Without them we had horrible hold time > problems. However, before we used the BUFGs we also tried adding an extra > latch in between the data bus and the latches that were fed by the gated > clock. This was a quick fix until the design got more complicated. > > Shareef. > > > However, gating the clock like this is not recommended and will likely > > cause problems or not work at all - your gated clock nets will be > > delayed from the original clock by a significant amount of time > > (possibly several nanoseconds). If the inputs to the flops are from > > off-chip, this will result in large hold time requirements (which > > maybe you can deal with). If they are internal, then you're likely to > > end up with hold time violations that you just can't fix. > > > > Mike If you are gating clocks, you will be asking for help from the Charmed ones, more likely you will be up the creek!Article: 50737
Hi, I'm trying to build a synchronous FPGA design on the A15E APEX DSP Development Board (Professional Version) from Altera. The board has 512 Kbytes of "asynchronous" RAM which can be used with the FPGA. Since this on-board RAM is asynchronous, it cannot be used in my synchronous design on the FPGA. Altera always recommends using synchronous RAM for all synchronous designs and I feel that should be the case. No asynchronous cores in a synchronous design. Is there any way the async on-board RAM can be used with a synchronous design on the FPGA, without causing any errors ? I have tried using the async RAM and have found that when I read 64 7-bit values from the async RAM, some of them are erroneous. The errors are unpredictable from one run to another. I guess this would mean that the asynchronicity of the RAM is causing the problem. Let me know if anyone has any suggestions. Thanks, PrashantArticle: 50738
"Prashant" <prashantj@usa.net> wrote > Is there any way the async on-board RAM can be used with a synchronous > design on the FPGA, without causing any errors ? You've simply got to find some way to make your synchronous FPGA generate correctly timed read and write cycles for the asynch RAM (see its data sheet). It's usually easy to get read cycles correct (note I didn't say "get read cycles right" - groan). Set up address and read-enable on one clock, then on the next clock (or perhaps two or even three clocks later, depending on RAM speed vs. clock speed) you capture the read data off the data lines and on the same clock edge you can remove read-enable and the address. No problems, because there is sure to be some delay after the clock edge before address and read-enable go away, therefore plenty of hold time for the RAM at the end of the read cycle. Write cycles, on the other hand, are a PITA because you need to ensure that you have enough hold time for address and data AFTER your FPGA removes write-enable. Even if the SRAM has zero hold time (trailing edge of write-enable to address/data invalid), you can't guarantee that the write-enable to address/data skew is in your favour if they are both removed by the same clock edge. So you end up playing horrible games to hold the address and write data valid for a little while after write-enable is removed. Typically you need to resynchronise write-enable to the falling edge of your system clock. If you don't do this, the only other way is to allow one complete clock cycle AFTER the end of write-enable, and then remove the address and data. This makes write cycles one whole clock slower than they need to be, and it explains why everyone prefers synchronous RAMs. Depending on exactly what you are doing with the RAM, it may be possible to finesse your way around these issues by using write-posting or a FIFO on writes. But it's not easy to get these tricks working correctly, and I suggest you start with a simpler approach and just accept that things will be a little slower. -- 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.Article: 50739
Hello,
My friend has an ISE project on his PC, now I want to load his
project and on top of that do some minor modification and re-build it,
but when I load it, PROJNAV told some directory path error and I can
only see an empty project. I know that's because my directory structure
is different from his, then I open the .npl file in a text editor, but I
see a lot info which I am not sure I understand correctly. Then is there
any easy way for me to port his project to my area? Is it possible to do
it without his involvement?
Thanks
Article: 50740"Christopher R. Carlen" wrote: > I have discovered that the R input is not in fact an asynchronous reset > input, but instead it doesn't do its thing until a clock pulse comes > along. This is very strange, but I suppose I simply assumed that R > meant something that it doesn't seem to mean. It is a long-standing practice to use "R" for synchronous Reset, and "C" for asynchronous Clear., and "P" for synchronous Preset, and "S" for asynchronous Set. Of course, not everybody abides by these inofficial rules... You have already the answer to your problem: Use the right library element. Peter Alfke, Xilinx ApplicationsArticle: 50741
Don't expect to do this in an FPGA alone, but -if I remember right - a Sigma-Delta A/D converter is ideal for this applications. Others may know more or better... Peter Alfke ================= Bill Sloman wrote: > This is a dumb "wouldn't it be nice if there were a" question. > > At the moment we have a fast-ish, relatively low level alaog front end > whose amplified output is digitised to 8-bits at 2.5MHz, and > accumulated into 16 32-bit wide bins over about 2000 sampling cycles > (24-bits would be enough ...). > > The conversion noise is visible on the analog signal and the "wouldn't > it be nice" idea is that if the A/D converter were embedded in an FPGA > which also managed the accumulation into on-chip RAM, there would be a > whole lot less conversion noise visible at the front end. > > In the interests of creeping featurism, a 10-bit A/D converter would > be interesting, and room for 200 32-bit bins. The 2.5MHz sampling rate > seems to be perfectly adequate. > > I've had a quick look at Lattice's analog FPGA and the analog isn't > really fast enough while the digital side looks to be rudimentary - is > there anything better out there? > > The application is a low volume (order of 100 per year) industrial > measuring instrument, so ASICs are out of the question, and > significant up-front costs would be a real problem. > > I suspect that what I'm asking for is a cross-breed between a camel > and a mantee, but I'd love to be wrong. > > ----- > Bill Sloman, NijmegenArticle: 50742
"Peter Alfke" <peter@xilinx.com> wrote: > It is a long-standing practice to use "R" for synchronous Reset, and "C" > for asynchronous Clear., and "P" for synchronous Preset, and "S" for > asynchronous Set. 15+ years' standing in Xilinx libraries, but what are the other precedents? I was completely unaware of it pre-Xilinx. Two-letter abbreviations with the first letter being A for Asynchronous or S for Synchronous were fairly common, and IMHO a lot more lucid. -- 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.Article: 50743
Jee <jee@hotmail.com> wrote: : Hello, : My friend has an ISE project on his PC, now I want to load his : project and on top of that do some minor modification and re-build it, : but when I load it, PROJNAV told some directory path error and I can : only see an empty project. I know that's because my directory structure : is different from his, then I open the .npl file in a text editor, but I : see a lot info which I am not sure I understand correctly. Then is there : any easy way for me to port his project to my area? Is it possible to do : it without his involvement? ISE has an archive/snapshot option. use that. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 50744
Ray Andraka wrote: > FDR is a flip-flop with a synchronous reset. FDC, which has an asynchronous > clear, is what you want. This is detailed in the libraries guide. Thanks for the reply. I'll have to go hunting down and reading more of the documentation. I'm just getting started with this, but planning to do my next 2-3 projects using the CPLD. Until now I had only gotten my very first test circuit working. Good day. -- ____________________________________ Christopher R. Carlen Principal Laser/Optical Technologist Sandia National Laboratories CA USA crcarle@sandia.govArticle: 50745
The paid version of modelsim, as well as Aldec have an analog display mode
that lets you display any signal as an "analog" value. You can also write
to a text file and import to Excel (I used to do that with viewlogic
simulations).
Kevin Becker wrote:
> Hi,
>
> for developing an audio application, I need a way to display a bus
> signal as a "real" waveform, not a number. I want to see the actual
> waveform that goes out to the DAC (sine, triangle or whatever).
>
> For example, for an 8bit bus, 00 would be a line at the bottom, 80
> would be in the middle and FF would be at the top of the wave display.
>
> Can you recommend a software that does this? I'm using WebPack with
> ModelSimXE so far.
>
> Thanks,
> Kevin
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 50746Peter Alfke wrote: > > Don't expect to do this in an FPGA alone, but -if I remember right - a > Sigma-Delta A/D converter is ideal for this applications. Others may know > more or better... There is a lot of science in the better S-D ADC's, but a 2.5MHz sample rate will push a first order one - that indicates a clock speed of 640MHz. There are maths schemes to give higher resolutions, but they usually impact the step response times. FPGAs are inherently noisy, but that need not be inside the Analog Loop - tiny logic gates can buffer from a (very) clean Vcc for the integrator drive. > > Peter Alfke > ================= > Bill Sloman wrote: > > > This is a dumb "wouldn't it be nice if there were a" question. > > > > At the moment we have a fast-ish, relatively low level alaog front end > > whose amplified output is digitised to 8-bits at 2.5MHz, and > > accumulated into 16 32-bit wide bins over about 2000 sampling cycles > > (24-bits would be enough ...). > > > > The conversion noise is visible on the analog signal and the "wouldn't > > it be nice" idea is that if the A/D converter were embedded in an FPGA > > which also managed the accumulation into on-chip RAM, there would be a > > whole lot less conversion noise visible at the front end. So you don't actually need 2.5MHz x 8 - but are trying to sample over 2000 cycles to get more 'bits' - correct ? Multi-Cycle averaging makes a very important assumption about the errors, that they are random, and evenly distributed. Real ADCs do not always follow classic maths, so large base averages do not give the expected noise reductions. Use a better ADC... That said, the Sigma-Delta ADCs are good for multi cycle maths, because the integration cap preserves fractional sample info, so you can, for example, have a faster 8 bit loop running, for good step response, and a 12/14/16 bit averaging loop, for good static / low slew following. > > > > In the interests of creeping featurism, a 10-bit A/D converter would > > be interesting, and room for 200 32-bit bins. The 2.5MHz sampling rate > > seems to be perfectly adequate. > > > > I've had a quick look at Lattice's analog FPGA and the analog isn't > > really fast enough while the digital side looks to be rudimentary - is > > there anything better out there? > > > > The application is a low volume (order of 100 per year) industrial > > measuring instrument, so ASICs are out of the question, and > > significant up-front costs would be a real problem. > > > > I suspect that what I'm asking for is a cross-breed between a camel > > and a mantee, but I'd love to be wrong. There are Micro Controllers with 16 & 24 bit ADCs, so the art of mixing Noisy Digital and Analog is getting better, but it is significant that they come from the very experienced Analog players - Burr Brown, and Analog Devices. - jgArticle: 50747
Well, I only go back 33 years to my days at Fairchild Applications... Everybody is affected by his roots. Peter Alfke ================================ Jonathan Bromley wrote: > "Peter Alfke" <peter@xilinx.com> wrote: > > > It is a long-standing practice to use "R" for synchronous Reset, and "C" > > for asynchronous Clear., and "P" for synchronous Preset, and "S" for > > asynchronous Set. > > 15+ years' standing in Xilinx libraries, but what are the other precedents? > I was completely unaware of it pre-Xilinx. Two-letter abbreviations with > the first letter being A for Asynchronous or S for Synchronous were > fairly common, and IMHO a lot more lucid. > -- > 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.Article: 50748
Jonathan Bromley wrote: > > "Peter Alfke" <peter@xilinx.com> wrote: > > > It is a long-standing practice to use "R" for synchronous Reset, and "C" > > for asynchronous Clear., and "P" for synchronous Preset, and "S" for > > asynchronous Set. > > 15+ years' standing in Xilinx libraries, but what are the other precedents? > I was completely unaware of it pre-Xilinx. Two-letter abbreviations with > the first letter being A for Asynchronous or S for Synchronous were > fairly common, and IMHO a lot more lucid. In HDL languages that use DOT extensions ( which I prefer, to 'inference design' ) these are the conventions : ========= Dot Extensions, CUPL V5.0 language ================== .Ext Side Description .AP L Asynchronous preset of flip-flop .AR L Asynchronous reset of flip-flop .SP L Synchronous preset of flip-flop .SR L Synchronous reset of flip-flop ========= Dot Extensions, XPLA V3.31, PHD language ================== .AP, .ASET, .PR Asynchronous preset .AR, .ACLR, .RE Asynchronous reset .CLR, .SR Synchronous reset .SET, .SP Synchronous preset ========== Dot Extensions, ABEL V5.00 ============================ Extension Description .AP Asynchronous Preset .AR Asynchronous Reset .CLR Device Independent Synchronous Reset .SET Device Independent Synchronous Preset .SP Synchronous Preset .SR Synchronous ResetArticle: 50749
"Allan Herriman" <allan_herriman.hates.spam@agilent.com> ha scritto nel messaggio news:3e006906.33423169@netnews.agilent.com... > These won't even come close to being able to convert 10 > bit values at > 2.5MHz. In the previous message I haven't noticed the 2.5 MHz thing; I agree with you. Anyway, I think that the delta-sigma approach (even with an external ADC) should be better in order to avoid the switching noise: they are inherently better for this kind of problems. Sadly, I'm not sure that you can find sigma-delta ADCs so fast. I have seen some at 200-300 kSPS, not more. The other user can try with a flash converter. It should be better than a SAR (obviously is costs more). -- Lorenzo
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