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
Holger Azenhofer wrote: > > Dear All, > > I'm looking for a small and free microcontroller core (8051). Can someone > tell me, where to find information about this core in the web. hi Have a look there: http://www.free-ip.com/, they have a free 8051 core Nicolas MATRINGE DotCom S.A. Conception electronique 16 rue du Moulin des Bruyeres Tel 00 33 1 46 67 51 11 92400 COURBEVOIE Fax 00 33 1 46 67 51 01 FRANCEArticle: 20101
Steve Dewey <steve@s-dewey123.demon.co.uk> writes: > One point in this debate is that Xylinx seem to put the DLLs into ALL > the Virtex and Spartan parts. Altera definitely only puts them into > certain speed grades/packages/device sizes. So you have to pay extra and > probably not use the speed grade, package, or device size that you > thought. Well, wont you have to pay extra for the Xilinx DLLs all the time too? Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 20102
Hi folks, In face, I am familiar with Lattice's ispPLD chip 1000, 2000, 3000 series: Such as 1016, 2032, etc. including there structures, and programming. How about the difference between FPGA and the same. Where can I find (website) the information about FPGA, and learn it quickly, I need to develop circurts with FPGA in the near future. Thanks.Article: 20103
On Tue, 25 Jan 2000 22:12:45 GMT, eml@riverside-machines.com.NOSPAM wrote: >Anyone managed this? I've tried modding the boot sector with a '95 >boot disk and Debug, but Debug can't even see the C drive, let alone >modify the boot sector. And does anyone know where the serial number >is? Presumably the NTFS location is different from the FAT16 and FAT32 >locations. > >By the way, this is (I think) legal. This paranoia is infectious, so I won't actually repeat the answer I received by email. If you want it, do an Altavista search on +volumeid +russinovich. For those who are concerned for my moral wellbeing, I'm replacing an old '95 machine with a new NT machine, and I want to minimise the trauma. The actual act of changing a serial number can't be illegal unless Microsoft forbids it in its licence agreement, or unless you specifically agree to another licence agreement that forbids it. I don't believe that this is the case. This leaves the licence agreements for any software that I previously ran on the old machine, and which I intend to run on the new machine. I don't have any of these in front of me but, IIRC, mine restrict me to usage on a *single* machine. This is exactly the same situation as when you're supplied with a dongle, which you can carry from machine to machine. Seems Ok to me. EvanArticle: 20104
On Wed, 26 Jan 2000 19:46:37 GMT, Ray Andraka <randraka@ids.net> wrote: > I've got two cases that are creating a problem with using the Virtex >GSR with flip-flop primitives for me: > >1) I've got a flip-flop that I need to have use the synchronous reset >that goes directly into the FF (virtex). I also want it to start up >initialized with GSR. That flip-flop is instantiated as a primitive >(FDRE) in my code so that I can put RLOCs on it to place it from within >the code. Normally, this could be handled at an RTL level with >appropriate coding, but where I'm instantiating the primitive, I don't >see a way of getting GSR in there too. Presumably you're only thinking about simulation? I had a quick think about this when you last mentioned it, and I don't think that it can be done. The reason is that all the Unisim FDRx models only have the sync R input, and there's no way to simulate a second async reset, short of writing your own simulation model. There's no implicit GSR mechanism in Unisims, unless I've missed something obvious. This seems like a significant oversight. If you're desperate, I'd think about forcing the required signals using the simulator, or possibly adding a default value to the output on the FDRE model. I don't think that the RTL solution would work either - I suspect that you'd just get an FDCE, with the sync reset signal rolled into the LUT. >2) I've got a case where I instantiate a FDE and an SRL16E and place >them both in the same half of the slice. The reset/clear on the FDE is >unusable in the design because it is shared with the SRL16E enable. If >I instantiate an FDCE to get a GSR input, the tools don't seem to make >it into an FDE when they recognize the GSR, and it results in a mapper >failure. Not sure that I understand this, but if you want an FDE that clears during GSR, then you've got the same problem. EvanArticle: 20105
Hi friends, i am trying to synthesize one external mC core with Sinplicity and Leonardo. I have got very strange results by synplisity. The Leonardo make really good job, but simpisity synthesize some memory cells (quite many of them) as combinatorial loops. Have somebody any thinks about this phenomena. Sorry, that i can't send you source code. * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network * The fastest and easiest way to search and participate in Usenet - Free!Article: 20106
Hi, Holger Azenhofer wrote: > Dear All, > > I'm looking for a small and free microcontroller core (8051). Can someone > tell me, where to find information about this core in the web. > > Any information is greatly appreciated !! > Take a look at section 4.9 (part 1) of the VHDL FAQ (http://www.vhdl.org/comp.lang.vhdl/). It lists a couple of 8051 models. -- EdwinArticle: 20107
Bonio Lopez <bonio.lopezNOboSPAM@gmx.ch.invalid> wrote: > but simpisity synthesize some memory cells (quite many of them) as > combinatorial loops. I saw this happen when the number of memory words was not exactly a power of 2. For example, I had a memory array defined as (16 downto 0) instead of (15 downto 0). Synplicity tried to synthesize the extra memory word as flip-flops instead of LUT-SRAM. If I increased the size to (31 downto 0) it would use the SRAM. -- Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby Fermi National Accelerator Lab Phone: 630-840-3668 Batavia, IL 60510 Fax: 630-840-5406Article: 20108
The problem is not the implementation on the physical silicon, it is a simulation issue. This application is rather long filter and the FDRE and SRL16Es are in the delay path, so it needs to run a substantial number of cycles to flush the X's out in the simulation. In the real device, everything gets cleared (the init defaults to 0 if not explicity specified) on configuration, so the pre and post tools simulations do not match. Additionally, it is a real PITA to run the simulation for what amounts to about 4 hours to get it to the point where you start getting useful sim results out. Simon Bacon wrote: > Ray > > Try putting an INIT attribute on the flop. To quote the > reference guide (page 18-9 in dev_ref.pdf): > > For Xilinx Virtex devices, a high signal on the GSR > (Global Set/Reset) net initializes each flip-flop and > latch to the state (0 or 1) specified by its INIT > property (default is 0).... > > The syntax would be the same as adding an RLOC. In VHDL: > > attribute INIT: string; > attribute INIT of Fipper:label is "S"; -- or "R" > > Of course the simulation won't match up unless you cook up > your own version of the flop. > > Ray Andraka <randraka@ids.net> wrote in message > news:388F4F58.6436047@ids.net... > > I've got two cases that are creating a problem with using the Virtex > > GSR with flip-flop primitives for me: > > > > 1) I've got a flip-flop that I need to have use the synchronous reset > > that goes directly into the FF (virtex). I also want it to start up > > initialized with GSR. That flip-flop is instantiated as a primitive > > (FDRE) in my code so that I can put RLOCs on it to place it from > within > > the code. Normally, this could be handled at an RTL level with > > appropriate coding, but where I'm instantiating the primitive, I don't > > see a way of getting GSR in there too. > > > > 2) I've got a case where I instantiate a FDE and an SRL16E and place > > them both in the same half of the slice. The reset/clear on the FDE > is > > unusable in the design because it is shared with the SRL16E enable. > If > > I instantiate an FDCE to get a GSR input, the tools don't seem to make > > it into an FDE when they recognize the GSR, and it results in a mapper > > failure. > > > > Has anyone encountered this and found a suitable workaround (RTL > coding > > doesn't count, I need to specify placement). > > > > -- > > -Ray Andraka, P.E. > > President, the Andraka Consulting Group, Inc. > > 401/884-7930 Fax 401/884-7950 > > email randraka@ids.net > > http://users.ids.net/~randraka > > > > -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 20109
eml@riverside-machines.com.NOSPAM wrote: > On Wed, 26 Jan 2000 19:46:37 GMT, Ray Andraka <randraka@ids.net> > wrote: > > > I've got two cases that are creating a problem with using the Virtex > >GSR with flip-flop primitives for me: > > > >1) I've got a flip-flop that I need to have use the synchronous reset > >that goes directly into the FF (virtex). I also want it to start up > >initialized with GSR. That flip-flop is instantiated as a primitive > >(FDRE) in my code so that I can put RLOCs on it to place it from within > >the code. Normally, this could be handled at an RTL level with > >appropriate coding, but where I'm instantiating the primitive, I don't > >see a way of getting GSR in there too. > > Presumably you're only thinking about simulation? I had a quick think > about this when you last mentioned it, and I don't think that it can > be done. The reason is that all the Unisim FDRx models only have the > sync R input, and there's no way to simulate a second async reset, > short of writing your own simulation model. There's no implicit GSR > mechanism in Unisims, unless I've missed something obvious. This seems > like a significant oversight. If you're desperate, I'd think about > forcing the required signals using the simulator, or possibly adding a > default value to the output on the FDRE model. > > I don't think that the RTL solution would work either - I suspect that > you'd just get an FDCE, with the sync reset signal rolled into the > LUT. In the test case I did, the GSR was connected only to an ROC sim component. In that case it did optimize out the GSR connection and gave me an FDRE. > > > >2) I've got a case where I instantiate a FDE and an SRL16E and place > >them both in the same half of the slice. The reset/clear on the FDE is > >unusable in the design because it is shared with the SRL16E enable. If > >I instantiate an FDCE to get a GSR input, the tools don't seem to make > >it into an FDE when they recognize the GSR, and it results in a mapper > >failure. > > Not sure that I understand this, but if you want an FDE that clears > during GSR, then you've got the same problem. > Here, apparently the tools saw FDCE, and black-boxed it. Then the mapper saw FDCE in the same half-slice as an SRL16E, and said nope, cain't do that! All of these are basically just what I need to do to make the simulation happy. It would be nice to have a GSR pin on the unisim primitives. I understand the reason xilinx doesn't have it it to maintain compatibility with the schematic unisim library. I've considered going in an putting a default value in the unisim model, but I have been reluctant to do so because it would create problems for the customer later if he recompiles the design without the 'special' unisim library. > > Evan -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 20110
I vaguely recall there being a conflict of interest issue there. Didn't he (they guy who ran the freecore site) go to work for Xilinx? If so, I'll bet that he closed up shop to avoid a conflict of interest. Andreas Heiner wrote: > > Hi > > > > Does anyone know what has happened to the FreeCore Homepage > > (www.freecore.com)? > > > > I have not been able to get through since the start of this year. > > > > Cheers > > -- > > Steve Dewey > > Remove 123 for email > > The last time I've seen it was in december. But as far as I know, this > wasn't a freecore page in december, because on this page only were Xilinx > Cores (in december). In January the page has been removed. I suppose that > freecore.com was bought by Xilinx at the end of last year. > > Andreas Heiner -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 20111
Magnus Homann wrote: > Steve Dewey <steve@s-dewey123.demon.co.uk> writes: > > > One point in this debate is that Xylinx seem to put the DLLs into ALL > > the Virtex and Spartan parts. Altera definitely only puts them into > > certain speed grades/packages/device sizes. So you have to pay extra and > > probably not use the speed grade, package, or device size that you > > thought. > > Well, wont you have to pay extra for the Xilinx DLLs all the time too? Sure, but not as much as you'd pay to have with and without versions. The spartanII devices have the DLLs too, and from what I've heard there, you're looking at less than $10 in quantity. Nice thing is you're not forced into one of the big parts to get the DLL. > > > Homann > -- > Magnus Homann, M.Sc. CS & E > d0asta@dtek.chalmers.se -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 20112
Oh, one more thing, The DLL is implemented basically as delay gates with feedback, which allows it to be done in the same process as the SRAM technology for the rest of the chip, with virtually nothing extra added to the process or yield testing. It's a totally digital circuit. That means the incremental cost of adding the DLL is virtually nothing after the NRE. Contrast that with a PLL, which by nature is an analog animal. That means extra care is required in the fab, as there are parameters that have to be met which would not have to be met for a strictly digital circuit. Magnus Homann wrote: > Steve Dewey <steve@s-dewey123.demon.co.uk> writes: > > > One point in this debate is that Xylinx seem to put the DLLs into ALL > > the Virtex and Spartan parts. Altera definitely only puts them into > > certain speed grades/packages/device sizes. So you have to pay extra and > > probably not use the speed grade, package, or device size that you > > thought. > > Well, wont you have to pay extra for the Xilinx DLLs all the time too? > > Homann > -- > Magnus Homann, M.Sc. CS & E > d0asta@dtek.chalmers.se -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 20113
Hi, Does anyone know how to display an internal node when simulating an APEX device with with Quartus ? I am able to select (with node finder) a node buried in my hierarchy and to store it in the input waveform file containing my simulation patterns. However, once the simulation process is done, this node is no more displayed : only the nodes corresponding to the output pins can be simulated. Thanks for any help. Jean-PierreArticle: 20114
I offer perfectly valid licenses for all tools protected by FLEXlm. Imagine having the latest editions of ModelsimEE, Synplify, Renoir, Visual HDL... You name it!!! The price is negotiable and very low. The licenses offered are any type you wish and for any time period, however I will not issue licenses with the HOSTID=ANY, since I find it immoral. I will ofcourse send you a temporary license to any prog before payment. Please use these addresses: eda1000@my-deja.com or eda1000@hotmail.com I expect these accounts to be shut down very soon, due to the nature of this posting, so I will send new postings regularly with my current e- mail address. Please look out for eda1000 in the body of the message. I gurantee that you will not be dissatisfied. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 20115
Ray Andraka <randraka@ids.net> writes: > Oh, one more thing, The DLL is implemented basically as delay gates > with feedback, which allows it to be done in the same process as the > SRAM technology for the rest of the chip, with virtually nothing > extra added to the process or yield testing. It's a totally digital > circuit. That means the incremental cost of adding the DLL is > virtually nothing after the NRE. Yup, that's what Xilinx told me too. Altera has a different view on the subject, though... :-) Who is right? Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 20116
In article <ltaelrs8b3.fsf@licia.dtek.chalmers.se>, Magnus Homann <d0asta@licia.dtek.chalmers.se> wrote: >Ray Andraka <randraka@ids.net> writes: > >Yup, that's what Xilinx told me too. Altera has a different view on >the subject, though... :-) > >Who is right? The one who's latest generation of low end FPGAs include 4 DLLs? -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 20117
Bob Wagner wrote: > Rick, > > I would encourage you to review the Orca Foundry 9.4 software release > (shiping Jan 15th) as the tools have been enhanced to clean up > this "logical" preferencing flow. > > It is now possible to simply enter the "logical" timing preferences into > the > .prf file. The tools will understand these preferences without having > to expand them into another file as before and you will be able to > review > the results and correlate them to your initial entry. > > This enhancement includes support for the use of wildcards in the > logical > preferences as well. > > Other enhancements will include a floorplanning tool, guided design, > STAMP > timing model support for improved FPSC timing analysis, and many > run-time > enhancements. > > Check it out. > > Bob Wagner > Lucent Technologies > New England Region FPGA/FPSC FAE I have a bit more experience with the tools now and I have found that with the OR2T parts at least, the packing leaves something to be desired. I can't tell if this is due to the software or the parts, but I can only get about 50% utilization of the logic. This is not a routing issue. It has to do with how the FFs and LUTs get packed into the PLCs. In a OR2T04 part with 100 PLCs containing 400 LUTs and 400 FFs, I get a 65% utilization when I am using about 161 LUTs and 139 FFs. This indicates that only half of the available logic in the 65 PLCs are being used. This is not a matter of the logic being spread out because of the PLCs being available. Before I made some changes to the design to minimize the logic used, I was consuming over 100% of the design. The changes I made reduced the logic by about 35 PLCs to get to where I am now. I suspect that this is more a limitation of the chip than the tools. The LUTs share inputs so that you can't have all four LUTs in a PLC implementing 4 input functions with independant inputs. In fact they can't even implement 3 input functions unless you have shared inputs. The good news is that I am becoming more familiar with the tools and I can get things done more easily than I could before. I some ways, the software is friendlier than the Xilinx tools just because the flow is rather simple and I can find all the files I need to look at. I am interested in trying the new version of the tools. How can I get them? I currently have the Silver Edition ver 9.35. Is there a Silver Edition ver 9.4? I am not inclined to download the backend tools unless I can be assured that they are compatible with the ver 9.35 frontend tools. I have had a lot of trouble in the past from mixing upgrades like that. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 20118
If you end up writing your own sim model to check out pre-tools,
this may help:
------------------------------------------------------------------------
-----
-- synthesis translate_of
------------------------------------------------------------------------
-----
library IEEE;
use IEEE.STD_LOGIC_1164.all;
entity SRL16E is
port (D : in STD_ULOGIC;
CE : in STD_ULOGIC;
CLK : in STD_ULOGIC;
A0 : in STD_ULOGIC;
A1 : in STD_ULOGIC;
A2 : in STD_ULOGIC;
A3 : in STD_ULOGIC;
Q : out STD_ULOGIC := '0' ); -- or 'U'
end SRL16E;
architecture MySim of SRL16E is
-- choose you preferred initialisation value here
signal SHIFT_REG : std_logic_vector (15 downto 0) := (others=>'0');
begin
ReadBehavior : process(A0, A1, A2, A3, SHIFT_REG)
variable LENGTH : integer;
variable ADDR : std_logic_vector(3 downto 0);
begin
ADDR := (A3, A2, A1, A0);
LENGTH := ToInteger(ADDR); -- choose your preferred version of
ToInteger()
Q <= SHIFT_REG(LENGTH); -- could add 'after 1 ns' to make the sim
more readable
end process ReadBehavior;
WriteBehavior : process (CLK)
begin
if rising_edge(CLK) then
if CE='1' then
for I in 15 downto 1 loop
SHIFT_REG(I) <= SHIFT_REG(I-1);
end loop;
SHIFT_REG(0) <= D;
end if;
end if;
end process WriteBehavior;
end MySim;
------------------------------------------------------------------------
-----
-- synthesis translate_on
------------------------------------------------------------------------
-----
Ray Andraka <randraka@ids.net> wrote
> The problem is not the implementation on the physical silicon, it is a
> simulation issue. This application is rather long filter and the FDRE
and
> SRL16Es are in the delay path, so it needs to run a substantial number
of
> cycles to flush the X's out in the simulation.
Article: 20119Check out www.opencores.org for a similar effort. (Notice the ".org" instead of the ".com" of freecores. :-) Stefan Steve Dewey wrote: > Hi > > Does anyone know what has happened to the FreeCore Homepage > (www.freecore.com)? > > I have not been able to get through since the start of this year. > > Cheers > -- > Steve Dewey > Remove 123 for emailArticle: 20120
raja wrote: > > hai folks > > do you anyone know about ORCA 3T series carry chain > 1. what is the basic advanatge in ORCA 3T carry chain than XC4000 from > xilinx > > what are basic advanatges and disavantages in both of this > > anyone knows this, i need your help > thanks in advance > kamal I have not studied the Lucent Orca series 3 carry chains in detail, but in general they allow much more flexible placement than the Xilinx carry chains. The Lucent parts provide carry in and out in all four directions to the adjacent PLCs. In the 4000 series Xilinx provides two directions (up and down IIRC) and in the newer series (and possibly some new versions of the 4000 such as the Spartan I or the XL parts) they have cut that to just the up direction. This is not likely to be a major difference since it is not uncommon to align your counters, etc. in a column to achieve good data buss connections. But if you don't have other limitations, the Lucent method should make placement and routing a bit easier. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 20121
raja wrote: > > hai folks > > do you anyone know about ORCA 3T series carry chain > 1. what is the basic advanatge in ORCA 3T carry chain than XC4000 from > xilinx > > what are basic advanatges and disavantages in both of this > > anyone knows this, i need your help > thanks in advance > kamal I have not studied the Lucent Orca series 3 carry chains in detail, but in general they allow much more flexible placement than the Xilinx carry chains. The Lucent parts provide carry in and out in all four directions to the adjacent PLCs. In the 4000 series Xilinx provides two directions (up and down IIRC) and in the newer series (and possibly some new versions of the 4000 such as the Spartan I or the XL parts) they have cut that to just the up direction. This is not likely to be a major difference since it is not uncommon to align your counters, etc. in a column to achieve good data buss connections. But if you don't have other limitations, the Lucent method should make placement and routing a bit easier. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 20122
Magnus Homann wrote: > > > Yup, that's what Xilinx told me too. Altera has a different view on > the subject, though... :-) > > Who is right? It's an interesting battle. Here are my views: In an ideal world without any noise, ground bounce, and processing problems, the PLL would have some advantages, since it can multiply the incoming frequency by any factor, and it can suppress incoming jitter ( if that is desirable). Now let's leave the idealized world and enter the real world: Keeping the spontaneous jitter of an RC-based on-chip VCO under control is a very difficult task. I know; I cut my teeth on TV-tuner and citizen band analog PLLs many years ago, and there we had the luxury of using LC oscillators, which I find easier to keep clean. Putting a sensitive and delicate analog circuit onto any notoriously noisy digital chip is asking for trouble. First, the analog parameters of the PLL transistors must be controlled ( and what happens when the process migrates to smaller geometries? ), and then you need separate ground/Vcc pins and decoupling, and you still don't know how much spontaneous jitter is being generated. Combining digital and analog is like moving a rock band into an old folks home. They just don't like each other. The DLL is a 100% digital circuit; its output jitter has a well-defined max value, and no extra supply connections are needed. I for one feel much more comfortable in the predictable digital world of the DLL. Peter Alfke, Xilinx ApplicationsArticle: 20123
You might try changing as many of the outputs as you can to the 'slow' slew rate setting. Doing this helped my out considerably on some EMI problems I was having on a design. -- Andrew Dyer <adyer@enteractDOTcom> Where do you want to go today? Nevermind, you're coming with us.Article: 20124
Help!!! I am looking for a way to acquire 11 channels of 12-bit data at 11kHz. The DSP I am using is a Texas Instrument TMS320C32, the 60MHz one. The DSP needs to do quite a bit of number crunching so I was hoping that there could be some way of automating/buffering the incomining data from the ADC at the rate of approximately 200kBytes/s. I don't think that having the DSP interrupted 11,000 times per second to service the ADC is going to work. In the name of saving space and cost, I was looking for ADCs with buffering FIFO built into it. So far, I found a Texas Instrument THS1206, which is a 4 channel 1.5Msps/channel 12-bit ADC with a 16-word FIFO built in. This means I can take up to four samples before the ADC have to be serviced by the DSP. But this chip is around $15.00 a piece, which means I would be spending $40+ on three of them just to cover 11 channels. Do I have any other options? I don't need the 1.5Msps/channel rate of the THS1206. Is there a less expensive ADC out there with multichannel input, built-in MUX, S&H, 12-bit resolution, FIFO, and at least 11ksps/channel? If not, what are my other options at interfacing the ADC front end circuitry to the DSP? Would I need a PLD logic of some sort with enough flip-flops to act as a data buffer? Thanx -- Lee Cao
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