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
Foundation will run under NT4.0. To be fair though, I still think the capture tools (both the schematics and the FPGA express) are "amateurish". Both of these tools pale in comparison to professional tools such as viewlogic and mentor for schematics and synplicity and exemplar for HDL entry. Joel Kolstad wrote: > Dave Vanden Bout <devb@xess.com> wrote in message > news:38945AC9.41B6AA23@xess.com... > > As always, I will recommend our XSK-40 product which combines an XS40 FPGA > Board with the Xilinx Student Edition for around $200. > > Does this come with programming software (for the XS40 board) that works > under Windows NT or Linux yet? When I looked at it a couple of years ago, > the provided software appeared a little on the amateurish side; hopefully a > lot has changed over time. > > ---Joel Kolstad -- -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: 20201
Hi all I am trying to instantiate some RAM in a design I exported from Altera to Xilinx (of course, it's 100% VHDL). I generate the RAM aither with COREgen or as a Logiblox but I can't get a functional design in the end: everything gets trimmed. Should I include the memory .xnrf file in the design? How do I tell FPGA Express not to synthesize (or whatever) the .xnf? As I read in an App Note, I ignore the warnings saying that the memory is unlinked but I wonder if I really should... Should I specify some "dont_touch" attributes? Thanks in advance Best regards 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: 20202
Don Husby wrote: >Does the part meet your timing constraints? Almost. >Did you use the same timing analyzer for both measurements? >(IE: did you use the 9.35 analyzer to check the 9.4 compilation >or the 9.4 analyzer to check the 9.35 compliation?) The new analyzer reports just 4 more pathes with a total additional timing slack of only 23 ns (=23000 more score, what actually is peanuts). >Lucent may have just changed the way they compute the score. I think not, (because the worst time slacks in my design were very big) but the assumption about reading from a dual-port ram: http://www.lucent.com/micro/fpga/faq/orcasft/mem_del.html I must try out whether this helps. (In one of our designs we use a lot of dual-port RAMs ..) >Also note that some new paths-types were added to the analysis: >For example, 9.35 does not check paths through an open latch >(a serious flaw that I have been whining about for years.) >9.4 does (according to the release notes). It also is supposed >to handle timing between multiple clock domains differently (better). This was one of our requests long time ago. Let's see whether it is useful. >> timing slack was 2 times worse..... (then with 9.35). > >Unfortunately, the software doesn't try to optimize timing slack. >To get an optimal design, I usually rachet-up the clock speed until >it no-longer routes. For example, I try to place a 62.5 MHz design >using an 80 MHz constraint. Even if a few paths fail to meet that >constraint, the whole design runs easily at 62.5. Good idea. I will try this out. * 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: 20203
Has anyone had trouble with the Virtex DLLs locking? If so, were you able to find a workaround? Steve D.Article: 20204
In article <3895ECA5.175F9D08@wgate.com>, Steve Diferdinando <sdiferdinando@wgate.com> wrote: >Has anyone had trouble with the Virtex DLLs locking? If so, were you >able to find a workaround? > There aren't any real problems with the Virtex DLL locking. The DLLs are extremely robust, so much so that the Virtex-E family includes eight of them in every device. There are a few issues that can prevent them from locking that are noted on the solution records at the support.xilinx.com site (50 records at the current time). You haven't indicated what your DLL setup is or any symptoms that you may have, so I can't suggest any concrete items to look at. Ed McGettigan -- Xilinx Inc.Article: 20205
Let me explain the fundamental similarities and differences between a Delay-Locked Loop and a Phase-Locked Loop, ignoring frills like duty-cycle correction, frequency multiplication and division, or multiphase clock generation. Fundamentally both DLL and PLL attempt to generate an internally distributed clock signal that is in phase with the incoming clock, i.e. they virtually eliminate the clock distribution delay. The DLL uses the incoming clock edge to fire a delay ( call it a monostable) that is servo-adjusted to be the right duration, so that the DLL output coincides with the next incoming clock edge. The PLL uses a continuously running internal oscillator and servo-adjusts its frequency and phase such that the PLL output coincides with the incoming clock edge. The big difference is that an error in the DLL delay is non-cumulative, it just means that the compensation is not perfect. An error in the PLL oscillator period, however, is cumulative, getting bigger with every clock cycle. That's why a DLL can be implemented with purely digital circuitry, which inherently has a time-quantization error of up to one incremental delay step, ca. 50 picoseconds. Such an internal error is acceptable. It will slowly drift with temperature, and the phase comparator, by changing the tap setting after an appropriate "calming-down" delay, will prevent the error from exceeding one delay step. In a hypothetical fully-digital PLL, the oscillating period would be an integer multiple of stage delays, which would have an error of between 0 and ~50 ps ( one stage delay), and this error would accumulate every clock period. So the phase comparator must correct it every couple of clock cycles, before the error becomes unacceptable. This means such an all-digital PLL would have a much higher jitter frequency and probably also amplitude ( max time deviation). I doubt that anybody builds such a nervous PLL. Instead, all real PLLs adjust the frequency in an analog fashion by varying a certain filtered control voltage. In other words, the PLL has to be analog, with all the associated problems ( separate filtered Vcc and ground, noise sensitivity, poorly controlled jitter etc), while the DLL can be 100% digital with a guaranteed max jitter specification ( both jitter amplitude and jitter frequency ). The digital DLL is a much more rugged and predictable circuit than an analog PLL could ever hope to be. BTW: Wouldn't it be nice if the Altera designers ( who are known to be monitoring this newsgroup all the time ) came out and enlightened us? Maybe they have nothing good to tell. Maybe they are embarrassed. Just guessing. No guts, no glory ! Peter Alfke, Xilinx ApplicationsArticle: 20206
How does your input clock look? If there is alot of noise or jitter on it, the DLLs won't lock. Try terminating the clock lines and use a single source to single destination wiring (a low skew clock driver will probably be necessary). If the clock looks clean, then you could be getting a bunch of ground bounce. Make sure the package connections to ground are robust, and the vcc pins are properly decoupled. Also, make sure your input clock is within the capture range of the DLL. It has a minimum clock of around 25MHz. I'm sure you checked the data sheet, but it doesn't hurt to mention it (It wouldn't be the first time someone forgot to check this little detail) Steve Diferdinando wrote: > Has anyone had trouble with the Virtex DLLs locking? If so, were you > able to find a workaround? > > Steve D. -- -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: 20207
We have a tiny embedded system based on a 386, 486, or 586-compatible AMD Elan SCxxx CPU (xxx=300,400,410 or 520), along with a Xilinx Spartan XCSxx FPGA (xx=10,20,30 or 40) plus memory plus peripheral interfaces. Please reply if you have design experience with this combination, or a possible suggestion for either an OEM (designer/manufacturer) or a pure design house which might have an application. Since 1993 we have had several successes in embedded designs including vertical market handheld computers. Thank you. Clay A. Bullwinkel E.W. Bridge LLC Sent via Deja.com http://www.deja.com/ Before you buy.Article: 20208
We have a tiny embedded system based on a 386, 486, or 586-compatible AMD Elan SCxxx CPU (xxx=300,400,410 or 520), along with a Xilinx Spartan XCSxx FPGA (xx=10,20,30 or 40) plus memory plus peripheral interfaces. Please reply if you have design experience with this combination, or a possible suggestion for either an OEM (designer/manufacturer) or a pure design house which might have an application. Since 1993 we have had several successes in embedded designs including vertical market handheld computers. Thank you. Clay A. Bullwinkel E.W. Bridge LLC Sent via Deja.com http://www.deja.com/ Before you buy.Article: 20209
As usual Peter gives a nice explaination of the working of the Xilinx parts. My only difference with his discussion comes regarding digital PLLs. They are real, they are used and they can work quite nicely. It is just that they must be used in an appropriate application. For an application like the Xilinx clock distribution, digital PLLs are not appropriate. For products which need a variety of lower frequency clocks, multiplexers and demultiplexers for example, digital PLLs work very nicely. The basic structure is a DDS feeding a phase/frequency detector and an accumulator feeding back to add with the frequency set word in the DDS. All of the analog PLL equations come over directly to this and for test purposes, you can even connect a D/A to the correction signal and watch it on an oscilloscope to verify its behavior. In fact, the first one of these I implemented years ago was in a Xilinx (then 4006 no suffix). "Peter Alfke" <peter@xilinx.com> wrote in message news:389601F8.D555A140@xilinx.com... > Let me explain the fundamental similarities and differences between a Delay-Locked > Loop and a Phase-Locked Loop, ignoring frills like duty-cycle correction, frequency > multiplication and division, or multiphase clock generation. > > Fundamentally both DLL and PLL attempt to generate an internally distributed clock > signal that is in phase with the incoming clock, i.e. they virtually eliminate the > clock distribution delay. > > The DLL uses the incoming clock edge to fire a delay ( call it a monostable) that is > servo-adjusted to be the right duration, so that the DLL output coincides with the > next incoming clock edge. > > The PLL uses a continuously running internal oscillator and servo-adjusts its > frequency and phase such that the PLL output coincides with the incoming clock edge. > > The big difference is that an error in the DLL delay is non-cumulative, it just means > that the compensation is not perfect. An error in the PLL oscillator period, however, > is cumulative, getting bigger with every clock cycle. > > That's why a DLL can be implemented with purely digital circuitry, which inherently > has a time-quantization error of up to one incremental delay step, ca. 50 picoseconds. > Such an internal error is acceptable. It will slowly drift with temperature, and the > phase comparator, by changing the tap setting after an appropriate "calming-down" > delay, will prevent the error from exceeding one delay step. > > In a hypothetical fully-digital PLL, the oscillating period would be an integer > multiple of stage delays, which would have an error of between 0 and ~50 ps ( one > stage delay), and this error would accumulate every clock period. So the phase > comparator must correct it every couple of clock cycles, before the error becomes > unacceptable. This means such an all-digital PLL would have a much higher jitter > frequency and probably also amplitude ( max time deviation). > I doubt that anybody builds such a nervous PLL. Instead, all real PLLs adjust the > frequency in an analog fashion by varying a certain filtered control voltage. > In other words, the PLL has to be analog, with all the associated problems ( separate > filtered Vcc and ground, noise sensitivity, poorly controlled jitter etc), while the > DLL can be 100% digital with a guaranteed max jitter specification ( both jitter > amplitude and jitter frequency ). > The digital DLL is a much more rugged and predictable circuit than an analog PLL > could ever hope to be. > > > BTW: > Wouldn't it be nice if the Altera designers ( who are known to be monitoring > this newsgroup all the time ) came out and enlightened us? > Maybe they have nothing good to tell. Maybe they are embarrassed. > Just guessing. > No guts, no glory ! > > Peter Alfke, Xilinx Applications > > > > > > >Article: 20210
************************************************ Project VeriPage: http://www.angelfire.com/ca/verilog/ ************************************************ Project VeriPage is a free site for Verilog related information with emphasis on Verilog PLI. The site has been designed as a meeting point for newbies and gurus alike. Thanks for your continuous support to make the site a success. Recent updates include an article on "Debugging Your PLI Routine". -- =-=-= 100% pure Verilog PLI - go, get it ! =-=-= Principles of Verilog PLI -By- Swapnajit Mittra Kluwer Academic Publishers. ISBN: 0-7923-8477-6 http://www.angelfire.com/ca/verilog/ Sent via Deja.com http://www.deja.com/ Before you buy.Article: 20211
Dear Friend, LOOKING TO DO MORE WITH YOUR COMPUTER THAN JUST SEND E-MAIL? "Become an Internet Business Consultant". Let me show you step by step every avenue that you need to take in order to position yourself to be profitable on the web. There is a PROVEN method of gaining profitability on the web and I will provide you with this information. Once you finish this course, I GUARANTEE you that you will be able to bring just about ANY business to the web and "make" it make money. When you finish this course you WILL be a "professional" and "qualified" Internet Business Consultant. You will receive FULL resell rights to this course. You will be able to buy the course manuals once a month. My course manuals will introduce "other" residual income opportunities in "addition" to reselling the manuals. These manuals will consist of: 1. Web Hosting & Servers (this first manual will ALSO introduce a very lucrative monthly residual program consisting a partnership program.) 2. HTML the Easy Way (HTML is the language used to build web pages) 3. Choosing the Business You Want to Start & Building Your Site 4. Design & Graphics (completion of this manual will open up yet ANOTHER revenue stream to you) 5. Search Engine Submission and Optimization Advanced Techniques (another revenue stream). 6. Advanced HTML 7. Webvertising - The Art of Advertising on the Web (this manual will introduce yet ANOTHER revenue stream to you... that's 5 different ways you're making money already) 8. Electronic Commerce (this information alone can make you rich.... we'll show you how to sell anything you want on the web). 9. Script Programming Intro 10. Script Programming Intermediate (this manual is optional). Your first month is absolutely FREE! Return to my e-mail address with "IBC" in the subject box and I will send you the URL where you can find out more about your exciting new career in Internet Business Consulting. Let's start supporting each other and learn how to make money on the web.... The RIGHT Way!! Sincerely, Luis GomezArticle: 20212
Dear Friend, LOOKING TO DO MORE WITH YOUR COMPUTER THAN JUST SEND E-MAIL? "Become an Internet Business Consultant". Let me show you step by step every avenue that you need to take in order to position yourself to be profitable on the web. There is a PROVEN method of gaining profitability on the web and I will provide you with this information. Once you finish this course, I GUARANTEE you that you will be able to bring just about ANY business to the web and "make" it make money. When you finish this course you WILL be a "professional" and "qualified" Internet Business Consultant. You will receive FULL resell rights to this course. You will be able to buy the course manuals once a month. My course manuals will introduce "other" residual income opportunities in "addition" to reselling the manuals. These manuals will consist of: 1. Web Hosting & Servers (this first manual will ALSO introduce a very lucrative monthly residual program consisting a partnership program.) 2. HTML the Easy Way (HTML is the language used to build web pages) 3. Choosing the Business You Want to Start & Building Your Site 4. Design & Graphics (completion of this manual will open up yet ANOTHER revenue stream to you) 5. Search Engine Submission and Optimization Advanced Techniques (another revenue stream). 6. Advanced HTML 7. Webvertising - The Art of Advertising on the Web (this manual will introduce yet ANOTHER revenue stream to you... that's 5 different ways you're making money already) 8. Electronic Commerce (this information alone can make you rich.... we'll show you how to sell anything you want on the web). 9. Script Programming Intro 10. Script Programming Intermediate (this manual is optional). Your first month is absolutely FREE! Return to my e-mail address with "IBC" in the subject box and I will send you the URL where you can find out more about your exciting new career in Internet Business Consulting. Let's start supporting each other and learn how to make money on the web.... The RIGHT Way!! Sincerely, Luis GomezArticle: 20213
Hi, I'm using the tool "xdl" in the Xilinx M1 tools to get some information about the routing resources used by a circuit. Has anyone tried it ? If so, can u point me to some documentation for the tool. Specifically, about the information, the tool spits out. For example, in the follwing piece of a .xdl file, is there some documentation on what the W4,E4,S10, LEFT_E15,W_P4,etc mean ?( and where they are on the fpga ?) ? net "count_c(2)" , outpin "count_c(2)" XQ , inpin "count(2)" O , inpin "count_c(2)" F3 , pip R15C3 S0_XQ -> OUT1 , pip R15C3 OUT1 -> W4 , pip R15C2 E4 == W4 , pip R15C1 E4 == S10 , pip R16C1 N10 == W15 , pip LR16 LEFT_E15 -> LEFT_E_BUF15 , pip LR16 LEFT_E_BUF15 -> LEFT_O2 , pip R15C3 W4 -> W_P4 , pip R15C3 W_P4 -> S0_F_B3 , # net "count_c(2)" loads=2 drivers=1 pips=9 rtpips=0 advance thanks, -navaneeArticle: 20214
The Digital PLL you are talking about is quite different than the one Peter is talking about. The classic DPLL requires a clock that is many times faster than the intended output clock, the larger the difference the better the performance. Anything less than a 16x clock in a DPLL is likely to be a disaster. This classic DPLL doesn't contain an oscillator, rather it modulates the divide ratio of a fixed frequency master oscillator. The discussion we were having relates to a PLL that has an oscillator whose frequency is modulated as a function of the phase relationship of that oscillator and a reference. As Peter pointed out, there are fundamental problems with an all digital PLL of this style. This digital PLL and the classic DPLL are two very different circuits with very different applications and very different operation. doug wrote: > As usual Peter gives a nice explaination of the working of the Xilinx parts. > My only > difference with his discussion comes regarding digital PLLs. They are real, > they are > used and they can work quite nicely. It is just that they must be used in > an appropriate > application. For an application like the Xilinx clock distribution, digital > PLLs are not > appropriate. For products which need a variety of lower frequency clocks, > multiplexers > and demultiplexers for example, digital PLLs work very nicely. > The basic structure is a DDS feeding a phase/frequency detector and an > accumulator > feeding back to add with the frequency set word in the DDS. All of the > analog PLL > equations come over directly to this and for test purposes, you can even > connect a > D/A to the correction signal and watch it on an oscilloscope to verify its > behavior. > In fact, the first one of these I implemented years ago was in a Xilinx > (then 4006 no > suffix). > > "Peter Alfke" <peter@xilinx.com> wrote in message > news:389601F8.D555A140@xilinx.com... > > Let me explain the fundamental similarities and differences between a > Delay-Locked > > Loop and a Phase-Locked Loop, ignoring frills like duty-cycle correction, > frequency > > multiplication and division, or multiphase clock generation. > > > > Fundamentally both DLL and PLL attempt to generate an internally > distributed clock > > signal that is in phase with the incoming clock, i.e. they virtually > eliminate the > > clock distribution delay. > > > > The DLL uses the incoming clock edge to fire a delay ( call it a > monostable) that is > > servo-adjusted to be the right duration, so that the DLL output coincides > with the > > next incoming clock edge. > > > > The PLL uses a continuously running internal oscillator and servo-adjusts > its > > frequency and phase such that the PLL output coincides with the incoming > clock edge. > > > > The big difference is that an error in the DLL delay is non-cumulative, it > just means > > that the compensation is not perfect. An error in the PLL oscillator > period, however, > > is cumulative, getting bigger with every clock cycle. > > > > That's why a DLL can be implemented with purely digital circuitry, which > inherently > > has a time-quantization error of up to one incremental delay step, ca. 50 > picoseconds. > > Such an internal error is acceptable. It will slowly drift with > temperature, and the > > phase comparator, by changing the tap setting after an appropriate > "calming-down" > > delay, will prevent the error from exceeding one delay step. > > > > In a hypothetical fully-digital PLL, the oscillating period would be an > integer > > multiple of stage delays, which would have an error of between 0 and ~50 > ps ( one > > stage delay), and this error would accumulate every clock period. So the > phase > > comparator must correct it every couple of clock cycles, before the error > becomes > > unacceptable. This means such an all-digital PLL would have a much higher > jitter > > frequency and probably also amplitude ( max time deviation). > > I doubt that anybody builds such a nervous PLL. Instead, all real PLLs > adjust the > > frequency in an analog fashion by varying a certain filtered control > voltage. > > In other words, the PLL has to be analog, with all the associated problems > ( separate > > filtered Vcc and ground, noise sensitivity, poorly controlled jitter etc), > while the > > DLL can be 100% digital with a guaranteed max jitter specification ( both > jitter > > amplitude and jitter frequency ). > > The digital DLL is a much more rugged and predictable circuit than an > analog PLL > > could ever hope to be. > > > > > > BTW: > > Wouldn't it be nice if the Altera designers ( who are known to be > monitoring > > this newsgroup all the time ) came out and enlightened us? > > Maybe they have nothing good to tell. Maybe they are embarrassed. > > Just guessing. > > No guts, no glory ! > > > > Peter Alfke, Xilinx Applications > > > > > > > > > > > > > > -- -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: 20215
This is a multi-part message in MIME format. --------------AC073D73DDFD9D300637E1B4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Does anyone has an idea how to quiclky count number of 1's (or 0's) in a word (i.e. 8 or 24 bits). I have to implement this as a part of algorithm in FPGA. -- Regards, Pawel J. Rajda ----------------------------------------------------------------------------- Pawel J. Rajda, MSc. E.E. mail: pjrajda@uci.agh.edu.pl Dept. of Electronic Engineering www: http://galaxy.uci.agh.edu.pl/~pjrajda AGH Technical University tel: (+48-12) 617 3980 Al. Mickiewicza 30 fax: (+48-12) 633 2398 30-059 Cracow, POLAND ----------------------------------------------------------------------------- --------------AC073D73DDFD9D300637E1B4 Content-Type: text/x-vcard; charset=us-ascii; name="pjrajda.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Paweł J. Rajda Content-Disposition: attachment; filename="pjrajda.vcf" begin:vcard n:Rajda;Pawel J. x-mozilla-html:FALSE org:AGH Technical University version:2.1 email;internet:pjrajda@uci.agh.edu.pl title:M.Sc. E.E. tel;fax:+48 12 633 2398 tel;home:+48 12 634 0653 tel;work:+48 12 617 3980 adr;quoted-printable:;;Dept. of Electronics=0D=0AAl. Mickiewicza 30;Krakow;;30-059;POLAND x-mozilla-cpt:;0 fn:Rajda, Pawel J. end:vcard --------------AC073D73DDFD9D300637E1B4--Article: 20216
Hi is there any part time job that I can do via the internet I know VHDL and FPGA design and basics of verifications ThanksArticle: 20217
Ray Andraka wrote: > I've gotten most of the things I could do in schematics working in VHDL, but the code is > hard to read and a pain in the tail to debug, and it's not portable across tools (then > again, neither was schematics). Hmmm ... Ray, I think you're guilty of blasphemy! :-) Of course, we must mention that schematics are portable across humanoids. Two humanoids reading the same schematic will understand the design exactly the same. Two humanoids reading the same VHDL (or Verilog or C++ or whatever) code can not understand the design exactly the same way since they are shielded from the design (except if the design is completely structural). ** Now, about portable schematics, has any one tried to transfer schematics with EDIF? I know viewlogic has buttons for EDIF schematic import/export but I have never owned the license for that so have never tried it out. Additionally, I note that now Orcad claims to be able to read Viewlogic schematics. Has anyone tried that one out? Have a nice day, ---------------------------------------------------------------------- rk The world of space holds vast promise stellar engineering, ltd. for the service of man, and it is a stellare@erols.com.NOSPAM world we have only begun to explore. Hi-Rel Digital Systems Design -- James E. Webb, 1968 ** - Note for the HDL zealots - Yes, I use VHDL, too, a lot, but it does have it's limit. Relax, we do want to have some fun here - and HDL's are not THE solution to everything by default. :-)Article: 20218
Does anyone know of a PCI core which is the public domain. My specific needs are for a simplified target (non-master) version only. All the licensed designs I have found are full blown PCI, with associated full blown license fees. LarryArticle: 20219
Hi I've been using Foundation F1.4 for a while, using XC5215 and Spartan XCS40. I want to change to the 3.3V XCS40XL part, but my software won't support this part. Apparently, there is no upgrade path for F1.4 and I'll have to *buy* some new software. To cope with both the XC5215 and the XCS40XL parts, I'll need to spend over GBP1000 - yes, one kilopound. I already spent over GBP2000 for the F1.4 stuff, and I'm not a volume user. Why do they do this? Surely the small company user has *some* value? The support from the dealer was poor and the promised training sessions never materialised once the money was paid, so cost of support is no justification. Can anyone recommend a UK dealer who is not a shark? Cheers -- Keith WoottenArticle: 20220
Hello,
When I want to generate a macro from VHDL code (Synthesis Succesful!) I
get
following error:
'Wrong number of fields
BUS`
although synthesizing works. Anyone familiar with it?
Thanx in advance!
Steven.
Article: 20221Ray Andraka <randraka@ids.net> wrote: > I thought the point to using a DLL was to get away from the analog circuit. Speculating about the Lucent chip, I think they chose a tapped-delay DLL/PLL because it uses the best features of an analog/digital implementation. The tapped delay allows a coarse adjustment while allowing the analog part to operate with a small dynamic range. The analog can then be implemented in a standard digital process. Since it's in the feedback path, it doesn't have to be terribly linear, and it's probably just as tolerant of power and temperature fluctuations as a strictly digital DLL. Since the analog provides a fine adjustment, the digital part can have fewer taps (32), and doesn't have to spend a lot of effort on keeping individual tap delays within a tight tolerance. -- 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: 20222
In article <38940299@news.actrix.gen.nz>, "Ralph Mason" <ralphmason@geocities.com> wrote: > I have been using the Xilinx webpack to experiment with VHDL using a couple > of XL95108's and would now like move to a FPGA for larger designs. > > So far my designs have included an AVR so I am quite interested in the Atmel > FPSLIC but I don't think they're readily available yet, and I'm not sure of > what tools are available for them. > > So which I am looking for is a beginner friendly FPGA with a free or low > cost VHDL compiler and programmer. Preferably a low cost part that is easy > to obtain one or two at a time. > > Thanks for any help. Check www.kanda.com they have an Atmel FPGA sterter kit for about US$150 that includes an AT40K20 FPGA, a PCB with all kinds of LED/switches/LCD, etc. and a socket for an AVR micro. Also comes with the Atmel IDS FPGA synthesis CDROM, and an ISP cable. This might be helpful for your AVR interests as the board takes one, though the AVR chip is sold separate. Bill Toner Sent via Deja.com http://www.deja.com/ Before you buy.Article: 20223
Hi, Altera has those two functions already fully parameterizable : For the Decimating Filter see the FIR Compiler (1.1): http://www.altera.com/html/mega/m-alt-fir-1.html For the NCO see : http://www.altera.com/html/mega/m-ham-nco.html You can download those MegaCore and evaluate it for Free (Compile+Simulate) Philippe Molson In article <85kvfc$bgf$1@supernews.com>, "Philippe Robert" <PhilippeR@sundance.com> wrote: > Hi > > Does anyone know about an existing DDC (Digital Down Converter) in VHDL or > schematics for an Altera FPGA ? > A DDC is basically of a NCO, a decimator and of an FIR filter. > > Thanks. > Philippe. > > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 20224
--------------DE507EE2DF1A32A66C9BAB52 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steven, This error will occur when creating an HDL macro in Foundation when a bus is declared as a port in your HDL code, but then is entirely removed during synthesis. Solution 6539 on support.xilinx.com explains this issue. thanks, david. David Dye Xilinx Technical Marketing Boulder, Colorado Steven Sanders wrote: > Hello, > > When I want to generate a macro from VHDL code (Synthesis Succesful!) I > get following error: > > 'Wrong number of fields > BUS` > > although synthesizing works. Anyone familiar with it? > Thanx in advance! > > Steven. --------------DE507EE2DF1A32A66C9BAB52 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Steven, <p>This error will occur when creating an HDL macro in Foundation when a bus is declared as a port in your HDL code, but then is entirely removed during synthesis. <a href="http://www.xilinx.com/techdocs/6539.htm">Solution 6539</a> on <a href="http://support.xilinx.com">support.xilinx.com</a> explains this issue. <p>thanks, <br>david. <br> <p>David Dye <br>Xilinx Technical Marketing <br>Boulder, Colorado <br> <p>Steven Sanders wrote: <blockquote TYPE=CITE>Hello, <p>When I want to generate a macro from VHDL code (Synthesis Succesful!) I <br>get following error: <p> 'Wrong number of fields <br> BUS` <p>although synthesizing works. Anyone familiar with it? <br>Thanx in advance! <p>Steven.</blockquote> </html> --------------DE507EE2DF1A32A66C9BAB52--
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