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
As far as I know, there are no chanels available, but we might open one :) regards, Domagoj "AH" <akha@attbi.com> wrote in message news:%ZWP7.7496$ER5.259797@rwcrnsc52... > This newsgroup has been very helpful the short time I've been here. I've > been on IRC for 6 years and maybe only once or twice found other hardware > engineers to talk to that actually know something. Are there any channels > on efnet that comp.arch.fpga people hang out in? > > Andy > > >Article: 37776
Burch Electronic Designs announces the new (and amazing :) ) B5-SUPER-VALUE-PACK http://www.burched.com.au/B5SuperValuePack.html Main FPGA board, with Xilinx XC2S200 200K gate FPGA, and a complete set of expansion plug-on modules. * Complete set of units, provides excellent platform for FPGA education * Ideal for System-On-Chip and FPGA-CPU prototyping * Works with the free Xilinx WebPACK software The B5-SUPER-VALUE-PACK includes: 1 x B5-SPARTAN2+ FPGA Main Board 1 x B5-SRAM 1 x B5-SWITCHES 1 x B5-LEDS 1 x B5-PERIPHERAL-CONNECTORS 1 x B5-PARALLEL-PORT-INTERFACE 1 x B5-IDE-INTERFACE 1 x B5-SOLIDSTATE-HARDDISK Flash Memory Disk 1 x 7SEG-DISPLAYS Amazing introductory price, US$359.00 (whole set). B5-SPARTAN2+ FPGA Main Board is also available separately, US$149.00 ! In stock now. International orders are very welcome. Best regards and season's greetings Tony Burch http://www.BurchED.com.au Low cost FPGA boards, for seriously powerful prototyping and education !Article: 37777
Hi Harris, > I have a small question. I work in a Virtex-E FPGA, my model has 4 clocks (3 > in 155MHz and the other one slower~100MHz) as inputs. In the ucf file I > located all clocks in the GCK pins, is that right? Yup > If yes, is this the only constraint that ensures proper distribution of the > signals? I think it is likely that your synthesis tool will infer clock buffers for you (provided you use the dedicated clock pins). Alternatively you could instantiate the components directly to remove any doubt (I needed to 'cos at the time it was the only was to get the LVPECL input standard that I needed). I used IBUFG to get the clock on chip, then BUFG to distribute it for simple clocking and IBUFG then CLKDLLE then BUFG in a more complex setup. You could do this if your synthesis tool doesn't infer clock distribution directly (try it and see). > Ah , and another one :) .. one of the processes (VHDL coding) in my model > that i want to implement uses the falling edge of the slow clock while the > others use the rising edge of all clocks, is this going to be a problem? No problem, an entity can contain rising edge clocked processes and falling edge clocked process, you just can't have rising & falling in one process. FredArticle: 37778
In article <9vs55r$nm4$1@casey.uvic.ca>, yeah_spam_me@thisaddress.com says... > The Virtex-E just has more BlockRAM available, IIRC... I think the comparison is on Xilinx' site, but IIRC. - Processes: Virtex-E is .18u 6-layer. Virtex is .22u 5-layer (Virtex-E is faster and denser) - Core voltage: Virtex-E = 1.8V Virtex = 2.5V - 5V tolerant: Virtex-E = "sorta", Virtex = yes - I/O types: Virtex-E <= Virtex + [LVPECL, LVDS...] - Differential I/O: Virtex = No, Virtex-E = Yes - DLLs: Virtex = 4, Virtex-E = 8 I'm sure there is something else I've forgotten. ---- KeithArticle: 37779
In article <3C216B3B.88F475B1@andraka.com>, Ray Andraka <ray@andraka.com> wrote: > Yup, and those glue on pentium heatsinks with the fans on them come in handy > for some of those high clock high density designs. Oh, I work in a big company, so we have guys who do nothing specialize in thermal analysis, so no problems there. The actual design speed is only 500 Mbps. Ths chips are well heat sunk and we have fans on this unit that coiuld be vectored to give it vertical takeoff and land capability. :-) Even at 800 they barely got warm. -- - Quiet Desperation - "The mass of men lead lives of quiet desperation." -- Henry David ThoreauArticle: 37780
"Antonio" <dottavio@ised.it> schrieb im Newsbeitrag news:fb35ea96.0112190733.19044bb@posting.google.com... > In my project I've a master clock and a clock derived by it via > combinatorial logic, in Synplify I could apply constrain to the first, This is no good idea. Deriving a low frequency clock from a high frequency clock by using DIRECTLY a combinatorical logic will generate glitches on this clock signal. What this means can bee seen on digital.burned-fuses.de At least you have to generate this low frequency clock dirctly from a FlipFlop Output, which is always glitch free (unless you violate setup/hold times) Or better for FPGA design, use a low frequency clock enable and run everything on the high frequency clock. -- MfG FalkArticle: 37781
"Antonio" <dottavio@ised.it> schrieb im Newsbeitrag news:fb35ea96.0112190727.7a65d9df@posting.google.com... > I would want to use clk_dll to divide a clock by 3, where can I found > an example of this ?? Can I also apply some constrain to the clk_dll There is an application note on the Xilinx website. -- MfG FalkArticle: 37782
Dear Kevin, we have recently solved simillar problem with our own PCI Core. You have to improve your design ! Try to rearange your logic that input signals (IRDY, FRAME, DEVSEL, TRDY - from the most crucial paths) has the lowest number of logic levels. In VHDL you should move these signals to outer IF's expresions (whatever duplication of inner conditional statements is introduced) to give it the highest priority. Internal signals (from DFFs) have 30 ns to propagate through the comb. logic (they can pass more logic levels that IRDY, TRDY etc.). For example use IRDY to choose between the subexpression (where IRDY='1') and subexpression (where IRDY='0'). STOP has generally lower fanout than IRDY and FRAME, so it can be the second in the IF statements tree. Normally there is no difference for this to be synthesised as a mux or a LUT. All this can be done in HDL without vendor specific modifications. Check it visually after the synthesis step whether the logic is such as described. In our case (Virtex xcv100-4) 7 ns Tsu is achieveable only if there are two levels of logic for IRDY, FRAME and DEVSEL. We also applied about 6 hand placements, mostly for these critical paths, to move the comb.logic luts as close to the IOB DFF's as it is posible. (It is an iterative process and takes time until you find the best placement, in the -5 device this can be easily achievable). Good luck ! MilosArticle: 37783
Synplify does have a syn_useioff attribute that you can set to 1 as a global attribute. This will default all packable boundary flip-flops into the IOB by putting the IOB attribute on them. You can then override the default on a pin by pin basis with the same attribute. Austin Franklin wrote: > "Bret Wade" <bret.wade@xilinx.com> wrote in message > news:3C2128F1.68274384@xilinx.com... > >> >>Austin Franklin wrote: >> >> >>>>>>ALWAYS >>>>>> >>>>>> >>>>>>>want my designs to use IOB flip flops if possible. It seems to me >>>>>>> >>>that >>> >>>>>>That's what you get for using Design Mangler...er...Manager ;-) >>>>>> >>>>>heh. I find that make does a fair job of managing builds. But >>>>> > then, I > >>>>>always did find CLIs more user friendly than GUIs. >>>>> >>>>>Even if you invoke map from the commandline or means other than >>>>> > through > >>>>>DM, packing flops into I/Os is not done unless the -pr flag is >>>>> > supplied. > >>>>> So I suppose DM is following the defaults of map. >>>>> >>>>>M. Ramirez's question still holds good -- is there ever a reason not >>>>> > to > >>>>>pack flops into IOBs? >>>>> >>>>> >>>>I think that packing registers is not the default map option because >>>> > the > >>>>expectation is that registers will have IOB=TRUE|FALSE attributes >>>> > applied > >>>to >>> >>>>them by the front end tool. This attribute takes precedence over >>>> > the -pr > >>>map >>> >>>>switch and allows for individual control of registers. >>>> >>>>Regards, >>>>Bret Wade >>>>Xilinx Product Applications >>>> >>>Bret, >>> >>>I don't know that that is true. Even if Synplicity has that checked, >>> > the > >>>Xilinx tools STILL need the "-pr b" to be added to the mapper from what >>> > I > >>>remember. >>> >>>Regards, >>> >>>Austin >>> >>Austin, >> >>Using the IOB=TRUE attribute does take precedence and there is no need to >> > also > >>use the "-pr b" switch. Likewise, using "-pr b" will not override an >> > IOB=FALSE > >>attribute. >> >>Regards, >>Bret >> > > Bret, > > Where are you assigning these attributes? You said in the "front end > tools", yet Synplcity has an "syn_useioff" that doesn't appear to > matter...you still need the "-pr b" in the mapper. According to the > Synplicity docs, there is no "iob" attribute... Are you talking about in a > constraint file? That's really got nothing to do with the synthesis front > end tools... > > Austin > > > >Article: 37784
"Bryan" <bryan@srccomp.com> schrieb im Newsbeitrag news:3c20c0ef$0$25796$4c41069e@reader1.ash.ops.us.uu.net... > ncd to hand route my couple nets. What I am building into a macro is a 16 > bit FIFO, I have 16 of these FIFOs in the design and each one contains IOB The question is, how fast are the clocks for this FIFOs. If it is not too fast, you can use some oversampling methods to run everything on ONE clock. Also, if the frequency of these FIFOs is considerably high, you should think about a very small, fast synchronizer circuit to synchonize the incomming datas to one clock domain and, again, work everything on one clock. Its quite easy to run out of clock nets, but its engineering to solve the problem without crying that much ;-) -- MfG FalkArticle: 37785
"Keith R. Williams" <krw@btv.ibm.com> schrieb im Newsbeitrag news:MPG.168bc2501d45f6e09896d2@enews.newsguy.com... > In article <9vs55r$nm4$1@casey.uvic.ca>, yeah_spam_me@thisaddress.com > says... > > The Virtex-E just has more BlockRAM available, IIRC... > > I think the comparison is on Xilinx' site, but IIRC. > > - Processes: Virtex-E is .18u 6-layer. Virtex is .22u 5-layer > (Virtex-E is faster and denser) > - Core voltage: Virtex-E = 1.8V Virtex = 2.5V > - 5V tolerant: Virtex-E = "sorta", Virtex = yes > - I/O types: Virtex-E <= Virtex + [LVPECL, LVDS...] > - Differential I/O: Virtex = No, Virtex-E = Yes > - DLLs: Virtex = 4, Virtex-E = 8 > > I'm sure there is something else I've forgotten. Due to the better (denser) process, Virtex-E is cheaper. -- MfG FalkArticle: 37786
"Antonio" <dottavio@ised.it> schrieb im Newsbeitrag news:fb35ea96.0112132356.7f43b3fe@posting.google.com... > I'm preparing a QPSK modulator, > until now I arrange it for a VIRTEX 1000 -4 , but it seem that could > be impossible to use it at a maximum clock speed of 165MHz especially Virtex-E is faster (and cheaper). Virtex-II is even more faster. -- MfG FalkArticle: 37787
Use Coregen. It is quite straightforward.Article: 37788
Hi Ken, If you read what I wrote in my reply, you would note that I mentioned the syn_useioff "attribute" and also said that you still need the "pr -b" option, as just the attribute alone does not put the FFs in the IOBs...at least in the tool set I have been using... Regards, Austin "Ken McElvain" <ken@synplicity.com> wrote in message news:3C221CDB.2060207@synplicity.com... > Synplify does have a syn_useioff attribute that you can > set to 1 as a global attribute. This will default all > packable boundary flip-flops into the IOB by putting the > IOB attribute on them. You can then override the default > on a pin by pin basis with the same attribute. > > Austin Franklin wrote: > > > "Bret Wade" <bret.wade@xilinx.com> wrote in message > > news:3C2128F1.68274384@xilinx.com... > > > >> > >>Austin Franklin wrote: > >> > >> > >>>>>>ALWAYS > >>>>>> > >>>>>> > >>>>>>>want my designs to use IOB flip flops if possible. It seems to me > >>>>>>> > >>>that > >>> > >>>>>>That's what you get for using Design Mangler...er...Manager ;-) > >>>>>> > >>>>>heh. I find that make does a fair job of managing builds. But > >>>>> > > then, I > > > >>>>>always did find CLIs more user friendly than GUIs. > >>>>> > >>>>>Even if you invoke map from the commandline or means other than > >>>>> > > through > > > >>>>>DM, packing flops into I/Os is not done unless the -pr flag is > >>>>> > > supplied. > > > >>>>> So I suppose DM is following the defaults of map. > >>>>> > >>>>>M. Ramirez's question still holds good -- is there ever a reason not > >>>>> > > to > > > >>>>>pack flops into IOBs? > >>>>> > >>>>> > >>>>I think that packing registers is not the default map option because > >>>> > > the > > > >>>>expectation is that registers will have IOB=TRUE|FALSE attributes > >>>> > > applied > > > >>>to > >>> > >>>>them by the front end tool. This attribute takes precedence over > >>>> > > the -pr > > > >>>map > >>> > >>>>switch and allows for individual control of registers. > >>>> > >>>>Regards, > >>>>Bret Wade > >>>>Xilinx Product Applications > >>>> > >>>Bret, > >>> > >>>I don't know that that is true. Even if Synplicity has that checked, > >>> > > the > > > >>>Xilinx tools STILL need the "-pr b" to be added to the mapper from what > >>> > > I > > > >>>remember. > >>> > >>>Regards, > >>> > >>>Austin > >>> > >>Austin, > >> > >>Using the IOB=TRUE attribute does take precedence and there is no need to > >> > > also > > > >>use the "-pr b" switch. Likewise, using "-pr b" will not override an > >> > > IOB=FALSE > > > >>attribute. > >> > >>Regards, > >>Bret > >> > > > > Bret, > > > > Where are you assigning these attributes? You said in the "front end > > tools", yet Synplcity has an "syn_useioff" that doesn't appear to > > matter...you still need the "-pr b" in the mapper. According to the > > Synplicity docs, there is no "iob" attribute... Are you talking about in a > > constraint file? That's really got nothing to do with the synthesis front > > end tools... > > > > Austin > > > > > > > > >Article: 37789
Hi, I'm searching for vhdl code of an 8 bit array divider. If you know any, please introduce it. Thanks in Advance, Behrang.Article: 37790
Hey folks, howareyez? Just wondering if anyone has any ideas about floating point numbers in Handel C. I'm having a look at the Celoxica Floating-point library but i'm wondering if anyone has discovered an easier way than this. Anyone come across this or have their own way of using floating point numbers in Handel C? Cheers, Rob.Article: 37791
Bob Perlman wrote: > On Wed, 19 Dec 2001 17:19:58 GMT, Andy Peters > <andy@exponentmedia.nospam.com> wrote: > > >>Stephen Byrne wrote: >> >> >>>I originally posted this yesterday on google groups, but I'm not seeing it >>>on my home news server. In case it is not visible to all, I'm reposting. >>> >>>Hello All, >>> >>>My company is currently comparing 66MHz PCI core solutions from Xilinx >>>and Altera, as well as debating using a home-spun core. One issue >>>I've come upon is the PCI requirement for a MAX clock-to-out time of 6 >>>ns and MIN clock-to-out time of 2 ns. Both the Xilinx ISE and Altera >>>Quartus II tools seem very helpful in supplying MAX (worst-case) Tco >>>times, but I don't see any info on best-case times. Apparently the >>>SDF files for back-annotated timing sim have the same worst-case >>>numbers repeated 3 times, resulting in the same simulation regardless >>>of case selection. My question is: how is anyone (FPGA vendors >>>included) guaranteeing a MIN Tco of 2 ns across all conditions and >>>parts if the design tools don't even yield that information? >>> >> >>You like to live dangerously if you depend on best-case timing information. >> > > What's the alternative? Um, worst-case timing information? --aArticle: 37792
Antonio wrote: > Some hardware question on FPGA : > > 1) What's the difference between a part with speed -3 and another with > speed -4 , the number is the number of metal layers ?? -4 -5 etc are the speed grades, determined by testing ( the actual silicon is identical for all speed grades and also for com, ind and military parts. It's the performance that differs). Watch out for the direction of these numbers: In the XC4000 series, we used the propagation delay through a look-up table , expressed in nanoseconds. So a lower number was faster. That got us in trouble as the parts got faster and faster, below 1 ns. So, for Virtex etc, we switched to "just numbers" without any physical significance, and -since the parts are always getting faster - we use the open-ended larger number to describe the faster part. > > > 2) I read data sheet of Virtex and Virtex E, I didn't found really > much difference, can you explain me which is better and why ?? Go to page 2 of the Virtex-E data sheet: "Virtex-E compared to Virtex" Equally or more important is the price difference: Virtex-E is not only better, but also cheaper, since the die is smaller, which leads to lower manufacturing costs. Peter Alfke, Xilinx ApplicationsArticle: 37793
"H.L" wrote: > Hello all and Merry Christmas, > I have a small question. I work in a Virtex-E FPGA, my model has 4 clocks (3 > in 155MHz and the other one slower~100MHz) as inputs. Why do you have 3 clocks with the same frequency? Use only one! But if the phases or frequencies are not identical, then be very careful when you cross from one frequency domain to the other > In the ucf file I > located all clocks in the GCK pins, is that right? Yes > > If yes, is this the only constraint that ensures proper distribution of the > signals? Yes, you always get very good, low-skew distribution on the global clocks. > > Ah , and another one :) .. one of the processes (VHDL coding) in my model > that i want to implement uses the falling edge of the slow clock while the > others use the rising edge of all clocks, is this going to be a problem? No problem Peter AlfkeArticle: 37794
It's more correct to say that the inevitable delays are shorter on the Virtex parts with a higher speed-grade number. Therefore you can clock your design at a higher clock rate. Peter Alfke "H.L" wrote: > Hello , > > That difference on speed is owing to "faster" flip-flops? > So if you want to buy a FPGA you must determine the speed grade you want or > the same FPGA has the ability to operate in different speeds (i.e 6,8)? > I am a bit confused > Harris >Article: 37796
Cheers noel. Rob.Article: 37797
Austin F. is right on the value of schematics vs. hdl and Austin L. is wrong. It's best to use schematics to design the architectural hierarchy and only use HDL within blocks where it makes sense. When an HDL is used structurally you have to maintain a graphical block diagram (schematic) on the side to keep track of how it all fits together. In any case most schematic tools will write out a structural VHDL netlist automatically if you're required to provide a pure HDL design. HDL's have many valuable characteristics like portability but they have been oversold as productivity enhancers. "Ray Andraka" <ray@andraka.com> wrote in message news:3C20F7F0.CCE642F6@andraka.com... > Both schematics and HDL can be horrendous or stellar. I've seen examples both > ways of both. In either case, proper use of hierarchy is the key to a > maintainable design. > > Austin Franklin wrote: > > > Hi Austin, > > > > > If I see hdl code, at least I can see where it is going, even if it is > > written > > > badly. > > > > For me, that is not true. I have to wade around pages and pages of > > text....where with a schematic, I can pick up what's going on almost > > instantly. Schematics offer, if done right that is, a built-in block > > diagram...which can not be done with text files very easily. The data flow > > is FAR easier to pick out in a schematic than in HDL, and control logic may > > or may not be easier to "understand" in HDL...it depends on how it's done. > > > > > Nice thing about software is that people have figured out how to manage > > it, and > > > document it. > > > > Why is that any different than schematics? > > > > > If I examine a design, from top to bottom, I can make a determination of > > the > > > quality of the design by examining the hdl code. It is possible, but more > > > difficult to see what is going on in schematic. > > > > I believe the exact opposite. > > > > > As a > > > technical manager, code review is one tool that should be used to make > > sure the > > > project is on track, following the rules, and has a higher likelihood of > > > success. > > > > And you've never seen/done a schematic review? I believe schematics are FAR > > easier to review than text files are. Anyway, design reviews are typically > > NOT the source files, but the architecture...it's rare that one brings > > source files to a design review and gives a copy to everyone in the room, > > and people just sit around flipping through hundreds of pages of text > > discussing constructs... > > > > I think you should attend my lecture in the spring on mixed design entry for > > FPGA design ;-) > > > > Regards, > > > > Austin > > -- > --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: 37798
In article <9vt7ve$264h$1@ulysses.noc.ntua.gr>, alphaboran@yahoo.com says... > Hello , > > That difference on speed is owing to "faster" flip-flops? The logic is faster. Gate delay lower => flops faster. I'm looking an an old Virtex and Virtex-E spec here. Each speed grade seems to be about 10% faster than the next lower grade. I'm fairly sure this only applies to the logic and not the interconnect though. > So if you want to buy a FPGA you must determine the speed grade you want or > the same FPGA has the ability to operate in different speeds (i.e 6,8)? > I am a bit confused You get what you pay for. You buy the speed grade you need. It's rather like Intel processors. If you need the fastest, get out your wallet! ---- KeithArticle: 37799
The V1000-4 is the slowest and oldest member of the Virtex families. 165 MHz is a bit on the high side
for that speed grade if you are doing anything with the carry chain, the SRL16's or the Block RAM. You
can get there just by moving up to the -6 speed grade, provided your design is very carefully executed.
Unless there is something holding you to that part (a military/space application requiring the QPRO part,
for example), you are better off migrating to VirtexE or VirexII parts. Virtex E is basically the same
architecture (extra block rams and extra DLLs) but 1.8volt instead of 2.5 volt. A virtex design can be
easily migrated to virtex E in most cases. VirtexII is a similar architecture with more features such as
dedicated multipliers, larger Block RAM, a more flexible clock management scheme and impedance controlled
I/O. It also has less logic elements for a given device size.
Altera's later parts are also capable, although for DSP applications, I find the Xilinx architecture to
be a better fit.
ron wrote:
> Why don't you use Virtex II?
>
> dottavio@ised.it (Antonio) wrote in message news:<fb35ea96.0112132356.7f43b3fe@posting.google.com>...
> > I'm preparing a QPSK modulator,
> > until now I arrange it for a VIRTEX 1000 -4 , but it seem that could
> > be impossible to use it at a maximum clock speed of 165MHz especially
> > 'cause I've to put in and out that speed and this seems not possible
> > (..or I'm wrong ??) I'm using less than 30% of VIRTEX 1000 so my
> > question is which FPGA is actually the one with best speed
> > performance, it could be not only Xilinx 'cause my scope is to verify
> > that there's actually a technology where my project could be
> > implemented. Thanks
> >
> > Antonio
--
--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
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