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
andrew.newsgroup@gmail.com wrote: > Hi, > I'm using EMACS vhdl-mode to generate a makefile for simulation. My > problem is that I don't know how to tell EMACS to rescan the source > code folders before re-generating the makefile. If it doesn't rescan > then it doesn't find new files I have added or new dependencies. My > workaround is to close down emacs. Delete the emacs cache file. Reopen > emacs, and then regenerate the makefile. Sorry I can't help you on this. Is there a verilog mode for emacs. Highlighting would be good. Being able to match begin and end statements would save me significant pain. Andy > > Is there a simple way to force emacs to rescan the source code > folders? > > Cheers > AndrewArticle: 140476
Andy Botterill wrote: > Is there a verilog mode for emacs. http://www.verilog.com/verilog-mode.html First hit from Googling verilog mode emacsArticle: 140477
Just curious if anyone out there has any recommendations for FPGA conferences: Which ones provide the most insight into FPGA design (latest verification, design, methodologies/techniques)? Where have you learned the most that you can apply to your job?Article: 140478
phil hays wrote: > Andy Botterill wrote: > >> Is there a verilog mode for emacs. > > http://www.verilog.com/verilog-mode.html > > First hit from Googling verilog mode emacs > > I have already installed (from www.veripool.org) verilog-mode-494.el . I do not see anything which allows me to relate a begin to a specific end. If the www.verilog.com emacs mode does this I will install it. Does it do this please. Thanks AndyArticle: 140479
On May 13, 6:31=A0pm, Mike Harrison <m...@whitewing.co.uk> wrote: > On Wed, 13 May 2009 12:36:26 -0700 (PDT), rickman <gnu...@gmail.com> wrot= e: > >On May 13, 1:45=A0pm, Mike Harrison <m...@whitewing.co.uk> wrote: > >> On Wed, 13 May 2009 03:58:40 -0700 (PDT), "Antti.Luk...@googlemail.com= " > > >> <Antti.Luk...@googlemail.com> wrote: > >> >On May 13, 1:23=A0pm, Mike Harrison <m...@whitewing.co.uk> wrote: > >> >> I'm looking at a possible application and trying to figure the rela= tive costs of FPGA/CPLD versus > >> >> MCU. > >> >> I can do it with a microcontroller, but the only MCUs with the hard= ware I need (TFT LCD controller) > >> >> tend to come with lots of other stuff (ethernet, large flash, USB e= tc.) which I don't need. > > >> >> As it can be hard to get 'real' prices of FPGAs without talking to = all the distis etc. I =A0wonder if > >> >> anyone can suggest parts to look at . > > >> >> Rough reqiurement is : > > >> >> Cheapest in 100x qtys for total solution inc. config and power supp= ly ( from 3.3v supply), below > >> >> about GBP5(US$7.5) > >> >> Not BGA > >> >> Readly available : ex-stock or sensible leadtimes (2 weeks) > >> >> A couple of RAM blocks, around 1K byte each > >> >> about 60 IOs, all 3.3v > >> >> 30MHz clock > >> >> Logic equivalent to around 100 CPLD macrocells > >> >> Free or low cost (<$500) design software > > >> >> The Xilinx S3A/AN-50 is the cheapest I've found so far, but is a a = bit over-specced. > >> >> CPLDs seem to get expensive above 72 cells and don't tend to have R= AM > > >> >the IC you need is always the one that doesnt exist ;) > > >> >S3-50AN prices do go below 4$ but not at 100x qty. > >> >in 100x qty, it proabably more than your target price 7.5 (depend how > >> >good you deal..) > > >> >Xilinx disties say: leadtime 12 weeks, call for order > >> >Digikey has 4 pcs in stock > > >> >if you can deal with 2 KB RAM, then lattice EC1 is 6.1$ online price > >> >available in stock, need spi flash, but it still cheap total price > > >> >but here XC3S50A would be better at about same price > > >> >Lattice XP3 is too expensive with online pricing.. $10, stock YES, > >> >this is the IC that needs NO Externals, no flash, no LDO, just 3.3V ! > > >> >Actel A3P060, is cheap, but again 2K RAM only > > >> >all the above have free tools > >> >Altera doesnt seem to have devices that come to your desired price > >> >range > > >> >hm.. call lattice disti, say you would like XP3-VQ100, but your BOM > >> >limit is 7.5$ see what they say !! > > >> >if price doesnt come down, place xc3s50a-vq100 order on digikey, to > >> >secure your devices before those are gone too (disties have no stock. > >> >leadt=3D12w) > > >> >Antti > > >> Thanks for the suggestions - the Lattice EC1 looks a pretty good fit o= n all counts - RAM is 'only > >> just' enough, but means I'm not paying for stuff I don't need. > > >> I even found a cheap eval board for it :http://www.msc-toolguide.com/l= atticeec-low-cost-evaluation-board.html > > >I had to do this same search last year and I found very little that > >would suit my needs... in fact, I found exactly one part that really > >was suited to the job. =A0The problem you will find with most parts is > >not actually the price of the part itself, but rather the price of the > >package. =A0The FPGA vendors will attest to the fact that the pricing of > >these parts at the low end is mostly governed by testing which is in > >tern dominated by the cost of testing the I/Os. =A0So the lower the pin > >count, the cheaper the part. > > And nobody seems to do low pin-count FPGAs, and CPLDs seem to have a big = price jump above 72 > macrocells which I've never quite understood - there appears to be a gapi= ng hole between the $2 CPLD > and the $8ish FPGA. I used a 256 cell CPLD in a project once and yes, it was a bit pricey. I think the routing of these parts goes up very quickly as the size increases. They don't have the same routing structure as an FPGA and that may be what drives up the cost and limits the size. > > =A0I remember that some ram based FPGA vendors would jump up and down a= nd > >insist that ram was the only way to go when considering the advantages > >of die size and how it would impact the cost. =A0I guess that really is > >not the whole picture is it? > > Well the pricing of S3A+SPI flash compared to S3AN seems to support this.= .. > Single-chip and single-supply are nice, but not if the additional cost is= several times that of > external regulator/flash! What pricing do you have for these parts? I'm not clear on which are saying is the expensive option. Both of the Spartan devices use two die, one for the FPGA and one for the flash. The S3AN parts just put them both in the same package. That is how they did it when they came out; I don't think they have changed this. According to Xlinx Flash is just not compatible with their small geometry process. > >The only issue may be availability, but then I have never found *any* > >FPGA that they maintain significant amounts of stock at all times. > >Mouser sells Lattice, but the inventory is mostly at Lattice and is > >drop shipped. > > Farnell also list several Lattice devices, so availability appears to at = least be better than > Xilinx. Xilinx should be as available as the others, no? RickArticle: 140480
On May 14, 6:57=A0am, Sharan <sharan.basa...@gmail.com> wrote: > Hi, > > I have some basic questions on sync and async reset schemes. I would > be thankful if any design experts clarify them for me. > > 1. Most of the chips that use async reset schemes, tend to process > these resets using clocks. Now doesn't this result on depending on > clock being present, which is quoted as one of the main disadvantage > of sync clocks. I'm not certain what you mean here. The internal async reset on most FPGAs does depend on a clock, but the FPGA will provide the clock if you don't specify your own clock. In fact, there is a startup sequence that depends on the clock and it controls the release of the sequential logic from global set/reset, release from tri-state of the I/Os and the hand shake lines for configuration. Xilinx and Lattice are nearly identical in basic serial mode and Altera is very similar. The only reason they provide the means of using your own clock is so that the boot process can be synchronized with your clock if needed. > 2. While normally the async reset input is processed inside the chips > to ensure that assertion is async but deassertion is synchronous, I > have seen some cases where the async reset is first synchronized and > then used throughout the design. So what is the advantage of > synchronizing async resets inside the chips Again, I am not clear on what you mean. By synchronizing do you mean something the internal logic of the FPGA is doing or something the user logic in the FPGA is doing? I used to think I knew how to design the startup of my designs in FPGAs. But my method always requires either an external reset, or the instantiation of the GSR block with just an output and no input. So far I have not needed to instantiate the GSR. This does require that you sync the release of reset with the rest of your design since it is using a separate clock. Even if you specify that the global reset should use the user's clock, there is no spec that I have seen (maybe I haven't looked hard enough) on the timing of the GSR signal. Even if this signal is spec'd and the timing analyzer checks it, in a design with a fast clock the GSR will not be fast enough to release every FF on the same clock cycle. That's my story and I'm sticking to it... at least until someone shows me evidence that I am mistaken. Some of the design notes I have read do suggest that a sync reset is preferred since they can be made local and don't have to run around the whole chip. That would seem to depend on the design, wouldn't it? > 3. In case of sync resets, how is the reset generated by the system > (which is outside the chip) since the reset should have a defined > relation wrt the clock that uses this reset. Also, in case the chip > uses multiple clock domains, it means that the reset should also be > different and properly synchronized with the corresponding clock. How > is this ensured. Is it that the system generally generates a wide > reset and the reset circuitry inside the chip synchronizes per clock > domain and fans out the reset? You are asking, "how long is a piece of string?" The details of using an external reset depend entirely on your design. Most of my designs do not need a reset sync'd to the clock. The user logic inside the chip syncs the reset so that the design starts on the same clock cycle when important. If I have multiple clocks, then I have to understand the details of how the different circuits need to start up in relation to the rest. Normally, I use finite state machines which are in an idle state until they receive some signal, so the startup sequence is not important, they all just need to startup in the right state which is entirely within each FSM, not between them. So they can run on any clock they need to use. > 4. Also, sync resets directly go to input of the data input of the > flop. Does not this have an impact on the max frequency of the circuit > since one level of logic will get added due to this input? The sync resets do not *have* to go to the data inputs. I know what many devices can use dedicated inputs to the FFs to synchronously set/ reset the FF. In fact, a design note I was reading the other day (I forget if it was Xilinx, Lattice or Synplicity) said to use sync resets so that the logic *would* be separate from the data path. I think they were showing the coding style to do that without mixing the data path and the reset circuit. RickArticle: 140481
Answers to your questions are embedded below... >Hi, > >I have some basic questions on sync and async reset schemes. I would >be thankful if any design experts clarify them for me. > >1. Most of the chips that use async reset schemes, tend to process >these resets using clocks. Now doesn't this result on depending on >clock being present, which is quoted as one of the main disadvantage >of sync clocks. Many designs use will asynchronously pull reset active and synchronously de-activate reset. This ensures the design will go into reset ASAP and will "cleanly" come out of reset. In this case, yes a clock is needed to come out of reset, but is not need to force the reset. > >2. While normally the async reset input is processed inside the chips >to ensure that assertion is async but deassertion is synchronous, I >have seen some cases where the async reset is first synchronized and >then used throughout the design. So what is the advantage of >synchronizing async resets inside the chips Depending on the design, you may not want to violate any FF setup of hold times when transitioning the reset line. This come into play when multiple state bits can transition coming out of reset or if a counter wants to be held at its last value when going into reset. If the setup and hold times for these two examples are not met, one FF may see the reset at a different clock edge or metastability may cause 1 FF to transition and not another when they were both ment to change. Example: Coming out of reset a state machine may want to jump from state 000 to state 011. If bit 0 sees the reset going inactive slightly later than bit 1, the SM could jump to state 010 which may be invalid. > >3. In case of sync resets, how is the reset generated by the system >(which is outside the chip) since the reset should have a defined >relation wrt the clock that uses this reset. Also, in case the chip >uses multiple clock domains, it means that the reset should also be >different and properly synchronized with the corresponding clock. How >is this ensured. Is it that the system generally generates a wide >reset and the reset circuitry inside the chip synchronizes per clock >domain and fans out the reset? My default methodolgy is to sync the deassertion of the reset to each clock domain within the FPGA and to assert reset async. Again, its design dependant so you should understand what each domains reset requirements are. > >4. Also, sync resets directly go to input of the data input of the >flop. Does not this have an impact on the max frequency of the circuit >since one level of logic will get added due to this input? Yes, that can be the case. I also have used the async clear FF input with the reset signal sync'ed on the deasserted edge. This async clears the FF and sync removes the clear. The timing contraints file needs to be setup correctly to insure your meeting timing thru the async input. > >Regards >Article: 140482
I honestly can't understand exactly what you are trying to do. Your description may be clear to you, but I don't understand the details. From the drawing, it does appear that you want to move data from an image sensor via ADC to either/or the FPGA and DSP, do some processing and then dump the data to the USB port. I'm not clear on whether this needs to be live or it is an image capture like a camera. The only thing I can say is that sharing the perpherial devices, (USB, SDRAM and flash) is not as easy as putting each device on one or the other processor (FPGA or DSP). Trying to share a high speed bus is not so easy to do from a signal integrity standpoint. Your diagram does not show what the dual port ram is connected to on the other port. I guess this is something else outside the diagram? Yes, if you don't need a lot of dual port ram, you can use the ram internal to the FPGA (for most FPGAs). Rick On May 13, 5:13=A0pm, bigca...@gmail.com wrote: > Dear All: > > I am thinking about my system, the picture is here: > > http://www.flickr.com/photos/26914086@N05/3528643109/sizes/l/ > > I want to transfer the raw/processed image sensor data to USB 2.0 or > dpram. > > Two choices: > > 1. ADC -> DSP, this means parallel ADC, then DSP processed data -> > USB, FPGA works as a coprocessor, use FPGA's DSP (difficult), FPGA- > > >DPRAM > > 2. ADC -> FPGA, this means serial ADC or whatever, then FPGA<---- > EMIF---->DSP processed data, data feedbacked from DSP to FPGA -> USB, > DSP works as a coprocessor. > In choice 2, the USB could also connect from DSP but this will > accelerate processed data transfer, decelerate the raw data transfer. > > Other questions: > > I also need to store raw data, thus the data saving path will be > different: > Choice 1: the raw data will be from ADC -> DSP -> FLASH > Choice 2: the raw data will be from ADC -> FPGA -> FLASH (Is Flash > good for fast data saving, or use EEPROM instead?) > > It will meet the same question when I save processed data on board. > > The last question is FIFO vs. DPRAM, FIFO could be implemented in > FPGA, could DPRAM be implemented in FPGA? the DPRAM has more > flexibility for sure. > > Thanks!Article: 140483
andrew.newsgroup@gmail.com wrote: > Hi, > I'm using EMACS vhdl-mode to generate a makefile for simulation. My > problem is that I don't know how to tell EMACS to rescan the source > code folders before re-generating the makefile. On the speedbar: center-click project, right-click and hold down, speedbar, rescan-project -- Mike TreselerArticle: 140484
> hi.. > i am presently doing one project, in that i need to convert a 128 bit > plain text to a 4X4 matrix, each element in the matrix is of 8bit > length...how to write a vhdl code for this....can u please help me in this > regard...... > thanks in advance..... Sounds like homework to me. You will probably want to start with a for loop that goes from 0 to 127 or some nested loops that go from 0 to 7, 0 to 3, and 0 to 3. Why don't you take a shot and report back to us. It's hard to help you when we don't know waht exactly the assignment is or what trouble you are having. Brad SmallridgeArticle: 140485
"jayantbala" <jayantbala@gmail.com> wrote in message news:uoCdnSUvHOMiOJbXnZ2dnUVZ_gqdnZ2d@giganews.com... > >jayantbala <jayantbala@gmail.com> wrote: >>(snip) >> >>< but for this purpose i dont want to implement TCP/IP >>< .i just simply want to send and receive MAC Packets i.e >>< preamble+Destination Address+source address+type+data+FCS >> >>For type X'0800' that will be hard on many systems. >> >>If you don't need or want TCP, can you use UDP? >>It is a very simple header to add and then send it out. >> >>Receivers can ignore the header, if that is easier, though >>they should probably verify the IP address. >> >>-- glen >> > thank you glen. > I am using XP with intel machine .glen the thing is that i even dont > want > UDP also. cant i write few lines of code in any supportive s/w > language > which can read and write MAC packet over ethernet bcoz my > application > is point 2 point connection. > i just want to make it simple. > > also i am not very much familiar with TCP/IP. so can u suggest me the > S/W language and some gud tutorial for implementing TCP/IP if needed. libpcap will read and write to the link layer. Please do something about your spelling.Article: 140486
A need just came up and I was greatly surprised to find 5 V Spartan FPGAs back on Digi-Key's web site. I thought I had read a release from Xilinx that the process was no longer available, and the chips would not be available from registered distributors once the supply dried up. I think I looked on Digi-Key last year and the 5V spartan was either not found or came up with "call for info". There are minimum quantities, and the price is WAY higher than I had paid years ago. I have re-designed our high-volume stuff to use newer (and cheaper) FPGAs, but there are some legacy motherboard-type stuff where we only make a couple a year, where it doesn't warrant the re-design (or the voltage level translators) to go with a newer (and non-5V) FPGA. Is my (carbon-based) memory going bad, or have these discontinued, legacy parts been revived due to demand? JonArticle: 140487
Mike Harrison wrote: > I'm looking at a possible application and trying to figure the relative costs of FPGA/CPLD versus > MCU. > I can do it with a microcontroller, but the only MCUs with the hardware I need (TFT LCD controller) > tend to come with lots of other stuff (ethernet, large flash, USB etc.) which I don't need. > > As it can be hard to get 'real' prices of FPGAs without talking to all the distis etc. I wonder if > anyone can suggest parts to look at . > > Rough reqiurement is : > > Cheapest in 100x qtys for total solution inc. config and power supply ( from 3.3v supply), below > about GBP5(US$7.5) > Not BGA > Readly available : ex-stock or sensible leadtimes (2 weeks) > A couple of RAM blocks, around 1K byte each > about 60 IOs, all 3.3v > 30MHz clock > Logic equivalent to around 100 CPLD macrocells > Free or low cost (<$500) design software > > The Xilinx S3A/AN-50 is the cheapest I've found so far, but is a a bit over-specced. > CPLDs seem to get expensive above 72 cells and don't tend to have RAM > Take a look at Xilinx Spartan 2E, they are just a bit more expensive, but no problem on availability. I buy them 25 at a time, for about US $12 each. You might get them down about where you want the price in 100 Pc quantity. I use the TQ144 package, no problem hand soldering or cheap reflow. JonArticle: 140488
Hello is something like Serial Gigabit Media Independent Interface (SGMII) to Media Independent Interface (MII) available somewhere? I have to use A SGMII connected Gigabit PHY with a Standard Fast Ethernet MAC using MII. Thanks for any help HeinzArticle: 140489
Andy Botterill <andy@plymouth2.demon.co.uk> writes: > phil hays wrote: >> Andy Botterill wrote: >> >>> Is there a verilog mode for emacs. >> >> http://www.verilog.com/verilog-mode.html >> >> First hit from Googling verilog mode emacs > > I have already installed (from www.veripool.org) verilog-mode-494.el . > I do not see anything which allows me to relate a begin to a specific > end. If the www.verilog.com emacs mode does this I will [...] I have the one from Michael McNamara (www.verilog.com). With sexp-moves you can move from begin to end and vice-versa (bound to C-M-b and C-M-f). FlorianArticle: 140490
On May 14, 9:20=A0pm, Mike Harrison <m...@whitewing.co.uk> wrote: > What I'm looking at is the cheapest way to drive a large number (potentia= lly hundreds) of > distributed TFT (PSP) displays with local SDRAM and/or NAND flash storage= for a few tens to hundreds > of frames, with a relatively a low bandwidth network of some sort to upda= te content in non-realtime, > and switch the display between stored frames realtime. The aim is to mini= mise the cost per node as > much as possible. Ah, so you need many slaves, and the smarts can be elsewhere. I found some info on TFT(PSP), [9MHz, 8+8+8 Colour] and it seems the simplest solution would be a 32 bit wide SDRAM and a CPLD, and 128MC should be plenty. - I don't see you need a line-ram in a SDRAM playback scheme (tho the Qimonda SDRAM data I had was poor ). Run the CPLD at >> 9MHz (or whatever is needed to interleave access), and a simple BUS connect CPLD.SDRAM.TFT, then something like nibble-wide SPI to link all the slaves. We have done simple cascade shifters, when doing similar designs - all slaves chain, and here ~13 clocks are needed per slave node. > > Interesting - I'd not noticed that one - I've used Atmel CPLDs in the dis= tant past but had sort of > forgotten that they still did them as they don't seem promote them very m= uch these days..! They are poor on promotion, which is a shame as they have nice parts. -jgArticle: 140491
As others have pointed out, a Synchronously Deasserted Asynchronous Reset (SDAR) still allows the system to reset without a clock, but the system cannot resume without a clock (the latter of which is identical to synchronous resets). The SDAR is distributed to the asynchronous reset inputs of the registers needing reset. The SDAR can be delayed (pipelined and/or fanned out via register replication) to reach the far corners of large, high speed designs just like a synchronous reset can. Multiple versions of SDAR can be created for each clock domain, just like synchronous resets. My general preference is to use SDARs. Another method of accomplishing the effect of an SDAR is to have a clock enable (or enabled clock buffer) that is disabled until sufficient time after the deassertion of reset to allow the reset to propagate to the register before its clock is enabled. This requires a small amount of logic running off the virgin clock to create the delay, and that logic needs to have a traditional SDAR. AndyArticle: 140492
On May 15, 7:51=A0am, Jon Elson <jmel...@wustl.edu> wrote: > A need just came up and I was greatly surprised to find 5 V Spartan > FPGAs back on Digi-Key's web site. =A0I thought I had read a release from > Xilinx that the process was no longer available, and the chips would not > be available from registered distributors once the supply dried up. =A0I > think I looked on Digi-Key last year and the 5V spartan was either not > found or came up with "call for info". =A0There are minimum quantities, > and the price is WAY higher than I had paid years ago. =A0I have > re-designed our high-volume stuff to use newer (and cheaper) FPGAs, but > there are some legacy motherboard-type stuff where we only make a couple > a year, where it doesn't warrant the re-design (or the voltage level > translators) to go with a newer (and non-5V) FPGA. > > Is my (carbon-based) memory going bad, or have these discontinued, > legacy parts been revived due to demand? > > Jon Perhaps in the downturn, ANY demand is good demand ! ;) Certainly 5V is not going away as many predicted, and in many sectors is making a comeback. (but perhaps not at the cutting edge of FPGA) -jgArticle: 140493
In ISE 11.1 the license model has changed. 1.The restricted license model is in conflict with a long time availability. 2.It is a problem for users using reconfiguration. 3.FPGAS are like hardware. Now with limited access. This license model makes no sence for XILINX and makes it more complicate and uncertain for there users. 1.The restricted license model is in conflict with a long time availability. Until this ISE software was easy to install on different computers. There was no admin account nessesary. Run more than one installation on different computers was no problem. After 15 years you could quite shure this works. Now when you change your computer you need a new license. I need design's which need ISE 4. In 10 years I will have design which need ISE 11. And then? 2. This is hard for reconfiguration users. They have systems that need design software, all the time of the project livetime. May be you must make a design modifikation(or new design) every week. These hardcore user lost: The possibility to run more than one instance on different computers. This helps in more than one way. 1. Finding out bitstream patterns for partioal reconfiguration. 2. Find a good routing solution very quick. 3.FPGAS are like hardware. Now with limited access. The users trust on FPGA. But a strict license model makes the access to design software uncertain.Article: 140494
hi can not find in the datasheets, i need to know if the RAM blocks are known 0 filled at power up or not. Actel docs only talk about methods of init, but do not seem to mention the power up value of the ram cells AnttiArticle: 140495
On May 15, 6:15=A0am, r.frido...@gmx.de wrote: > In ISE 11.1 the license model has changed. > > 1.The restricted license model is in conflict with a long time > availability. > 2.It is a problem for users using reconfiguration. > 3.FPGAS are like hardware. Now with limited access. > > This license model makes no sence for XILINX and > =A0 =A0makes it more complicate and uncertain for there users. > > 1.The restricted license model is in conflict with a long time > availability. > > Until this ISE software was easy to install on different computers. > There was no admin account nessesary. > Run more than one installation on different computers was no problem. > After 15 years you could quite shure this works. > > Now when you change your computer you need a new license. > I need design's which need ISE 4. > In 10 years I will have design which need ISE 11. And then? > > 2. > This is hard for reconfiguration users. > They have systems that need design software, all the time of the > project livetime. > May be you must make a design modifikation(or new design) every week. > These hardcore user lost: > =A0The possibility to run more than one instance on different computers. > =A0 =A0This helps in more than one way. > =A0 =A0 =A0 =A01. Finding out bitstream patterns for partioal reconfigura= tion. > =A0 =A0 =A0 =A02. Find a good routing solution very quick. > > 3.FPGAS are like hardware. Now with limited access. > =A0The users trust on FPGA. > =A0But a strict license model makes the access to design software > uncertain. Xilinx (top management, marketing..) expects you 1) use only the leading family IC (those that are not yet available from the distributors) 2) do not think there is any commercial use for partial reconfiguration 3) of course expects you to pay EACH YEAR for the licenses, also for your products in long maintenance so see, the problem does not exist for them. I bet the flexLM will not at all work or be available in 10 years from now, so chances using 11.1 in that time are nil AnttiArticle: 140496
Antti.Lukats@googlemail.com wrote: > I bet the flexLM will not at all work or be available in 10 years from > now, so chances using 11.1 in that time are nil Usually the EDA firms have been quite good in supplying even really old licenses if needed, sometimes installation media is the bigger problem. I think flexlm is already 20 years old, so it is not a new thing ;) One big problem is also to find the HW/SW platform to run those 15+ year old software packages. How many for example has working HP Apollo or HP9000 machines available ;) Sun sparc software is little easier, because Solaris can run old SunOS software. Maybe we still use x86 15+ years on, but maybe not. Virtualization of course helps in maintaining old environments. At least the designs are in digital form now, dusty 5cm thick piles of schematics from old chips are not fun to read, or transfer to electronic form ;) --KimArticle: 140497
On Mar 30, 4:46=A0pm, Andy Ross <andy.ross...@gmail.com> wrote: > I recently bought a Digilent Nexys 2 board, and after a few days of > research got to the point where I can successfully program it over USB > from a Linux host without the use of a separate (and expensive!) JTAG > interface... Hi, Andy -- Thanks for posting this Perl script, Andy -- it makes a nice self- documenting summary of the hoops to jump through. I've been playing with the same board as well over the past week or so, attempting to build a C API that's just enough to support standalone PC-hosted FPGA apps (data acquisition, SDR, and so forth). I'm working in Win32 but there's nothing really OS-specific about it. The API is actually running OK in a limited fashion (see below), and is relatively short and to the point: int N2LoadFX2Image(CCyUSBDevice *device, char *image, int image_bytes) void N2SetFX2ClockMHz(CCyUSBDevice *device, int MHz) int N2LoadSpartan3EImage(CCyUSBDevice *device, char *image, int image_bytes) The whole thing lives in just two C files -- fx2_ctrl.c which sdcc turns into an image file suitable for passing to the N2LoadFX2Image() function, and nexys2.cpp which is the USB-over-JTAG host API. An application built with this API doesn't need any external projects, libraries, scripts, tools, shells, or whatever. I'm using the stock CyUSB driver from the Cypress FX2 devkit, which can talk to the Nexys2 if you cut the JP6 trace and install a jumper to disable the EEPROM that the FX2 normally boots from. (I had problems trying to override the EEPROM code, hence the need for the jumper to switch between "API mode" and "Adept mode," and it didn't seem vital to pursue the issue too far given the jumper pads provided by Digilent.) I also have it working under the older EzUSB driver from the same devkit; presumably it wouldn't be hard to support libusb as well. So: I'm fine with putting the API and its source out there for anyone else who wants to play with it, but I'm hoping to deal with one troubling issue first. Currently, JP9 has to be in the ROM (Master Serial/Platform Flash) position, not the JTAG position, and you have to use -StartupClk:CClk to build the .bit file. If you set JP9 to JTAG and use -StartupClk:JtagClk, the .bit upload fails, and the DONE light never comes on. I don't feel comfortable releasing the code until I have a better understanding of what's up with that. My questions come down to these: 1) Regardless of the M2:M0 bits resulting from a given JP9 setting, I'm still considered to be using "JTAG configuration" as long as I'm sending the .bit image via the JTAG TAP state machine, correct? 2) Assuming that's true, I understand that the M2:M0 bits are ignored during a boundary-scan upload... but then, why does -StartupClk:CClk work OK for JTAG configurations if, and only if, M2:M0 are set for Master Serial mode (000)? Page 250 of Xilinx's UG332 v1.5 suggests that it won't work at all -- it's JtagClk or nothing if you're performing JTAG configuration. 3) Most, but not all, of the Xilinx documentation says that a a successful upload with the JTAG jumper setting and -StartupClk:JtagClk requires a JSTART instruction followed by >=3D 12 TCK ticks after the .bit image is transferred. I've spent quite a bit of time trying to get JSTART to do something, following the guidelines in various Xilinx manuals, with no luck. No state-machine sequences I've tried have yielded a successful configuration with JP9=3DJTAG/- StartupClk:JtagClk. The JSTART thing bugs me because of how flaky its documentation is. In fact, newer versions of XAPP058 no longer mention JSTART at all, while various open-source USB-JTAG implementations still use it with various chips. I'm fine with including a readme note that says "You must set JP9 to the 'ROM' position and use -StartupClk:CClk," but clearly there's *some* way to use the JTAG/StartupClk:JtagClk technique, since Adept can use it. Any opinions on whether it's safe/ smart to ignore this issue? Finally, apologies for hijacking your Linux-specific thread with some lower-level minutiae, but this seems to be a good place to catch the attention of people who're more familiar with Spartan3E config topics. Would be nice to hear from anyone with a clue stick. > Hopefully this will help other newbies with the learning curve. =A0Let > me know if something doesn't work, or if there are questions. More than you bargained for, I'm sure! -- john, KE5FXArticle: 140498
On May 13, 10:13=A0pm, bigca...@gmail.com wrote: > Dear All: > > I am thinking about my system, the picture is here: > > http://www.flickr.com/photos/26914086@N05/3528643109/sizes/l/ > > I want to transfer the raw/processed image sensor data to USB 2.0 or > dpram. > > Two choices: > > 1. ADC -> DSP, this means parallel ADC, then DSP processed data -> > USB, FPGA works as a coprocessor, use FPGA's DSP (difficult), FPGA- > > >DPRAM > > 2. ADC -> FPGA, this means serial ADC or whatever, then FPGA<---- > EMIF---->DSP processed data, data feedbacked from DSP to FPGA -> USB, > DSP works as a coprocessor. > In choice 2, the USB could also connect from DSP but this will > accelerate processed data transfer, decelerate the raw data transfer. What kind of processing do you need to do? If you are mostly concerned with taking in the camera data, fpga is certainly faster. It is also faster than dsp for the processing where algorithms have parallelisms in them. It also depends on your preference in implementing algorithms in hardware or software. > > Other questions: > > I also need to store raw data, thus the data saving path will be > different: > Choice 1: the raw data will be from ADC -> DSP -> FLASH > Choice 2: the raw data will be from ADC -> FPGA -> FLASH (Is Flash > good for fast data saving, or use EEPROM instead?) How much of the data you need to store. > > It will meet the same question when I save processed data on board. > > The last question is FIFO vs. DPRAM, FIFO could be implemented in > FPGA, could DPRAM be implemented in FPGA? the DPRAM has more > flexibility for sure. > > Thanks!Article: 140499
>> Well the pricing of S3A+SPI flash compared to S3AN seems to support this... >> Single-chip and single-supply are nice, but not if the additional cost is several times that of >> external regulator/flash! > >What pricing do you have for these parts? I'm not clear on which are >saying is the expensive option. Last time I looked at pricing on Digikey, the AN was noticeably more then the A plus the cost of an SPI flash - this was a while ago though. >> >The only issue may be availability, but then I have never found *any* >> >FPGA that they maintain significant amounts of stock at all times. >> >Mouser sells Lattice, but the inventory is mostly at Lattice and is >> >drop shipped. >> >> Farnell also list several Lattice devices, so availability appears to at least be better than >> Xilinx. > >Xilinx should be as available as the others, no? Findchips.com search for xc3s50a shows 7 lines in stock at 2 distributors Findchips.com search for LFEC1 (Lattice) shows about 20 lines in stock at 4 distis.
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