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
In article <kLMj4.353$425.17897@typhoon-la.pbi.net>, Don Golding <dgolding@angelusresearch.com> wrote: >I am rather new to VHDL and FPGA. I want to hook a XC4005 using Xilinx >Foundation 1.5 tools and talk to the FPGA through a 68HC11. >Currently, I am taking a course in VHLD at UCI. > > >Master/Slave arangement... > >Thanks >Don Golding > > > Unless you are missing at least an "E" on the end of XC4005 you will not be able to use the Foundation 1.5 tools with this FPGA. In order to work with the original XC4k series you have to use the XACT place and route tools which are only supported up to Foundation 1.3. HOw do I know this? I inherited a project with an XC4008 soldered on! How this helps. Tyrone -- -------------- thompson@eecis.udel.edu University of Delaware Tyrone Thompson EE Graduate StudentArticle: 20126
Thanks, The SRL'16s do initialize ok in simulation if you use the INIT generic. The problem was applying an initial value to an instantiated flip-flop paired in the same CLB and to an instantiated FDRE. Simon Bacon wrote: > 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. -- -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: 20127
Here is what I would do: Get the simplest and cheapest A/D converter chips, and solve all your formatting and FIFO jobs in one FPGA, like the Xilinx XC4005XL or XCS05XL for under $10.- ( depending on quantity) For really deep (4k) FIFO buffering I would use the smallest Spartan-II chip, which has dual-ported BlockRAM. FPGAs offer you all the flexibility you could possibly ask for, and they are not expensive any more. Peter Alfke, Xilinx Applications ============================= Lee Cao wrote: > 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 CaoArticle: 20128
The PLL should give you more flexibility, as you are not restricted to the specific divide/multiply ratios. Realistically though, it is an analog circuit and that has lots of extra baggage. For starters, the transistors have to have relatively tightly controlled (relative to a digital circuit) parameters in the active region for the thing to oscillate right. On top of that, it is working in a noisy digital environment so there are considerations there. I've done PLLs with dedicated chips, and there's enough to worry about there without ahving to worry about digital stuff on the same chip, or about compromising digital performance vs PLL performance. Bottom line is it is a tricky design problem at best, and a customer support nightmare at worst. I'll take the limited functionality of the digital DLL as my choice for an on chip clock management unit, thanks. Magnus Homann wrote: > 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.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: 20129
On Thu, 27 Jan 2000 15:26:31 GMT, Ray Andraka <randraka@ids.net> wrote: >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. Ray, I disagree with your statements about DLLs and PLLs. Both are implemented with delay lines made from gates. Both use feedback to adjust the gate delay. Both have an analog loop filter (but the DLL loop filter is simpler). About the only difference is that the PLL has the output of its delay line fed back to the input to make a ring oscillator. The DLL has its input connected to the input clock signal. This should give the DLL better jitter performance, but the quoted specs (A vs X) are identical. (BTW, I'm making some guesses about the implementations. It is possible that they have been implemented in other ways.) Regards, Allan. >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/~randraka > >Article: 20130
I'm not knowledgable on the Texas part, but doing it with a DSP like a ADSP2181, you can get the SPORT port on it to obtain the data directly into "circular" memory from serial ADCs without processor intervention. In our last project, we collect 14 bit data from 128 sensors continously at < 5usec per sample, without the processor doing anything. I'd be suprised if you couldn't do that in a Texas part as well. Regards, Saddle Lee Cao <ligeng@NOSPAMleecao.com> wrote in message news:MPG.12fa7a0ba5f0a8d898970f@news.erols.com... > > 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 CaoArticle: 20131
Peter, I'm designing a circuit that receives a copy of a 120 MHz sample clock (used in radio astronomy, and locked to an atomic standard at the observatory, typically an H Maser) along with the sample data. The input samples and clock are fed to an XCV050 and the clock is passed through one of the DLL's and into the chip for use in the input side of a FIFO/Packer setup, the CLKDV output of that CLKDLLHF is passed to the two CLKDLLs on the other side of the chip, on of which redrives the now 60 MHz clock for the rest of the board's data path and the other passing it into the Virtex for the output side of the FIFO/Packer and other logic. The question is, with the extremely low jitter at the input, how much will be added by the two levels of CLKDLLHF and CLKDLL that it goes through? I'm curious because at the board's final output I'm using that 60 MHz clock to drive a serializer, which multiplies it up to 1440 MHz internally, and has pretty tight jitter specs in order to maintain reliable lock at the Rx end and a low BER. (It's an HP G-Link in case you're familiar with it) Is there a potential problem? Until now I had been convinced that there was not going to be, which may even have been an idea I got from you when we discussed the subject during the break in one of the classes you guys hold there at Xilinx. (Can't remember why I thought that now, hoping I had a good reason) Thanks, Ben Sanchez Peter Alfke wrote: > > 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: 20132
Hi, Ben. The way I understand your circuit, each DLL will introduce a max jitter of less than 50 picoseconds. I'll think about this tomorrow at work, but I think the jitter is additive or orthoganal( square root) additive. Looks like you pick up, worst case a jitter of almost 100 ps at the DLL output. You understand the rest better than I. But you don't have to worry about additional analog jitter... Is that an answer? It's getting late here... Peter Alfke Ben Sanchez wrote: > Peter, > > I'm designing a circuit that receives a copy of a 120 MHz sample clock > (used in radio astronomy, and locked to an atomic standard at the > observatory, typically an H Maser) along with the sample data. The > input samples and clock are fed to an XCV050 and the clock is passed > through one of the DLL's and into the chip for use in the input side of > a FIFO/Packer setup, the CLKDV output of that CLKDLLHF is passed to the > two CLKDLLs on the other side of the chip, on of which redrives the now > 60 MHz clock for the rest of the board's data path and the other passing > it into the Virtex for the output side of the FIFO/Packer and other > logic. > > The question is, with the extremely low jitter at the input, how much > will be added by the two levels of CLKDLLHF and CLKDLL that it goes > through? I'm curious because at the board's final output I'm using that > 60 MHz clock to drive a serializer, which multiplies it up to 1440 MHz > internally, and has pretty tight jitter specs in order to maintain > reliable lock at the Rx end and a low BER. (It's an HP G-Link in case > you're familiar with it) > > Is there a potential problem? Until now I had been convinced that there > was not going to be, which may even have been an idea I got from you > when we discussed the subject during the break in one of the classes you > guys hold there at Xilinx. (Can't remember why I thought that now, > hoping I had a good reason) > > Thanks, > Ben Sanchez > > Peter Alfke wrote: > > > > 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: 20133
Hi. I am working on a project that requires interfacing LVPECL I/Os from an ASIC to the FPGA. The FPGA I/Os are LVCMOS, LVTTL. Can anybody guide me on how to approach this problem. Unfortunately I cannot use a LVPECL based FPGA such as Virtex-E). Thanks KarenArticle: 20134
hi, friends. what is the ARM core? Is there any site or Book for this question? thanks, good day!!Article: 20135
Motorola has a great line of ECL, PECL, LVECL, and LVPECL devices. The best IMHO are the ECLinPS or 'Eclipse' line (because they are fully differential, all the way through the internal logic and out again (except for things like special single ended devices and/or translators like this) and so when they operate, even at GHz operating frequencies, they have di/dt nearly zero. Now, sales pitch aside (kidding, I'm just a user) the device you need is one I use frequently to convert high speed clocks distributed in LVPECL to LVTTL/LVCMOS for use at the target device. It is the MC100LVELT23 Dual Differential LVPECL to LVCMOS (LVTTL compatible) Translator. See the following URL on Motorola's web site for info... http://scgproducts.motorola.com/ProdSum.asp?base=MC100LVELT23 Enjoy, Ben Sanchez K wrote: > > Hi. > > I am working on a project that requires interfacing LVPECL I/Os from an ASIC > to the FPGA. The FPGA I/Os are LVCMOS, LVTTL. Can anybody guide me on how > to approach this problem. Unfortunately I cannot use a LVPECL based FPGA > such as Virtex-E). > > Thanks > > KarenArticle: 20136
Ah, but the bit that should be free is most expensive (the software that gives you the privelidge of using said cheep chips). Peter Alfke wrote: > > FPGAs offer you all the flexibility you could possibly ask for, and they > are not expensive any more. > > -- ******************************************* * Russell Shaw, B.Eng, M.Eng(Research) * * Electronics Consultant * * email: russell@webaxs.net * * Australia * *******************************************Article: 20137
But I have anothe problem, I get not latches but compinatorial logic with loops In article <86pmg8$3kb$1@info3.fnal.gov>, husby@fnal.gov (Don Husby) wrote: > 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-5406 * 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: 20138
In article <MPG.12fa7a0ba5f0a8d898970f@news.erols.com>, Lee Cao <ligeng@NOSPAMleecao.com> writes [snipped] >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. Why not? - that's about 90 us, which is a lot of instructions. It sounds a lot simpler and more deterministic than messing about with external buffering. I'm a great stack machine fan, where interrupt overheads are usually very small (you don't need to stack registers, they're already there), but I'm sure a register-based processor can do it with appropriate register allocation. Cheers -- Keith WoottenArticle: 20139
This guy is posting an offer to pirate any package for you, but only some. If he did them ALL, THAT would be immoral. Give me a break! -- Keith F. Jasinski, Jr. kfjasins@execpc.com <eda1000@my-deja.com> wrote in message news:86pu80$g47$1@nnrp1.deja.com... > 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: 20140
Has anyone used TI serail McBSP to program Spartan XL. If so how did you accomplish this? Thanks- MikeArticle: 20141
Ben Sanchez wrote: > Motorola has a great line of ECL, PECL, LVECL, and LVPECL devices. The > best IMHO are the ECLinPS or 'Eclipse' line (because they are fully > differential, all the way through the internal logic and out again > (except for things like special single ended devices and/or translators > like this) and so when they operate, even at GHz operating frequencies, > they have di/dt nearly zero. > > Now, sales pitch aside (kidding, I'm just a user) the device you need is > one I use frequently to convert high speed clocks distributed in LVPECL > to LVTTL/LVCMOS for use at the target device. It is the MC100LVELT23 > Dual Differential LVPECL to LVCMOS (LVTTL compatible) Translator. > > See the following URL on Motorola's web site for info... > > http://scgproducts.motorola.com/ProdSum.asp?base=MC100LVELT23 > > Enjoy, > > Ben Sanchez > > K wrote: > > > > Hi. > > > > I am working on a project that requires interfacing LVPECL I/Os from an ASIC > > to the FPGA. The FPGA I/Os are LVCMOS, LVTTL. Can anybody guide me on how > > to approach this problem. Unfortunately I cannot use a LVPECL based FPGA > > such as Virtex-E). > > > > Thanks > > > > Karen Having just completed a design with similar constraints (PECL signals into a 3.3 volt FPGA) I can agree with this statement. Actually there is a whole family of parts available depending on required speed, direction of signal flow, and number of channels. A second vendor to consider is Micrel. The positives are a slightly different product spectrum and lower cost (at least at the small purchase quantity level.) Motorola (now OnSemi) has the advantage of having a faster line of new products and generally better availability. In general the two basic part numbering schemes are very similar and the pin-outs are identical. Lately the OnSemi web site has been highly uncooperative as far as downloading data sheets. A possible alternative source might be Fairchild. I don't know if they have any low voltage PECL translators. (By the way, that is what these parts are listed as, LVPECL to LVTTL translators or vice versa). The Fairchild parts are also second sourced by Micrel. The best stocking distributor for Micrel ECL family parts that I have found is Future. I don't work for them but I have been quite impressed with the assistance they are willing to give the little guy.Article: 20142
Ben Sanchez wrote: > Motorola has a great line of ECL, PECL, LVECL, and LVPECL devices. The > best IMHO are the ECLinPS or 'Eclipse' line (because they are fully > differential, all the way through the internal logic and out again > (except for things like special single ended devices and/or translators > like this) and so when they operate, even at GHz operating frequencies, > they have di/dt nearly zero. > > Now, sales pitch aside (kidding, I'm just a user) the device you need is > one I use frequently to convert high speed clocks distributed in LVPECL > to LVTTL/LVCMOS for use at the target device. It is the MC100LVELT23 > Dual Differential LVPECL to LVCMOS (LVTTL compatible) Translator. > > See the following URL on Motorola's web site for info... > > http://scgproducts.motorola.com/ProdSum.asp?base=MC100LVELT23 > > Enjoy, > > Ben Sanchez > > K wrote: > > > > Hi. > > > > I am working on a project that requires interfacing LVPECL I/Os from an ASIC > > to the FPGA. The FPGA I/Os are LVCMOS, LVTTL. Can anybody guide me on how > > to approach this problem. Unfortunately I cannot use a LVPECL based FPGA > > such as Virtex-E). > > > > Thanks > > > > Karen Having just completed a design with similar constraints (PECL signals into a 3.3 volt FPGA) I can agree with this statement. Actually there is a whole family of parts available depending on required speed, direction of signal flow, and number of channels. A second vendor to consider is Micrel. The positives are a slightly different product spectrum and lower cost (at least at the small purchase quantity level.) Motorola (now OnSemi) has the advantage of having a faster line of new products and generally better availability. In general the two basic part numbering schemes are very similar and the pin-outs are identical. Lately the OnSemi web site has been highly uncooperative as far as downloading data sheets. A possible alternative source might be Fairchild. I don't know if they have any low voltage PECL translators. (By the way, that is what these parts are listed as, LVPECL to LVTTL translators or vice versa). The Fairchild parts are also second sourced by Micrel. The best stocking distributor for Micrel ECL family parts that I have found is Future. I don't work for them but I have been quite impressed with the assistance they are willing to give the little guy.Article: 20143
Hi everyone, For my next project I am planing to use Xilinx SpartanXL in 240-pin or 208-pin PQFP package. For the prototyping phase I would like to use some kind of an adapter or even better socket that converts PQFP into thruhole type device for easier handling. I have found a company named NPLAS that offers PQFP sockets. As an answer to my enquiry they gave me these two part numbers: PQFP 208pin socket: OTQ-208-0.5-01 PQFP 240pin socket: OTQ-240-0.5-01 but in the following text they stated that they are uncertain that the sockets would fit Xilinx PQFP's. Has anyone used these sockets, and if so do they fit Xilinx PQFP packages? Can anyone suggest me some other manufacturer of PQFP sockets or give me some other alternative? Thanks in advance Rastislav StruharikArticle: 20144
"¹Ú±¸¿ë" <hereim@maru.comtec.re.kr> wrote: : what is the ARM core? Is there any site or Book for this question? http://www.arm.com/ Strewth, that globe is getting mighty small these days ;-) ARM Architecture Reference Manual - D. Jaggar; ARM System Architecture - S.Furber; The ARM RISC Chip, A Programmer's Guide A. van Someron & C. Atack. -- __________ |im |yler The Mandala Centre http://www.mandala.co.uk/ tt@cryogen.com Many are cold, but few are frozen.Article: 20145
Rick Filipkiewicz wrote: > I used these parts a couple of years ago & they were fine EXCEPT for one > problem. The first byte of config data was only loaded into the serialiser > on power-up and not every time RESET was asserted. In fact it was much > worse than this since even a power cycle didn't always load the first byte > correctly. > [...] This problem may be solved. I use Atmel AT17C128 and AT17C256, they work fine, after reset also. - WernerArticle: 20146
We are introducing a new course on Digital Design at the School of Engineering at the University of Guelph. We would like to choose between the Altera MAXII-Plus and the Xilinx Foundation Series Software. Anyone with the experience of using the two systems? Which is better to use by the students (i.e simpler to use e.t.c) Thanks, Shawki Areibi -- Shawki Areibi Assistant Professor School of Engineering University of Guelph Guelph, Ont, Canada N1G 2W1 Tel: (519) 824-4120 Fax: (519) 836-0227Article: 20147
> >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. Why don't you just use the on-board dma controller? I'm not a user of the c32, but I looked and it has 2 dma controllers. I use this method on the other non-TI chips all the time. all you have to do is set up a few registers in your DSP, wire up a few external dma control pins, and you're good to go. Then you don't need any fifo's at all. Just a thought Craig Jacobs Sent via Deja.com http://www.deja.com/ Before you buy.Article: 20148
russell shaw wrote: > > Ah, but the bit that should be free is most expensive (the software that > gives you the privelidge of using said cheep chips). > > > Peter Alfke wrote: > > > > FPGAs offer you all the flexibility you could possibly ask for, and they > > are not expensive any more. > > > > > > -- > ******************************************* > * Russell Shaw, B.Eng, M.Eng(Research) * > * Electronics Consultant * > * email: russell@webaxs.net * > * Australia * > ******************************************* Doesn't Altera let you have a limited-time license free? Jerry -- Engineering is the art of making what you want from things you can get. -----------------------------------------------------------------------Article: 20149
I hadn't considered a VCO made as a ring oscillator. I'll have to noodle on that. I'm pretty sure the DLL's loop filter function can be done digitally pretty easily (require more than one phase miss before moving to a new delay tap). Allan Herriman wrote: > On Thu, 27 Jan 2000 15:26:31 GMT, Ray Andraka <randraka@ids.net> > wrote: > > >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. > > Ray, I disagree with your statements about DLLs and PLLs. Both are > implemented with delay lines made from gates. Both use feedback to > adjust the gate delay. Both have an analog loop filter (but the DLL > loop filter is simpler). > > About the only difference is that the PLL has the output of its delay > line fed back to the input to make a ring oscillator. The DLL has its > input connected to the input clock signal. This should give the DLL > better jitter performance, but the quoted specs (A vs X) are > identical. > > (BTW, I'm making some guesses about the implementations. It is > possible that they have been implemented in other ways.) > > Regards, > Allan. > > >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/~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/~randraka
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