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
Thanks for the answer. I haven=92t even started the design, but I intend to use a Microblaze to enable access to MP3 bitstreams from a network. I just came across an interesting publication from Xilinx: http://www.xilinx.com/publications/xcellonline/xcell_58/xc_pdf/p066-069_58-= embroc.pdf which deals with just that. In addition it deals with an MP3 decoder running in another Microblaze in the same FPGA. By using the FPGA logic and DSP resources for accelerating the DCT/IMDCT part of the decoding they managed to increase the performance 41x compared to a pure software implementation. Looks promising, but I don=92t know about the amount of work it would require. Your decoding core also looks interesting. Please tell me more about it. You are mentioning processor - is it a custom hardware accelerated processor executing code?? Or? Generally, do you have any idea how many streams you can encode/decode in real time in a 30 000 LUT FPGA? You=92re free to use any technique! /FredrikArticle: 137926
On Feb 1, 10:08 am, "Wiljan" <wil...@post8.fjern.tele.dk> wrote: > Now I realy need to rotate the video signal 90 degree.... and I'm a bit out > of ideas If your aspect ratio (horizontal to vertical pixel counts) were identical it could be as simple as changing the input or output state machine to index through memory in a different way. Since the aspect ratios are probably not the same, it's going to be harder - you will likely need to shrink the video and put some black bars on either side. You should be able to do the shrinking computation-free by using different bit block rates on the input and output. The black bars are just a little logic adjustment to the idea of on-screen vs. overscan areas.Article: 137927
On Feb 2, 2:51 pm, cs_post...@hotmail.com wrote: > On Feb 1, 10:08 am, "Wiljan" <wil...@post8.fjern.tele.dk> wrote: > > > Now I realy need to rotate the video signal 90 degree.... and I'm a bit out > > of ideas > > If your aspect ratio (horizontal to vertical pixel counts) were > identical it could be as simple as changing the input or output state > machine to index through memory in a different way. > > Since the aspect ratios are probably not the same, it's going to be > harder - you will likely need to shrink the video and put some black > bars on either side. You should be able to do the shrinking > computation-free by using different bit block rates on the input and > output. The black bars are just a little logic adjustment to the > idea of on-screen vs. overscan areas. sorry, 'bit clock' not 'bit block'Article: 137928
On Feb 2, 11:44=A0am, Enno L=FCbbers <ennonym...@googlemail.com> wrote: > Hi .*, > > in my partially reconfigurable Xilinx EDK design, I'm trying to > constrain a certain BUFG to a BUFGMUX location. The BUFG in question > is located inside a DCM wrapper, and its instantiation is controlled > by a generic: > > ### excerpt from DCM source code $XILINX_EDK/hw/XilinxProcessorIPLib/ > pcores/dcm_module_v1_00_c/hdl/vhdl/dcm_module.vhd> > > =A0Using_BUGF_for_CLK0 : if (C_CLK0_BUF) generate > > =A0 =A0 CLK0_BUFG_INST : BUFG > =A0 =A0 =A0 port map ( > =A0 =A0 =A0 =A0 I =3D> CLK0_BUF, > =A0 =A0 =A0 =A0 O =3D> CLK0); > =A0 end generate Using_BUGF_for_CLK0; > > ### > > How do I find the actual instance name of this BUFG to put into my UCF > file? I've tried looking it up in the fpga_editor, which gives me > "dcm_0/dcm_0/Using_BUGF_for_CLK0.CLK0_BUFG_INST", which doesn't work > (ngdbuild complains about unrecognized LOC constraints). I've tried > allowing unmached constraints (-aul), mapping the design, and > converting it to a xdl file using "xdl -ncd2xdl". That crashed on me > with an assertion error. I've tried almost every combination of > slashes, underscores and periods to separate the components of the > instance name, to no avail. > > I'm using ISE9.2.04/EDK9.2.02 with EAPR patch PR7. The FPGA is a > xc2vp30-ff896. > > Any suggestions would be greatly appreciated! > > Thanks > - Enno The most obvious suggestion is to go back to the architecture wizard, select "internal" clock source, instantiate your BUFG at your higher level of code, and then add the LOC constraint. Cheers, GaborArticle: 137929
On Feb 2, 2:22=A0pm, fbob <fantasma...@gmail.com> wrote: > Hi everyone, > > I have 2 unrelated questions: > > 1) I have a Xilinx ML505 board and I am looking for a way to make my > SRAM power cycle automatically. Ideally I would like the SRAM to power > off, then power on again after 30 seconds or more. Is there any way to > have either the SRAM individually, or the board as a whole, do this? > > 2) The ML505 schematics say the RS 232 port is DTE, while the User > Guide says it is DCE. Can anyone confirm which is correct? Do I need a > null-modem cable or a straight-through cable to connect to a PC? If you have the schematics, you can find out if the driver is on pin 2 or pin 3 of the DB-9 connector telling you how to wire the cable. I'm not familiar with this board. Does it have jumpers to allow pin 2 and 3 to be swapped? RickArticle: 137930
FIY, to obtain the number of Logic cells in the spartan-6 device, you multiply the number of slices by 6.4, even though there are only 4 LUTs in each slice. Basically, Xilinx expects each 6-input LUT to be 1.6 times more efficient than a 4-input LUT. Simple arithmetic tells us that it's 1.5, I suppose that the people at Xilinx have their reasons. Time will tell, if that comparison is valid, though I suppose it depends on the kind of logic you use, whether or not can split your logic in 2 5-input LUTs, etc. Plus only 25% of the slices will be able to implement SRL32, don't know why, but it remains to be seen what kind of impact this will have. On the bright side, there are now integrated memeory controllers for DDR, DDR-II and DDR-3, apparently up to 800 MHz DDR . So far, it seems promising. My 2 centsArticle: 137931
On Feb 2, 2:11=A0pm, "Symon" <symon_bre...@hotmail.com> wrote: > Antti wrote: > > On Feb 2, 8:33 pm, Uwe Bonnes <b...@elektron.ikp.physik.tu- > > darmstadt.de> wrote: > >> Leon <leon...@btinternet.com> wrote: > >>> TQ144 is the smallest Spartan-6. > > >> ... and the onle non-BGA > >> -- > >> Uwe Bonnes b...@elektron.ikp.physik.tu-darmstadt.de > > >> Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > >> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > > > it could be that there is one BIG client who needs this package > > this also explains why it was in initial offering for the S3A > > as only non-BGA (at initial announcment of s3a) > > > Antti > > Hi, > It might be the only TQ package that has a hope in hell of having decent = SI > performance with the rise times of these new parts. I'd suggest only QFNs > would be an alternative to the BGA packages. I see 3.3V logic has gone fr= om > the V6 parts. > Cheers, Syms. The last time I looked at a Xilinx part, the edge rates were programmable. Besides, if you are in a 100 pin package, you don't have to provide for ground currents of 200 pins. Most will provide 60 some I/Os with around 6 to 8 I/Os per ground and power pin pair. It is the high pin count packages that have trouble with ground bounce and fast edge rates that have trouble with SI issues. I have a current design that is using a 100 QFP with a 3000 LUT part. The initial design is using around 2000 of those LUTs. If I need to expand the design, which may be an enhancement request from the customer, I may not be able to provide it without going to a new package which will raise the cost. It would be nice to have choices of chips in the small packages without paying more for BGAs. The other choice in this case is to remove the FPGA and use an MCU/DSP with a small CPLD for the specialized hardware. This won't be more expensive in recurring costs, but will have higher development costs of course. The QFNs are an option, but there are still few in low pin counts which is what drives the part cost from what I have been told. RickArticle: 137932
>kristian <kris11@gmx.de> wrote: > >> I'm implementing a autocorrelation function using a fft and ifft hard core >> (v6.0) on a Virtex5. When starting the fft, I see at the output that the >> result is reversed in the frequency domain. > >If you are feeding the result of fft into ifft, possibly with some >frequency domain filtering, it is much more efficient that way. > >If not, there should be cores that generate in the more usual order. > >-- glen > hi glen, the ifft expects the values in normal order. the only way is to save the values from the fft in ram. is this normal that the fft core from xilinx has reversed output data? Regards, krisArticle: 137933
On Fri, 30 Jan 2009 15:43:10 -0800 (PST), -jg <Jim.Granville@gmail.com> wrote: |> What happened to 4 & 5? | |Looks like Xilinx marketing want to 'resync' as the Virtex 6 and |Spartan 6 |(and hey, it's a number higher than Altera so that's worth something |in their |world, right ;) | |Anyone seen package choices for Spartan 6 yet ? | try this link http://www.xilinx.com/products/v6s6.htm jamesArticle: 137934
On Jan 31, 8:01=A0pm, Antti <Antti.Luk...@googlemail.com> wrote: > On Jan 31, 8:06=A0am, rickman <gnu...@gmail.com> wrote: > > > > > On Jan 30, 6:43=A0pm, -jg <Jim.Granvi...@gmail.com> wrote: > > > > > What happened to 4 & 5? > > > > Looks like Xilinx marketing want to 'resync' as the Virtex 6 and > > > Spartan 6 > > > (and hey, it's a number =A0higher than Altera so that's worth somethi= ng > > > in their > > > world, right ;) > > > > Anyone seen package choices for Spartan 6 yet ? > > > > Are Xilinx going to push prices, or leave the sub $1 / Low power area > > > to Actel ? > > > I sure wish they would support the smaller leaded packages. =A0A decent > > sized chip in a 100 pin QFP would be so nice; low price, easy assembly > > and good access to the pins for debug. =A0I don't get why they haven't > > done this before. =A0Every I/O adds cost. =A0They won't get under $10 i= n > > moderate quanties until they pick some better packages. > > > Rick > > Sorry Rick I can not comment in public. I hope it all be known on > monday. > I have some comments, i make them public as soon as the info is no > longer under NDA > (that is i can comment on what xilinx has made public itself) > > Antti Comments: Xilinx have goofed and made one PDF (Spartan6_Overview.pdf) non- selectable Smallest package is TQG144, 0.5mm 20mm sides - 2 parts in that package VCO looks good : - 400MHz-1100MHz, and 8 phases out. Missing: Any notes on prices, or relative speeds of IP ? and Rather Too much of this sort of nonsense-fluff : "Fulfilling the Programmable Imperative"Article: 137935
Nathan Bialke wrote: > Hello, > > In case anyone hasn't already seen, Xilinx has some preliminary > information about Virtex-6 and Spartan-6 online here - > http://www.xilinx.com/products/v6s6.htm . > > I do have a question about Virtex-6 and it's one LUT6/two flip-flop > architecture. I'm struggling to think of why a user would have any use > for that second flip-flop. Hopefully the tools will be able to use it. :) They have split to three slice types: Slice M,L,X - and the most comprehensive has SRL32, 2 x SRL16, 2 x 32 bit RAM - with those dual choices, it also points to a dual-output / dual flip- flip cell being needed to handle their outputs. All sounds logical to me. -jgArticle: 137936
On Feb 2, 4:45=A0pm, -jg <Jim.Granvi...@gmail.com> wrote: > > =A0and Rather Too much of this sort of nonsense-fluff : "Fulfilling the > Programmable Imperative" Are you saying that you don't care if your programmable imperative is fulfilled or not??? ;^)Article: 137937
On Mon, 2 Feb 2009 12:25:34 -0800 (PST), rickman <gnuarm@gmail.com> wrote: >On Feb 2, 2:22 pm, fbob <fantasma...@gmail.com> wrote: >> Hi everyone, >> >> I have 2 unrelated questions: >> 2) The ML505 schematics say the RS 232 port is DTE, while the User >> Guide says it is DCE. Can anyone confirm which is correct? Do I need a >> null-modem cable or a straight-through cable to connect to a PC? > >If you have the schematics, you can find out if the driver is on pin 2 >or pin 3 of the DB-9 connector telling you how to wire the cable. > >I'm not familiar with this board. Does it have jumpers to allow pin 2 >and 3 to be swapped? I don't believe it does, and DTE vs DCE is one of those naming conventions that is pretty much lost in the mists of time, asong with 25-pin RS232 connectors. But you do need a null-modem cable to connect to a PC's serial port. - BrianArticle: 137938
On 2 Feb., 21:33, Benjamin Couillard <benjamin.couill...@gmail.com> wrote: > FIY, to obtain the number of Logic cells in the spartan-6 device, you > multiply the number of slices by 6.4, even though there are only 4 > LUTs in each slice. Basically, Xilinx expects each 6-input LUT to be > 1.6 times more efficient than a 4-input LUT. Simple arithmetic tells > us that it's 1.5, How is that? Why should a 6 LUT be 1.5 times a 4 LUT? If all functions would be equally likely to occur in a netlist than the ratio would be 4x. (There are O(2**(2**N)) function of N inputs. It can be shown that at least half of those functions require at least O(2**N) gates to be implemented). Also, a 6-LUT is 4x as large as a 4-LUT. On the other hand, adders are among the most common functions in real world circuits, and for these even a 4-LUT is wasted area and a 6-LUT gains nothing. What you really need to compare is how many gates of a typical netlist can be covered by a single LUT on average. The reason why it makes sense to spend 4x the logic area to cover only 1.6x the number of gates is that in todays FPGAs most of the area is spent by routing. So blowing up the logic does not hurt the area a lot and actually makes routing simpler. Kolja SulimmaArticle: 137939
Kolja Sulimma <ksulimma@googlemail.com> wrote: > On 2 Feb., 21:33, Benjamin Couillard <benjamin.couill...@gmail.com> > wrote: >> FIY, to obtain the number of Logic cells in the spartan-6 device, you >> multiply the number of slices by 6.4, even though there are only 4 >> LUTs in each slice. Basically, Xilinx expects each 6-input LUT to be >> 1.6 times more efficient than a 4-input LUT. Simple arithmetic tells >> us that it's 1.5, > What you really need to compare is how many gates of a typical netlist > can be covered by a single LUT on average. Well, the ratio of the number of 4LUTs to the number of 6LUTs to cover an average netlist. That makes it independent of the actual 'gate' count. -- glenArticle: 137940
On Feb 2, 11:50=A0am, Muzaffer Kal <k...@dspia.com> wrote: > On Mon, 2 Feb 2009 00:59:11 -0800 (PST), Digi Suji > > <digis...@gmail.com> wrote: > >Hi, > > >My design has modules like i2c controller, cpu, sram, gpio. I > >integrated all the above modules. This design is implemented in > >Spartan 3e based Digilent Basys board. The design when triggered, > >reads data from the externally connected I2C EEPROM, copies into SRAM > >in the design and then triggers the cpu to process the data and output > >the result on to the leds on board. > > >When I configure the FPGA with the bit file(write the bit file into > >ROM on board/FPGA), the design works fine for the first time but when > >I push the FPGA reset button to reconfigure the FPGA, the design does > >not work. When I power the whole board off, wait for some time and > >then repeat the process, it works fine only for the first time. > > You're probably not using the reset correctly. Make sure you > synchronize the reset signal to your internal clock (ie pass it > through a 2 bit shift register and use the output as the reset) which > would allow you to check the timing of it whether it's synchronous or > asynchronous. > -- > Muzaffer Kal > > DSPIA INC. > ASIC/FPGA Design Serviceshttp://www.dspia.com Hi Muzaffer, Thanks for your response. I am talking about the whole FPGA being reset in order to reload my design into FPGA again, not resetting my design in the FPGA......here is the data sheet of EEPROM I am using... http://ww1.microchip.com/downloads/en/devicedoc/21203M.pdf I get expected results when I do post place and route simulation but not in the hardware... Do you have any suggestions for me? Thanks for your time and help.Article: 137941
On Feb 2, 11:50 pm, Gabor <ga...@alacron.com> wrote: > On Feb 2, 12:41 am, reganirel...@gmail.com wrote: > > > 1 more things I should have added: > > > I have used XAPP485 to do the deserializing of the stream. > > Camera Link puts FVAL and LVAL in the same LVDS pair > for the channel link interface. So it is possible that > only that one pair has some signal integrity problem, > possibly too much skew to the clock pair? If that is > the case and the other pairs work OK, you could get > good pixel data while the FVAL and LVAL signals bounce > around. > > Regards, > Gabor Yes, that is what I'm hoping is the problem, solely the RX2 pair where DVAL/FVAL/LVAL are consecutive. The pixel data looks very well behaved, bouncing around on clock edges for 320 clocks (2 taps, 320 each, 640pix wide image), then dead low for 80pix. I have few doubts now that the problem lies in the way I have connected the camera to the FPGA dev board: from an MDR26 connector fly-wired to some 2.54mm crimps. I know eventually I will need a proper board, but I hoped to get a bit of prototyping done without much outlay... Going to talk to some others about how better to shield the LVDS pairs, particularly RX2. ReganArticle: 137942
On Feb 3, 10:59=A0am, rickman <gnu...@gmail.com> wrote: > On Feb 2, 4:45=A0pm, -jg <Jim.Granvi...@gmail.com> wrote: > > > =A0and Rather Too much of this sort of nonsense-fluff : "Fulfilling the > > Programmable Imperative" > > Are you saying that you don't care if your programmable imperative is > fulfilled or not??? > > ;^) I'm not even sure where to find my programmable imperative !! ;)Article: 137943
well, this is all very nice, but more importantly, when are they going to actually start delivering these things, and how much will they cost ? I can't really believe they haven't *got* that information, so why the staged release of info ? SimonArticle: 137944
On Feb 2, 3:33 pm, Benjamin Couillard <benjamin.couill...@gmail.com> wrote: > FIY, to obtain the number of Logic cells in the spartan-6 device, you > multiply the number of slices by 6.4, even though there are only 4 > LUTs in each slice. Basically, Xilinx expects each 6-input LUT to be > 1.6 times more efficient than a 4-input LUT. This is all too bizarre. No other company in the world counts "logic cells" or "slices". No one but Xilinx knows what a "logic cell" is and I don't know what a slice is in the Spartan 6 parts because I can't open the Spartan 6 overview in Acrobat 6. For whatever reason I can't install Acrobat Reader 8 and Sumatra PDF seems to be considered a virus by my AVS and it won't let it run. Regardless, counting logic cells and slices is pointless. Counting LUT4s was a valid comparison because most FPGAs used them. But with the introduction of LUT6s in Altera and now Xilinx parts, the jig is up and we can't compare across families with these logic elements. Trying to compare parts with different LUT sizes (or different mixtures of LUTs and FFs) depends too much on the details of your design. Different applications require different mixtures of logic and FFs just like you can't compare processor speeds based on the CPU MHz or the memory bandwidth. > Simple arithmetic tells > us that it's 1.5, I suppose that the people at Xilinx have their > reasons. You mean the marketing people?... > Time will tell, if that comparison is valid, though I suppose > it depends on the kind of logic you use, whether or not can split your > logic in 2 5-input LUTs, etc. Plus only 25% of the slices will be able > to implement SRL32, don't know why, but it remains to be seen what > kind of impact this will have. Using a LUT as an SRL requires added logic in the LUT. No design will use a large fraction of the LUTs as SRLs. So why add the logic in all LUTs? The only real impact is in how to route to the SRLs that are implemented. > On the bright side, there are now integrated memeory controllers for > DDR, DDR-II and DDR-3, apparently up to 800 MHz DDR . Is that in the Virtex only or also the Spartan parts? RickArticle: 137945
On Feb 2, 8:38=A0pm, Simon <goo...@gornall.net> wrote: > well, this is all very nice, but more importantly, when are they going > to actually start delivering these things, and how much will they > cost ? > > I can't really believe they haven't *got* that information, so why the > staged release of info ? > > Simon Whatttt??? Are you saying that you want to put a price and schedule on fulfilling your programmable imperative? RickArticle: 137946
On 2 f=E9v, 21:59, rickman <gnu...@gmail.com> wrote: > On Feb 2, 3:33 pm, Benjamin Couillard <benjamin.couill...@gmail.com> > wrote: > > > FIY, to obtain the number of Logic cells in the spartan-6 device, you > > multiply the number of slices by 6.4, even though there are only 4 > > LUTs in each slice. Basically, Xilinx expects each 6-input LUT to be > > 1.6 times more efficient than a 4-input LUT. > > This is all too bizarre. =A0No other company in the world counts "logic > cells" or "slices". =A0No one but Xilinx knows what a "logic cell" is > and I don't know what a slice is in the Spartan 6 parts because I > can't open the Spartan 6 overview in Acrobat 6. =A0For whatever reason I > can't install Acrobat Reader 8 and Sumatra PDF seems to be considered > a virus by my AVS and it won't let it run. Yeah, of course, you can't really compare a 6-input LUT with a 4-input LUT. Plus ALtera seems to have a more flexible 6-input LUT than Xilinx, so I wonder how we can compare exactly 2 FPGAs from 2 differente companies. > > Regardless, counting logic cells and slices is pointless. =A0Counting > LUT4s was a valid comparison because most FPGAs used them. =A0But with > the introduction of LUT6s in Altera and now Xilinx parts, the jig is > up and we can't compare across families with these logic elements. > > Trying to compare parts with different LUT sizes (or different > mixtures of LUTs and FFs) depends too much on the details of your > design. =A0Different applications require different mixtures of logic > and FFs just like you can't compare processor speeds based on the CPU > MHz or the memory bandwidth. > > > Simple arithmetic tells > > us that it's 1.5, I suppose that the people at Xilinx have their > > reasons. > > You mean the marketing people?... Yeah,but I hope that they have benchmarks, like FFTs, memory controllers, microblaze, etc. that will give us an idea of how efficient is the new 6-input LUT. > > > Time will tell, if that comparison is valid, though I suppose > > it depends on the kind of logic you use, whether or not can split your > > logic in 2 5-input LUTs, etc. Plus only 25% of the slices will be able > > to implement SRL32, don't know why, but it remains to be seen what > > kind of impact this will have. > > Using a LUT as an SRL requires added logic in the LUT. =A0No design will > use a large fraction of the LUTs as SRLs. =A0So why add the logic in all > LUTs? =A0The only real impact is in how to route to the SRLs that are > implemented. Yeah, you're right I guess. > > > On the bright side, there are now integrated memeory controllers for > > DDR, DDR-II and DDR-3, apparently up to 800 MHz DDR . > > Is that in the Virtex only or also the Spartan parts? > > Rick Spartan-6 only, I suppose that they determined that the cost of adding embedded memory controllers was worth it. Furthermore, it seems to be a multiport memory controller, so the wrapping needed might be minimal. Of course, time will tell.Article: 137947
On Feb 3, 5:05=A0am, rickman <gnu...@gmail.com> wrote: > On Feb 2, 8:38=A0pm, Simon <goo...@gornall.net> wrote: > > > well, this is all very nice, but more importantly, when are they going > > to actually start delivering these things, and how much will they > > cost ? > > > I can't really believe they haven't *got* that information, so why the > > staged release of info ? > > > Simon > > Whatttt??? =A0Are you saying that you want to put a price and schedule > on fulfilling your programmable imperative? > > Rick yes, we would like to see the price tag on the "programmable imperative" well, Xilinx is now the second company offering high speed serdes in the low cost family, while Lattice being the only one currently shipping low cost with serdes (ECP family) if i recall correctly Lattice rule of thumb is 1KLUT=3D1$ hmm the small volume pricing seems to be more 1KLUT=3D1.5$ so i bet the S-6 pricing should line up somewhere close say in range 1-2$ per KLUT probably less then 1$ for some devices in large volume AnttiArticle: 137948
"Digi Suji": > I am talking about the whole FPGA being reset in order to reload my > design into FPGA again, not resetting my design in the FPGA......here > is the data sheet of EEPROM I am using... > I get expected results when I do post place and route simulation but > not in the hardware... > Do you have any suggestions for me? > Thanks for your time and help. Have you tried to track down the error? You just said: "powerup: everyting works", "reset: nothing works" Is there a problem with the the FPGA-configuration, or is it a bootloading problem of the fpga-embeded cpu? Gruss Jan BrunsArticle: 137949
On 2 Feb., 21:16, Gabor <ga...@alacron.com> wrote: > The most obvious suggestion is to go back to the architecture > wizard, select "internal" clock source, instantiate your BUFG > at your higher level of code, and then add the LOC constraint. Right, that's what I'm going to do as a workaround, but the whole BUFG constraining process is part of a larger automated tool chain, which would have to be adapted. I imagine there has to be an easier way, but if that's what I have to do... Thanks! - Enno
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