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
mitrusc1980-newsgroup@yahoo.com.br (Marcio A. A. Fialho) wrote: > After searching the Web, I've found out that Actel manufactures micro > antifuse FPGAs. These would be fine, but I would like to know if are > there any other alternatives besides Actel FPGAs. Since Xilinx stopped manufacturing such fpgas, I know no alternative fpga supplier for Actel. You could of course contact Xilinx to see if a reprogramable device is suitable for you. > The device should have around 2500 user gates or more. What to you mean with "user gates"? 2input-NAND? 4 input LUT When an RH1020 is to small you need an RT54SX32S. But be aware, there's currently a relability problem when using the RT54SX-S devices. > Reliability is a concern to us, and availability of a similar or > equivalent, in System Programmable (ISP), part would be a plus. When using the 5V IO, you will have trouble finding a reprogrammable equivalent. > P.S: ASICs (Field Gate Arrays) would be OK, provided it cost less than > US$10,000.00 and takes less than a month or two to be fabricated. In > case we opt for an ASIC, only around 3-5 units would be produced. I know no alternative when spending 30-50k$ for that number. AFAIK there are Actel fpgas above 10k$ per device.Article: 76151
> http://www.universalscan.com > Thanks for your input. It seems that the trial version of universalscan supports flashprogramming and hopefully my AM29F010 too! That would be the easyest solution, the price seens to be fair if it keeps the promises. WolfgangArticle: 76152
On Thu, 25 Nov 2004 22:12:57 +0100, Marcin Olak wrote: > Hello, > >> Why bother with 80386? > > Anyone can write programmes for embedded systems with 386 processor > using tools, everybody's familliar with. It's just mere PC-AT. No additional > knowledge needed to program it. > No - the great majority of programmers and tools for x86 processors are for non-embedded systems. If you have a big enough and fast enough embedded x86 system, you can pretend that embedded issues like efficiency, memory footprint, and limited resources don't matter, and then allow your pc-programmers to work on it. That gives you access to cheaper programmers and lower time-to-market, at a higher cost of hardware. But you won't get that kind of performance from an 386 core on an fpga - a cheapo embedded x86 chip will give you ten times the performance for a tenth of the cost. >> With other CPU architectures you can run your >> CPU faster, get better system performance, and use less LUT in your >> FPGA. > > In some cases time-to-market factor may have the biggest priority : ) > > greetings! > Marcin OlakArticle: 76153
I thought I'd give my 2 cents on this matter. Altera and Xilinx both make excellent products. They make state of the art VLSI circuits, using technologies other manufacturers dream of. 90nm being one of them. As with respect on who's the best, that's very hard to say. My suggestion is, don't listen to Austin or Paul. Or, for that matter anyone from Altera or Xilinx. They are great people, and always help out whenever they can on this newsgroup. But, let's face it, they're a bit biased. If Austin said Altera is better than Xiinx, he'd be admitting he's no good at what he does. Same goes for Paul. As for benchmarks, I believe what Altera says. Or most of it. What they can do is what we all do, and that is compare devices that are available on the market. And, at this point in time, the Stratix II is the best FPGA on the market. So, if you need it today, go out and buy a Stratix II. Having said that, the V4, once in full production, will probably be a better device. But by that time Altera might have another device in the pipeline, almost ready to go out. So there you have it. It's a pedulum effect. Right now, go for Stratix II. At some point in the future, the advantage will Xilinx's. And at some other point, it will swing back to Altera. The important thing is, of course, that Xilinx and Altera will keep on making excellent devices, all the better for us users!! Have a nice day everyone! On Wed, 24 Nov 2004 07:56:57 -0800, Austin Lesea <austin@xilinx.com> wrote: >Varun, > >Your best bet is to contact the FAE (Field Applications Engineers) for >both campanies, and have them explain exactly what their claims are >based on. > >What speed grades were compared (e.g. their fastest with our mid-grade)? > >What were the settings of the synthesis tools (e.g. their default vs our >default -- we default for speed of synthesis, theirs for a compromise of >performance)? > >What effort was made to use device specific features (e.g. theirs a lot, >ours a little)? > >What choice of device was made (e.g. their only one choice, versus our >three options to best fit: LX for logic, SX for DSP, and FX for >networking and comms)? > > >Or, you could do like the other posters' suggest: IGNORE IT and do your >own benchmark by examining specifications and trying out some intended >critical logic, and/or examining the offering of IP from each company >(and its perfomance). > >Who is to say which device is 'better'? Only after careful study, and >use of specific features that may offer an improvement can one make a >decision. And that decision only holds for that one (type of) design! > >The "speed superiority" claims appeared three days after we announced >the availability of three V4 parts as engineering samples.....compared >to their unavailability. Hey it ain't fun when your foundry can't >supply the parts to you, is it? > >Our 90nm offerings are succeeding because we did engage early with our >fab partners, and did shake the process out. If you wait until the >process is stable, you will wait forever. If you don't want the >process, you are dependent on other larger customers of the fab.....and >maybe they are making 130nm ASICs and are perfectly happy to wait until >someone else has paid for the 90nm wafer starts to shake out the new >process. And who will use the triple oxide process for reduce leakage >and power on currents? No one but an FPGA vendor. No process, no >performance. > >Our fabs like us for our willingness to be full partners in the >development of a new advanced process. I think our customers understand >that sometimes there will be rough spots in a new introduction of a new >product on a new process, but overall we continue to offer superior >products (in my opinion). > >Austin > > >Varun Jindal wrote: > >> hello all, >> >> i have been reading a lot about performance comparisons between >> leading FPGA chip makers on hteir web-sites. both claim improvement >> upon the other by metrics of 20 - 40 % .... though none has ever >> described what exactly was compared. >> >> are there resources available on the net, which compare different >> architecture in detail (and also impartially) .. !! ?? >> >> -- Varun.Article: 76154
Hello! as I see there are people here using Altera Quartus II. Has anyone succeeded installing Quartus on systems other than RedHat? I'm looking for hints how to run the installer with csh on a Debian Linux with kernel 2.6.8. Any help is greatly appreciated. Mat --Article: 76155
OK, I've tried a simple project in Lattice ispLever software and it tells me the number of pin used, number of registers and the number of logic pterms. Are the pterms equivalent to macrocell? "General Schvantzkoph" <schvantzkoph@yahoo.com> schrieb im Newsbeitrag news:pan.2004.11.25.18.51.15.32873@yahoo.com... > On Thu, 25 Nov 2004 13:05:14 +0100, Mouarf wrote: > >> hello all, >> >> For a hobbyist purpose, I want to drive an LCD display (320x240) with a >> CPLD >> or FPGA in a standalone device (weather station). I've already played >> with >> FPGA and VHDL for some projects but I was never involved in the hardware >> part of such projects. >> >> The CPLD would have to read data (bitmap picture) from a dual port RAM >> and >> write it to the 4 bit data input of the LCD controller (+control lines, >> clock...). On the other side of the RAM, a microcontroller will update >> sometimes the content of the picture to be displayed. >> >> I would like to know how to estimate the number of gate needed for the >> project in order to buy the cheapest CPLD that fits the number of gate. >> >> Do I need first to design the VHDL part and synthetize to know the number >> of >> gate and then choose the CPLD? >> >> I do not really understand the difference between CPLD and FPGA and what >> is >> better for me. >> >> For a CPLD, the configuration is non volatile and in the FPGA it is >> volatile so a reconfiguration is needed on each start (via configuration >> EEPROM or JTAG programming) but the FPGA is much more powerfull. Correct? >> >> Is a CPLD enough for my project? I'm turning around Xilinx XC9536 which >> seems to be very often used nowadays, is it a good choice for this >> project? >> >> >> Many thanks by advance. > > Since this a learning experience for you I'd suggest that you design, > simulate and synthesize it before you attempt to build any hardware. The > best way to get a feel for what a logic family is capable of is to try > a number of designs. After a while you'll be able to look at a project and > know what the right device is. >Article: 76156
"Alex Gibson" <me@privacy.net> wrote in message news:<30j6d7F313dh0U4@uni-berlin.de>... > "Jack// ani" <nospam4u_jack@yahoo.com> wrote in message > news:86040da6.0411200551.6609a567@posting.google.com... I was expecting Leon to solve my query! It appears that he is out or no more interested in me. BTW, I got answer to all the questions except one: What is the frequency to crystal oscillator used here http://www.geocities.com/leon_heller/pld_starter.html , it is mentioned no where! I'm still in a hope that some one will help me! I think is should be 50Mhz…but not sure. ThanksArticle: 76157
"Mouarf" <mouarf@chezmoi.fr> wrote in message news:41a742ca$0$2337$626a14ce@news.free.fr... > OK, > > I've tried a simple project in Lattice ispLever software and it tells me the > number of pin used, number of registers and the number of logic pterms. > Are the pterms equivalent to macrocell? noArticle: 76158
and are the macrocells almost equivalent between devices of the same range from different manufacturers? "Antti Lukats" <antti@case2000.com> schrieb im Newsbeitrag news:co7gt3$4gl$04$1@news.t-online.com... > > "Mouarf" <mouarf@chezmoi.fr> wrote in message > news:41a742ca$0$2337$626a14ce@news.free.fr... >> OK, >> >> I've tried a simple project in Lattice ispLever software and it tells me > the >> number of pin used, number of registers and the number of logic pterms. >> Are the pterms equivalent to macrocell? > > no > >Article: 76159
Marcio A. A. Fialho wrote: > I'm looking for a rad-tolerant, non-volatile (preferably programmable > at once) FPGA or CPLD, for a new project (a satellite instrument). > > ... > P.S: ASICs (Field Gate Arrays) would be OK, provided it cost less than > US$10,000.00 and takes less than a month or two to be fabricated. In > case we opt for an ASIC, only around 3-5 units would be produced. > Hmmm... have you checked the prices of rad hard parts? You might be in for a rude shock, even with Actel FPGAs.Article: 76160
Hi Mat, > as I see there are people here using Altera Quartus II. > Has anyone succeeded installing Quartus on systems other than RedHat? > I'm looking for hints how to run the installer with csh on a Debian > Linux with kernel 2.6.8. Any help is greatly appreciated. > Mat I'm running Quartus on a Gentoo box having used any sort of kernel ranging from 2.4.18 through my current 2.6.9 (and having done 1 successful run on 2.6.10-rc2), and tcsh version 6.13. I have never had any real issues with the installer as long as I ran it from a normal console window. If I run it from a KDE kommand window, for some reason the backspace key gets remapped to something useless, but since the installation procedure mainly involves hitting Enter a few times, then typing a path, and then hitting Enter a few more times again I don't think that that's a show-stopper. Just type "stty sane" once the script finishes. Once installed, if Quartus won't run on your machine, take a good look at the $QUARTUS/adm/qenv.csh script, and make sure that the settings the script automatically makes for a RedHat machine are also set in the non-Redhat part of the settings script (around line 111). The important ones are QUARTUS_MWWM and LD_ASSUME_KERNEL. Both of these should be unnecessary on a Debian machine, unless you compiled your glibc with NTPL threading support, in which case you should definitely add an LD_ASSUME_KERNEL=2.4 line. There's a few more possible hiccups and glitches I've found in the field, but as long as you're using a fairly vanilla installation you should be able to run Quartus just fine. My biggest gripe with the Linux port is that the mouse wheel won't work. If you feel that this is a feature you's like to see as well, complain to Altera, and to Mainsoft, who are the cause of all this trouble because it's their platform layer that doesn't support the mouse wheel. The more people that complain about this, the better. Best regards, Ben SascoArticle: 76161
I would like to second Nick's opinion... The key thing to remember is that Altera and Xilinx are competitors... so of course each's product is better than the other and benchmarks are just that... 'bench' marks.. Altera and Intel have been playing the smoke and mirrors of benchmarking for years.... even MS is getting into the act against Linux ... There are pros and cons for both implementations but I think the most important is the software used to create the FPGA. That's what it boils down too in the long run.. There's an old saying... if you don't like the weather in Florida wait a few minutes and it'll change.. same is true for FPGA's. Unless you need bleeding edge either manufacturer will do... I/O is another thing.. Xilinx seems to support LVDS better than Altera... (especially BUS LVDS).. Also the way you write code will affect the benchmark to some degree too... So my advice to someone is write your code using no built in libraries.. then compile using free tools on both... look at the speeds, delays etc... is it what you want ? is it everything you need ? Do both manufacturers work ? Then throw that out and ask your Xilinx and Altera agents who will give the best price ?? We had a 30% discount for not using Altera in our design :-) When it all comes down to it its not who's better... but if they both work... which gives you the best profit .. its no good having a product that's too expensive to sell! A somewhat sceptical approach. Simon "Nick" <brakepiston@REMOVEyahoo.co.uk> wrote in > I thought I'd give my 2 cents on this matter. > > Altera and Xilinx both make excellent products. They make state of the > art VLSI circuits, using technologies other manufacturers dream of. > 90nm being one of them. > > As with respect on who's the best, that's very hard to say. My > suggestion is, don't listen to Austin or Paul. Or, for that matter > anyone from Altera or Xilinx. They are great people, and always help > out whenever they can on this newsgroup. But, let's face it, they're a > bit biased. > > If Austin said Altera is better than Xiinx, he'd be admitting he's no > good at what he does. Same goes for Paul. > > As for benchmarks, I believe what Altera says. Or most of it. What > they can do is what we all do, and that is compare devices that are > available on the market. And, at this point in time, the Stratix II is > the best FPGA on the market. So, if you need it today, go out and buy > a Stratix II. > > Having said that, the V4, once in full production, will probably be a > better device. But by that time Altera might have another device in > the pipeline, almost ready to go out. > > So there you have it. It's a pedulum effect. Right now, go for Stratix > II. At some point in the future, the advantage will Xilinx's. And at > some other point, it will swing back to Altera. > > The important thing is, of course, that Xilinx and Altera will keep on > making excellent devices, all the better for us users!! > > Have a nice day everyone! > > On Wed, 24 Nov 2004 07:56:57 -0800, Austin Lesea <austin@xilinx.com> > wrote: > > >Varun, > > > >Your best bet is to contact the FAE (Field Applications Engineers) for > >both campanies, and have them explain exactly what their claims are > >based on. > > > >What speed grades were compared (e.g. their fastest with our mid-grade)? > > > >What were the settings of the synthesis tools (e.g. their default vs our > >default -- we default for speed of synthesis, theirs for a compromise of > >performance)? > > > >What effort was made to use device specific features (e.g. theirs a lot, > >ours a little)? > > > >What choice of device was made (e.g. their only one choice, versus our > >three options to best fit: LX for logic, SX for DSP, and FX for > >networking and comms)? > > > > > >Or, you could do like the other posters' suggest: IGNORE IT and do your > >own benchmark by examining specifications and trying out some intended > >critical logic, and/or examining the offering of IP from each company > >(and its perfomance). > > > >Who is to say which device is 'better'? Only after careful study, and > >use of specific features that may offer an improvement can one make a > >decision. And that decision only holds for that one (type of) design! > > > >The "speed superiority" claims appeared three days after we announced > >the availability of three V4 parts as engineering samples.....compared > >to their unavailability. Hey it ain't fun when your foundry can't > >supply the parts to you, is it? > > > >Our 90nm offerings are succeeding because we did engage early with our > >fab partners, and did shake the process out. If you wait until the > >process is stable, you will wait forever. If you don't want the > >process, you are dependent on other larger customers of the fab.....and > >maybe they are making 130nm ASICs and are perfectly happy to wait until > >someone else has paid for the 90nm wafer starts to shake out the new > >process. And who will use the triple oxide process for reduce leakage > >and power on currents? No one but an FPGA vendor. No process, no > >performance. > > > >Our fabs like us for our willingness to be full partners in the > >development of a new advanced process. I think our customers understand > >that sometimes there will be rough spots in a new introduction of a new > >product on a new process, but overall we continue to offer superior > >products (in my opinion). > > > >Austin > > > > > >Varun Jindal wrote: > > > >> hello all, > >> > >> i have been reading a lot about performance comparisons between > >> leading FPGA chip makers on hteir web-sites. both claim improvement > >> upon the other by metrics of 20 - 40 % .... though none has ever > >> described what exactly was compared. > >> > >> are there resources available on the net, which compare different > >> architecture in detail (and also impartially) .. !! ?? > >> > >> -- Varun. >Article: 76162
Hi, Matlab SysGen provide a microblaze module that we can have the design of microblaze processor together with other FPGA logic solely defined in the SysGen design environment. But when I try to place more than one microblaze module, says two microblaze communication through some FPGA logics, SysGen fails to compile such a case. Are there any solutions to achieve multi-microblaze in one chip? Many thanks, TerrenceArticle: 76163
Nick, Hmmm. We introduced V4 before SII (as in announced shipments to customers). We shipped thousands of V4 ES parts, more than S2. We shipped both LX60, LX25, and SX35 (three devices from the family). We are getting ready to ship all the others. In production on 90nm a full year ahead (Spartan 3). So how are they 'ahead' this time? One family, no processor(s), no MGTs, no built in FIFOs, .... Too many deficiencies to name. But, you are right, don't take my word for it. How could I possibly be fair? I'll leave the marketing to the marketeers. But when I see patently false statements, I will respond. Austin Nick wrote: > I thought I'd give my 2 cents on this matter. > > Altera and Xilinx both make excellent products. They make state of the > art VLSI circuits, using technologies other manufacturers dream of. > 90nm being one of them. > > As with respect on who's the best, that's very hard to say. My > suggestion is, don't listen to Austin or Paul. Or, for that matter > anyone from Altera or Xilinx. They are great people, and always help > out whenever they can on this newsgroup. But, let's face it, they're a > bit biased. > > If Austin said Altera is better than Xiinx, he'd be admitting he's no > good at what he does. Same goes for Paul. > > As for benchmarks, I believe what Altera says. Or most of it. What > they can do is what we all do, and that is compare devices that are > available on the market. And, at this point in time, the Stratix II is > the best FPGA on the market. So, if you need it today, go out and buy > a Stratix II. > > Having said that, the V4, once in full production, will probably be a > better device. But by that time Altera might have another device in > the pipeline, almost ready to go out. > > So there you have it. It's a pedulum effect. Right now, go for Stratix > II. At some point in the future, the advantage will Xilinx's. And at > some other point, it will swing back to Altera. > > The important thing is, of course, that Xilinx and Altera will keep on > making excellent devices, all the better for us users!! > > Have a nice day everyone! > > On Wed, 24 Nov 2004 07:56:57 -0800, Austin Lesea <austin@xilinx.com> > wrote: > > >>Varun, >> >>Your best bet is to contact the FAE (Field Applications Engineers) for >>both campanies, and have them explain exactly what their claims are >>based on. >> >>What speed grades were compared (e.g. their fastest with our mid-grade)? >> >>What were the settings of the synthesis tools (e.g. their default vs our >>default -- we default for speed of synthesis, theirs for a compromise of >>performance)? >> >>What effort was made to use device specific features (e.g. theirs a lot, >>ours a little)? >> >>What choice of device was made (e.g. their only one choice, versus our >>three options to best fit: LX for logic, SX for DSP, and FX for >>networking and comms)? >> >> >>Or, you could do like the other posters' suggest: IGNORE IT and do your >>own benchmark by examining specifications and trying out some intended >>critical logic, and/or examining the offering of IP from each company >>(and its perfomance). >> >>Who is to say which device is 'better'? Only after careful study, and >>use of specific features that may offer an improvement can one make a >>decision. And that decision only holds for that one (type of) design! >> >>The "speed superiority" claims appeared three days after we announced >>the availability of three V4 parts as engineering samples.....compared >>to their unavailability. Hey it ain't fun when your foundry can't >>supply the parts to you, is it? >> >>Our 90nm offerings are succeeding because we did engage early with our >>fab partners, and did shake the process out. If you wait until the >>process is stable, you will wait forever. If you don't want the >>process, you are dependent on other larger customers of the fab.....and >>maybe they are making 130nm ASICs and are perfectly happy to wait until >>someone else has paid for the 90nm wafer starts to shake out the new >>process. And who will use the triple oxide process for reduce leakage >>and power on currents? No one but an FPGA vendor. No process, no >>performance. >> >>Our fabs like us for our willingness to be full partners in the >>development of a new advanced process. I think our customers understand >>that sometimes there will be rough spots in a new introduction of a new >>product on a new process, but overall we continue to offer superior >>products (in my opinion). >> >>Austin >> >> >>Varun Jindal wrote: >> >> >>>hello all, >>> >>>i have been reading a lot about performance comparisons between >>>leading FPGA chip makers on hteir web-sites. both claim improvement >>>upon the other by metrics of 20 - 40 % .... though none has ever >>>described what exactly was compared. >>> >>>are there resources available on the net, which compare different >>>architecture in detail (and also impartially) .. !! ?? >>> >>>-- Varun. > >Article: 76164
Mouarf wrote: > and are the macrocells almost equivalent between devices of the same range > from different manufacturers? An easy answer is that you would like to download software from each of those manufacturers try your design on each of them. I am going to do just that. vax, 9000Article: 76165
>So my advice to someone is write your code using no built in libraries.. >then compile using free tools on both... look at the speeds, delays etc... >is it what you want ? is it everything you need ? Do both manufacturers >work ? Anybody have a rule-of-thumb on how much performance you give up if you don't tweak your code to take advantage of a vendor's features/quirks? (both software and hardware) Are the free tools appropriate if we are discussing volumes big enough to be worth arguing about? -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 76166
Simon Peacock wrote:
>>So my advice to someone is write your code using no built in libraries..
>>then compile using free tools on both... look at the speeds, delays etc...
>>is it what you want ? is it everything you need ? Do both manufacturers
>>work ?
Mike Treseler wrote:
Yes, start with your own functional synthesis code
and compare utilization and static timing for all
devices under consideration.
That's also a good way to design portable code.
Synthesis in 2004 is surprisingly efficient, and there's
not much on the chip besides the clock PLL that can't
be inferred from your own code.
Hal Murray wrote:
> Anybody have a rule-of-thumb on how much performance you give up if
> you don't tweak your code to take advantage of a vendor's
> features/quirks? (both software and hardware)
My rule is try it and see.
It doesn't take long to run static
timing to get the exact answer for the
actual routed design.
Sometimes I can catch the synth on small inefficiencies,
but then it often kicks my rear on bigger things.
And if I spend even one minute fussing with each of
50,000 logic cells, I'd probably be brewing mocha lattes today.
-- Mike Treseler
Article: 76167Hello everybody, Iam using ISE 6.2 with XST as synthesis tool. So far so good. But Now I have a design with plenty of timing margin (just 36 MHz ;-) and the goal is to fit it into a XC2S50E. At the end, it doesnt. So looking a little closer to the reports, I saw in the MAP report something like this. blabla 1000 LUTs used 300 LUTs used a s route-thru. How is this to understand? I understand it this way, that XST (and the other tools) use a LUT to feed data into a FF, but only 1 input is used, so the LUT has no real function, maybe only a inversion. Is this how it works? So how can I tell the software not to use LUTs as route thru, even if this will decrease timing performance? I mean it is tecnically possible to use th BY input to feed data into a FF. Regards FalkArticle: 76168
Hi I was wondering if anyone here can help me. I need to infer a true dual port BRAM with seperate clk, addr, data, en and wr lines on a Spartan-3 device but according to the XST manual this is not supported and after googling for a couple of days I've come to a dead end. I need this in order to provide an external memory interface to some shared memory and the design is so simple and clean at the moment that I really want avoid having to use an async FIFO which would need alot of re-jigging to the upper levels and make things quite ugly. Does anyone know if this is even possible with the free ISE Webpack tools? Or will it require me buying some other software? This is my first FPGA design and is more of a hobby that may have some commercial potential so I cant really justify spending lots of $$$ for something I may only require the use of once. Many thanks in advance.Article: 76169
Hi Hal, > Are the free tools appropriate if we are discussing volumes big enough > to be worth arguing about? The Quartus II Web Edition is almost fully-featured when it comes to push-button place & route. Web Edition provides all synthesis & fitter options intended for optimizing design performance and/or area, with the exception of the physical synthesis options. Physical synthesis can be a huge boost on many designs (10-15%?), so its ommision is a bit of a downside to using the Web Edition. It may be included in a future edition of the product. The other issue is device support. If you require a large Stratix II device, they are not shipped with the Web Edition, so you will not be able to evaluate those devices. Regards, Paul Leventis Altera Corp.Article: 76170
Kotek Barajazz <darkgold@lycos.co.uk> wrote: > I need to infer a true dual port BRAM with seperate clk, addr, data, > en and wr lines on a Spartan-3 device but according to the XST manual > this is not supported and after googling for a couple of days I've > come to a dead end. > > I need this in order to provide an external memory interface to some > shared memory and the design is so simple and clean at the moment that > I really want avoid having to use an async FIFO which would need alot > of re-jigging to the upper levels and make things quite ugly. > > Does anyone know if this is even possible with the free ISE Webpack > tools? Or will it require me buying some other software? This is my > first FPGA design and is more of a hobby that may have some commercial > potential so I cant really justify spending lots of $$$ for something > I may only require the use of once. You cannot infer dual-port BRAM with Webpack, but you can instantiate primitives. See http://groups.google.dk/groups?hl=en&lr=&selm=vGhO5.241%24ey5.18887%40news000.worldonline.dk Karl OlsenArticle: 76171
In article <W6idnWZS49YksjXcRVn-jg@megapath.net>, Hal Murray <hmurray@suespammers.org> wrote: >>So my advice to someone is write your code using no built in libraries.. >>then compile using free tools on both... look at the speeds, delays etc... >>is it what you want ? is it everything you need ? Do both manufacturers >>work ? > >Anybody have a rule-of-thumb on how much performance you give up if >you don't tweak your code to take advantage of a vendor's >features/quirks? (both software and hardware) Placement and careful pipelining are big wins. My AES design of a few years ago was about 1/2 the size and 2x the performance of the academic synthesized versions because I hand-mapped to the Virtex E/Spartan II family including placement. Placement alone can be a good 20%+ performance win (and better tooltimes as well, as I'm rediscovering), the application-specific mapping gave the area savings, and architecturally-aware pipelining is a HUGE win on the performance. So just one data point, but taking advantages of layout, architectural mapping, and specific quirks (eg, the BlockRAMs are the right size to do both the AES S-box and ONE of the Galios multiplies of the mix-column operation. The register can be used independantly of the LUT under MOST conditions. SRL16s need an output register but are good for retiming chains, etc) are hugely critical for area & performance. >Are the free tools appropriate if we are discussing volumes big enough >to be worth arguing about? To my mind, the reason to select Brand A vs Brand X should come down to two major things: Familiarity. I'm a Brand X guy, because I'm more familiar with the architecture (and Xilinx has given a lot of support to UC Berkeley over the years, which has created this familiarity). NON-FPGA features: For the work I'm currently doing (working on NIDS-in-FPGA), the MGTs are an absolute essential for the network interfaces, and the processor may become useful in the very near-term future, so its very useful to have in place. -- Nicholas C. Weaver. to reply email to "nweaver" at the domain icsi.berkeley.eduArticle: 76172
Kotek Barajazz wrote:
> I need to infer a true dual port BRAM with seperate clk, addr, data,
> en and wr lines on a Spartan-3 device but according to the XST manual
> this is not supported and after googling for a couple of days I've
> come to a dead end.
>
> I need this in order to provide an external memory interface to some
> shared memory and the design is so simple and clean at the moment that
> I really want avoid having to use an async FIFO which would need alot
> of re-jigging to the upper levels and make things quite ugly.
A fifo-like controller requires one read-only port
and one write-only port. Such a two port description
infers the "true dual port BRAM" just fine,
but with the extra read and write controls tied off.
As an added benefit, the description is portable
across vendors. Related posting:
http://groups.google.com/groups?q=infer+RAM_B4_S16_S16
-- Mike Treseler
Article: 76173
Hi,
I got this error message from my laptop while on my work place desktop it
didn't have this at all.
The message is this:
ERROR: iMPACK:583 - '1': The idcode read from the device does not match
the idcode in the bsdl file.
Both PCs are running Win2k/SP4. I am using the latest iMPACK 6.3.02i. Can
somebody help me to explain
why this is happening and how to fix it?
Jack
Article: 76174
Lawrence Kiss wrote:
>
> Thanks for the reply Peter.
>
> My 8051 specifies a minimum high logiv level at .7*VCC = 3.5V. What is the
> gaurentee that the Spartan 3 will ever output a 3.3V signal? I would think
> that I need to pull up to VCC=5V not 3.3V.
I am pretty sure you can use a voltage divider connected to Vcc rather
than ground to protect the Spartan 3 input and give you a higher Vin
voltage.
| Vcc5 |
| | |
| / |
| \ R1 |
8051 | / | Spartan 3
| \ |
| | R2 |
In |------+----\/\/-----| Out
| |
| |
You need to find an appropriate ratio to give you both high and low
voltages that meet your input spec. The absolute values will be set by
considering the max input current at the Spartan 3 when the output is
pulled above Vcc3.
In reality, I don't think the resistor divider is needed since the
Spartan output will be pulled above the 3.3 volt rail until the
protection diodes clamp, at Vcc3+0.5 IIRC. But the divider can give you
a bit more noise margin on the high side at the expense of noise margin
on the low side.
--
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 FAX
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