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
Hi all. I'm currently in the final stages of getting a design we have developed at uni as a group to load into our FPGA. We can load the Virtex (XCV150) using JTAG, and now require a bitstream file in a format suitable for slave serial programming. Are there any special requirements in programming using slave serial, or will the bitstream that comes out of Foundation 2.1 work with minimal hassle? Do I need to run bitgen with any special options. I have been doing some reading on this and most of the material I have found has left me somewhat confused as to what exactly is going on. Thanks in advance for your help. Adam -- Adam Hawes Web: http://overfiend.iwarp.com Email: adam_hawes@dingoblue.com.au ICQ: 2492016 Voicemail: +61 (08) 8219-3238 Fax: +61 (08) 8219-3238 -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GAT dpu s+: a-- C++++ UL++ P+ L+++ E W- N+++ o+ K- w--- O- M V-- PS+ PE Y++ PGP++ t 5- X+++ R* tv b+ DI+ D---- G e* h! r--- y** ------END GEEK CODE BLOCK------Article: 27576
"Jean Nicolle" <jeann17@home.com> wrote in message news:H10V5.482363$i5.8584346@news1.frmt1.sfba.home.com... > why not use an already debugged FIFO core? > Altera has a FIFO wizard/megafunctions, while Xilinx had CoreGen (I > believe). It was/is a Xilinx-provided FIFO. From one of the other poster's comments, however, it appears that discrete component FIFOs occasionally suffer from this same problem, and I also recall reading on John Cooley's ESNUG list that some of the Synospys FIFO cores targeted at ASICs have problems as well. Hence I'm convinced it is slightly non-trivial to design a robust, bullet-proof asynchronous FIFO. One other note to Andy -- as far as simulation vs. reality goes, we actually did go so far as to route the internal "full" signal out to a pin with FPGA editor and, indeed, it would sit there and go active, well before it should have. While we were debugging this (a better part of a month ago, now), our only other arguably reasonable thought was that we weren't covering some timing path; we could take the _exact same design_, and re-PAR it using different _only different cost tables_, and sometimes overflow would work, and sometimes it wouldn't. We eventually covered every last timing path possible (trce -u didn't report any unconstrained paths), and that left us with, "well, I guess GSR isn't really covered by a timing constraint, is it?" and the theory of the pipelined counters misstepping when the FPGA is reset. ---Joel KolstadArticle: 27577
Greetings,
I've been curious about how many gates it takes to achieve
a simple & small MPU, (such as a Z80 for example).
Essentially, I have an XC4005XL FPGA, and am writing the pieces of this pie
out, and they come up 500 gates a piece (Program Counter,
Address Registers, Data Registers.)
Is it seriously conceivable to use a XC4005? if not, would an XC4010
be closer to appropriate?
Article: 27578Hi Nick, "Nick Bruty" <nick.bruty@easynet.co.uk> schrieb im Newsbeitrag news:ZNVU5.104202$K64.1294531@monolith.news.easynet.net... > Yes the power pins are different from the outside the reason being not to > force a board spin but to force a re compile as the internal pad bondings > are different so your expected IO's would appear on different pins. > I'd do a re-compile any time I would change the device. I would not use the 10KE compiler output with the ACEX 1K, as it's another family. That doesn't seems for me a good explanation to switch the Power Pins to prevent users to replace the 10K by a 1K or vice versa to prevent problems with switched I/Os. I still believe, that the 1K family was designed with the goal to prevent users replace the 10K by the 1K without re-design of the PCB. CU, Carlhermann BTW: I'm stil a fan of ALTERA.Article: 27579
In article <6uk89nh9k6.fsf@chonsp.franklin.ch>, Neil Franklin <neil@franklin.ch.remove> wrote: > Jonas Thor <thor@NOSPAMsm.luth.se> writes: > > > On Mon, 27 Nov 2000 22:22:32 GMT, longwayhome@my-deja.com wrote: > > > > >Is a XS40-005XL ( http://www.xess.com/prod004.html ) board suitable for > > >hardware evolution, has anyone actually used it for that purpose ? > > What do you exactly mean with "hardware evolution". Improving hardware > for some project? Or are you trying to used genetic algorithms to > generate FPGA configurations? Or using FPGAs as co-processors to > compute GAs for something else? Or? > > Perhaps if you tried to describe what you are trying to do, people > here could help you in selecting. What i'm wanting to do is (i suppose) the 'genetic algoriths to generate FPGA configurations' which i want to try to use in the same way that i read in http://www.newscientist.com/nsplus/insight/ai/primordial.html since it seems like a very interesting subject to learn about (and i want to try using it for a very cunning idea i have :) Suggestions about existing setups used by people for similar things would be great, I agree (but I posted a few weeks back asking pretty much for that kind of info and didn't really get many replies of "I use board X" variety (in fact none iirc)) Thanks David Sent via Deja.com http://www.deja.com/ Before you buy.Article: 27580
I recommend www.fpgacpu.org on this topic. FPGA CPUs start as low as 35 CLBs for a minimalistic 8-Bit processor with 256 Byte address range and go up to 100KGates full fledged 32-Bit Sparc and MIPS implementations. It is often easier and more accurate to count CLBs instead of gates. This way it is easy to see, that for a 16-Bit CPU Datapath a PC costs about 8 CLBs, a Register file 8 to 16 CLBs, a simple ALU 8 CLBs, a data Mux 8 CLBs, and so on. Beware that a a regular Mux is as expensive as an ALU. Try to use a Tristate Bus for the result Bus. CU, Kolja For your own design, to quote Jan Gray: "smaller ist better" CU, Kolja In article <6f2V5.16069$nh5.1534936@newsread1.prod.itd.earthlink.net>, "Akito" <..@no.com> wrote: > Greetings, > > I've been curious about how many gates it takes to achieve > a simple & small MPU, (such as a Z80 for example). > > Essentially, I have an XC4005XL FPGA, and am writing the pieces of this pie > out, and they come up 500 gates a piece (Program Counter, > Address Registers, Data Registers.) > > Is it seriously conceivable to use a XC4005? if not, would an XC4010 > be closer to appropriate? > > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 27581
I am trying to decide between machine specs for running Synplify on with a design size of around 200-300k gates and have a question or two for those having Synplify experience. What is a typical machine spec for running Synplify on? What do people generally use for designs of around 200k gates? Sun machines? Or fast PCs with reasonable amounts of memory and disk? What make of CPU is prevalent? Does anyone know if there are any benchmarks anywhere that don't show up on Google or any other search engine that may show this sort of thing? Has anyone run Synplify on a Pentium 4 based system yet? ;) Cheers, RichArticle: 27582
What can I do if I want to integrate some functional units (tested and optimized on different small FPGA's) into one large FPGA. We are using Xilinx Virtex-E FPGAs and the Foundation Express software with VHDL. I think we need a kind of self-programmed cores with optimized placement and routing that can be coalesced in the top-level VHDL-design. I think it'll get to complex to hand optimize the whole project afterwards. I can't find any information about that in the Xilinx literature. Thanks for some hints. -- _________________________________________________________________ | | | Dipl.-Ing. Marc Reinert | | | | Technical University of Hamburg-Harburg | | Department of Telecommunications | | Eissendorfer Strasse 40 | | D-21073 Hamburg / Germany | | | | Telefon/ Phone: (+49) (0)40 4 28 78 - 20 63 | | Fax/ : (+49) (0)40 4 28 78 - 22 81 | | E-Mail: mailto:reinert@tu-harburg.de | | WWW: http://www.et2.tu-harburg.de | |_________________________________________________________________|Article: 27583
Wolfgang Loewer wrote: > > When you implement NIOS in an ACEX 1K device, which we successfully did, the > silicon cost for the processor core is only about US-$ 5,- and the complete > development environment is only US-$ 995,-. > > Best regards > Wolfgang Loewer Wolfgang, What are the software development/emulation tools like for the NIOS core? Nial.Article: 27584
Phil Martin wrote: > Hi Rick, > > Why not upgrade to a Athlon 1.2GHz, with 133MHz DDR? > > Then you can tell me whether or not I should do the same! > > Cheers, > > Phil Martin > That's what I'd do if I had the opportunity but we're building an office in Cambridge so all £££ decisions are subject to questions. That said the DDR Athlon boards are very much cheaper now than they were even 6 month ago & I expect a bread&butter 900/133DDR would do almost as well.Article: 27585
Kent Orthner wrote: > > Kent Orthner wrote: > > > > > > Seeing as I want to do this in one clock cycle, > > > and *really* don't want to pipeline it, is > > > there a fancy way of implementing a wide > <snip> > > > nothing like this on the inside of a Virtex/SpartanII > > > FPGA. > > > > Duane <junkmail@junkmail.com> writes: > > Actually, there is. For clues, take a look in the Libraries guide at the > <snip> > > the way through and the result is a high. > > Duane, > > Thanks. This is exactly the kind of "Fancy way" that I was looking for. > In the data book it shown Cin to Cout delay to be 0.2ns max, which should > give me 6.4 ns for the entire thing. I'm hoping for 9.6ns for everything, > including the compare, but maybe I'm being too optimistic. (I'm stuck > with the cheapest speed grade, after all.) > > Maybe I'll run it as a tree of CinCout chains or something; we'll see. > > Thanks for the advice. > > On a side note, when I look at the CY Muxes, do you know what the 'BX' > input is, and what it's for? > > -Kent You might be able to do even better if you split the thing into 2 16 bit chains using the left & right slices of a CLB column. Use local routing in the last CLB to and them togther via an LUT (or MULT_AND ?) and the result might come in under 5ns.Article: 27586
Richard Wilkinson wrote: > I am trying to decide between machine specs for running Synplify on with > a design size of around 200-300k gates and have a question or two for > those having Synplify experience. > > What is a typical machine spec for running Synplify on? What do people > generally use for designs of around 200k gates? Sun machines? Or fast > PCs with reasonable amounts of memory and disk? What make of CPU is > prevalent? Does anyone know if there are any benchmarks anywhere that > don't show up on Google or any other search engine that may show this > sort of thing? > > Has anyone run Synplify on a Pentium 4 based system yet? ;) > > Cheers, > > Rich Of all the tools in the EDA chain Synplify is the fastest. At the moment I'm synthesising a 75% used XCV400 in < 9 minutes on a vanilla 600MHz PIII/PC100 M'brd. As to memory the max useage is about 70MB if I synthesise everything together and < 25MB if I do my normal approach of synthesising the top and level 1 modules separately. In the second case [for Xilinx parts] the ngdbuild linking takes another 2 min or so. Note that the big memory burners - again for Xilinx - are MAP & PAR that in my case are using 150MB. PAR is taking just under an hour for a place&route with 10 router iterations.Article: 27587
Can anyone shed some light on this FGPA Express warning? Cheers in advance, Dave Warning: Duplicate cells '/FPGA1-Optimized/DIN_reg31' and '/FPGA1-Optimized/MICRO_reg31' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg1' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg2' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg3' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg4' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg5' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg6' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg7' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg8' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg9' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg10' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg11' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg12' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg13' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg14' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg15' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg16' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg17' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg18' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg19' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg20' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg21' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg22' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg23' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg24' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg25' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg26' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg27' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg28' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg29' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg30' and '/FPGA1-Optimized/DOUT_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg1' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg2' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg3' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg4' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg5' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg6' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg7' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg8' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg9' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg10' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg11' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg12' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg13' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg14' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg15' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg16' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg17' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg18' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg19' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg20' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg21' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg22' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg23' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg24' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg25' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg26' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg27' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg28' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg29' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2) Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg30' and '/FPGA1-Optimized/DIO501_reg0' merged. (FPGA-CLEAN-2)Article: 27588
What were the reg names in the EDIF? On Sat, 25 Nov 2000 12:26:08 +0000, Rick Filipkiewicz <rick@algor.co.uk> wrote: >For me this is not really too dangerous most of the time since the majority >of the timespecs are multi-cycled easing up of the basic period one. However >if the timespec's job is to tighten the timing then there's potential for >trouble. The one place I *do* tighten specs is on clock domain changing FFs! A great example of why you can't rely on static timing analysis. EvanArticle: 27589
Austin, could you give those figures? I am planning to use the 20KE for an application where I need low jitter. Can you compare jitter on an Apex PLL to that obtained using a Virtex DLL? Thanks, Javier Austin Lesea wrote: > > Nick, > > Measuring the jitter on the NIOS pcb coming out of the PLL clock out pin of > the 20KE had us smiling all around, > > If you are going to mess with analog PLL's on the same chip as the digital > stuff: caveat emptor! > > AustinArticle: 27590
On Tue, 28 Nov 2000 09:36:02 -0800, "Walter Haas" <walter_haas@pmc-sierra.com> wrote: >Hi everybody <Hi Dr. Nick> :) > >I didn't mean to imply that I'd use the 50MHz clock as a clock enable. I would actually just have a data_valid register, that was essentially just a flop with an inverter between it's Q->D data path, and that signal would be the clock enable. The rest of my design would consist of multi-cycle paths (2 cycles), because the FFs couldn't change on the odd cycle, and I'd still get the nice combinatorial buffer. > >Cheers, > >Wally Hey Wally, I would like to really read your posts. I think they are informative. But, I am really annoyed with your lack of <CR> in the message. Think you can hit that enter key every once in a while Ralph Watson Return Email Address is: ralphwat dot home at excite dot comArticle: 27591
adam_hawes@dingoblue.net.au wrote: > > Hi all. > > I'm currently in the final stages of getting a design we have > developed at uni as a group to load into our FPGA. We can load > the Virtex (XCV150) using JTAG, and now require a bitstream file > in a format suitable for slave serial programming. > > Are there any special requirements in programming using slave > serial, or will the bitstream that comes out of Foundation 2.1 > work with minimal hassle? Do I need to run bitgen with any > special options. Hi The only thing you need to do is re-run bitgen with the option -g StartupClock:CCclk instead of -g StartupClock:JtagClock If you use the GUI, find where the startup clock is specified (I don't remember) and change from JTAg to CClk. -- Nicolas MATRINGE IPricot European Headquarters Conception electronique 10-12 Avenue de Verdun Tel +33 1 46 52 53 00 F-92250 LA GARENNE-COLOMBES - FRANCE Fax +33 1 46 52 53 01 http://www.IPricot.com/Article: 27592
"Richard Wilkinson" <richard.wilkinson@csr.com> wrote in message news:3A24D86F.3AA3208@csr.com... > I am trying to decide between machine specs for running Synplify on with > a design size of around 200-300k gates and have a question or two for > those having Synplify experience. Place and route is going to take you significantly longer than Synplify's synthesis. > What is a typical machine spec for running Synplify on? What do people > generally use for designs of around 200k gates? Sun machines? Or fast > PCs with reasonable amounts of memory and disk? What make of CPU is > prevalent? Our current PAR machine is a 700MHz Athlon with half a gig of memory. Soon it'll be replaced by a gigaHerttz Athlon; I'm curious to see what the PAR speedup is, although I'm not expecting a lot. For an XCV400 desigin that's 85% full, PAR takes about an hour. Synplify takes, I don't know, somewhere between 5 minutes and ten minutes -- it's quite fast. Whatever you do, get yourself a PC with high quality components; leave the CPU overclocking and cheap no-name SDRAM for some other computer that you don't do "real work" on. Where I work in general they purchase Dell's, and from what I can tell they're pretty solidly designed. > Has anyone run Synplify on a Pentium 4 based system yet? ;) No, but from looking at the Pentium IV's benchmarks I'd bet a nickel that at the same clock speeds it's be slower than a Pentium III or an Athlon. (Granted, P-IV's are only available at 1.4GHz and 1.5GHz at the moment, but check out the benchmarks -- often a 1.5GHz P-IV can't even keep up with a 1GHz P-III/Athlon, depending on the benchmark you look at.) Objectively, a Pentium IV isn't the right choice for very darn many applications -- yet. I'd wait until Intel gets the faster P-IV's out (with the 487? pin footprint instead of the 423? pin footprint that they're going to obsolete in the next six months!). ---Joel KolstadArticle: 27593
Joel Kolstad wrote: > > "Richard Wilkinson" <richard.wilkinson@csr.com> wrote in message > news:3A24D86F.3AA3208@csr.com... > > I am trying to decide between machine specs for running Synplify on with > > a design size of around 200-300k gates and have a question or two for > > those having Synplify experience. > > Place and route is going to take you significantly longer than Synplify's > synthesis. Yes, that seems to be the limiting factor. > Whatever you do, get yourself a PC with high quality components; leave the > CPU overclocking and cheap no-name SDRAM for some other computer that you > don't do "real work" on. Where I work in general they purchase Dell's, and > from what I can tell they're pretty solidly designed. That was my intention. A good, solid machine from a well-known supplier. > > > Has anyone run Synplify on a Pentium 4 based system yet? ;) > > No, but from looking at the Pentium IV's benchmarks I'd bet a nickel that at > the same clock speeds it's be slower than a Pentium III or an Athlon. > (Granted, P-IV's are only available at 1.4GHz and 1.5GHz at the moment, but > check out the benchmarks -- often a 1.5GHz P-IV can't even keep up with a > 1GHz P-III/Athlon, depending on the benchmark you look at.) The benchmarks I have looked at for P4 machines seems to differ considerably. SpecFP2000 and SpecInt2000 give pretty favourable results - significantly faster than Athlon 1.2GHz machines for example. But they may take the much higher memory bandwidth into account as well. The other processor-based benchmarks, as you say, point to the Athlon being pretty good in comparison. Does the place and route take so long because of memory bottlenecks? Or just a lack of number-crunching power? > > ---Joel Kolstad Cheers, RichArticle: 27594
Javier, I have sent the FPGA Lab measurement results to you directly. For a complete discussion of jitter, we are preparing a techincal note. There are many elements of jitter measurement that require careful attention. First: signal integrity must be perfect (reflections add jitter). Second: the clock source must have extremely low intrinsic jitter. Third: the measurement should be made of just going in, and coming out of an IO, as a calibration of the contribution to jitter of the IO's alone. Fourth: the measurement equipment should gather at least a few hundred thousand samples, when the jitter stops increasing. We typically take a million samples, or more. Curve fitting will also add to the accuracy of the prediction. Fifth: output pins should be toggled, logic should be clocked, and other elements should be exercised to discover the influence of their operation on the DLL/PLL under test. Sixth: power supplies must be perfectly clean for the baseline measurements. Actual supplies are then used to see the influence of power supply noise on the results. We also inject 1 V spikes into the Vccint and Vcco to judge the resistance of the DLL to outside noise in our testing (simulates the ground bounce and ringing in a poor design). Austin Javier SERRANO wrote: > Austin, could you give those figures? I am planning to use the 20KE for > an application where I need low jitter. Can you compare jitter on an > Apex PLL to that obtained using a Virtex DLL? > > Thanks, > > Javier > > Austin Lesea wrote: > > > > Nick, > > > > Measuring the jitter on the NIOS pcb coming out of the PLL clock out pin of > > the 20KE had us smiling all around, > > > > If you are going to mess with analog PLL's on the same chip as the digital > > stuff: caveat emptor! > > > > AustinArticle: 27595
On Tue, 28 Nov 2000 22:51:32 -0500, rickman <spamgoeshere4@yahoo.com> wrote: >...But this signal is replaced by the GSR net in >the FPGA. The GSR net is what puts all the FFs in a defined state when >coming out of configuration. If you wish, you can use this as an >external reset as well by bringing it to a pin. But that is not >required. I am confused about this. Is it possible to use both GSR and an external reset ? IOW, If you use an external reset how does the internal configuration done signal get to the FFs ? Who does the "and" of external reset with GSR so that one or the other is functional ? Muzaffer FPGA DSP Consulting http://www.dspia.comArticle: 27596
Joel Kolstad wrote: > > "Andy Peters n o a o [.] e d u>" <"apeters <"@> wrote in message > news:901ckf$2h1q$1@noao.edu... > > Are you sure you weren't being screwed by the simulation model? > > No, it worked fine in simulation, it was the real design PARed on the real > live PCB that had problems! That's what I mean: the simulation is fine, the real hardware isn't. I'd aim a beady eye on that there simulation model. Actually, no, I'd write my own damn FIFO. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u "It is better to be silent and thought a fool, than to send an e-mail to the entire company and remove all doubt."Article: 27597
Jean Nicolle wrote: > > why not use an already debugged FIFO core? > Altera has a FIFO wizard/megafunctions, while Xilinx had CoreGen (I > believe). I've gotten better results speed-wise by rolling my own FIFOs. For some reason, every design I do requires a little tweak here or there and the generic CORE functions just won't fill the bill. And I still don't trust the simulation models. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u "It is better to be silent and thought a fool, than to send an e-mail to the entire company and remove all doubt."Article: 27598
Muzaffer Kal wrote: > > On Tue, 28 Nov 2000 22:51:32 -0500, rickman <spamgoeshere4@yahoo.com> > wrote: > > >...But this signal is replaced by the GSR net in > >the FPGA. The GSR net is what puts all the FFs in a defined state when > >coming out of configuration. If you wish, you can use this as an > >external reset as well by bringing it to a pin. But that is not > >required. > > I am confused about this. Is it possible to use both GSR and an > external reset ? IOW, If you use an external reset how does the > internal configuration done signal get to the FFs ? Who does the "and" > of external reset with GSR so that one or the other is functional ? The external reset signal is an input to the STARTUP block (in 4K/Spartan, at least) which is where the ORing occurs. The GSR output of the STARTUP block is distributed to all of the flops via the GSR nets. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u "It is better to be silent and thought a fool, than to send an e-mail to the entire company and remove all doubt."Article: 27599
On Wed, 29 Nov 2000 16:12:16 +0000, Richard Wilkinson <richard.wilkinson@csr.com> wrote: >considerably. SpecFP2000 and SpecInt2000 give pretty favourable results >- significantly faster than Athlon 1.2GHz machines for example. But they one problem with deciding on a P4 after looking at SpecInt and SpecFP is that the program you're running has not been compiled with the same compiler. P4 has changed a lot of optimization guidelines and "legacy" (this is what Intel is calling the programs we are running now) programs may run slower than their newly compiled versions. Anyone knows what compiler Xilinx is using for PC versions of their tools ? It might be upto a year before MSFT comes up with P4 optimized toolset and I am curious whether Xilinx is using Intel's VC plug-in. Muzaffer FPGA DSP Consulting http://www.dspia.com
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