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
You will have to engineer a solution! Can you use 133 with an enable for the 66MHz clock? Don't play with the PCI clock routing - it drives lots of flops in the PCI core. "Guibert, Martin" <guibert@americasm01.nt.com> wrote in message news:3A841639.A509571C@americasm01.nt.com... > Hi, > > I'm currently working on a design that has 5 clock domains (33, 66, 104, > 110 and 133) but unfortunately, only 4 global clock routing resources > are available. > > I thought about moving the 33 MHz clock to the low skew lines using the > "USELOWSKEWLINES" in the UCF file but it does not seem to work because > the mapper still report that 5 out of 4 global clock routing resources > are used. This 33MHz clock is used only in the PCI clock (32 bits, > 33MHz). I know that it's not recommended to do this but I've got > nothing to loose to try it... > > Anyone knows how to do this or has tried it? > > (the PCI_CLK input is on a GLCKIOB. Could it be why it can not be > routed on the local low skew lines? > > Thanks! > > MartinArticle: 29201
Guibert, Martin schrieb: > > Hi, > > (the PCI_CLK input is on a GLCKIOB. Could it be why it can not be > routed on the local low skew lines? Yes. -- MFG FalkArticle: 29202
Jakab, I've always found that when I need to be clear on what the tools are REALLY doing, I open the design in FPGA Editor. If have a concern regarding whether the input NODELAY attribute got used, I look at that IOB and I get my answer immediately. As far as Xilinx tech support, most of my recent calls to them have involved things like, "I've found a bug in the tool. It's repeatable. Please fix it." -andy Jakab Tanko wrote: > > I really dont't want to get into this again, but just for arguments > sake;- > If you are so sure that the software implements that > stinking attribute then why is it that the timing analyser > shows me a setup time of 9ns and why did you say > in one of your replays that , and I quote: > "I have discovered that the timing report will not give a very clear > picture > as to whether the NODELAY attribute took effect.".............. How > can that > be????. The timing analyser is not working or the attribute did not > take > effect???Which one is it? > Best regards, > jakab > > Kamal Patel wrote: > > > Since I was the engineer working on this case I would like to > > clear things up. I apologize, Jakab, for not being able to find > > out what the issue with your software was, but after verifying > > that the constraint was accepted in your design on my machine, > > I can state for sure that the Alliance tool does not refuse to > > implement this attribute. You will see the NODELAY attribute > > for the register in your MAP report as you say you did. To verify > > it was indeed implemented, you can look into the IOB in FPGA > > Editor to see if the signal is routed through a delay element or > > not. > > > > I offered you the opportunity for me to guide you through the steps, > > > > and only closed the case upon your request. I can re-open it for > > you at any time if you are not satisfied with my service. Please > > do not let our miscommunication reflect on all of Xilinx Support. > > > > Thank you for your time. > > > > Jakab Tanko wrote: > > > >> Just a note on Xilinx support;- I had a problem recently with > >> an 4000xla type device NODELAY attribute for some critical > >> inputs on my design. The problem was (and still is) that the > >> Alliance > >> tool refuses to implement this attribute; it is all good up to the > >> mapper > >> but on the next step which is the PAR, the attribute is not there > >> anymore. > >> Now, you would think that this is a pretty-strait-forward, > >> specific problem > >> that should be a no-brainer for a Xilinx application engineer.. > >> but not so fast;- after 4 days of trying to get the Xilinx support > >> to give me > >> an answer I simply gave up...It seems to me that they have a > >> two-tier system > >> where you get the top-notch support if you pay for it, but if you > >> just "another > >> customer" then you get the co-op student to solve your problems > >> and you might as well > >> try to solve them yourself, > >> But again this is just my oppinion and I could be wrong, > >> jakab > >> > >> Peter Alfke wrote: > >> > >> > serebr@my-deja.com wrote: > >> > > >> >> It's permanent trade-off: Xilinx provides instant and very high > >> >> quality > >> >> support but Altera's devices are mostly available in stock > >> >> (I mean in comparison with the Spartan-II availability). > >> >> > >> > Thanks for the friendly words about Xilinx support. > >> > And regarding availability: > >> > Please don't give all of Xilinx a black eye for the very special > >> > situation with > >> > Spartan-II. We expect that to clear up very soon. Let me tell > >> > you, there is no > >> > lack of attention on this case ! > >> > Peter Alfke > >> >Article: 29203
--------------=_4D4800C96DF00754FB78 Content-Description: filename="text1.txt" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Whether or not it uses global clock resources should depend upon how it = is described. GCLKIOB is probably putting it on global resources. Are any of the clocks synchronous to each other? Such as the 33 and=20 66MHz? You could use the 66MHz is both places and use the 33MHz as a=20= clock enable. Definitely recommended. There is a good chance of problems with clocks on paths with skew. Hope this helps. Regards, Tom Dillon Dillon Engineering, Inc. http://www.dilloneng.com >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 2/9/2001, 10:09:29 AM, "Guibert, Martin" <guibert@americasm01.nt.com>= =20 wrote regarding Low skew lines in Virtex-E: > Hi, > I'm currently working on a design that has 5 clock domains (33, 66, 10= 4, > 110 and 133) but unfortunately, only 4 global clock routing resources= > are available. > I thought about moving the 33 MHz clock to the low skew lines using th= e > "USELOWSKEWLINES" in the UCF file but it does not seem to work because= > the mapper still report that 5 out of 4 global clock routing resources= > are used. This 33MHz clock is used only in the PCI clock (32 bits, > 33MHz). I know that it's not recommended to do this but I've got > nothing to loose to try it... > Anyone knows how to do this or has tried it? > (the PCI_CLK input is on a GLCKIOB. Could it be why it can not be > routed on the local low skew lines? > Thanks! > Martin --------------=_4D4800C96DF00754FB78 Content-Description: filename="text1.html" Content-Type: text/html Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"CONTENT-TYPE" CONTENT=3D"text/html; charset=3Diso-8= 859-1"> <TITLE>Re: Low skew lines in Virtex-E</TITLE> <META NAME=3D"GENERATOR" CONTENT=3D"StarOffice/5.2 (Win32)"> <META NAME=3D"CREATED" CONTENT=3D"20010209;13064532"> <META NAME=3D"CHANGEDBY" CONTENT=3D"Tom Dillon"> <META NAME=3D"CHANGED" CONTENT=3D"20010209;13200891"> </HEAD> <BODY> <PRE>Whether or not it uses global clock resources should depend upon ho= w it is described. GCLKIOB is probably putting it on global resources. Are any of the clocks synchronous to each other? Such as the 33 and 66MHz? You could use the 66MHz is both places and use the 33MHz as a clock enable. Definitely recommended. There is a good chance of problems with clocks on paths with skew. Hope this helps. Regards, </PRE><P STYLE=3D"margin-bottom: 0in"> Tom Dillon</P> <P STYLE=3D"margin-bottom: 0in">Dillon Engineering, Inc.</P> <P STYLE=3D"margin-bottom: 0in"><A HREF=3D"http://www.dilloneng.com/">ht= tp://www.dilloneng.com</A></P> <PRE> >>>>>>>>>>>>>>>>>>= Original Message <<<<<<<<<<<<<&l= t;<<<< On 2/9/2001, 10:09:29 AM, "Guibert, Martin" <guibert@americasm01.nt.com> wrote regarding Low skew lines in Virtex-E: > Hi, > I'm currently working on a design that has 5 clock domains (33, 66,= 104, > 110 and 133) but unfortunately, only 4 global clock routing resourc= es > are available. > I thought about moving the 33 MHz clock to the low skew lines using= the > "USELOWSKEWLINES" in the UCF file but it does not seem to= work because > the mapper still report that 5 out of 4 global clock routing resources > are used. This 33MHz clock is used only in the PCI clock (32 bits,= > 33MHz). I know that it's not recommended to do this but I've got > nothing to loose to try it... > Anyone knows how to do this or has tried it? > (the PCI_CLK input is on a GLCKIOB. Could it be why it can not be= > routed on the local low skew lines? > Thanks! > Martin</PRE> </BODY> </HTML> --------------=_4D4800C96DF00754FB78--Article: 29204
Eric Smith wrote > I will be really impressed if you get them into stock at Digikey. :-) I am not so sure I can convince our marketing management that a listing in Digikey is the pinnacle of success and the ultimate sign of market acceptance. But I understand why you feel that way. I was very happy when our student's edition appeared at amazon.com Peter AlfkeArticle: 29205
--------------=_4D4800CB69310733A9F4 Content-Description: filename="text1.txt" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes it does. Tom Dillon Dillon Engineering, Inc. http://www.dilloneng.com >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 2/9/2001, 4:39:14 AM, Richard Wilkinson <richard.wilkinson@csr.com>=20= wrote regarding Synplify on Windows2000?: > Does anyone know if Synplify runs on Windows 2000? > Cheers, > Rich --------------=_4D4800CB69310733A9F4 Content-Description: filename="text1.html" Content-Type: text/html Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"CONTENT-TYPE" CONTENT=3D"text/html; charset=3Diso-8= 859-1"> <TITLE>Re: Synplify on Windows2000?</TITLE> <META NAME=3D"GENERATOR" CONTENT=3D"StarOffice/5.2 (Win32)"> <META NAME=3D"CREATED" CONTENT=3D"20010209;13323883"> <META NAME=3D"CHANGEDBY" CONTENT=3D"Tom Dillon"> <META NAME=3D"CHANGED" CONTENT=3D"20010209;13330746"> </HEAD> <BODY> <PRE>Yes it does. </PRE><P STYLE=3D"margin-bottom: 0in"> Tom Dillon</P> <P STYLE=3D"margin-bottom: 0in">Dillon Engineering, Inc.</P> <P STYLE=3D"margin-bottom: 0in"><A HREF=3D"http://www.dilloneng.com/">ht= tp://www.dilloneng.com</A></P> <PRE> >>>>>>>>>>>>>>>>>>= Original Message <<<<<<<<<<<<<&l= t;<<<< On 2/9/2001, 4:39:14 AM, Richard Wilkinson <richard.wilkinson@csr.com= > wrote regarding Synplify on Windows2000?: > Does anyone know if Synplify runs on Windows 2000? > Cheers, > Rich</PRE> </BODY> </HTML> --------------=_4D4800CB69310733A9F4--Article: 29206
--------------=_4D4800CC18C007522C18 Content-Description: filename="text1.txt" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just saw this one myself. You need to have I/O pads assigned to the=20 design prior to mapping.=20 The Xilinx tools will add them automatically if the option in enabled. Regards, Tom Dillon Dillon Engineering, Inc. http://www.dilloneng.com >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 2/6/2001, 7:48:27 AM, "JianYong Niu" <cop00jn@shef.ac.uk> wrote=20 regarding Xilinx Implementation Error! need help urgently: > I am trying to implement a simple design. An error report is as below:= > ERROR:Pack:198 - NCD was not produced. All logic was removed from desi= gn. > This is usually due to having no input or output PAD connections in t= he > design and > no nets or symbols marked as 'SAVE'. You can either add PADs or=20= 'SAVE' > attributes to the design, or run 'map -u' to disable logic trimming= in > the > mapper. > Problem encountered generating the NCD. > I have assigned all the pins in the design entry. what is wrong? --------------=_4D4800CC18C007522C18 Content-Description: filename="text1.html" Content-Type: text/html Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"CONTENT-TYPE" CONTENT=3D"text/html; charset=3Diso-8= 859-1"> <TITLE>Re: Xilinx Implementation Error! need help urgently</TITLE> <META NAME=3D"GENERATOR" CONTENT=3D"StarOffice/5.2 (Win32)"> <META NAME=3D"CREATED" CONTENT=3D"20010209;13370137"> <META NAME=3D"CHANGEDBY" CONTENT=3D"Tom Dillon"> <META NAME=3D"CHANGED" CONTENT=3D"20010209;13375690"> </HEAD> <BODY> <PRE>Just saw this one myself. You need to have I/O pads assigned to the= design prior to mapping.=20 The Xilinx tools will add them automatically if the option in enabled. Regards, </PRE><P STYLE=3D"margin-bottom: 0in"> Tom Dillon</P> <P STYLE=3D"margin-bottom: 0in">Dillon Engineering, Inc.</P> <P STYLE=3D"margin-bottom: 0in"><A HREF=3D"http://www.dilloneng.com/">ht= tp://www.dilloneng.com</A></P> <PRE> >>>>>>>>>>>>>>>>>>= Original Message <<<<<<<<<<<<<&l= t;<<<< On 2/6/2001, 7:48:27 AM, "JianYong Niu" <cop00jn@shef.ac.uk= > wrote regarding Xilinx Implementation Error! need help urgently: > I am trying to implement a simple design. An error report is as below: > ERROR:Pack:198 - NCD was not produced. All logic was removed from design. > This is usually due to having no input or output PAD connections i= n the > design and > no nets or symbols marked as 'SAVE'. You can either add PADs or= 'SAVE' > attributes to the design, or run 'map -u' to disable logic trimming in > the > mapper. > Problem encountered generating the NCD. > I have assigned all the pins in the design entry. what is wrong?</P= RE> </BODY> </HTML> --------------=_4D4800CC18C007522C18--Article: 29207
For those interested: http://www.xilinx.com/products/virtex/techtopic/vtt013.pdf Comments are appreciated, Austin serebr@my-deja.com wrote: > Look at that: http://www.altera.com/document/tb/tb70.pdf > I suppose you can find here some additional information about DLL > internal structure. > > Valeri Serebrianski. > > In article <3A789783.CD930548@gmx.de>, > Falk Brunner <Falk.Brunner@gmx.de> wrote: > > Simon Bacon schrieb: > > > > > > A clock doubler chip from ICS may be simpler for most people. > > > And it would be small and cheap. > > > > Hmmm, yes and no. My thougts are: > > > > Somewere I read that the granularity of the DLL is 40ps, because its > > absolut digital. One delay element incorporates a delay of 40ps. > > So the datasheet says the minimum frequency is 25 MHz, which has a > > period of 20ns. Hmmmm I guess the delay line consits of 1024 elements, > > but I think there are more elements for safety reason/ part to part > > variations / temperature compensation and so on. But when I see that > the > > DLL runs even on 13.2 MHz, this looks like plenty of safety. As I > said, > > I will check out the temperature dependence in a few days. > > Stay tuned folks. > > > > Hey Peter and Ken, say something. > > > > -- > > MFG > > Falk > > > > P.S. Why is the granularity in the new virtex 2 specifyed with 45 ps > > when the "old" Spartan 2 achives 40ps (I didnt measure it, just read > > about it)??? > > > > Sent via Deja.com > http://www.deja.com/Article: 29208
Thanks for a very easily understandable and good answer! :-) "Gil Golov" <golov@sony.de.REMOVE_THIS> wrote in message news:3A8418F4.2A49ADCE@sony.de.REMOVE_THIS... > Hi Philip > > The difference is in the internal architecture. > > CPLD has the more basic structure, it is build from two main matrixes, the first > is a NAND matrix that gives you products > y1=not (A*B2*d3) > y2=not(B3*C1.....) > > The second matrix gives you the sum of the products > resualt1=y1+y2+y5 and so on. It is possible to feed back the result to the NAND > matrix and so you can create any logical combination. > > FPGA is build from small units that each of them can perform a function and > every basic block is connected to a neighbor one so it gives a huge flexibility > in implementation of logical functions. > CPLD have some clock skews advantages but FPGA in normally in much larger > device. > > For your purpose: if your design is small, lets say only a few hundreds of > gates/ff, maybe you should go for a CPLD which can be cheaper than a FPGA. If > you are thinking on a large or you intend to to expend your design to a large > one in the future you should go for a FPGA. > > Serial eprom: depends on the vendor and the type, you can see FPGAs with an > internal EPROM or based on anti fuse technology. > > Basically if the device is large and fast enough, a proper synthesis tool can > take your VHDL code and implement is on a CPLD or a FPGA. > > Good lock > > Gil. > > > > PhilipKD wrote: > > > I am looking to get started with designing my own pseudo ic using fpga or > > cpld or pld or gal or...? maybe even some fift thing. > > The trouble is that i have a little problems seeing the exactl difrence > > between theese. > > At first i thought it was created in the order gal, pld, clpd and finally > > fpga, now i am not so sure. > > > > Seems like fpga reads its "code" from a serial eeprom whereas a cpld does > > from internal eeprom. This in my eyes make the cpld a bit smarter since it > > can function as an alone component, but is this the whole difrence and if so > > then why use fpga at all? > > And what is it with pld and gal? What exactly are those? Still components > > programmable by vhdl syntesis or..? > > > > My primary goal with using gate arrays is to make small and fast custom ic > > for addon units i am building for my current embeded digital elctronics. At > > first it will be nice to be able to reprogram the gate array any number of > > times till the design is done, and then it would be nice with a > > selccontained unit which is cheap but doesnt HAVE to be reprogrammable.. > > just to stuff the finished design on. > > > > What would be best suited for me there? > > > > If we look aside the difrent number of gates on the devices, can any vhdl > > design for any one of them run as well (though maybe slower) on the other > > devices? provided i have the correct synthesis tool ofcourse. > > > > I know theese are pretty basic questions, but i havent really seen any info > > on all of theese in comparison.. > > > >Article: 29209
Austin Lesea schrieb: > > For those interested: > > http://www.xilinx.com/products/virtex/techtopic/vtt013.pdf ;-))) This is getting funny. > Comments are appreciated, Hmm, what should we expect?? That Altera says the Xilinx parts are better?? And Xilinx says the Altera parts are better?? Both "experiments" have their points, but they both have the smell of marketing and influenced by company policy. Its like the Pepsi and Coca fight . . . After all, both devices must prove their qualities in real world appllication, its alwas possible to bring a good device down on the knees with a heavy test (and vica versa ;-)) -- MFG FalkArticle: 29210
Hi there, I started with A Verilog Primer by J. Bhasker (2nd edition). I think it's a good intro book b/c it has a lot of examples and a very helpful index for referencing... In article <3A83C30C.267B0B97@sun52a.desy.de>, Arthur Agababyan <arthura@sun52a.desy.de> wrote: > I am interested in learning the Verilog language. > > Could someone advise me a good book on Verilog like > > the one of Ashenden on VHDL? > > Thank you. > > -- > Arthur Aghababyan > DESY, MVP > Notkestrasse 85 > 22607 Hamburg > Germany > > e-mail: arthura@sun52a.desy.de > tel: +49 40 8998 4554 > fax: +49 40 8998 4448 > > Sent via Deja.com http://www.deja.com/Article: 29211
"Eddy Sambuaga" <esambuaga@yahoo.com> wrote in message news:ee6fa65.-1@WebX.sUN8CHnE... > BITGEN: Xilinx Bitstream Generator M1.5.19 > Copyright (c) 1995-1998 Xilinx, Inc. All rights reserved. I believe your version of bitgen is too old. Time to upgrade! Cheers, JamieArticle: 29212
"Guibert, Martin" <guibert@americasm01.nt.com> wrote in message news:3A841639.A509571C@americasm01.nt.com... > Hi, > > I'm currently working on a design that has 5 clock domains (33, 66, 104, > 110 and 133) but unfortunately, only 4 global clock routing resources > are available. > > I thought about moving the 33 MHz clock to the low skew lines using the > "USELOWSKEWLINES" in the UCF file but it does not seem to work because > the mapper still report that 5 out of 4 global clock routing resources > are used. This 33MHz clock is used only in the PCI clock (32 bits, > 33MHz). I know that it's not recommended to do this but I've got > nothing to loose to try it... > > Anyone knows how to do this or has tried it? > > (the PCI_CLK input is on a GLCKIOB. Could it be why it can not be > routed on the local low skew lines? > > Thanks! > > Martin Your synthesis tool may allow you to constrain specific clock lines away from the global clocks. For example, Synplify has "syn_noclockbuf". If you have more questions, come see me. We're in the same building... ;) Unless you've designed your own PCI solution, it's unlikely to be supported in a non-global clock configuration. It may be possible to put one of the other clocks on secondary routing, especially if the pin-out is still not defined. Cheers, JamieArticle: 29213
> > I will be really impressed if you get them into stock at Digikey. :-) > I am not so sure I can convince our marketing management that a listing in > Digikey is the pinnacle of success and the ultimate sign of market acceptance. Nothing magic about Digikey in particular. The key idea is low volume, reasonable delivery times, and a place that's easy to do business with (as in credit card over the phone). "stock at Digikey" meets those requirements. -- These are my opinions, not necessarily my employers. I hate spam.Article: 29214
If I remember right, I was the one coming up with the idea of self-initiated reconfiguration. I see no reason why this should be any different in Virtex. The idea is that the internal logic creates a Low output on Progr ( if necessary through a pc-board connection ). The paranoid pessimist might say that we cannot guarantee to maintain that Low long enough, but the realist knows that there is a causal relationship between the new configuration having started and the output losing its drive. Once started, the configuration will just go on. So it has to work because of this, to hell with the spec. Peter Alfke, Xilinx Applications ======================================= Kons Henrik Bohre wrote: > Record 4296 in the Answer Database states that newer devices after the > 4000 series > are not able to control their own reconfiguration due to other > requirements on the > PROGRAM pin. > > However, the Virtex series conforms to the 300 ns requirement on the > PROGRAM pin, > so does anyone know if it is possible to safely initiate a > reconfiguration by > pulling the PROGRAM pin low with its own logic? > > Best Regards, > /Henrik BohreArticle: 29215
I wrote (about Spartan II parts): > I will be really impressed if you get them into stock at Digikey. :-) Peter Alfke <peter.alfke@xilinx.com> writes: > I am not so sure I can convince our marketing management that a > listing in Digikey is the pinnacle of success and the ultimate sign of > market acceptance. Well, you already have the 4000 and 5200 series parts there. I'd think the Sparatan II parts would much better appeal to Digikey's clientele. Or you could add support for the 4000 series to Webpack ISE. Somehow I suspect getting SII parts there would be easier. Any chance of Webpack ISE supporting the smaller VII parts? And will JBits support VII parts? The applications I have for VII all require partial reconfiguration in-circuit, and AFAIK JBits is the only way Xilinx supports doing that. EricArticle: 29216
On Wed, 07 Feb 2001 17:35:44 GMT, p25486@my-deja.com wrote: <snip> >Renoir, is a graphical environment. So the source files in which you >work are not all text, but contain some Mentor proprietary crap-o- Not strictly true. You can manage a completely text-based (single or multiple file for entity/architecture) design within Renoir. >lium. I thought the whole point of VHDL and Verilog was that you could >use any dumb text editor to view or edit a design. This Renoir thing >seems to be taking that away. When originally concieved, that is true, the emphasis was on graphical capture because for the 90% of (non-rocket-scientist) users out there it was the most manageable approach. However in response to demand from HDL "purists", the ability to write structural HDL in text and maintain hierarchy down through those text files for automated compilation to the various downstream tools was introduced recently in Version 2000. The latest version is 2000.04 which is the version needed to have the automated GUI extension of Spectrum 2000.1b. >The Mentor people I've talked to say that is not so. True, that a VHDL >only version of the code is saved, but you can't directly edit it from >within Renoir. If you have multiple views (architectures) then the output HDL that is generated is an assembly of the correct entity and view for downstream compilation. Because they are generated from the views, they are opened read-only by default from the HDL window of Renoir. However, as your source can now be pure text HDL, then there is no longer an issue here I think. >So here's the question. What's the best way to approach using this >tool (assuming that I have to stay Mentor because it's free to me)? Go on the appropriate training course with Mentor, or perhaps try the tutorial. Failing that, ask for some methodology training to be tailored for your entire design group from the appropriate Renoir TME. I'm sure they will be happy to help you use the tool more effectively. >1. Use some other tool, emacs, or the foundation stuff for the HDL >entry, then import the design to Renoir. Glue your favourite editor straight into Renoir. >2. Use some other tool emacs, or the foundation stuff for the HDL, and >go directly to ModelSim and then on to Leonardo Spectrum (I haven't >attempted this, any pitfalls?). That's basically taking Renoir out of the flow. You would be missing the design management capabilities of Renoir and compromising the ability of your colleagues to cooperatively work with your design as part of a project. The documentation and re-use of your design would likely be a lot harder for those within your organisation using Renoir. Sure it adds a little overhead, but once you understand "how" it all works, you'll find Renoir quite useful I suspect. >3. Use some nifty option in Renoir that I don't know about. The all-text approach sounds like what you want at the moment. Cheers Stuart For Email remove "NOSPAM" from the addressArticle: 29217
This is a multi-part message in MIME format. --------------745AE6D95FCF47BD7DBA3836 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Christian Plessl wrote: > Hi Brian > > Thanks for this useful tip! I think this might the soulution to my > problem. > > >Most likely, you will have to hand create this structure as I am not sure > >if any synthesis tools currently infer this structure. Maybe in the near > >future though... > > So how do think such a design could be implemented, if the design > tools cannot infere it? Im using Xilinx Foundation 3.1i, the design is > coded in VHDL. Somehow I would need complete acces to the FPGA > elements, such as LUTs and carry chains. Exactly. You do have complete access to the LUTs and Carry-chain via structural instantiation. You can instantiate virvtually any device primitive for a brute-force method to get the tools to create the structure you so desire. > Is there a way to acces these directly? From the Xilinx Library Guide > I've seen, that components ADD16 and OR16 work exactly like this, but > since these are marcos I cannot extend them to my needs. Components like ADD16 and OR16 are macros and generally should not be used in HDL design. Whenever possible, infer the logic to create your design. This will generally result in the most efficient, portable, synthesis and simulation friendly code. However, sometimes you simply can't get what you want from inferrance so you build it by instantiating primitives. You will see the libraries guide will differentiate primitives from macros. To help you out, I created a small piece of VHDL to show you what I mean. The code shows how to create a 32-input AND gate using the carry chain. It can easily be expaned to accomodate more inputs. You can modify the code to best suit your needs, this is just an example. I used XST for the synthesis tool so some changes maybe necessary depending on your synthesis tool you use. The code is attached (and is not binary). Big_and is the top level. Good Luck, -- Brian > > > Chris --------------745AE6D95FCF47BD7DBA3836 Content-Type: application/x-unknown-content-type-vhd_auto_file; name="carry_and.vhd" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="carry_and.vhd" bGlicmFyeSBJRUVFOw0KdXNlIElFRUUuU1REX0xPR0lDXzExNjQuQUxMOw0KdXNlIElFRUUu U1REX0xPR0lDX0FSSVRILkFMTDsNCnVzZSBJRUVFLlNURF9MT0dJQ19VTlNJR05FRC5BTEw7 DQoNCi0tIHN5bm9wc3lzIHRyYW5zbGF0ZV9vZmYNCmxpYnJhcnkgVU5JU0lNOw0KdXNlIHVu aXNpbS5WY29tcG9uZW50cy5hbGw7DQotLSBzeW5vcHN5cyB0cmFuc2xhdGVfb24NCg0KZW50 aXR5IGNhcnJ5X2FuZCBpcw0KICAgIFBvcnQgKCBBbmRfaW4gOiBpbiBzdGRfbG9naWNfdmVj dG9yKDMgZG93bnRvIDApOw0KICAgICAgICAgICBDYXJyeV9pbiA6IGluIHN0ZF9sb2dpYzsN CiAgICAgICAgICAgQ2Fycnlfb3V0IDogb3V0IHN0ZF9sb2dpYyk7DQplbmQgY2FycnlfYW5k Ow0KDQphcmNoaXRlY3R1cmUgYmVoYXZpb3JhbCBvZiBjYXJyeV9hbmQgaXMNCg0KLS0gMi10 by0xIE11bHRpcGxleGVyIGZvciBDYXJyeSBMb2dpYyB3aXRoIEdlbmVyYWwgT3V0cHV0DQoN CmNvbXBvbmVudCBNVVhDWQ0KICBwb3J0ICgNCiAgICBESSA6IGluIHN0ZF9sb2dpYzsNCiAg ICBDSSA6IGluIHN0ZF9sb2dpYzsNCiAgICBTIDogaW4gc3RkX2xvZ2ljOw0KICAgIE8gOiBv dXQgc3RkX2xvZ2ljDQogICk7DQplbmQgY29tcG9uZW50Ow0KDQotLTQtQml0IExvb2stVXAt VGFibGUgd2l0aCBHZW5lcmFsIE91dHB1dA0KIA0KY29tcG9uZW50IExVVDQNCi0tIHN5bm9w c3lzIHRyYW5zbGF0ZV9vZmYNCiAgZ2VuZXJpYyAoSU5JVCA6IGJpdF92ZWN0b3IgOj0geCI4 MDAwIik7DQotLSBzeW5vcHN5cyB0cmFuc2xhdGVfb24NCiAgcG9ydCAoDQogICAgSTAgOiBp biBzdGRfbG9naWM7DQogICAgSTEgOiBpbiBzdGRfbG9naWM7DQogICAgSTIgOiBpbiBzdGRf bG9naWM7DQogICAgSTMgOiBpbiBzdGRfbG9naWM7DQogICAgTyA6IG91dCBzdGRfbG9naWMN CiAgKTsNCmVuZCBjb21wb25lbnQ7DQoNCnNpZ25hbCBMVVRfT1VUOiBzdGRfbG9naWM7DQoN CmF0dHJpYnV0ZSBJTklUOiBzdHJpbmc7DQphdHRyaWJ1dGUgSU5JVCBvZiBMVVRfSU5TVDog bGFiZWwgaXMgIjgwMDAiOw0KIA0KYmVnaW4NCg0KTFVUX0lOU1Q6IExVVDQgcG9ydCBtYXAg KEkwPT5BbmRfaW4oMCksIEkxPT5BbmRfaW4oMSksIEkyPT5BbmRfaW4oMiksDQogICAgICAg ICAgICAgICAgICAgICAgICAgSTM9PkFuZF9pbigzKSwgTz0+TFVUX09VVCk7DQoNCk1VWENZ X0lOU1Q6IE1VWENZIHBvcnQgbWFwIChEST0+JzAnLCBDST0+Q2FycnlfaW4sIFM9PkxVVF9P VVQsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgTz0+Q2Fycnlfb3V0KTsNCg0KDQpl bmQgYmVoYXZpb3JhbDsNCg== --------------745AE6D95FCF47BD7DBA3836 Content-Type: application/x-unknown-content-type-vhd_auto_file; name="big_and.vhd" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="big_and.vhd" bGlicmFyeSBJRUVFOw0KdXNlIElFRUUuU1REX0xPR0lDXzExNjQuQUxMOw0KdXNlIElFRUUu U1REX0xPR0lDX0FSSVRILkFMTDsNCnVzZSBJRUVFLlNURF9MT0dJQ19VTlNJR05FRC5BTEw7 DQoNCi0tIHN5bm9wc3lzIHRyYW5zbGF0ZV9vZmYNCmxpYnJhcnkgVU5JU0lNOw0KdXNlIHVu aXNpbS5WY29tcG9uZW50cy5hbGw7DQotLSBzeW5vcHN5cyB0cmFuc2xhdGVfb24NCg0KZW50 aXR5IGJpZ19hbmQgaXMNCiAgICBQb3J0ICggQW5kX2luIDogaW4gc3RkX2xvZ2ljX3ZlY3Rv cigzMSBkb3dudG8gMCk7DQogICAgICAgICAgIEFuZF9vdXQgOiBvdXQgc3RkX2xvZ2ljKTsN CmVuZCBiaWdfYW5kOw0KDQphcmNoaXRlY3R1cmUgYmVoYXZpb3JhbCBvZiBiaWdfYW5kIGlz DQoNCiAgY29tcG9uZW50IGNhcnJ5X2FuZA0KICAgIHBvcnQgKA0KICAgICAgQW5kX2luIDog aW4gc3RkX2xvZ2ljX3ZlY3RvcigzIGRvd250byAwKTsNCiAgICAgIGNhcnJ5X2luIDogaW4g c3RkX2xvZ2ljOw0KICAgICAgY2Fycnlfb3V0IDogb3V0IHN0ZF9sb2dpYw0KICAgICk7DQog IGVuZCBjb21wb25lbnQ7DQoNCiAgY29tcG9uZW50IFhPUkNZDQogICAgcG9ydCAoDQogICAg ICBMSSA6IGluIHN0ZF9sb2dpYzsNCiAgCSAgIENJIDogaW4gc3RkX2xvZ2ljOw0KICAJICAg TyA6IG91dCBzdGRfbG9naWMNCiAgICAgICk7DQogIGVuZCBjb21wb25lbnQ7DQoNCiAgc2ln bmFsIENBUlJZOiBzdGRfbG9naWNfdmVjdG9yKDggZG93bnRvIDApOw0KDQogIHNpZ25hbCB6 ZXJvOiBzdGRfbG9naWM7DQoNCg0KYmVnaW4NCg0KICAgQU5EX0dFTjoNCiAgICAgZm9yIEkg aW4gMCB0byA3IGdlbmVyYXRlDQogICAgICAgIENBUlJZX0FORF9JTlNUOiBjYXJyeV9hbmQg cG9ydCBtYXAoQW5kX2luPT5BbmRfaW4oKEkqNCszKSBkb3dudG8gKEkqNCkpLCANCgkJICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNhcnJ5X2luPT5DQVJSWShJKSwg Y2Fycnlfb3V0PT5DQVJSWShJKzEpKTsNCiAgICAgZW5kIGdlbmVyYXRlOw0KDQogICAtLSAg QnkgQWRkaW5nIGEgcmVkdW5kYW50IFhPUkNZIGdlbmVyYWxseSBnaXZlcyBhY2Nlc3MgdG8g ZmFzdGVyIHJvdXRpbmcgdGhhbg0KCS0tICBleGl0aW5nIHRoZSBjYXJyeSBjaGFpbg0KDQoJ WE9SQ1lfSU5TVCA6IFhPUkNZIHBvcnQgbWFwIChMST0+JzAnLCBDST0+Q0FSUlkoOCksIE89 PkFuZF9vdXQpOw0KICAJDQoJLS0gIFRoaXMgaXMgdXNlZCB0byBpbml0aWFsaXplIHRoZSBj YXJyeSBjaGFpbg0KDQogICBDQVJSWSgwKSA8PSAnMSc7DQoNCmVuZCBiZWhhdmlvcmFsOw0K DQo= --------------745AE6D95FCF47BD7DBA3836 Content-Type: text/x-vcard; charset=us-ascii; name="brian.philofsky.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Brian Philofsky Content-Disposition: attachment; filename="brian.philofsky.vcf" begin:vcard n:Philofsky;Brian tel;work:1-800-255-7778 x-mozilla-html:TRUE url:http://www.xilinx.com org:Xilinx, Inc.;Software Marketing adr:;;2300 55th Street;Boulder;CO;80301;USA version:2.1 email;internet:brianp@xilinx.com title:Sr. Technical Marketing Engineer fn:Brian Philofsky end:vcard --------------745AE6D95FCF47BD7DBA3836--Article: 29218
Here is a good link for you to learn the basics: http://www.chipcenter.com/circuitcellar/november99/c119lr1.htm PhilipKD wrote: > I am looking to get started with designing my own pseudo ic using fpga or > cpld or pld or gal or...? maybe even some fift thing. > The trouble is that i have a little problems seeing the exactl difrence > between theese. > At first i thought it was created in the order gal, pld, clpd and finally > fpga, now i am not so sure. > > Seems like fpga reads its "code" from a serial eeprom whereas a cpld does > from internal eeprom. This in my eyes make the cpld a bit smarter since it > can function as an alone component, but is this the whole difrence and if so > then why use fpga at all? > And what is it with pld and gal? What exactly are those? Still components > programmable by vhdl syntesis or..? > > My primary goal with using gate arrays is to make small and fast custom ic > for addon units i am building for my current embeded digital elctronics. At > first it will be nice to be able to reprogram the gate array any number of > times till the design is done, and then it would be nice with a > selccontained unit which is cheap but doesnt HAVE to be reprogrammable.. > just to stuff the finished design on. > > What would be best suited for me there? > > If we look aside the difrent number of gates on the devices, can any vhdl > design for any one of them run as well (though maybe slower) on the other > devices? provided i have the correct synthesis tool ofcourse. > > I know theese are pretty basic questions, but i havent really seen any info > on all of theese in comparison..Article: 29219
Hi Jorge, If you have an XC4010E device in an 84 pin PLCC package (ie. an XC4010E-PC84) then the Burch Electronic Designs BED-XILINX-BASE+ FPGA Prototyping Kit may be what you are looking for: http://www.burched.com.au/bedxilinxbase.html It is very low cost at about US$60. It comes with an XCS05 device, but an XC4010E-PC84 will drop straight into the socket on this board. We have stocks of BED-XILINX-BASE+, and international orders are very welcome. Best regards Tony Burch www.BurchED.com.au Lowest cost, easiest-to-use FPGA prototyping kits! "Jorge Neves" <jorge.correio@netc.pt> wrote in message news:3a82b99f@212.18.160.197... > Hi! I have woked with Xilinx XC4010E and wish to get a development kit, > for prototyping, but i dont seem to find one at afair price! If you can > help-me ? thank you! > >Article: 29220
I am also learning Verilog and have bought several books good and bad. I recommend 'Verilog Quickstart by James Lee'. James teaches verilog partime at UCSC and currently I'm attending his class and he is quite knowledgeable on the topic. In article <3A83C30C.267B0B97@sun52a.desy.de>, Arthur Agababyan <arthura@sun52a.desy.de> wrote: > I am interested in learning the Verilog language. > > Could someone advise me a good book on Verilog like > > the one of Ashenden on VHDL? > > Thank you. > > -- > Arthur Aghababyan > DESY, MVP > Notkestrasse 85 > 22607 Hamburg > Germany > > e-mail: arthura@sun52a.desy.de > tel: +49 40 8998 4554 > fax: +49 40 8998 4448 > > Sent via Deja.com http://www.deja.com/Article: 29221
Andy Peters wrote: > Brian, > > Oh, wait, now I remember. They were the 740 and the 780 series parts? > Named after Volvos. Interesting. > Don't be so sarcastic about these parts. They - Intel - had the idea of ISP through the JTAG port before anyone else was even thinking about ISP. We used them for quite a while after they came out [I saw them at a trade show & was immediately & unusually, given my normal cynisism, impressed] before, giving up on ever seeing any MAX 7K devices with ISP, we went XC95K. The Flex devices had 2 other advantages: (1) The fitter was incredibly efficient considering the meager resources it had to work with. It even ran fairly quickly on an i486-66. (2) The tools could produce a raw JTAG file i.e. a file consisting of a series of TDI/TMS pairs. This allowed us to hold the configuration in a socketed EPROM - great for customer upgrades.Article: 29222
Has anyone implemented a PID servo motion controller in VHDL? If so, is there any code or documentation that I can look at? Thanks in advance, EKC alpha3.1 AT ix DOT netcom DOT comArticle: 29223
Christian Plessl wrote: > So how do think such a design could be implemented, if the design > tools cannot infere it? Im using Xilinx Foundation 3.1i, the design is > coded in VHDL. Somehow I would need complete acces to the FPGA > elements, such as LUTs and carry chains. Carry chain can be infered by synthesis tools, however the code may not be highly readable. For example, to create an OR gate: OR_temp <= '0' & A & B & C & D & E; Result_temp = OR_temp + "011111" Result = Result_temp(5); -- result is zero unless (A or B or C or D or E) = 1 I'd suggest using a proceedure to improve readability. Biggest gain in speed is from using the carry chain for priority encoders, large AND and OR gates gain some. -- Phil HaysArticle: 29224
This is a good basic article ( and I am notoriously critical of anybody else's tutorials :-) Minor flaws: The author describes antifuse circuits as if they used fuses ( they really make a connection, not break it ) and he fails to mention the enormous difference in flip-flop count between CPLDs and FPGAs: CPLDs have from 32 or 36 to <300 flip-flops, while FPGAs nowadays start at a couple of hundred and end above 50,000 flip-flops. So that is a dramatic difference. The speed difference has disapeared, FPGAs are now as fast as CPLDs, even for simple functions. But, fundamentally, a good introductory story. Peter Alfke, Xilinx Applications ======================================== Kraig Lund wrote: > Here is a good link for you to learn the basics: > http://www.chipcenter.com/circuitcellar/november99/c119lr1.htm > > P
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