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
Dear All,
At last an answer to these interminable threads about which is
better! Just go to www.googlefight.com !
VHDL v. Verilog, winner is VHDL.
Xilinx v. Altera, winner is Altera.
Synchronous v. Asynchronous, winner is Asynchronous.
Hardware v. Software, winner is software.
It's foolproof!?
cheers, Syms.
Article: 48276
I have a PCI model for verilog simulators which includes:
arbiter
master(s)
slave(s)
monitor with GUI
It is designed to interface with PCI designs to exercise them and display
activity and protocol errors.
If there is interest, I will release this as open-source software for
free download.
Requirements: Unix/Linux/Solaris system with gcc compiler
Verilog simulator with PLI interface
Please email me if you would find this useful.
Dave Nelson
pci_model@nelsim.com
Article: 48277"Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message news:ao9q80$rqb$1@agate.berkeley.edu... > In article <3DA867BB.40301@mail.com>, John_H <johnhandwork@mail.com> wrote: > >CPLDs are typically not SRAM based and maintain their programming on > >startup. > > > >Take a look at the "System ACE" configuration solution from Xilinx, for > >instance. This method can use Compact Flash cards which is close to > >what you're looking for. Compact Flash is easier to use than SmartMedia > >cards because both systems need some intelligence in the interface; in > >SmartMedia, the intelligence is in the host or the reader while Compact > >Flash has the smarts on the card. This solution is great for the large > >FPGA designs but not so good for the little ones (cost and space). > > Unless, of course, your app would benefit from having some other > storage beyond just teh configuration, in which case Compact Flash is > nice. > > Compact Flash is nice and cheap for 32, 64, and 128 MB cards, with > microdrives if you need 1 GB of storage. Last time I checked...a Xilinx PROM was something like $10+. The SmartMedia cards are only that much, if not less for the same bit capacity. Of course, you need the socket and the CPLD too... AustinArticle: 48278
Falk Brunner wrote: > > "emanuel stiebler" <emu@ecubics.com> schrieb im Newsbeitrag > news:3DABA42C.8321741C@ecubics.com... > > Hi, > > > > anybody out here has some insight, why the 8 bit picoblaze (up 112 MHz) > > 112 MHz (one hundred twelf megahertz???) > In what device? the fastest Virtex-II?? http://www.xilinx.com/ipcenter/processor_central/picoblaze/index.htm was even a typo. It runs at 116 MHz ;-) at least in the press release ... > My expirience is somewhere 50 MHz in a -5/-6 Spartan-II(E). There are two "picoblazes". One for the Spartan, one for the Virtex. Pretty different beasts. > > is clocked lower than the 32 bit microblaze (up 150 MHz) ? > > Looks like the microblaze is more pipelied than the picoblaze (which has > some pipelining too). Picoblaze (Hello Ken ;-) was developed for minimum > size on top priority, speed was second (AFAIK) AFAIRC, the microblaze still needs only two clock per instruction ... cheersArticle: 48279
Is there any chance we could see something like this ? I would love to use the speed of the VirtexII on a cheaper PCB. Am I the only one who is dreaming about this packaging ? cheersArticle: 48280
Hi , The xilinx webpack is getting a basic command which is translating AHDL to VHDL files this is a free package, you will have to "pack" a bit some created lines but it speed a lot design migration hope it will help you too -- Use our news server 'news.foorum.com' from anywhere. More details at: http://nnrpinfo.go.foorum.com/Article: 48281
Symon wrote > Just go to www.googlefight.com ! > > VHDL v. Verilog, winner is VHDL. > Xilinx v. Altera, winner is Altera. > Synchronous v. Asynchronous, winner is Asynchronous. > Hardware v. Software, winner is software. schematic beats HDL ;-)Article: 48282
Hi, MicroBlaze is more pipelined and is more floorplanned than PicoBlaze. The 150 MHz for MicroBlaze is on a V2Pro and 116MHz for PicoBlaze is on VII-6. MicroBlaze runs at 135 MHz on a VII-6. Since PicoBlaze is optimized for area and more pipeline has a big area cost in processor design. There is also not that big difference on performance with different datasizes. The carry-chain is pretty fast as soon you starting to use it. A 64-bit MicroBlaze would probably run at 100 MHz and a 8 bit MicroBlaze would just run a little faster than the 32-bit version since the control decoding will probably be the limiting factor. By the way for most instruction MicroBlaze needs only 1 clock/instruction. Göran emanuel stiebler wrote: > Falk Brunner wrote: > > > > "emanuel stiebler" <emu@ecubics.com> schrieb im Newsbeitrag > > news:3DABA42C.8321741C@ecubics.com... > > > Hi, > > > > > > anybody out here has some insight, why the 8 bit picoblaze (up 112 MHz) > > > > 112 MHz (one hundred twelf megahertz???) > > In what device? the fastest Virtex-II?? > > http://www.xilinx.com/ipcenter/processor_central/picoblaze/index.htm > > was even a typo. It runs at 116 MHz ;-) > at least in the press release ... > > > My expirience is somewhere 50 MHz in a -5/-6 Spartan-II(E). > > There are two "picoblazes". One for the Spartan, one for the Virtex. > Pretty different beasts. > > > > is clocked lower than the 32 bit microblaze (up 150 MHz) ? > > > > Looks like the microblaze is more pipelied than the picoblaze (which has > > some pipelining too). Picoblaze (Hello Ken ;-) was developed for minimum > > size on top priority, speed was second (AFAIK) > > AFAIRC, the microblaze still needs only two clock per instruction ... > > cheersArticle: 48283
Just to double check, you are talking about the SET XILINX = {path} in my
config.sys file? (I am running Windows 98 in case this makes any difference)
adrian
> You can do separate installs for 3.3 and 4.2 on the same machine. In
order to
> switch back and forth between them, you need to modify the XILINX
environment
> variable to point to the tools directory you are currently using. Other
than
> that, there is nothing special that needs to be done. IIRC, there was a
new
> xilinx registration number to enter when first installing 4.x, but that is
a
> one-time thing.
>
> I have both 3.3 and 4.2 installed on the same drive, different
sub-directories
> on my NT machine. To switch, I change just the directory name in the
XILINX
> environment variable, then I'm good to go. Can't use both at the same
time
> unless you are strictly command line, in which case you can use the set
command
> to do the enviroment locally.
>
> Noddy wrote:
>
> > Hi,
> >
> > I am presently designing for a Spartan II using Foundation 3.3 software.
We
> > have upgrades (still in their boxes) to Foundation 4.2 aswell as ISE
4.2. We
> > need to upgrade the software sometime as I am going to be redesigning
and
> > modifying for a Spartan IIE.
> >
> > My question is the following: I was under the impression the ISE was
really
> > only useful if I was going to design for Virtex. Under this
understanding,
> > will probably want to install the software for Foundation 4.2. However,
I
> > still want to use Foundation 3.3 as I am still working on the design,
and am
> > worried about the design having problems in 4.2. So what I want to do is
put
> > Foundation 4.2 onto a separate hard drive, and plug into the same
system.
> > Will I have any registry issues? Is it possible to run two versions of
the
> > Xilinx Foundation software on the same machine? Do have to do the entire
> > Xilinx licensing thing again when I install 4.2? Finally, should I
rather be
> > install ISE instead?
> >
> > Thanks
> >
> > Adrian
>
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930 Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>
> "They that give up essential liberty to obtain a little
> temporary safety deserve neither liberty nor safety."
> -Benjamin Franklin, 1759
>
>
Article: 48284"emanuel stiebler" <emu@ecubics.com> schrieb im Newsbeitrag news:3DAC4F58.D2AE56ED@ecubics.com... > > My expirience is somewhere 50 MHz in a -5/-6 Spartan-II(E). > > There are two "picoblazes". One for the Spartan, one for the Virtex. > Pretty different beasts. ?? R u sure? I think there are NOT two picoblaze versions, since Sparten-II (why the hell is everyone talking about Spartan when it is actually Spartan-II, which, our honour, is a BIG difference???) is practically identical to Virtex. > > size on top priority, speed was second (AFAIK) > > AFAIRC, the microblaze still needs only two clock per instruction ... PICOBLAZE (TPFKAKCPSM , decode THIS;-)) executes EVERY instruction in two clock cycles, this was made for simplicity (ressource usage). But still much better than the original stupid 12 clocks/cycle design of the 8051 . .. . I dont know about microblaze. -- MfG FalkArticle: 48285
nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) writes: > In article <6un0pgioiv.fsf@chonsp.franklin.ch>, > Neil Franklin <neil@franklin.ch.remove> wrote: > >> How many users (outside a small cadre of open source true-believers) > >> really do? > > > >As the "small cadre" is already in the 100'000s, those outside are not > >really that important. > > Is the cadre of open source true blieveres that high? Perhaps only 1-2 times 100'000, but it is astonishingly large. There are a lot of people who have got fed up with closed source software. Loads of then to recruit from. And every time the "compromise and use closed when better" party burns its fingers on yet annother free beer product that vanishes without leaving source, the number grows. > >> A very poor analogy. C compilers can be simple (eg lcc), but you lose > >> a good deal of performance (50%). > > > >Which is acceptabe for simple designs. > > We have this with LCC, and I'll argue that it is not acceptable to > most. People use GCC because it is competitive with commercial > tools. If they aren't competitive, all but a few early adopters will > ignore them. GCC also took time. It once was small, then it growed to what it is today. I expect my stuff to start small and grow. So I an designeing for it to be growable, but to already work from small up. How far and how fast will be up to experimentation to see. > Linus Torvald uses Bitkeeper because it does a better job, even if it > does get RMS's panties in a twist. In a _large_ twist. We will see whether Linux gets to regret this move or not. Only time can show that. > >Run it (I assume it to be VHDL or Verilog code) through an compiler > >that targets my stuff as back end. Compare the results. > > The only way which this will occur is if you tie your flow in with the > Xilinx flow: If you want to do routing, accept post-placement XDL. > If you just want to do bitfile manipulation, only do layers on Jbits. > You will probably NEVER be able to do static timing analysis without > being able to read the Xilinx databases. And going through the official formats, all of them, is definitely too much work. So I intend to be just compatible at the two endpoints, source (where programmers put their time) at one, and bitstream (what the chip wants to see) at the other. > I doubt you could ever be independant of the Xilinx flow, but if you > ever DO want to be, you are going to have to leverage that flow for as > much as possible during development. Or not waste time being compatible with it. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Roleplayer - hardware runs the world, software controls the hardware code generates the software, have you coded today?Article: 48286
"Austin Franklin" <austin@da98rkroom.com> schrieb im Newsbeitrag news:uqojb9qj4l5j21@corp.supernews.com... > > "Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message > news:ao9q80$rqb$1@agate.berkeley.edu... > > In article <3DA867BB.40301@mail.com>, John_H <johnhandwork@mail.com> > wrote: > > >CPLDs are typically not SRAM based and maintain their programming on > > >startup. I think this is not quite correct. If you take a closer look to the Xilinx CPLDs datasheets, it says something about . . .configuration is finished within 200us . . . So it looks like that CPLD (from Xilinx) are SRAM based CPLDs + Flash on one chip. -- MfG FalkArticle: 48287
In article <6u8z0zwp72.fsf@chonsp.franklin.ch>, Neil Franklin <neil@franklin.ch.remove> wrote: >> Linus Torvald uses Bitkeeper because it does a better job, even if it >> does get RMS's panties in a twist. > >In a _large_ twist. We will see whether Linux gets to regret this move >or not. Only time can show that. Personally, I think RMS could use a good twisting. I much prefer BSD style liscences, as they have more real freedom. But thats a religious issues, and I will say no more. >> The only way which this will occur is if you tie your flow in with the >> Xilinx flow: If you want to do routing, accept post-placement XDL. >> If you just want to do bitfile manipulation, only do layers on Jbits. >> You will probably NEVER be able to do static timing analysis without >> being able to read the Xilinx databases. > >And going through the official formats, all of them, is definitely too >much work. So I intend to be just compatible at the two endpoints, >source (where programmers put their time) at one, and bitstream (what >the chip wants to see) at the other. That will be a significant mistake, as the amount of work needed to even get the "hello world" of FPGAs to compile will be enormous, an not to mention significantly limiting the reach of your tools. There are also really only 3 points where you should tying in, with each one being a "leapfrog" process where you skip over more of the tools: Post Routing XDL: You should OUTPUT this so you can do static timing analysis. Without static timing analysis, NOBODY even remotely serious will touch your tools. I'm not kidding. Static timing analysis is essential, as there is no other way to know at what clock a desgin can safely run. The only other way is to reverse engineer the database format, with the contents copyrighted so you can't distribute them anyway unless you OK it with Xilinx. So you want to start by using Xilinx static timing analysis, before trying to ask nicely for the database format and permission to distribute. Post Placement XDL: You should start your tool, if you want to start with routing and bitgen, taking this as input. This allows you to test your tool as you construct it, and allows you to leverage the Xilinx toolflow to do mapping and placement and all other upstream stuff. This is a complete description of the design, after mapping, in a form you can use. The only things outside this representation at this point are used for timing-driven back-annotation. EDIF: After you want to start doing mapping and placement as well, this is the format which compilers (all compilers) targeting Xilinx output as, with Xilinx specific libraries. When you are reading in EDIF and the static timing analysis libraries, you have completely subsumed the Xilinx toolflow, which is what you want. Don't bother with post-mapping, pre-placement XDL, it doesn't include any user defined placement on modules, at least in 4.1 (yeah, I'm not going to upgrade, what I got works for me). :( >> I doubt you could ever be independant of the Xilinx flow, but if you >> ever DO want to be, you are going to have to leverage that flow for as >> much as possible during development. > >Or not waste time being compatible with it. It will save you considerably more time than it will cost you, and it will allow you to at least get a skeleton working much earlier than you otherwise would. It will also make your tools usable by others. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 48288
No you are not the only one. The response I get is that the cost is minimal to place the BGA type packages on a circuit board. My experience tends to lead me to think otherwise. When I build a prototype I prefer that the package be something I can solder myself. The fact is that I typically build only a few devices of each type. Usually the prototype stage is only 5 boards or so. I do not have the quantity of boards to allow the assembler to experiment with my PCB in order to tweak their process to mount a BGA on my board. Nor can I use a standard board as the system will contain some very sensitive low noise high spped analog circuitry. As a result I stuck with the SpartanXL for quite a while. Now that the tools do not support the SpartanXL I use the Spartan2E. The Virtex2 would be an awesome device for me if it met three criteria. 1. Available in a more traditional leaded package. 2. More clock buffers readily accessable. Each DCM should have at least 4 clock buffers available. (5 or 6 buffers could be shared between two DCMs acceptably) 3. Parts readily available for purchase in small quantities for prototyping. Xilinx... Are you listening? I hope you are not intentionally trying to cut the small startups out of the picture? That would be a bad move. On the plus side... Having Xilinx people monitor this newsgroup is a very strong plus. That enables me to use the Spartan2 series with some ease. Thanks, Theron "emanuel stiebler" <emu@ecubics.com> wrote in message news:3DAC515B.A359A547@ecubics.com... > Is there any chance we could see something like this ? > I would love to use the speed of the VirtexII on a cheaper PCB. > > Am I the only one who is dreaming about this packaging ? > > cheersArticle: 48289
emanuel stiebler <emu@ecubics.com> wrote: : Is there any chance we could see something like this ? : I would love to use the speed of the VirtexII on a cheaper PCB. : Am I the only one who is dreaming about this packaging ? The question came up before. One answer was, that EMC problems nearly prohibit use of leaded packages for devices fast and powerfull like the virtex. One proposal was to put out a BGA package with 1.27 mm pitch. 4 Layer PCB prototypes with 0.3mm drill, 0.15mm lines/spaces designrules are afordable and a 4 row BGA can be routed with these rules. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 48290
Goran Bilski wrote: > > There is also not that big difference on performance with different datasizes. > The carry-chain is pretty fast as soon you starting to use it. > A 64-bit MicroBlaze would probably run at 100 MHz and a 8 bit MicroBlaze would > just run a little faster than the 32-bit version since the control decoding will > probably be the limiting factor. > > By the way for most instruction MicroBlaze needs only 1 clock/instruction. That was the answer I was looking for, even that I didn't make it clear what exactly my question was ;-) So, we can't go faster at the actual Xilinx parts than around 100 "MIPS", independent, if it is a 8,16,32,64 bit processor, right ? And the problem is really in the instruction decoding, control path. ThanksArticle: 48291
In article <3DAC62E1.5246FDF7@ecubics.com>, emanuel stiebler <emu@ecubics.com> wrote: >That was the answer I was looking for, even that I didn't make >it clear what exactly my question was ;-) > >So, we can't go faster at the actual Xilinx parts than around 100 >"MIPS", >independent, if it is a 8,16,32,64 bit processor, right ? > >And the problem is really in the instruction decoding, control path. Well, you CAN, but you are going to have to go multithreaded. If your critical path is 1 32 bit add + bypassing, yeah, you really can't do any faster. The only way to pipeline this (or the instruction decode, if that is the critical factor) is to use an interleaving, multithreading strategy (aka $C$-slow a microprocessor). -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 48292
symon_brewer@hotmail.com (Symon) wrote: > At last an answer to these interminable threads about which is >better! Just go to www.googlefight.com ! >VHDL v. Verilog, winner is VHDL. >Xilinx v. Altera, winner is Altera. >Synchronous v. Asynchronous, winner is Asynchronous. >Hardware v. Software, winner is software. > It's foolproof!? Completely. The site can also be used to prove sex is 177 times better than VHDL.Article: 48293
Hi, If your definition of MIPS is maximum number of instruction per clock cycle, the 150 MHz MicroBlaze has 150 MIPS. There is also possible to do a 200+ MIPS processor, if you want to optimize around MIPS. A heavy pipelined processor without any forwarding in the pipeline could easy run at 200+ MHz. Would that processor be more efficient than MicroBlaze? I don't think so, the number of stall due to pipeline hazardous will actually give it a lower performance than MicroBlaze. Processors in FPGAs has to be handle more delicate than ASIC processor due to forwarding in pipeline could easy remove all benefits gain by more pipeline stages. In FPGA a mux cost as much as an ALU which is not the case for ASIC or custom design. Another approach is to rely on advanced compiler techniques for handling all the pipeline hazardous but it would make it almost impossible to program the processor in assembler since the user has to do the handling. I personally don't think that this approach would gain that much more performance than MicroBlaze and you have to spend a lot of resources on the compiler which could be used for other stuff. Another approach is to add multi-threading capabilities but I think that multi-processing is better for FPGA than multi-threading. Göran Bilski emanuel stiebler wrote: > Goran Bilski wrote: > > > > There is also not that big difference on performance with different datasizes. > > The carry-chain is pretty fast as soon you starting to use it. > > A 64-bit MicroBlaze would probably run at 100 MHz and a 8 bit MicroBlaze would > > just run a little faster than the 32-bit version since the control decoding will > > probably be the limiting factor. > > > > By the way for most instruction MicroBlaze needs only 1 clock/instruction. > > That was the answer I was looking for, even that I didn't make > it clear what exactly my question was ;-) > > So, we can't go faster at the actual Xilinx parts than around 100 > "MIPS", > independent, if it is a 8,16,32,64 bit processor, right ? > > And the problem is really in the instruction decoding, control path. > > ThanksArticle: 48294
nospam wrote: > symon_brewer@hotmail.com (Symon) wrote: > > > >> At last an answer to these interminable threads about which is >>better! Just go to www.googlefight.com ! > > >>VHDL v. Verilog, winner is VHDL. >>Xilinx v. Altera, winner is Altera. >>Synchronous v. Asynchronous, winner is Asynchronous. >>Hardware v. Software, winner is software. > > >> It's foolproof!? > > > Completely. The site can also be used to prove sex is 177 times better than > VHDL. And HTML is 5.6 times better than sex.Article: 48295
Try using a ff1517 2V8000.... It is the number of pins. Austin Theron Hicks wrote: > Uwe, > I can route the package, I just can't assemble it. Changing the number > of pins won't solve the problem. Furthermore, I don't buy that the EMC > problems are insurmountable. I regularly build ECL circuits at 1GHz in > standard SOIC packages. In fact, try to buy 100K ECL in anthing but leaded > packages be they gullwing or J-lead. The only available packages are > leaded, not BGA. For example the MC100EP32 is rated for 4 Gigahertz toggle > (divide by 2). It is only available in an 8 pin SOIC or 8 pin TSSOP > package. Check the http://www.onsemi.com web site Only the reduced swing > ECL (RSECL) parts go to BGA. Those are rated for 12 GIGAHERTZ toggle. > Unless the problems are simply caused by the number of I/O pins then I > am skeptical of the EMC issue. > > Just my opinionated opinion, > Theron Hicks > > "Uwe Bonnes" <bon@elektron.ikp.physik.tu-darmstadt.de> wrote in message > news:aohn4s$olb$1@news.tu-darmstadt.de... > > emanuel stiebler <emu@ecubics.com> wrote: > > : Is there any chance we could see something like this ? > > : I would love to use the speed of the VirtexII on a cheaper PCB. > > > > : Am I the only one who is dreaming about this packaging ? > > > > The question came up before. One answer was, that EMC problems nearly > > prohibit use of leaded packages for devices fast and powerfull like the > > virtex. One proposal was to put out a BGA package with 1.27 mm pitch. 4 > > Layer PCB prototypes with 0.3mm drill, 0.15mm lines/spaces designrules are > > afordable and a 4 row BGA can be routed with these rules. > > > > Bye > > -- > > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de > > > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 48296
Uwe,
I can route the package, I just can't assemble it. Changing the number
of pins won't solve the problem. Furthermore, I don't buy that the EMC
problems are insurmountable. I regularly build ECL circuits at 1GHz in
standard SOIC packages. In fact, try to buy 100K ECL in anthing but leaded
packages be they gullwing or J-lead. The only available packages are
leaded, not BGA. For example the MC100EP32 is rated for 4 Gigahertz toggle
(divide by 2). It is only available in an 8 pin SOIC or 8 pin TSSOP
package. Check the http://www.onsemi.com web site Only the reduced swing
ECL (RSECL) parts go to BGA. Those are rated for 12 GIGAHERTZ toggle.
Unless the problems are simply caused by the number of I/O pins then I
am skeptical of the EMC issue.
Just my opinionated opinion,
Theron Hicks
"Uwe Bonnes" <bon@elektron.ikp.physik.tu-darmstadt.de> wrote in message
news:aohn4s$olb$1@news.tu-darmstadt.de...
> emanuel stiebler <emu@ecubics.com> wrote:
> : Is there any chance we could see something like this ?
> : I would love to use the speed of the VirtexII on a cheaper PCB.
>
> : Am I the only one who is dreaming about this packaging ?
>
> The question came up before. One answer was, that EMC problems nearly
> prohibit use of leaded packages for devices fast and powerfull like the
> virtex. One proposal was to put out a BGA package with 1.27 mm pitch. 4
> Layer PCB prototypes with 0.3mm drill, 0.15mm lines/spaces designrules are
> afordable and a 4 row BGA can be routed with these rules.
>
> Bye
> --
> Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de
>
> Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Article: 48297In article <3DAC6ED3.A8E721C4@Xilinx.com>, Goran Bilski <Goran.Bilski@Xilinx.com> wrote: >Another approach is to add multi-threading capabilities but I think that >multi-processing is better for FPGA than multi-threading. I disagree, based on the following observation: A 4-5 stage pipeline is going to have 2-3 levels of FPGA logic between each pipeline stage, suggesting that there are plentiful registers which can be exploited if the design is retimed and interleaved. Actual experience: Leon I (synthesized Sparc), Virtex: Initially: 23 MHz Retimed: 25 MHz 2-slow retimed: 46 MHz (so each thread at 23 MHz) -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 48298
Goran Bilski wrote: > Hi, > > MicroBlaze is more pipelined and is more floorplanned than PicoBlaze. > The 150 MHz for MicroBlaze is on a V2Pro and 116MHz for PicoBlaze is on VII-6. > MicroBlaze runs at 135 MHz on a VII-6. > Aha! There we have it caught on this very NG a Xilinx person admitting that floorplanning is important :-)).Article: 48299
would these be signed or unsigned integer - logic_vector, or bit literals? >> Completely. The site can also be used to prove sex is 177 times better than >> VHDL. > >And HTML is 5.6 times better than sex.
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