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
On Mar 19, 6:25 pm, General Schvantzkoph <schvantzk...@yahoo.com> wrote: > I built my system from components I bought from Newegg. I don't know of > any reliable online sources for custom machines, I used to use Monarch > but they've gone backrupt. Any local white box builder could put the > system together for you, that's you best bet for a system that can be > overclocked. The problem with white box builders is warranty... With Dell, you can have a technician on site within 24 hours if there is a problem. With a white box computer, you're pretty much on your own (or rather, in my case, the IT guys are on their own).Article: 116851
lschirrm@gmail.com wrote: > Hello: > Today, Altera announced the Cyclone III device family. > Highlights: > Industry's first 65nm low cost FPGA > Shipping now (yes, really) > Up to 120,000 logic elements, Up to 4 Mbits RAM, 288 18*18 multipliers > Aggressive family plan with 8 packages, 8 devices, 3 speed grades, 3 > temp grades, leaded/lead free packaging > Example of power spec: 120K Logic element device static power spec is > ~170mW at 85C typical > Device samples, low cost dev kits, documentation and software are all > available today on www.altera.com > Link to main page: > http://www.altera.com/products/devices/cyclone3/cy3-index.jsp > Handbook: > http://www.altera.com/literature/lit-cyc3.jsp Even prototyp friendly PQFP-240 packages are listed... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 116852
> Spartan 3 has hardware multipliers, so you are not entirely stuck with doing everything in > CLBs... only the accumulate, multiplexing and few other unique features you might not have > used. If you inferred those DSPs, you should not need to do anything in particular for the > Spartan switch. > > For the DRAMs, first estimate the peak bandwidth you need and the best-case the memory you > have can do. If your requirement is less than 75% of your memory's theoretical maximum, it > should be doable with a relatively simple memory controller but you will most likely have > to re-think your pipeline to accomodate the extra latency: you will at least have to add > logic to prefetch data and BRAMs to buffer both the input(s) and output(s). You can start > with pipelined bursts of eight words to do full-row transfers to start - video > applications can usually be made very compatible with full-row transfers. For more random > memory access patterns, bank interleaving and hiding precharge/activate behind burst > transfers to other banks is practically mandatory to achieve better than 50%. > > Experience with DRAMs is often listed as an asset on jobs I am looking at so I am trying > to complete a relevant design in case I get an interview for one of these. Things are > progressing slowly and I am expecting lots of grief from the IOB side, in part due to > inexperience and in part because the V2Pro's IOBs appear to be more quirky than the V4s I > have worked on last year. Yeh for the hardware multipliers, I guessed it automatically changed the DSP48s to the multipliers, but alas, shortage problems again. 60 mulitpliers needed for 36 available. Hmm, for the time being, I shall try to find the information about the peak bandwidth first. Then later on, i could move on to the logic for prefetch data and BRAMs as IO buffers. Heh, I guessed everyone got their own problems too. IOBs..huh.. Can't help you much on that though. Good luck to you! Thanks alot!~Article: 116853
lschirrm@gmail.com wrote: > Hello: > > Today, Altera announced the Cyclone III device family. > > Highlights: > > Industry's first 65nm low cost FPGA > Shipping now (yes, really) > Up to 120,000 logic elements, Up to 4 Mbits RAM, 288 18*18 multipliers > Aggressive family plan with 8 packages, 8 devices, 3 speed grades, 3 > temp grades, leaded/lead free packaging > Example of power spec: 120K Logic element device static power spec is > ~170mW at 85C typical > Device samples, low cost dev kits, documentation and software are all > available today on www.altera.com > > Link to main page: > http://www.altera.com/products/devices/cyclone3/cy3-index.jsp > Handbook: > http://www.altera.com/literature/lit-cyc3.jsp > > Just a friendly notice to the designer community on this usenet. I can't see any comparison specs for NIOS, on Cyclone II / Cyclone III ? Oh, wait, I found a comment "available in 4Q07" for Nios Kit ? Clicking on the starter kit also says docs : "(available mid-April)" Seems "Shipping now (yes, really)" - applies only to selective aspects of the rollout, not all.. -jgArticle: 116854
When I try to run a timing simulation (simprim is used) modelsim pe student exits with fatal error and exit code 211. Modelsim XE works fine, but sloooow. Does anybody has some experience with this problem and an advice maybe?Article: 116855
On Mar 19, 10:59 am, lyttlec <lytt...@e.goais.net> wrote: > I'm trying to install the alliance toolset > <http://www-asim.lip6.fr/recherche/alliance/> on an Ubuntu linux > machine. I've downloaded both a tarball and RPM sources. The site says > to see the README to install the tarball, but there is no README. The > RPM sources won't build because there is no libiberty.so. > > Anyone know where there are either instructions for installing the > binaries or source for libiberty? libiberty is part of the GNU compiler and debugger distributions. Google is your friend: http://www.google.com/search?hl=en&q=libiberty.so&btnG=Google+Search gets you http://www.sunfreeware.com/libiberty.htmlArticle: 116856
Stock: 0 Availability: ? New definition of "available today," I suppose. AustinArticle: 116857
What is the best way to generate a 125Khz square wave? The DCM only goes down to 5Mhz. Thanks.Article: 116858
Just build a counter that divides by 40. That takes 6 flip-flops. Make it a synchronous counter to avoid ripple delays. Peter Alfke, Xilinx Applications On Mar 19, 8:00 pm, "T-Mike" <tdashm...@gmail.com> wrote: > What is the best way to generate a 125Khz square wave? The DCM only > goes down to 5Mhz. > Thanks.Article: 116859
Engineering samples available now. Production I believe August/September "Austin" <austin@xilinx.com> wrote in message news:etnh8v$pl31@cnn.xsj.xilinx.com... > Stock: 0 > > Availability: ? > > New definition of "available today," I suppose. > > AustinArticle: 116860
Austin wrote: > Stock: 0 > > Availability: ? > > New definition of "available today," I suppose. > > Austin I found : EP3C25F324C8NES 324-FBGA Cyclone=99 III FPGAs Shows 5 avail @ $49.14 - other packages ( and sizes) seem to still be comming.... but. to be fair, let's go to the Xilinx on-line store, and compare performances. Oops, oh right, there IS no Xilinx on line store anymore : just a shell..... So, we jump thru the link to Avnet, on a Spartan XC3S50A in a couple of packages, and oops, again, No stock, "Call", and worse, no price either!! At least Altera tell users what the Cyclone III's will cost, when they are in stock. -jgArticle: 116861
I am getting a warning on 18 and 36 bit wide block rams inferred in my
Verilog code in ISE 9.1. The following code is an example of what
causes the warning. I do not get warnings on 16 or 32 bit wide
blockrams inferred this way. The resulting block rams do not work
properly when loaded into an FPGA.
module bramtest(din, dout, ain, aout, wr, clk);
input [17:0] din;
output [17:0] dout;
reg [17:0] dout;
input [9:0] ain, aout;
input wr, clk;
reg [17:0] bram_test[0:1023];
always @ (posedge clk)
begin
if(wr)
bram_test[ain] <= din;
dout <= bram_test[aout];
end // always @ (posedge clk)
endmodule // bramtest
(From map report)
WARNING:PhysDesignRules:1060 - Dangling pins on
block:<Mram_bram_test/Mram_bram_test.A>:<RAMB16_RAMB16A>. The
block is
configured to use input parity pins. There are dangling output
parity pins.
I would appreciate any suggestions. I would really like to stick with
the inferred memory, but may consider using alternative methods.
Thanks for your help
Darrell Harmon
Article: 116862On Mar 19, 5:49 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > lschi...@gmail.com wrote: > > Hello: > > > Today, Altera announced the Cyclone III device family. > > > Highlights: > > > Industry's first 65nm low cost FPGA > > Shipping now (yes, really) > > Up to 120,000 logic elements, Up to 4 Mbits RAM, 288 18*18 multipliers > > Aggressive family plan with 8 packages, 8 devices, 3 speed grades, 3 > > temp grades, leaded/lead free packaging > > Example of power spec: 120K Logic element device static power spec is > > ~170mW at 85C typical > > Device samples, low cost dev kits, documentation and software are all > > available today onwww.altera.com > > > Link to main page: > >http://www.altera.com/products/devices/cyclone3/cy3-index.jsp > > Handbook: > >http://www.altera.com/literature/lit-cyc3.jsp > > > Just a friendly notice to the designer community on this usenet. > > I can't see any comparison specs for NIOS, on Cyclone II / Cyclone III ? > > Oh, wait, I found a comment "available in 4Q07" for Nios Kit ? > > Clicking on the starter kit also says docs : "(available mid-April)" > > Seems "Shipping now (yes, really)" - applies only to selective aspects > of the rollout, not all.. > > -jg- Hide quoted text - > > - Show quoted text - Hi jg: Sorry for being vague - clarification: The Cyclone III starter kit can run Nios II. You can order it today on the Altera E-store, digikey or any Altera distributor ($199). The "Cyclone III Nios Kit" is a beefier version of the same board that adds embedded systems functionality to round out the platform. It's available later, as you noted. With respect to comparing Cyclone III to Cyclone II, high level looks like: Up to 50% lower power, the higher the density, the greater the power benefit (3C5 is marginal vs. 2C5, 3C120 beats any other FPGA in its density class on power specs by a pretty wide margin) CII has 70KLEs, CIII has 120KLEs CII has 1.1 Mbits of RAM, CIII has 3.9Mbits (huge increase across all densities) CIII has much more sophisticated PLLs (dynamic reconfig, cascadable, 5 outputs per) CII supports 333 Mbps DDR2, CIII supports 400 Mbps DDR2 (fastest to fastest comparison) CIII may be very slightly faster than CII We support both families in their entirety in our free Quartus II web edition software On device availability, I will let the shipments speak for themselves. I hope this answers your questions. This is a usenet for engineers so this is my last post. Altera engineering can take it from here. Lu Schirrmeister AlteraArticle: 116863
I did some search on the topic and the results were quite disappointing, though I would expect something like that should exist: I am working on a theoretical, combinational problem. My software implementation runs for hours for small problems. The main operation is a small table lookup, some additions, etc. However, I use some data structures for reuse of previously computed results. In my SW implementation these are C++ Standard Template Library instances, for instance a set<vector<unsigned short> >, so essentially a hash table. Another structure is a vector<vector<short int* > >, where the innermost array grows up to 10 or 12 elements, and the outer structures to 30 and several hundrets resp. The problem offers more parallelism than one could wish for and the updates to the data structures are moderately frequent. Too frequent however, to do it in SW on a processor. I even have a Spartan-3 board with external memory, this would be fine for running the problem on. However, I do not want to implement these data structures from scratch, which probably would require memory management, caching etc. I think it should be possible to make a circuit generator (similar to the BRASS one) where you feed your required data structures in, adding parameters, like the expected size, update rate etc. and get a circuit out, which will implement them. Similar to the C++ runtime library it would share the memory ressources, use a memory manager but allow parallel requests. In my case I would like to have a high number of ports for the addition to the hash table mentioned first. Seems like a great project for a thesis or a class. Does someone know, where this has been done? Thanks, AndreasArticle: 116864
hi every body , i m asked to read a video using an FPGA , can you please give me some ways that let me adopt to create the test bench of the video? it means what are the different ways to read video into simulation : they told me there is an automatic way and a manual one , please can u explain it to me thank youArticle: 116865
On 2007-03-20, Ruzica <ruzica@die.upm.es> wrote: > Hello everybody, > > I am using Xilinx Timing Analyzer in order to see average delay per > each wire type, i.e. for double, hex, long and single in Virtex II > chips. I found two nets where the number and the type of the wires > used in the both nets are absolutely the same and they pass through > the same number of switch matrixes. However, the difference in the > delays of these two nets is more than 300ps. Could someone tell me > where does this difference come from? Have you looked at the nets in the FPGA editor to see if they are truly taking similar paths? Also, see the following thread: http://groups.google.se/group/comp.arch.fpga/browse_thread/thread/7c6cd879e52ada12/8b60036a4dc77e66?lnk=gst&q=Xilinx+hi-speed+interconnect%2Frouting+question&rnum=1#8b60036a4dc77e66 /AndreasArticle: 116866
Hello everybody, I am using Xilinx Timing Analyzer in order to see average delay per each wire type, i.e. for double, hex, long and single in Virtex II chips. I found two nets where the number and the type of the wires used in the both nets are absolutely the same and they pass through the same number of switch matrixes. However, the difference in the delays of these two nets is more than 300ps. Could someone tell me where does this difference come from? Thanx in advance! RuzicaArticle: 116867
Ken, The Spartan & Virtex parts are VERY different parts... you will certainly encounter a handful of problems trying to port this design. First, the spartan has multipliers, but the DSP slices include MUCH more than that. You will find that if the old design used the multiplier-accumulate portion of the DSP slices, each of those is going to eat up a bunch of FPGA fabric (slices) in the ported version. As for using the DRAM... you will need to either design a controller or use an existing one. Xilinx has a memory interface generator that will generate a controller for you. There are also probably a couple on opencores.org. If you are brand new to FPGA design, I would definately not suggest trying to design your own - DRAM controllers can be tricky. But you will need to rewrite parts of your code to properly interface to the controller, as it will likely not look exactlly like a block ram. Also, if the design made use of the dual-ports on the BRAMs, then you're going to have to come up with a way to get around the fact that you no longer have the luxery of dual ports. Good luck, you've got a hefty project ahead of you. On Mar 19, 8:41 pm, "Ken Soon" <c...@xilinx.com> wrote: > > Spartan 3 has hardware multipliers, so you are not entirely stuck with > doing everything in > > CLBs... only the accumulate, multiplexing and few other unique features > you might not have > > used. If you inferred those DSPs, you should not need to do anything in > particular for the > > Spartan switch. > > > For the DRAMs, first estimate the peak bandwidth you need and the > > best-case the memory you> have can do. If your requirement is less than 75% of your memory's > > theoretical maximum, it> should be doable with a relatively simple memory controller but you will > most likely have > > to re-think your pipeline to accomodate the extra latency: you will at > least have to add > > logic to prefetch data and BRAMs to buffer both the input(s) and > > output(s). You can start > > > > > > > with pipelined bursts of eight words to do full-row transfers to start - > video > > applications can usually be made very compatible with full-row transfers. > For more random > > memory access patterns, bank interleaving and hiding precharge/activate > behind burst > > transfers to other banks is practically mandatory to achieve better than > 50%. > > > Experience with DRAMs is often listed as an asset on jobs I am looking at > so I am trying > > to complete a relevant design in case I get an interview for one of these. > Things are > > progressing slowly and I am expecting lots of grief from the IOB side, in > part due to > > inexperience and in part because the V2Pro's IOBs appear to be more quirky > than the V4s I > > have worked on last year. > > Yeh for the hardware multipliers, I guessed it automatically changed the > DSP48s to the multipliers, but alas, shortage problems again. 60 mulitpliers > needed for 36 available. > > Hmm, for the time being, I shall try to find the information about the peak > bandwidth first. Then later on, i could move on to the logic for prefetch > data and BRAMs as IO buffers. > > Heh, I guessed everyone got their own problems too. IOBs..huh.. Can't help > you much on that though. > Good luck to you! Thanks alot!~- Hide quoted text - > > - Show quoted text -Article: 116868
"Ruzica" <ruzica@die.upm.es> wrote in message news:1174389676.312762.272510@e65g2000hsc.googlegroups.com... > Hello everybody, > > I am using Xilinx Timing Analyzer in order to see average delay per > each wire type, i.e. for double, hex, long and single in Virtex II > chips. I found two nets where the number and the type of the wires > used in the both nets are absolutely the same and they pass through > the same number of switch matrixes. However, the difference in the > delays of these two nets is more than 300ps. Could someone tell me > where does this difference come from? > > Thanx in advance! > > Ruzica > Hello Ruzica, The 4 (?) inputs to the LUTs each have a different delay value associated with them. They're built as a cascade of muxes. Cheers, Syms.Article: 116869
On Mar 20, 12:16 pm, Andreas Ehliar <ehl...@lysator.liu.se> wrote: > On 2007-03-20, Ruzica <ruz...@die.upm.es> wrote: > > > Hello everybody, > > > I am using Xilinx Timing Analyzer in order to see average delay per > > each wire type, i.e. for double, hex, long and single in Virtex II > > chips. I found two nets where the number and the type of the wires > > used in the both nets are absolutely the same and they pass through > > the same number of switch matrixes. However, the difference in the > > delays of these two nets is more than 300ps. Could someone tell me > > where does this difference come from? > > Have you looked at the nets in the FPGA editor to see if they are truly > taking similar paths? > > Also, see the following thread:http://groups.google.se/group/comp.arch.fpga/browse_thread/thread/7c6... > > /Andreas Yes, I've looked at the nets in the FPGA editor and they are indeed taking similar paths. In fact, these two nets have the same source CLB and the same destination CLB (different slices tough), but one goes first to the east and then to the north and the other vice versa, first to the north and then to the east. RuzicaArticle: 116870
Austin wrote: > Stock: 0 > > Availability: ? > > New definition of "available today," I suppose. > > Austin Austin, I'm saddened. With all the recent discussion of sincere problems getting Xilinx parts - no availability at the Xilinx online store and troubles getting s straight answer from distributors who don't carry inventory - you really have no place poking the competition in the ribs about their apparent (lack of) availability. They're an FPGA vendor after all!Article: 116871
dlharmon wrote: > I am getting a warning on 18 and 36 bit wide block rams inferred in my > Verilog code in ISE 9.1. The following code is an example of what > causes the warning. I do not get warnings on 16 or 32 bit wide > blockrams inferred this way. The resulting block rams do not work > properly when loaded into an FPGA. > > module bramtest(din, dout, ain, aout, wr, clk); > input [17:0] din; > output [17:0] dout; > reg [17:0] dout; > input [9:0] ain, aout; > input wr, clk; > reg [17:0] bram_test[0:1023]; > always @ (posedge clk) > begin > if(wr) > bram_test[ain] <= din; > dout <= bram_test[aout]; > end // always @ (posedge clk) > endmodule // bramtest > > (From map report) > > WARNING:PhysDesignRules:1060 - Dangling pins on > block:<Mram_bram_test/Mram_bram_test.A>:<RAMB16_RAMB16A>. The > block is > configured to use input parity pins. There are dangling output > parity pins. > > I would appreciate any suggestions. I would really like to stick with > the inferred memory, but may consider using alternative methods. > > Thanks for your help > > Darrell Harmon I've seen this harmless warning for way too long though I often get it for instantiated BlockRAMs where I don't actually read the parity bits but I write them with zero values so the port isn't undefined. It's possible the complaint is because the write port is written with parity bits but the write port output parity bits are unused. Who cares? I'd suggest you take a look at the FPGA Editor (or some other technology view) to see if all your pins are hooked up properly. If your design truly does not work - as opposed to being a coding/debug problem which it often is for my development - then there is something wrong with the synthesis which has to be addressed by the vendor. I often infer memories with SynplifyPro but haven't used XST for any development. I'd love to see the warning actually mean something but I've lost any confidence that it's communicating anything real because of my past experience with it. - John_HArticle: 116872
On Mar 20, 1:42 pm, "Symon" <symon_bre...@hotmail.com> wrote: > "Ruzica" <ruz...@die.upm.es> wrote in message > > news:1174389676.312762.272510@e65g2000hsc.googlegroups.com...> Hello everybody, > > > I am using Xilinx Timing Analyzer in order to see average delay per > > each wire type, i.e. for double, hex, long and single in Virtex II > > chips. I found two nets where the number and the type of the wires > > used in the both nets are absolutely the same and they pass through > > the same number of switch matrixes. However, the difference in the > > delays of these two nets is more than 300ps. Could someone tell me > > where does this difference come from? > > > Thanx in advance! > > > Ruzica > > Hello Ruzica, > The 4 (?) inputs to the LUTs each have a different delay value associated > with them. They're built as a cascade of muxes. > Cheers, Syms. Hello Symon, 300ps seems like a lot of time to me. Is it possible that this time difference is only due to the different inputs of the LUT? Greetings, RuzicaArticle: 116873
Patrick Dubois wrote: > On Mar 19, 6:25 pm, General Schvantzkoph <schvantzk...@yahoo.com> > wrote: > > >>I built my system from components I bought from Newegg. I don't know of >>any reliable online sources for custom machines, I used to use Monarch >>but they've gone backrupt. Any local white box builder could put the >>system together for you, that's you best bet for a system that can be >>overclocked. > > > The problem with white box builders is warranty... With Dell, you can > have a technician on site within 24 hours if there is a problem. With > a white box computer, you're pretty much on your own (or rather, in my > case, the IT guys are on their own). > There are a few high-end white box builders such as Hypersonic that cater to the gamers, warranty their machines, and have been around for a while. They tend to be rather pricey though.Article: 116874
Ruzica wrote: > Hello everybody, > > I am using Xilinx Timing Analyzer in order to see average delay per > each wire type, i.e. for double, hex, long and single in Virtex II > chips. I found two nets where the number and the type of the wires > used in the both nets are absolutely the same and they pass through > the same number of switch matrixes. However, the difference in the > delays of these two nets is more than 300ps. Could someone tell me > where does this difference come from? > > Thanx in advance! > > Ruzica Often the destination can determine a large difference in delay - the four LUT inputs are not the same! THe HEX and DOUBLE lines are not necessarily the same delays unless you're using the same HEX or the same DOUBLE in two different CLB destination/source pairs. The path chosen within the routing box will vary greatly depending on the specific path chosen.
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