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
Followup to: <833030c0.0305271031.2399781e@posting.google.com> By author: tom1@launchbird.com (Tom Hawkins) In newsgroup: comp.arch.fpga > > I don't classify an FPGA's configuration bitstream as software > because the bitstream is not a Turing Complete language. > > Verilog, VHDL, Confluence, etc., are complete languages. But > synthesis translates these languages into a language that is > not complete. This differs significantly from software compilation; > the resulting assembly/machine code is still a Turing complete > language. > > Of course, as you alluded to, once an FPGA can perform "self" > reconfiguration, this changes everything. > Pardon me, but this is poppycock. Since you can synthesize a CPU as well as memory, etc, in an FPGA, and supply that CPU with a program, your FPGA is at least as Turing-complete as a CPU. Before anyone says "simulation doesn't count": proof of Turing-completeness are almost always of the form "A can simulate B". From a theoretical perspective, there is no such thing as a Turing-complete device, since one of the attributes of a Turing machine is infinite storage; hence my "at least as..." above. Personally, I refer to an FPGA configuration stream as firmware. It walks like firmware and quacks like firmware... -hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64Article: 56176
Peter Alfke wrote: > > Marc Randolph wrote: > >>Howdy Peter, >> >>This might be more effort than you had in mind, but we've had a need >>several times for an asymetric async FIFO... 8 bits in @ 155 MHz, 32 >>bits out @ 50 MHz. And the reverse of course. While I'm dreaming, we >>could use them in both BRAM and LUT RAM form. > > > Expect it this fall, but probably only in BRAM form. > The problem is that 1, 2 or 3 eight-bit words might get left stuck in > the FIFO when it declares itself empty, because there is no more 32-bit > word to be read. :-) Couldn't people just do this as a front end to a "vanilla" 32 bit wide FIFO? JohnArticle: 56177
"Peter Alfke" <peter@xilinx.com> wrote in message news:3ED67E37.5C9FC432@xilinx.com... > Undoubtably there might be a market for what you describe, but it would > be for single-chip applications, where cost is secondary, and > performance does not count. We think that this too small a market for us > to engage in. It might be an bigger marker than one thinks, a given vendor could sell their own application specific chips with very little in the way of startup costs. Then xilinx lowers the bar on being a fabless chip vendor. Imagine 100k - 500k gates in in a package with flash, the possibilities are endless for replacing other vendors chips. One and 2 man bands can start selling pre configured FPGA easily and quickly. It could spawn a nice little industry, that I don't believe is feasible with external configuration. The stacking Idea sounds pretty nice, like the p-pro was but one expects easier to manufacture and smaller in size. Or perhaps a new flash technology will come about that can be build on the latest processes. We can all dream. RalphArticle: 56178
"H. Peter Anvin" wrote: > You're forgetting one: yield. Because an antifuse FPGA is OTP, no > testing done at the factory can guarantee that every device will > program correctly. I don't know that the fallout percentage is > nowadays -- for all I know it might be negible -- but still.. I wanted to stay away from unsubstantiable mudslinging, especially considering my biased background. There are plenty more issues, but I consider them subtle... In a way, the marketplace has voted, and relegated Antifuse devices into specific application areas, where their advantages are being appreciated. Good for them, it keeps them focused. Better than slugging it out in the general market, with the likes of X and A. Peter AlfkeArticle: 56179
I've used Antifuse (Actel) devices in 5 different designs and couldn't be happier. Yes, debugging a design is tougher, but maybe I've just been lucky having to do very, very few "redos". However, I must admit that these designs have been fairly straight forward. The more complicated the design, the more likely it is to have to go back to the drawing board. BTW, the "instant on" is a very big plus in my opinion. -- Greg readgc.invalid@hotmail.com.invalid (Remove the '.invalid' twice to send Email) "Peter Alfke" <peter@xilinx.com> wrote in message news:3ED68A3B.3928AC70@xilinx.com... > > > "H. Peter Anvin" wrote: > > > You're forgetting one: yield. Because an antifuse FPGA is OTP, no > > testing done at the factory can guarantee that every device will > > program correctly. I don't know that the fallout percentage is > > nowadays -- for all I know it might be negible -- but still.. > > I wanted to stay away from unsubstantiable mudslinging, especially > considering my biased background. There are plenty more issues, but I > consider them subtle... > > In a way, the marketplace has voted, and relegated Antifuse devices into > specific application areas, where their advantages are being > appreciated. Good for them, it keeps them focused. Better than slugging > it out in the general market, with the likes of X and A. > > Peter AlfkeArticle: 56180
rickman <spamgoeshere4@yahoo.com> wrote in message > > I think you hit on the main differences. But I am not clear on what you > mean by "sacrificed". Both anti-fuse and SRAM based devices have > separate RAM blocks. The Xilinx SRAM based devices can use the RAM > based LUTs as small blocks of RAM as well. On the other hand, I believe > that you can create FFs (RAM) from logic in the anti-fuse parts. So if > you have enough logic cells you can make RAM. In anti-fuse parts where RAM is not available, there will be more SC cells. But the SC cells in SRAM-based parts are less because of RAM compare to anti-fuse parts which have the same amount of system gates. > > Otherwise the differences are in the debugging stage. The anti-fuse > parts require that you have a way to remove devices in order to change > your program and SRAM parts can be changed by reprogramming over a > cable. Yes, this is the trade-off. I have to make a good decision. > > Also, don't forget Flash based parts which combine many of the features > of both. Lattice has some XPLD and xFPGAs both using Flash *and* SRAM. > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 56181
Ditto on what Austin & Peter said with respect to the trade-offs of using an EEPROM/Flash process. BTW, Lattice has their ispXP series of devices (ispXPGA and ispXPLD) that appear to integrate EEPROM memories for configuration. - Paul "Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com> wrote in message news:TBtBa.35461$3t6.555738@news.xtra.co.nz... > I don't know much about Semiconductor processes. But I wonder why it isn't > possible to make FPGA's with some flash memory in there, enough to hold 2x > the bit streams for the FPGA. A little Flash boot section (like CPLDS') of > FPGA could be used to configure the rest of the FPGA from the Embedded > flash. > > This means you can self configure with a protected bitstream, you can use > the flash in your application if you like, etc etc. It also gives you NV > ram in the FPGA which just can't be a bad thing. > > Seems like a simple idea - and a nice setup, is there a big technical > barrier to such a setup? Is it comming? Should I have pateneted it? Are > there already some out there? > > Ralph > >Article: 56182
Wong wrote: > > > In anti-fuse parts where RAM is not available, there will be more SC > cells. But the SC cells in SRAM-based parts are less because of RAM > compare to anti-fuse parts which have the same amount of system gates. > This can get unreasonably confusing. Just compare the two device types on the basis of available user logic. Yes, SRAM-based FPGAs have lots of config storage cells, but you as a user should ignore that. These cells are a necessity that the FPGA has to pay for by more efficient layout of its logic circuits ( and it does that quite well). What finally counts is cost per function, and also performance. And some more subtle things like ease of use, software, reconfigurability etc. Peter AlfkeArticle: 56183
Peter: For easy pipelining of data it is nice to have the first word in the FIFO automatically read and presented onto the DOUT outputs. EMPTY would go low after the data is available at DOUT. RD_EN would get the next word from the FIFO. Control would look like this. next_stage_enable = ~EMPTY & flow_enable; RD_EN = next_stage_enable; Thanks Dan "Peter Alfke" <peter@xilinx.com> wrote in message news:3ED51C5D.3B8A1565@xilinx.com... > I am looking at revamping the FIFO cores, giving you many options: > asynchr. vs synchronous, with exact empty and full > extra one-clock-early empty and full indicators > programmable almost empty and full indicators, > readable occupied size , > etc > Any additional suggestions? > > Peter Alfke, Xilinx > ================ > Ralph Mason wrote: > > > > "Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com> wrote > > in message news:IhXAa.32629$3t6.476804@news.xtra.co.nz... > > > "Muthu" <muthu_nano@yahoo.co.in> wrote in message > > > news:28c66cd3.0305272041.4361c105@posting.google.com... > > > > Hi, > > > > > > > > With an N depth RAM, I could build a FIFO of depth N. Right? > > > > > > > > But this may not be true with asynchrnous FIFO. some where i heard > > > > that, for asynchrnous FIFO 1 location is wasted. why? and How? > > > > > > > > In general all the Circular FIFO documents also, saying that only N-1 > > > > depth is possible with N location RAM.? why? > > > > > > > > Thanks in advance > > > > > > > > Regards, > > > > Muthu > > > > > > You can never fill the FIFO to N because then the write pointer and the > > read > > > pointer would be equal and it would look like the fifo was empty. > > > > Never say never unless you mean it. > > > > Anyway as many have pointed out, you can design anything any way you like. > > > > Why did I say never - well for one fifo space is it worth the extra > > complexity? Are there implementations that would use the same resources to > > use all the ram and the above? Are there just plain better implementations? > > > > Ralph -----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 80,000 Newsgroups - 16 Different Servers! =-----Article: 56184
Ralph Mason wrote: > > I don't know much about Semiconductor processes. But I wonder why it isn't > possible to make FPGA's with some flash memory in there, enough to hold 2x > the bit streams for the FPGA. A little Flash boot section (like CPLDS') of > FPGA could be used to configure the rest of the FPGA from the Embedded > flash. > > This means you can self configure with a protected bitstream, you can use > the flash in your application if you like, etc etc. It also gives you NV > ram in the FPGA which just can't be a bad thing. > > Seems like a simple idea - and a nice setup, is there a big technical > barrier to such a setup? Is it comming? Should I have pateneted it? Are > there already some out there? > > Ralph The SRAM FPGA vendors will tell you that it is a big problem, but that is because they want to make the largest possible chips using the latest process technology. But Lattice is selling exactly what you are asking about, SRAM FPGAs and PLDs which are loaded from internal Flash on power up. You don't get 2x configurations, but you get one in the Flash and you can have as many as you want in a processor or external Flash which can be loaded into the SRAM by the initial design or by external trigger. This is what we are using in place of a Coolrunner part. The xPLD parts are pretty low power too, not uA, but low mA. IIRC, Altera also has some dual die parts which load the SRAM FPGA from the Flash part on power up. This has the advantage of both approaches. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 56185
Ralph Mason wrote: > > I don't know much about Semiconductor processes. But I wonder why it isn't > possible to make FPGA's with some flash memory in there, enough to hold 2x > the bit streams for the FPGA. A little Flash boot section (like CPLDS') of > FPGA could be used to configure the rest of the FPGA from the Embedded > flash. > > This means you can self configure with a protected bitstream, you can use > the flash in your application if you like, etc etc. It also gives you NV > ram in the FPGA which just can't be a bad thing. > > Seems like a simple idea - and a nice setup, is there a big technical > barrier to such a setup? Is it comming? Should I have pateneted it? Are > there already some out there? I also forgot to mention, anytime a vendor talks about how process or technology factors into price, take it with a grain of salt. If you are concerned about price, then talk price. Let the price speak for itself. I have seen more than one vendor bash another's technology based on how it "must affect price". But the other vendor sets his own prices and I often see them "overcome" the barrier of their technology to match or even beat price. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 56186
Jim Granville wrote: > > Hal Murray wrote: > > > > >If it doesn't have an assember.... > > > > >Then it is a pain. If it has an assembler OR it has a c compiler, then > > >it is really much more fun. > > > > >Picoblaze has assembler support, and MicroBlaze has c support. > > > > Good points. > > > > I'm thinking of the simple ROM based architecture where > > the PC gets loaded from a next-instruction field in each > > instruction. An assembler for that sort of system is really > > pretty simple. (The parser is the hard part.) All you need > > to do is recognize tokens and pack their values together into > > an instruction. Not quite that simple. There is also some > > work to assign instructions to locations and/or to pair up > > locations for the brancing logic. > > > > It is pretty simple if you have an example to start with. > > You just need to hack it to work with the appropriate tokens > > for your system. > > On this path, there was mention a while ago in c.a.f of a (very old) > uC core that used a LFSR as the PC. This solved a speed-bottleneck, > (plus uses less logic) but needed more work in the assembler. > Seems this could have real merit in the 'smallest cpu' direction. I can see PC relative addressing becoming a real PITA. Adding '1' to an LFSR is no big deal, but adding N is a big deal. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 56187
Take a look at the TVC family of buffers in TI. http://focus.ti.com/docs/logic/catalog/overview/overview.jhtml?templateId=5043&path=templatedata/cm/ovw/data/tvc_overview It might solve your problem. Brijesh Amontec Team wrote: > Hi all, > > I have to find the best solution to do a TTL level converter. > I have to convert 5v <-> 3.3v 2.5v 1.8v 1.2v. > > I have an external Vref signal for the second part. > I have some bidirectional signal :-( > > The shem would be some think like this: > > ¦-------------¦ > ¦ +<----- Vref from 1.2v to 3.3v > ¦ ¦ > ¦ TTL level ¦ > 5v TTL signals <--->+ converter +<----> 1.2v to 3.3v LVTTL signals > ¦-------------¦ depending on Vref > > > Which solutions to do that? > Is there any device to do that? > > MANY thanks for your help. > > Laurent Gauch > Amontec Team > www.amontec.com >Article: 56188
Fred Viles wrote: > > rickman <spamgoeshere4@yahoo.com> wrote in > news:3ED5FB2E.D1EF6320@yahoo.com: > > > Fred Viles wrote: > >> > >> rickman <spamgoeshere4@yahoo.com> wrote in > >> news:3ED3A6C7.229A5223@yahoo.com: > >> > >> >... > >> > The second will have an ARM MCU and a large CPLD. > >> >... > >> > >> There are JTAG probes available for ARM, at least, that have no > >> problem with there being mulitple TAPs on the JTAG chain. > >> (MultiICE from ARM and MAJIC from EPI, just to name two). > >> Unless your CPLD programmer can't handle it, you shouldn't need > >> to provide for isolating the TAPs in this section. > >>... > > To the best of my knowledge, the number of devices in the chain > > has little to do with the hardware. I belive it is entirely up > > to the software. > > Well sure. For some definition of "software" which varies > depending on the probe you choose. E.g. for MultiICE it's an RDI > compliant DLL on the PC, and for MAJIC it's firmware in the probe > itself. For a cheap parallel port bit-banger like a Wiggler, it's > host software either in a shared library or directly in the > debugger. > > But I guess I don't understand how that observation is relevant to > the question of whether your target board needs to isolate the > various TAPs or not. I would think the only question is whether > the probe+software you will use for each device supports the device > not being the only TAP on the chain. > > I don't know about your CPLD, so I was just pointing out that for > the ARM, at least, the answer can be yes. I still don't think I am with you. You are talking about firmware on the probe having something to do with "understanding" the nature of the chain. To the best of my knowledge (I have not dug into how the advanced probes work) this is still a function of the debugger software on the PC. If the debugger only supports one type of probe, then so be it. But I don't think the probe itself determines whether or not the software can work with multiple devices in a chain. I am asking about experiences others have had in this regard. I am not clear if you are talking from experience or from a general knowledge of how these devices work. I am also asking for ideas on how probe/software limitations have been handled by others. Surely I am not the first to encounter limitations of connector space on such a board. > > I am not up to speed on the many suppliers of > > debugging hardware and software for the ARM yet. I have heard a > > lot of recommendations, but not many provide info on *why* one > > combination is good or bad. > > That's a big subject to cover. There are a *lot* of products on > offer from a lot of companies, not to mention the freeware/hobbiest > options. They all have strengths and weaknesses, and what makes > one a better solution than another is largely dependent on your > particular needs. > > Do you need download performance? Multi-TAP support? Multi- > Processor support? RTCLK support? ETM support? Networkability? > Support for a particular debugger? Low cost? etc. I would much prefer a low cost solution. I described my chains in my earlier post. I have one chain with a single CPLD, no problem. A second chain has an ARM and a Lattice 5512MB CPLD. This CPLD is also programmable from the ARM MCU, so the CPLD JTAG connection is needed only in manufacturing test. The third chain has a TI DSP and a Xilinx FPGA. Again, the FPGA has no need to be configured by JTAG, so it will only be accessed during manufacturing test. I expect to provide a DSP debug connector for my customers to write their code. The ARM debug conector will only be needed by us unless our customers want to make mods to the code. So that connector would not be needed in production. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 56189
"H. Peter Anvin" wrote: > > Followup to: <3ED659EA.F20FBA79@xilinx.com> > By author: Peter Alfke <peter@xilinx.com> > In newsgroup: comp.arch.fpga > > > > Here are the undisputed pros and cons: > > > > Antifuse advantages: > > Instant-on, needs no configuration PROM or other store, security is > > easier, and radiation tolerance is better for space applications. > > > > Antifuse disadvantages: > > one-time only programming (you have to throw the device away if you want > > to make any change) > > slow programming,( takes many minutes for larger devices) > > more restricted upper device-size limit ( no multi-mega-gate circuits) > > fewer sophisticated features (clock manipulation, RAMs, multipliers, etc) > > > > You're forgetting one: yield. Because an antifuse FPGA is OTP, no > testing done at the factory can guarantee that every device will > program correctly. I don't know that the fallout percentage is > nowadays -- for all I know it might be negible -- but still... You make it sound like they can test the SRAM FPGAs 100%. If you belive that, I have a bridge in Brooklyn I would like to sell you. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 56190
"H. Peter Anvin" wrote: > > Personally, I refer to an FPGA configuration stream as firmware. It > walks like firmware and quacks like firmware... That is what this discussion is about. What exactly do you consider to be "walking" and "quacking"? This is an attempt to quantify the features that distinguish firmware from software from *other*ware. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 56191
Ralph Mason wrote: > > "Peter Alfke" <peter@xilinx.com> wrote in message > news:3ED67E37.5C9FC432@xilinx.com... > > > Undoubtably there might be a market for what you describe, but it would > > be for single-chip applications, where cost is secondary, and > > performance does not count. We think that this too small a market for us > > to engage in. > > It might be an bigger marker than one thinks, a given vendor could sell > their own application specific chips with very little in the way of startup > costs. Then xilinx lowers the bar on being a fabless chip vendor. > > Imagine 100k - 500k gates in in a package with flash, the possibilities are > endless for replacing other vendors chips. One and 2 man bands can start > selling pre configured FPGA easily and quickly. It could spawn a nice little > industry, that I don't believe is feasible with external configuration. > > The stacking Idea sounds pretty nice, like the p-pro was but one expects > easier to manufacture and smaller in size. Or perhaps a new flash technology > will come about that can be build on the latest processes. > > We can all dream. I don't know that the "price" issue is not a red herring. Check out the xPLD and xPGA devices from Lattice. Both families use SRAM configuration booted from on die Flash at power up. Self configuring and can still be changed in the field without reprogramming the Flash. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 56192
Wong wrote: > > rickman <spamgoeshere4@yahoo.com> wrote in message > > > > I think you hit on the main differences. But I am not clear on what you > > mean by "sacrificed". Both anti-fuse and SRAM based devices have > > separate RAM blocks. The Xilinx SRAM based devices can use the RAM > > based LUTs as small blocks of RAM as well. On the other hand, I believe > > that you can create FFs (RAM) from logic in the anti-fuse parts. So if > > you have enough logic cells you can make RAM. > > In anti-fuse parts where RAM is not available, there will be more SC > cells. But the SC cells in SRAM-based parts are less because of RAM > compare to anti-fuse parts which have the same amount of system gates. I don't know what an SC cell is. I also don't understand your analysis based on "system gates". "system gates" is a very abitrary metric of device. Besides, I don't give a whit how many "system gates" a device has. I care about fitting my design into the lowest cost part. SRAM nearly always helps in that regard, and is often *required* to get the job done. I don't think I could even use an anti-fuse part that did not have *any* on chip memory. > > Otherwise the differences are in the debugging stage. The anti-fuse > > parts require that you have a way to remove devices in order to change > > your program and SRAM parts can be changed by reprogramming over a > > cable. > > Yes, this is the trade-off. I have to make a good decision. > > > > > Also, don't forget Flash based parts which combine many of the features > > of both. Lattice has some XPLD and xFPGAs both using Flash *and* SRAM. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 56193
rickman wrote: > > Jim Granville wrote: <snip> > > > On this path, there was mention a while ago in c.a.f of a (very old) > > uC core that used a LFSR as the PC. This solved a speed-bottleneck, > > (plus uses less logic) but needed more work in the assembler. > > Seems this could have real merit in the 'smallest cpu' direction. > > I can see PC relative addressing becoming a real PITA. Adding '1' to an > LFSR is no big deal, but adding N is a big deal. Check the older thread - IIRC they avoided both operations, and moved all PC maths to the assembler. This thread is called "smallest embedded cpu....and the most pain", so the emphasis is very much on the vanilla end of the spectrum. On your Hi-Temp operation issues - I did see Zilog now offer high temp grades of their eZ8 uC ( and press info, but no data yet no the smaller Z8F04). Also saw some interesting FIT curves in a latest OnSemi curve, showing lifetime degrades going above 80'C - something like 120 yrs -> 2 yrs for 80'C to 130'C. -jgArticle: 56194
Hi, I have worked with FPGAs. and i am new to Gate array technology. What all are the things i should be considered while coding for gate arrays? Any good links on that. Regards, MuthuArticle: 56195
"Ed Stevens" <ed@stevens8436.fslife.co.uk> wrote in message news:bavjm4$q99$1@news6.svr.pol.co.uk... > Hi everyone, > > I have 2 questions: > > For the past few weeks I've been trying to get started with VHDL and FPGA's. > I've purchased a Spartan board from Digilent and I've also purchased the > Student software from XILINX. The problem im having is when I load the > XILINX software and select the Spartan device it won't allow me to select a > VHDL design flow, it only allows EDIF. If I select a Spartan2 device it > will allow VHDL. Does anyone know if its possible to get the XILINX Student > software to work with a Spartan in VHDL? > > My second question is: Does anyone have any opinions on the Cypress Delta39K > CPLD Evaluation Board? Im thinking of buying it so I can implement a > Digital Phase Locked Loop on it, in VHDL. Would it be capable of doing > this? It appeals to me because it comes with the Cypress Warp VHDL > software, is this software any good? > > Thanks for any help, which board ? D2 ? That is a spartan2. http://www.digilentinc.com/Catalog/digilab_2.html There is only one board on their web pages that uses a spartan fpga. Get the webpack either download or request a cd. http://www.xilinx.com/webpack/index.htm http://www.xilinx.com/ise/ise_promo/ise5_eval.htm The current webpack doesn't support spartan devices.Only spartan2 or spartan2E. also 5.2 only supports windows xp and windows 2000 sp2. But you can download previous releases which will support the spartan. http://www.xilinx.com/webpack/classics/wpclassic/index.htm see this link for which release supports which devices http://www.xilinx.com/webpack/classics/wpclassic/parts_list.htm Digilent sell a breadboard that plugs into the expansion connectors and also a couple of peripheral boards http://www.digilentinc.com/Catalog/peripheral_boards.html I have a digilent D2E boards(spartan2e) and a dio1 board as well as a xilinx coolrunner2 design kit board(made by digilent for xilinx ). Had no problems using them. Alex Gibson.Article: 56196
"Spam Hater" <spam_hater_7@email.com> wrote in message news:ap07dvg9qje6mugq6np508863shimgjqiu@4ax.com... > I have two answers (opinions) > > 1) It is not possible. The contract between Xilinx and the synthesis > vendor was terminated over a year ago. There is NO HDL software > support for this device from Xilinx. See if Digilent will trade the > board for a SpartanII board. > > 2) The software is good, but the board is useless. All it has is the > chip on a PCB; no oscillator, stake pins for I/O, and not even a > voltage regulator. (I was going to make an expansion for mine, but > decided that getting a different board would be cheaper.) > > $.02, > SH7 > > PS: Take a look at Tony's products: www.burched.com > huh ? what do you mean the board has no oscillator ? He didn't say which board he had and all the digilent boards have regulators and oscillators. See http://www.digilentinc.com/Catalog/system_boards.html and http://www.digilentinc.com/Catalog/all_in_one.html for the two that don't mention if they have oscillators check the pages for each and you will see they do. The student software is a real pain. 4.1 or 4.2 don't run properly on windows xp. webpack 5.1 or 5.2 are only supported on windows 2000 and windows xp. I'm having the fun of providing lab and tutorial support for a university subject Introductory Digital Systems at the moment. The programmable logic part uses xc9572xl's and one of the main problems has been the software. Also the lack of simple simulation software. That was one of the best things about xilinx 2.1 student edition, how simple it was to do simulations. Alex GibsonArticle: 56197
Hi, I'm now doing a design on Xilinx CoolR-II, using Verilog. Everything is ok except when I try to do timing simulation. I change the part to a FPGA, it's ok; I change my design to VHDL, it's also ok. I did this both with Modelsim and VCS, they all could not work when using Verilog+CPLD. So I wonder if there's any bug in ISE's Verilog simprims library? --Article: 56198
"Ben Jackson" <ben@ben.com> wrote in message news:aIxAa.472108$Si4.408309@rwcrnsc51.ops.asp.att.net... > In article <3ed28769$1@news.iconz.co.nz>, > James Fitzsimons <jamesf@intergen.co.nz> wrote: > > > >> U1 is a clock oscillator module, I should have made that clear > > > >Um, at the risk of sounding stupid, what part are you using for this? Ben > >Jackson posted a link to a Xilinx app note that uses a 555 timer to generate > >a 14Hz clock signal, but this seems kinda slow. I thought these CPLD's were > >supposed to operate in the ~100Mhz range? > > They *can* but it depends on what you're doing. I thought the same thing > about the 555 in that appnote. I built my board with a socket for a half- > size clock oscillator (same size as 8pin dip, but only 4 pins, one at each > corner). The slowest oscillator I bought was 1Mhz. So if you want to > do a blinky-light demo, the first thing you'll want to do is divide by > nearly 1M (about 2^20). Ok, there's 20 macrocells for a clock divider! > Yes, half of your XC9536. So a clock source in the handful-of-Hz range > is perfect for experiments. > > As for how fast you *can* go, look at the datasheet. It shows how to > read the partnumber to find the gate speed. The slow parts are "-15" > (or even -20 for the XC95108, I think). That means 15ns gate speed, > or about 1/15ns = about 66Mhz (probably the practical limit is slower). > > And note that there are THREE global clock inputs on a XC9536/72, so > you can run different parts of your logic at different speeds. > Also if you going to use a 555 as a timer, using the cmos version of the 555 gives less problems. (less noise, cleaner transistions) TLC555 or 7555 Alex GibsonArticle: 56199
Now it's working. I found an error in my reset sequence. The thing was that I had two DCM in serial, the first one for multiplying by four and the second one for off chip de-skeew. Instead of using the LOCK output from the first DCM as a reset condition for the second one I was using STATUS[2] (CLKFX stopped). So the problem was not the first DCM, it was the second one that didn't lock or lost lock after a while. The reason for this connection was that I read somewhere (I think in Xilinx answer data base) that there was some uncertainties about the LOCK signal when no feedback was applied to the DCM. The STATUS[2] was safer to use. How is the STATUS[2] signal working? It seems to me that it signals OK as soon as there is a output clock on the CLKFX output but this is not necessary the wanted clock (yet). /Patrik Austin Lesea wrote: > Jay, > > Yes, you lose the skew war, as you do not know what your timing is > anymore. But, from the CLKIN to all of the outputs, you will have known > timing, and at 19.44 MHz, the skew difference is going to be so small, > that maybe you can ignore it? > > Austin > > Jay wrote: > >>Yes, I'v thought about the frequency doubler. >>But what I'm afraid of is: would any delay be introduced between fin and >>fout, for there is no guarantee of de-skew. >>Anyway, I would use it as "a tool of last resort". >> >>"Austin Lesea" <Austin.Lesea@xilinx.com> >>??????:3ED4C5C4.CCA011EA@xilinx.com... >> >>>Yes, >>> >>>One can put the input through a simple frequency doubler (see Peter's >>>circuit tricks Xclusive), and then into the input. This gets the >>>frequency down to 12 MHz for the DLL. One then uses the duty cycle >>>correction ON (to help fix the asymmetry of the doubled clock). Since >>>taps are updated every 6 times the 2's complement of the jitter filter >>>settings, the asymmetry of the doubled clock does not violate the input >>>jitter specification. >>> >>>Haven't tried this, but there is no reason why it shouldn't work. If >>>anyone has it working, let us know. >>> >>>Austin >>> >>>Heavenfish wrote: >>> >>>>So my question is if there any alternate way to implement both DLL and >>>> >>DFS >> >>>>function when my input clk is less than 24MHz? >>>>or I have to change my application. >>>> >>>>"Austin Lesea" <Austin.Lesea@xilinx.com> >>>>??????:3ED3C590.F0C93004@xilinx.com... >>>> >>>>>Jon, >>>>> >>>>>The DCM CLKFX feature works down to a 1 MHz input frequency (as long >>>>> >>as >> >>>>>the output being synthesized is greater than 24 MHz). >>>>> >>>>>Note that you can not use "sync to DLL" (ie connect CLK0 to CLKFB) in >>>>>this mode (DFS only mode). >>>>> >>>>>Austin >>>>> -- Patrik Eriksson | patrik.eriksson@netinsight.net Net Insight AB | phone: +46 8 685 04 89 Västberga Allé 9 | fax: +46 8 685 04 20 SE-126 30 STOCKHOLM, Sweden | http://www.netinsight.net
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