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
Dear all, I am looking for data on the global FPGA market distribution (e.g. telecom, DSP, military, etc..) for a talk that I'm preparing. Does anyone know a good source for this kind of information ? thanks -Arrigo -- Arrigo Benedetti o e-mail: arrigo@vision.caltech.edu Caltech, MS 136-93 < > phone: (626) 395-3695 Pasadena, CA 91125 / \ fax: (626) 795-8649Article: 10451
Mike Butts wrote: > > There are a number of good reasons for doing a small CPU in > an FPGA: > > * Cost and size: With a single $20 chip, you get a CPU, which is > as fast or faster than common 8-bit or 16-bit embedded control > CPUs, *plus* you get all your peripheral logic for ports, > timers, UART, etc. For example, the 68HC11 is still very > commonly used in small robotics apps, and it only runs at > a few MHz. I expect at least 10 MHz from a carefully designed > FPGA-based CPU; 30 MHz or better with good pipelining. What about the 50 MHz versions of the 8051 I see advertised? Surely this is as fast as the custom CPU and would allow you to use a smaller FPGA. I suspect that the total cost would be lower for a standard CPU/small FPGA than for a bigger FPGA with custom CPU. > * Performance: You can use reconfigurable computing techniques > to customize CPU instructions, and/or include "accelerator" > hardware to increase performance on your specific app. Reconfigurable computing certainly has a lot of possiblities. But I haven't seen very much to support it. I do know that it can be very difficult to debug. Everyone knows how tricky it can be to debug self modifing code. Think about how hard it would be to debug a self modifing processor!! 8-O > * Education: The guts of the CPU and its peripherals are > completely open for inspection and modification. It's > an ideal teaching tool for undergraduates to get hands-on > exposure to hardware architecture and systems design. I think that is an excellent point. When I was in grad school, I wanted to implement a simulation of a microcoded teaching CPU that they used for a couple of classes. Until then it had only existed on paper. But the simulation would not have allowed the students to modify or extend the design easily. This would allow an EE student to play to his hearts content, and he might actually learn something. ;-) > * Satisfaction: Building a small computer from the gates up > through the instruction set architecture up through the > OS and compiler up to apps is a very satisfying exercise, > akin to building one's own small sailboat. It can be a > potent antidote to the shrink-wrapped proprietary HW and > SW we generally must live with. > > --Mike This is certainly a good reason to do a project in your spare time. The education you would receive is not trivial either. It appears that a lot of people have done this with a Forth implementation in mind. Do you think they are doing this because of the personal satisfaction motivation or do you think they have commercial motivations in mind? -- Rick Collins rickman@XYwriteme.com remove the XY to email me.Article: 10452
Rita Madarassy wrote: > > You can use unbonded pads to add delay like setup in the following manner: > > ->---------------------[OBUF]-----[UPAD]----------[IBUF]-----> > > The delayed signal is the output of the IBUF. This should add at least > 7ns of delay in a 4000XL-09 device. > If you want to get an idea of the min delay expect a > conservative 50% out of the max delay reported in the static timing > analyzer. > Whoa!!! Just because the timning analyser reports a delay of 7 ns doesn't mean that you will get a 7 ns delay. That is an upper bound on the delay. In any real chip it will be faster and as Xilinx produces more mature parts, it may get MUCH faster. That is why they try to pound on you to never, never assume minimum prop delays. Xilinx doesn't even publish minimum delays. That one of the reasons behind the push to use synchronous designs. A fully synchronous design can be proven to work simply by performing logic analysis and a static timing analysis. If a signal runs too fast, the clock makes it wait at the next register. But if you are doing asynchronous design, you can't count on a minimum delay. So you have to design your logic without feedback, or use a very complex analysis to avoid race conditions. I learned how to do this in school, but in 20 years I have only seen it done once. No one else is willing to go the extra mile (or ten) to be able to make sure it will work. -- Rick Collins rickman@XYwriteme.com remove the XY to email me.Article: 10453
Rita Madarassy <madarass@cats.ucsc.edu> wrote in article <6jscep$gm8@darkstar.ucsc.edu>... > You can use unbonded pads to add delay like setup in the following manner: > > > > ->---------------------[OBUF]-----[UPAD]----------[IBUF]-----> > > > The delayed signal is the output of the IBUF. This should add at least > 7ns of delay in a 4000XL-09 device. > If you want to get an idea of the min delay expect a > conservative 50% out of the max delay reported in the static timing > analyzer. > Rita, I don't think you noticed that Alfredo needs to delay the signal 1 to 3 microseconds. > In article <35614A77.D253C2E3@uv.es>, > Alfredo Rosado <alfredo.rosado@uv.es> wrote: > >Hi, > > I am trying to build some kind of architecture to delay a signal > >(typical delay ranging from 1 to 3 useconds). I have thought of doing it > >with chained flip-flops, but if I have a fast clock signal, it will > >waste a big amount of resources. Also, a FIFO could be an option, but it > >would spend lots of resources as well. > > Is there any other possibility to do it?. > > Thanks in advance. Alfredo, You didn't mention some of the details of how you needed this signal to be delayed. For example, do you need some active edge to be delayed by 1us or do you need every transition of the signal (referenced to the fast clock) to appear somewhere 1us later? If its the first case where the signal transitions to an active state and you don't care what the signal does after that for 1us until you process it, then the suggestion to use a counter made by another poster will work great. Load the counter when the signal transitions, then your delayed signal is created by logic that detects when the counter counts down to 0. However, if its the second case, where every transition must show up 1 to 3 us later, then you have no choice (that I can see) but to chain flip-flops or use a fifo like you were saying. You can't even send slower clocks to that chain to save resources because that would cause you to miss some transitions. Hope this helps. -- Rich Iachetta IBM Corporation iachetta@us.ibm.comArticle: 10454
Back in April, Peter Alfke wrote: >Prentice Hall publishes and sells the "Xilinx Foundation Student >Edition" which supports all XC9500 devices and all XC4000-type devices >up to 8k gates today, 10k gates in the next upgrade. >... The book and CD appear to be available from amazon.com and also at Quantum Books in Cambridge, MA. I am considering purchasing this book and software, but was wondering when the "next upgrade" would be available and how one would be able to tell which version of the software was included. I would like to have the capability to target a design for the XC4010E device, but would be more inclined to go ahead and purchase the current version if the next upgrade will not take place within the next year. Can anyone (Peter?) shed any light on this subject? Thank you in advance for your replies. -EwanArticle: 10455
this is a test, please ignore. new news reader rkArticle: 10456
If you are using xilinx 4K series (also spartan or virtex), use the CLB memories as shift registers. This gives you up to 17x (not quite due to the counter logic) the density of a design that just uses the CLB flip-flops. Word-wide delay queues occur frequently in pipelined DSP hardware. The 4K's ability to implement a compact delay queue is one of the reasons I prefer the Xilinx 4K over its competitors for signal processing applications. Xilinx has an app-note detailing the use of the clb ram for long shift registers. I think it is XAPP-52. If you can live with an inertial delay, using a counter as Ed suggested will be more compact for large clock count delays. Ed McCauley wrote: > > Alfredo, > > With what degree of precision must you delay your signal? In the > crudest terms, lets say you have three flops (in serial) each clocking > at a 1 us rate: What goes in comes out 3 us later. OK, that's probably > not what you'd want BUT, how about 30 flops (or FIFO stages) clocking at > 0.3 us? You get the idea. More precision / resolution --> more flops > at a higher rate. > > Plan 'B': use an counter! On the occurrence of your signal, release a > counter that was held in reset. After N clocks of frequency, the count > value reaches N which then signals the completion of your delay period. > > To get a bit more technical, the latter approach would implement an > inertial delay the former, a transport dely. > > Alfredo Rosado wrote: > > > > Hi, > > I am trying to build some kind of architecture to delay a signal > > (typical delay ranging from 1 to 3 useconds). I have thought of doing it > > with chained flip-flops, but if I have a fast clock signal, it will > > waste a big amount of resources. Also, a FIFO could be an option, but it > > would spend lots of resources as well. > > Is there any other possibility to do it?. > > Thanks in advance. -- -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 The Andraka Consulting Group is a digital hardware design firm specializing in high performance FPGA designs for digital signal processing, computing and control applications.Article: 10457
John Eaton wrote: > Many FPGA's tout speeds up into the 100 Mhz's. It sounds great until you you realize > and the only design that will actually run that fast is a shift register. This makes > FPGA's the ideal canidate for a CPU design using serial logic. With serial logic all > registers are serial shift registers and you can load anyone with a single bit mux. > A 8 bit Full adder is simply a one bit full adder stage and one carry flip flop. > It a great speed/logic trade off. > > John Eaton Bit serial processing also translates to the routing structure nicely. Most connections are very local, so the delays associated with long runs and high fanouts don't exist, which means you can often get close to the word rates of a fully parallel processor. The big thing to watch for if you pack alot of serial logic into one part is the power dissipation. The serial logic can often be clocked at or near the advertised toggle frequency, and it is possible to present data that will cause nearly every flop in the design to toggle on every clock. -- -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 The Andraka Consulting Group is a digital hardware design firm specializing in high performance FPGA designs for digital signal processing, computing and control applications.Article: 10458
Xilinx has provided updated and complete information about Xilinx Student Edition upgrades to VHDL, Verilog, F1.4, F1.5, and XC4010E/XL devices at http://www.xilinx.com/programs/xse1.htm#FUO . ----------------------------------------------------------- Steven K. Knapp OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally" E-mail: sknapp@optimagic.com Web: http://www.optimagic.com ----------------------------------------------------------- Ewan D. Milne wrote in message <6jskfr$9up$1@sunfish.hi.com>... >Back in April, Peter Alfke wrote: >>Prentice Hall publishes and sells the "Xilinx Foundation Student >>Edition" which supports all XC9500 devices and all XC4000-type devices >>up to 8k gates today, 10k gates in the next upgrade. >>... > >The book and CD appear to be available from amazon.com and also >at Quantum Books in Cambridge, MA. I am considering purchasing >this book and software, but was wondering when the "next upgrade" >would be available and how one would be able to tell which version >of the software was included. I would like to have the capability >to target a design for the XC4010E device, but would be more inclined >to go ahead and purchase the current version if the next upgrade >will not take place within the next year. > >Can anyone (Peter?) shed any light on this subject? > >Thank you in advance for your replies. > >-EwanArticle: 10459
Rickman <spamgoeshere2@yahoo.com> wrote: > Graham Eastwood wrote: > This sounds very scary to me. What happens if you just bought the M1 > tool and you don't have the XACT stuff? You also wouldn't even know that > this is not normal!!! The M1 tools have been out for about 5 or 6 months > now. Is anyone working on this??? > > I assume that this is not a problem for any of the XC4000 families? My group has been pleased with M1.4 for XC4000XL (using Syplify for synthesis at least.) Some of our designs have been moved from XACT, with no problems. Thanks, -- Bill Warner Silicon Graphics wtw@sgi.comArticle: 10460
I wonder if someone could point me to an archive for this newsgroup that would contain old posts from 1990 plus or minus a couple of years. I have had no luck with Deja News (only goes back to 1995); I can't find an FAQ for this group, and the super.org archive that some of the web pages point to is 404 Not Found. I would appreciate any help in finding a comp.arch.fpga archive--thanx in advance! ChrisArticle: 10461
The following conferences on FPGAs, programmable logic, reconfigurable computing, or related topics will be happening during the remained of May and June, 1998. For additional information, visit the Conferences section on The Programmable Logic Jump Station at http://www.optimagic.com/conferences.html. June, 1998 (http://www.optimagic.com/conferences.html#Jun98) ========== The Sixth FPGA/PLD Design Conference & Exhibit, 24-26 June, 1998, Pacifico Yokohama, Yokohama, Japan. Design Automation Conference (DAC'98) 15-19 June, 1998, Moscone Center, San Francisco, California, USA. Synplicity Users Group 14 June 1998, ANA Hotel, San Francisco, CA, USA. Field-Programmable Devices (FPD'98) Conference The 5th Canadian Workshop of Field-Programmable Devices. 7-10 June 1998, Montréal, Québec, Canada. May, 1998 (http://www.optimagic.com/conferences.html#May98) ========= Lattice VHDL and In-System Programming Training Seminar 27/28 May, 1998, Unterschleissheim, Germany Atmel's New AT40K FPGA, 21 May, 1998, 10:00 Pacific time. Web-based seminar requires pre-registration and download. ----------------------------------------------------------- Steven K. Knapp OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally" E-mail: sknapp@optimagic.com Web: http://www.optimagic.com -----------------------------------------------------------Article: 10462
Beware the TURBO bit.. If you turn off the turbo bit, a timing simulation will not check setup and hold you could have all sorts of violations and it wouldn't tell you. This is of course a feature, "bug", in 8.2 and below. I haven't checked 8.3 to see if they fixed it yet. Matt Ying C. wrote in message <6jpo40$iat$1@agate.berkeley.edu>... > > >If you click on the warning message and click on "Help on Message" in >Max+plus II, it will tell you that for 7000E device, there is only 1 bit >which controls slow slew rate/turbo hit. Hence, either slow slew rate or >turbo bit (not both) needs to be enabled. > >By the way, Global Project Logic Synthesis will affect the whole design; >use Logic option if you want to do it pin by pin. > >Regards, > >Ying >ying@csua.berkeley.edu > >In article <355FFCF3.4BF41553@cern.ch>, >Flemming JENSEN <Flemming.Jensen@cern.ch> wrote: >>Dear everybody >> >>I am trying to switch off the turbo bit in my Altera 7128E circuit, but >>I can't make it work. I try to set the global settings under "Global >>project logic synthesis" and here I choose the "define synthesis style". >>No matter how I set the turbo bit it is not switched off. Either I get >>the warning "Project has conflicting defaults for turbo bit and slow >>slew rate. >> >>My problem is that I want to reduce the switching speed, because they >>might cause some problems in my design. >> >>Thank you for taking the time for reading this. >> >>Flemming > >Article: 10463
In article <35614A77.D253C2E3@uv.es>, Alfredo Rosado <alfredo.rosado@uv.es> writes: > I am trying to build some kind of architecture to delay a signal > (typical delay ranging from 1 to 3 useconds). I have thought of doing it > with chained flip-flops, but if I have a fast clock signal, it will > waste a big amount of resources. Also, a FIFO could be an option, but it > would spend lots of resources as well. What sort of signal are you trying to delay and/or how accurately does the output of the delay have to follow the input? If you just need to delay an occasional rising edge, then you can do that with a counter. -- These are my opinions, not necessarily my employers.Article: 10464
Rickman wrote:
> What about the 50 MHz versions of the 8051 I see advertised? Surely this
> is as fast as the custom CPU and would allow you to use a smaller FPGA.
> I suspect that the total cost would be lower for a standard CPU/small
> FPGA than for a bigger FPGA with custom CPU.
No question. Mostly the point of this little exercise is to do
CPU+logic
with the smallest FPGA. Total cost of FPGA + SW = $20. Plus a
hardwired
CPU would miss out on the reconfigurable processor angle, and would
place lower on the education and satisfaction scales. In any serious
commercial effort I don't think there's any question that silicon
is best spent on a fast hard-wired CPU, tightly coupled to FPGA.
> Reconfigurable computing certainly has a lot of possiblities. But I
> haven't seen very much to support it. I do know that it can be very
> difficult to debug. Everyone knows how tricky it can be to debug self
> modifing code. Think about how hard it would be to debug a self modifing
> processor!!
Oh, no, that's almost never the idea. Nearly all reconfigurable
computing
applications are compiled, or should I say cross-compiled, on
conventional
computers. One or more pre-compiled FPGA binaries are downloaded at
run time to get the computing done. Even that's hard enough. Someday
we
hope to have FCCMs doing their own place and route jobs at high speed,
but even that is still a research topic.
> It appears that a lot
> of people have done this with a Forth implementation in mind. Do you
> think they are doing this because of the personal satisfaction
> motivation or do you think they have commercial motivations in mind?
Oh, gee, you'd have to ask on comp.lang.forth, but I'm pretty sure it's
99% personal satisfaction. The author of SOD32, the Forth system that
the folks in Hong-Kong used for their FPGA-based Forth processor
<http://www.xs4all.nl/~lennartb/forth.html> says he "wrote it just for
the hack value". (Not forgetting that most good things in computing got
started for just their hack value.)
--Mike
Article: 10465Hi, pardon my ignorance, but is there any 44-pins sized fpga or cpld around that contains about 7000 gates? Thanks in advanceArticle: 10466
>What about the 50 MHz versions of the 8051 I see advertised? Surely this >is as fast as the custom CPU and would allow you to use a smaller FPGA. >I suspect that the total cost would be lower for a standard CPU/small >FPGA than for a bigger FPGA with custom CPU. I was recently involved in a project which was going to go to 500k-1M pieces per year, obviously to an ASIC, and we found that under about 1M pieces a *separate* CPU was always cheaper. Eventually, the company running this got into a partnership with a major Japanese chip vendor (who makes various CPUs) and this Jap firm was so interested in making this ASIC that they chucked in one of their CPUs very cheaply. Only then it made sense. As the volumes go up, the FPGA gets cheaper, but the external CPU gets cheaper too. The exception to the above is when there is no physical space for a CPU. Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y.Article: 10467
In article <35620D0E.786B@earthlink.net>, Chris Lee <p_halpern@earthlink.net> writes >I wonder if someone could point me to an archive for this newsgroup that >would contain old posts from 1990 plus or minus a couple of years. I >have had no luck with Deja News (only goes back to 1995); I can't find >an FAQ for this group, and the super.org archive that some of the web >pages point to is 404 Not Found. I would appreciate any help in finding >a comp.arch.fpga archive--thanx in advance! > Chris, There's no "official" faq, although if you look through recent threads, there are plenty of useful websites around. I started contributing here in late 1993 IIRC, at which point the group was very new, running at just a couple of postings per week, and mainly about parallel computer architectures using multiple FPGAs, which was the original purpose. I'm unaware of any earlier archive, but there's probably little to find before 1995 anyway. -- David Pashley < ------------------------ < < < ---------- Email: david@fpga.demon.co.uk | Direct Insight Ltd < < < < > Tel: +44 1280 700262 | | < < < Fax: +44 1280 700577 | --------------------------- < ------------------------------------------Article: 10468
Chris Lee (p_halpern@earthlink.net) wrote: : I wonder if someone could point me to an archive for this newsgroup that : would contain old posts from 1990 plus or minus a couple of years. I : have had no luck with Deja News (only goes back to 1995); I can't find : an FAQ for this group, and the super.org archive that some of the web : pages point to is 404 Not Found. I would appreciate any help in finding : a comp.arch.fpga archive--thanx in advance! Hi Chis, The super.org archive includes threads from July 94 to Aug. 96 There is no more support for this archive, so it is in bad condition. The address is: ftp://www.super.org/pub/www/FPGA/caf.html Be sure to use "ftp", not "http". The links on this page are not correct. Use allways ftp://www.super.org/pub/www/FPGA as the base address and add manually the file name, e.g. ftp://www.super.org/pub/www/FPGA/thread_old.html Additionally, I do maintain a newer archive with all threads starting from Febr. 1997: http://www.fernuni-hagen.de/IT/FPGA/news/ Good luck Markus WannemacherArticle: 10469
Mike Butts <mbutts@realizer.com> writes:
>There are a number of good reasons for doing a small CPU in
>an FPGA:
>* Cost and size: (...)
>* Performance: (...)
>* Education: (...)
>* Satisfaction: (...)
You've left out: *Versatility: Once the design is made, it's rather easy
to retarget it to the next version of chips, debug, add features, etc.
--
Amos Shapir
Paper: nSOF Parallel Software, Ltd.
Givat-Hashlosha 48800, Israel
Tel: +972 3 9388551 Fax: +972 3 9388552 GEO: 34 55 15 E / 32 05 52 N
Article: 10470Those interested in a CPU+FPGA for fun or education should take a look at the relatively inexpensive board offered by XESS Corp. (http://www.xess.com/FPGA/ho05000.html). It has an 8031, a 32K SRAM, and either an FPGA or CPLD (your choice). Prices range from US$160 to US$350, depending on the FPGA and whether you qualify for an educational discount. The XESS board is also supported by the Xilinx Student Edition book, which contains the Xilinx design software on CD-ROM. The book retails for $87 and is available for sale on-line (http://www.optimagic.com/books.html#Xilinx). ----------------------------------------------------------- Steven K. Knapp OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally" E-mail: sknapp@optimagic.com Web: http://www.optimagic.com ----------------------------------------------------------- Mike Butts wrote in message <356262AB.1CA1BC6D@realizer.com>... >Rickman wrote: > >> What about the 50 MHz versions of the 8051 I see advertised? Surely this >> is as fast as the custom CPU and would allow you to use a smaller FPGA. >> I suspect that the total cost would be lower for a standard CPU/small >> FPGA than for a bigger FPGA with custom CPU. > >No question. Mostly the point of this little exercise is to do >CPU+logic >with the smallest FPGA. Total cost of FPGA + SW = $20. Plus a >hardwired >CPU would miss out on the reconfigurable processor angle, and would >place lower on the education and satisfaction scales. In any serious >commercial effort I don't think there's any question that silicon >is best spent on a fast hard-wired CPU, tightly coupled to FPGA. > >> Reconfigurable computing certainly has a lot of possiblities. But I >> haven't seen very much to support it. I do know that it can be very >> difficult to debug. Everyone knows how tricky it can be to debug self >> modifing code. Think about how hard it would be to debug a self modifing >> processor!! > >Oh, no, that's almost never the idea. Nearly all reconfigurable >computing >applications are compiled, or should I say cross-compiled, on >conventional >computers. One or more pre-compiled FPGA binaries are downloaded at >run time to get the computing done. Even that's hard enough. Someday >we >hope to have FCCMs doing their own place and route jobs at high speed, >but even that is still a research topic. > >> It appears that a lot >> of people have done this with a Forth implementation in mind. Do you >> think they are doing this because of the personal satisfaction >> motivation or do you think they have commercial motivations in mind? > >Oh, gee, you'd have to ask on comp.lang.forth, but I'm pretty sure it's >99% personal satisfaction. The author of SOD32, the Forth system that >the folks in Hong-Kong used for their FPGA-based Forth processor ><http://www.xs4all.nl/~lennartb/forth.html> says he "wrote it just for >the hack value". (Not forgetting that most good things in computing got >started for just their hack value.) > > --MikeArticle: 10471
We maintain a partial FAQ on programmable logic on The Programmable Logic Jump Station (http://www.optimagic.com/faq.html). We also have links to the comp.arch.fpga newsgroup and archives on our Newsgroups page at http://www.optimagic.com/newsgroups.html. Special thanks to Markus Wannemacher for pointing out the problem with links to the older comp.arch.fpga archive. ----------------------------------------------------------- Steven K. Knapp OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally" E-mail: sknapp@optimagic.com Web: http://www.optimagic.com ----------------------------------------------------------- Chris Lee wrote in message <35620D0E.786B@earthlink.net>... >I wonder if someone could point me to an archive for this newsgroup that >would contain old posts from 1990 plus or minus a couple of years. I >have had no luck with Deja News (only goes back to 1995); I can't find >an FAQ for this group, and the super.org archive that some of the web >pages point to is 404 Not Found. I would appreciate any help in finding >a comp.arch.fpga archive--thanx in advance! > >ChrisArticle: 10472
Hi, I wonder if somebody has used any ROM in the XC3000 series FPGAS..... Looking in Xilinx documentation of the UNIFIED libraries there is no such feature. Although, in their site there is a patch that provides schematic files (Viewlogic) for 16x2 and 32x1 ROMs for XC3000 along with the XNF files..... I tried to instantiate in VHDL code these XNFs and I get a PAR error in the M1.4 placement tool saying something like: F and G LUTs in the CLBMAP have 5 inputs instead of 4....and this comes from the above XNFs !!! Can anybody provide some help? Thanks in advance P.S.: Removing from the XNF file the CLBMAP section, the placement goes on normally (?) !!!Article: 10473
In article <Et568q.1zq@world.std.com>, Joseph H Allen <jhallen@world.std.com> wrote: >If I were using the XC4000 series they might be workable because of the >relatively large stack cache. But if I'm going to assume an XC4000, I might >as well assume wider memory paths, implement a MIPS or ARM clone and then >have GCC available for it. Since your original target was 5202, ie. bottom end, and having enough RAM for stack cache is now arising, the newer baby Spartan parts might fit the bill, as being in the same league, price/size-wise, but also having the on-board distributed RAM. Dunno if the toy tools available in book/CD formats include the Spartan parts as targets yet, though. FWIW, Arnim. -- Arnim Littek arnim@actrix.gen.nz Actrix Networks Ltd. fax +64-4-801-5335 uucp/PPP/SLIP/BBS accounts tel +64-4-801-5225Article: 10474
Alfredo Rosado wrote: > Hi, > I am trying to build some kind of architecture to delay a signal > (typical delay ranging from 1 to 3 useconds). I have thought of doing > it > with chained flip-flops, but if I have a fast clock signal, it will You can build a virtual shift register in the synchronous RAM of the XC4000E or XC4000XL devices, which gives you 32 bits per CLB. Or you can use a presettable synchronous counter. There are lots of ways of doing this, depending on your constraints. You will never get close to microseconds by just concatenating logic delays of a few nanoseconds each. Peter Alfke, Xilinx Applications
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