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
--------------6B33379119AB197250C2686D Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Click on http://www.google.com where billions of pages are indexed. Peter Alfke Dan wrote: > Is it possible to directly drive/receive a IEEE1394 firewire bus from the > LVDS outputs of a Xilinx FPGA ? > > Also, where is a good place to learn more about the firewire standard ? > > Sincerely > Daniel DeConinck > High Res Technologies, Inc. --------------6B33379119AB197250C2686D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Click on<u></u> <p><u><A HREF="http://www.google.com">http://www.google.com</A></u> <p>where billions of pages are indexed. <p>Peter Alfke <p>Dan wrote: <blockquote TYPE=CITE>Is it possible to directly drive/receive a IEEE1394 firewire bus from the <br>LVDS outputs of a Xilinx FPGA ? <p>Also, where is a good place to learn more about the firewire standard ? <p>Sincerely <br>Daniel DeConinck <br>High Res Technologies, Inc.</blockquote> </html> --------------6B33379119AB197250C2686D--Article: 28701
> Everybody came out a winner: They, we, and you, our Virtex-II customers. And where can I buy that Virtex-II so I can become a "Virtex-II customer", hum? I can't even get Spartan II devices now, much less Virtex-II....Article: 28702
Austin Franklin wrote: > > Everybody came out a winner: They, we, and you, our Virtex-II customers. > > And where can I buy that Virtex-II so I can become a "Virtex-II customer", > hum? > > I can't even get Spartan II devices now, much less Virtex-II.... Spartan-II was a unique kind of problem, and it looks like we are getting to the end of the tunnel. Sorry for the aggrevation, and be assured that there are plenty of people in this building here that are also very aggrevated about the problem, and have been working hard to fix it. I have been hounding Virtex marketing, and they have sworn holy oaths to be more sensitive to the small-volume customer. Let's see. The first Virtex-II part that should be plentifully available is the little XC2V40, in case you need something to experiment with. We are just finishing an evaluation board to give to our FAEs worldwide. That's also the vehicle to build the 1 GHz counter, and to measure metastability. BTW the Virtex-II Handbook is on the web, all 536 pages of it: Go to www.xilinx.com click on the top big circle: Platform FPGA click on the top-right item under Related Features: The Virtex-II Handbook Enjoy ! Peter Alfke, Xilinx ApplicationsArticle: 28703
Allan, There is a register before the last partial product accumulator that can be used to make the multiplier synchonous, and aid in pipelining it and getting much higher speed from it. Unfortunately, software does not support this feature initially. (I know, I know...but we got almost everything else in and working so don't be too unhappy). If this is a requirement initially, I am sure we can work something out (e.g. a core or something). The idea behind the multiplieres is that they are parked next to the bram's so FIR filters, FFT's, etc are easy to implement at incredible clock rates. This is all part of the Xtreme DSP initiative that is rolling in to town. With all of those 18X18 multipliers, BRAM's, and gates, these things blow the doors of any DSP out there by a factor of about 80 times faster. Austin Allan Herriman wrote: > Hi Peter, > > Can you please let me know if there's an option to allow the multipliers > to be clocked? The picture in the datasheet makes it look like the > multiplier is a purely combinatorial function of the inputs. The timing > information supports this. > > I am concerned that the relatively slow clock to output delay of the > block rams coupled with the multiplier delay will limit the clock speed > to about 100MHz in filter applications. > > Thanks, > Allan. > > Peter Alfke wrote: > > > > Ray, this may be the rare case where your long ( and distinguished ! > > ) experience misleads you. > > In the 13 years I have been at Xilinx, I have never seen us as well > > prepared for the introduction of a new family, as we are today with > > Virtex-II. > > We have had software since last October, silicon since late > > November, and have been testing it furiously ever since. We finished > > writing a 536-page Virtex-II Handbook in December, and shipped many > > thousands of printed copies in early January. We have had extensive > > training for our FAEs last fall, and we are putting together the > > slides for a public seminar right now. > > Highest on my list of exciting features is the Digitally Controlled > > Impedance, which effectively puts the series termination resistor > > right into the output driver, or the parallel termination right into > > the input buffer ( all optionally of course). It will be a gods-end > > for people putting >500-pin packages on a pc-board, not having to > > bother with resistor packs... > > Hundreds of 18 x 18 multipliers (<4ns) are nice, as are 16 global > > clocks in all devices, each with an input mux that can glitch-free > > select between two sources. Ripple carry delay is 45 ps per bit, a > > 24-bit synchronous counter runs at 300 MHz, etc. > > Exciting stuff. As I mentioned,earlier, I am working on a 1 GHz > > frequency counter, on a 200 MHz asynchronous FIFO, and on > > metastability testing. > > > > Sorry for the blatant propaganda. Got carried away by my enthusiasm. > > > > I had been impatiently waiting for the Ides of January, for a long > > time ! > > > > Peter Alfke, Xilinx Applications > > ===================================== > > Ray Andraka wrote: > > > > > erika_uk@my-deja.com wrote: > > > > > > > > Hi, > > > > > > > > Does the tool handle it well ? > > > > > > Like any other new architecture, I suspect it will take a while > > > for the tools to catch up to the new silicon. In the past, > > > it has taken about a year after the introduction of the > > > silicon before the tools were close to ready for prime time. > > > Macro libraries lag even further behind. In the case of Virtex, > > > I didn't start recommending them for customers until a little > > > over a year ago...because of tools issues. > > > > > > > > > > > --Erika > > > > In article <979567585.218715@news2.cybercity.dk>, > > > > "Rune Baeverrud" <fpga@no.spam.iname.com> wrote: > > > > > Hello, > > > > > > > > > > Xilinx Virtex-II has now been officially announced. > > > > > > > > > > Check out the press release: > > > > > http://www.xilinx.com/prs_rls/vtx2ship.htm > > > > > > > > > > and the Virtex-II Handbook: > > > > > http://www.xilinx.com/products/virtex/handbook/index.htm > > > > > > > > > > Some highlights are: > > > > > - digitally controlled impedances for input and output pins > > > > > - new resources for clock management and clock synthesis > > > > > - digital spread spectrum clocking > > > > > - encrypted bitstreams > > > > > - dedicated multipliers > > > > > > > > > > Go and see for yourself! > > > > > > > > > > Regards, > > > > > Rune Baeverrud > > > > > > > > > > > > > > > > > > Sent via Deja.com > > > > http://www.deja.com/ > > > > > > -- > > > -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 or http://www.fpga-guru.comArticle: 28704
Austin, Good points. I will look it up tomorrow when I get in to work. I am thinking of Virtex II, with its flip chip and conventional packages, for the same die in two different packages. I am thinking that die up, or die down is a good thing to know when IO floorplanning as you state. I doubt that the software can (or will) be made to "look in the mirror" so to speak, I think you will have to get used to the mental adjustment of thinking top down, or bottom up as required. Austin (that seems odd...I have never met anyone with the first name Austin....) Austin Franklin wrote: > It appears that the FG456 parts are cavity UP, but I want to make sure > before doing my pinouts... > > The floorplanner gives the low number, low letter in the upper left. The > FPGA Editor gives the low number, low letter in the upper left. The package > drawing shows low number, low letter in the upper left (top view of > package). That to me, means this is a cavity up part. > > The BG352 is a cavity down part...since the floorplanner gives the low > number low letter in the in the upper RIGHT . The FPGA Editor gives the low > number, low letter in the upper RIGHT. The package drawing shows the low > number, low letter in the upper left (top view of package). That, to me, > means this is a cavity DOWN part...since the die has to be flipped to line > up the die pins with the package pins. > > Both the FPGA Editor and the Floorplanner are both 'die' view, it would > appear. When doing floorplanning, at least for me, I would prefer the > Floorplanner be a TOP view (or give you the option of die view or top view), > so I can lay my chip out without having to flip everything over to really > see how it lines up with the outside world... > > I REALLY wish they had a chart that showed the orientation of the die in > each package...and I've mentioned this to them many a time. > > Any comments?Article: 28705
Ralf A. Eckhardt wrote: > > Greg Neff wrote: > > Have you checked to make sure that the input data meets the input > > setup and hold time requirements? > > The input comes asynchroneously (changes slowly, stable for > microseconds) and the D-FF is supposed to synchronize it. > If the hold time is not met, I would expect the data to be > latched at the following rising clock (33ns later). > But it comes /never/ or 10..20 cycles later. > > Might metastability be a serious problem here? Slow edges can do strange things, as can data undershoot, but for a register to miss MORE than one cycle is strange in the extreme. After all, when a NEW clock arrives, a new state-pair occur in the register follow/hold latch Can you run just this register, without the BUS or any other activity ? Unused pins are ?? - All Power pins connected ? -jgArticle: 28706
<html><head><title>ewebform</title> <meta http-equiv="Content-Type" content="text/html; charset=gb2312"> </head><body><p> Hi,<br><br>You have to check out DatingClub.com!<br><br>It's an incredible dating site with 1,700,000 members from all over the world. You can meet your ideal mate by searching through the database, matching profiles, checking out photos, sending anonymous emails, chatting, and sending messages.<br><br>There are also many other features that make online dating fun, and DatingClub.com Membership worthwhile. For instance, they have community pages with great links and interactive features. There are forums and search features for each individual community, as well. Not to mention the amazing special offers made available only to Members! <br><br>Your profile will be visible as soon as you activate your Membership, so go register now! http://DatingClub.com/Aenter.asp?SID=222716145 <br><br><br><br></p> <br><br><iframe src="http://www.ewebform.com/webinfo/showme.htm" width=60 height=15 frameborder=0 scrolling=no></iframe></body></html>Article: 28707
Peter Alfke wrote: > Rick Collins wrote: > > > > I doubt that it will be practical to use five XC2V250s on our board in > > place of five XC2S50s. But the SpartanII chips use too much power on > > current. > > Sorry for that. Can you perhaps stagger the Vcc to teh 5 chips? The power-on > current lasts only milliseconds... Staging the power up is not practical. I have been told that the power surge is purely due to the Vcc coming up and there is no way to hold it off. Adding power switches would take up too much real estate. Plus I need to make the board in the industrial temp range for some customers. This gives me less power from the converters and makes the SpartanII chips draw more power on startup. > > So I expect that I will be back where I started, needing to use > > the Altera 1K parts. But I may be able to use one XC2S50-5FG256C and > > four XC2V40-4CS144C. I need to look at the IO requirements in detail. > > I would be aggressive and integrate higher. I cannot believe you need all those I/O > when you put it all in one chip, like the XC2V1000. > You get 432 I/O, >10,000 Logic Cells = flip-flops, where the XC2S50 has only > 1,728. > > And, the XC2V1000 is alreadyavailable ( in very limited quantity ) > The '40 and '1000 were the first ones "out of the oven", all others will be coming > soon. > > I think I have already touted the superior features of Virtex-II before. > > Good luck! > > Peter I would love to use just one chip on the board instead of five. But one chip is a master board controller and the other four are IO interface devices. The four IO devices get loaded with different bit files at power up depending on the IO module installed, much like plug and play. So until someone gets partial reconfiguration working to a point that it is not just a research topic, I am stuck with five FPGAs on this tiny board. And I have to use fine pitch BGAs to boot! One advantage of the Altera ACEX chips is that I can use the same part in all five positions by using some of the extra IO of one of the IO interface devices to let me have less IO on the main board controller. The total cost is still pretty low considering that I am using larger parts for the IO than is really needed. Any idea of when I can get pricing on the '40? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX URL http://www.arius.comArticle: 28708
On Fri, 19 Jan 2001 05:38:29 -0800, "Tomasz Nakielski" <tnakiels@poland.com> wrote: This usually happens when the cable is not powered. The JTAG cable needs +5V from the board at which it is connected. Greetings Klaus >Hello. > >I have a problem with programming Virtex (XVC200PQ240) via >JTAG Parallel Cable III Model DLC5 and Programmer 3.3.06i. from one of my PC. >I receive message: "Communication with the cable could not be established". I have tried with all settings of Parallel Port (lpt 1). >On the other computer everything is OK (There is older version of Foundation). On both PC is Windows 98 SE so I think the Parallel Cable is OK. > >If someone knows what's wrong just write to me. > >Tomasz Falser Klaus R&D Electronics Department Company : Durst Phototechnik AG Vittorio Veneto Str. 59 I-39042 Brixen Voice : +0472/810235 : +0472/810111 FAX : +0472/830980 Email : kfalser@durst.itArticle: 28709
> a fractional counter were you can programme the denominator and numerator, Hope this helps. Please note the following: * the denominator is a power of two * this divider works on both clock edges so that fractionals > 0.5 are possible. Best regards Felix Bertram _____ Dipl.-Ing. Felix Bertram Trenz Electronic Duenner Kirchweg 77 D - 32257 Buende Tel.: +49 (0) 5223 41652 Fax.: +49 (0) 5223 48945 Mailto:felix.bertram@trenz-electronic.de http://www.trenz-electronic.de ------------------------------------------------------------------ -- History: Felix Bertram, 2001jan22, Created. ------------------------------------------------------------------ library IEEE; use IEEE.STD_LOGIC_1164.all; use IEEE.NUMERIC_STD.all; entity DDS is port( clk: in STD_LOGIC; -- clock input rst: in STD_LOGIC; -- async reset inc: in STD_LOGIC_VECTOR(14 downto 0); -- increment value clko: out STD_LOGIC -- clock output ); end DDS; ------------------------------------------------------------------ architecture bhv of DDS is signal inc_us: UNSIGNED(inc'range); signal cnt1, cnt2: UNSIGNED(inc'range); signal sum1, sum2: UNSIGNED(inc'range); signal t_rc, t_fc, t_fc2: STD_LOGIC; signal x_rc, x_fc: STD_LOGIC; begin inc_us<= UNSIGNED(inc); -- adders sum1<= cnt2 + inc_us; -- rising clock sum2<= cnt2 + SHIFT_LEFT(inc_us, 1); -- falling clock -- toggle conditions t_rc<= sum1(inc'high) xor cnt2(inc'high); --t_fc<= cnt1(inc'high) xor cnt2(inc'high); t_fc2<= sum1(inc'high) xor sum2(inc'high); process(clk, rst) begin if rst= '1' then t_fc<= '0'; elsif rising_edge(clk) then t_fc<= t_fc2; end if; end process; -- counter registers process(clk, rst) begin if rst= '1' then cnt1<= (others=> '0'); cnt2<= (others=> '0'); elsif rising_edge(clk) then cnt1<= sum1; cnt2<= sum2; end if; end process; -- rising edge process process(clk, rst) begin if rst= '1' then x_rc <= '0'; elsif rising_edge(clk) then if t_rc= '1' then x_rc<= not(x_rc); end if; end if; end process; -- falling edge process process(clk, rst) begin if rst= '1' then x_fc <= '0'; elsif falling_edge(clk) then if t_fc= '1' then x_fc<= not(x_fc); end if; end if; end process; -- clock output clko<= x_rc xor x_fc; end bhv; ------------------------------------------------------------------ -- end of file Sent via Deja.com http://www.deja.com/Article: 28710
Hi, working with FPGA Compiler II. We instantiated some Synopsys DesignWare RAM cells in our design. Is there any way to tell FC2 to map these DW-RAMs to Virtex Block selectRAM? Looked over several AppNotes, but the only way to use them seems to be generating cells with Xilinx Core Generator, which are then instantiated in the HDL code. Not the best method if you want to stay technology independent... LarsArticle: 28711
Hello everybody, I am feeding a combinational signal into a Spartan-II DLL. As this combinational signal is some kind of a cheasy clock doubler created around an XOR gate, I have two different timing constraints for the XOR output, one of them being the original frequency, the other one being the doubled frequency. ngdbuild then traces both contraints through the CLKDLL, creating two new constraints for the CLKDLL output: INFO:Ngd - TNM "Ubufgdll/Uclk/U4x/CLK48", used in period specification "TS_CLK48", was traced into CLKDLL instance "Ubufgdll/Uclk/U4x/U8". The following new TNM groups and period specifications were generated at the CLKDLL output(s): TS_Ubufgdll_Uclk_U4x_II_CLK96=PERIOD Ubufgdll_Uclk_U4x_II_CLK96 100.000000 MHz HIGH 50.000000% Place&Route then choses the slower clock to constrain its pathes- which leads to wrong results. Question: How can I either prevent one of the original constraints from being traced through the CLKDLL or specify the timing at the CLKDLL output on my own? It seems that Xilinx' Constraints Editor does not offer to specify constraints for the CLKDLL output? Thank you very much for your time, best regards Felix Bertram Sent via Deja.com http://www.deja.com/Article: 28712
Peter Alfke wrote:
< snip >
> BTW the Virtex-II Handbook is on the web, all 536 pages of it:
>
> Go to www.xilinx.com
> click on the top big circle: Platform FPGA
> click on the top-right item under Related Features: The Virtex-II Handbook
>
> Enjoy !
OK, for us semi-old geezers, can we order the handbook in hardcopy?
I prefer reading technical material in hardcopy and 536 pages seems like
quite a bit for my little LaserJet.
----------------------------------------------------------------------
rk The key to developing engineering
stellar engineering, ltd. confidence is the rigorous identi-
stellare@erols.com.NOSPAM cation of the cause for ALL failures
Hi-Rel Digital Systems Design encountered for ALL phases of testing
... - Dr. Joseph F. Shea, Deputy
Director of Manned Space Flight, Spaceborne Computer Engineering
Conference, October, 1962.
Article: 28713> BTW the Virtex-II Handbook is on the web, all 536 pages of it: Is there any way to download ALL of it at once, instead of 30 individual downloads?Article: 28714
Austin Lesea wrote: > > Allan, > > There is a register before the last partial product accumulator that can be > used to make the multiplier synchonous, and aid in pipelining it and getting > much higher speed from it. > > Unfortunately, software does not support this feature initially. (I know, I > know...but we got almost everything else in and working so don't be too > unhappy). If this is a requirement initially, I am sure we can work > something out (e.g. a core or something). > > The idea behind the multiplieres is that they are parked next to the bram's > so FIR filters, FFT's, etc are easy to implement at incredible clock rates. ^^^^^^^^^^ Hmmm... Those multipliers coupled with the BRAM look like the *SLOWEST* part of the VirtexII architecture, especially if we don't have access to the multiplier's pipeline registers. I think we can already match the performance for FIRs and FFTs in the Virtex architecture, perhaps even in the slower speed grades, granted at a higher area cost and using techinques that may not be obvious to the software DSP guy. For example, Andraka Consulting is now offering a 16 point fft core for virtex which will run at clock/sample rates of better than 140 MS/s in the slow virtex-4 parts. Looks like that is already faster than you can make the multipliers in V2 go. Go to a VirtexE-8, and the speed advantage of not using the multipliers is substantial. > > This is all part of the Xtreme DSP initiative that is rolling in to town. > > With all of those 18X18 multipliers, BRAM's, and gates, these things blow > the doors of any DSP out there by a factor of about 80 times faster. > > Austin > > Allan Herriman wrote: > > > Hi Peter, > > > > Can you please let me know if there's an option to allow the multipliers > > to be clocked? The picture in the datasheet makes it look like the > > multiplier is a purely combinatorial function of the inputs. The timing > > information supports this. > > > > I am concerned that the relatively slow clock to output delay of the > > block rams coupled with the multiplier delay will limit the clock speed > > to about 100MHz in filter applications. > > > > Thanks, > > Allan. > > > > Peter Alfke wrote: > > > > > > Ray, this may be the rare case where your long ( and distinguished ! > > > ) experience misleads you. > > > In the 13 years I have been at Xilinx, I have never seen us as well > > > prepared for the introduction of a new family, as we are today with > > > Virtex-II. > > > We have had software since last October, silicon since late > > > November, and have been testing it furiously ever since. We finished > > > writing a 536-page Virtex-II Handbook in December, and shipped many > > > thousands of printed copies in early January. We have had extensive > > > training for our FAEs last fall, and we are putting together the > > > slides for a public seminar right now. > > > Highest on my list of exciting features is the Digitally Controlled > > > Impedance, which effectively puts the series termination resistor > > > right into the output driver, or the parallel termination right into > > > the input buffer ( all optionally of course). It will be a gods-end > > > for people putting >500-pin packages on a pc-board, not having to > > > bother with resistor packs... > > > Hundreds of 18 x 18 multipliers (<4ns) are nice, as are 16 global > > > clocks in all devices, each with an input mux that can glitch-free > > > select between two sources. Ripple carry delay is 45 ps per bit, a > > > 24-bit synchronous counter runs at 300 MHz, etc. > > > Exciting stuff. As I mentioned,earlier, I am working on a 1 GHz > > > frequency counter, on a 200 MHz asynchronous FIFO, and on > > > metastability testing. > > > > > > Sorry for the blatant propaganda. Got carried away by my enthusiasm. > > > > > > I had been impatiently waiting for the Ides of January, for a long > > > time ! > > > > > > Peter Alfke, Xilinx Applications > > > ===================================== > > > Ray Andraka wrote: > > > > > > > erika_uk@my-deja.com wrote: > > > > > > > > > > Hi, > > > > > > > > > > Does the tool handle it well ? > > > > > > > > Like any other new architecture, I suspect it will take a while > > > > for the tools to catch up to the new silicon. In the past, > > > > it has taken about a year after the introduction of the > > > > silicon before the tools were close to ready for prime time. > > > > Macro libraries lag even further behind. In the case of Virtex, > > > > I didn't start recommending them for customers until a little > > > > over a year ago...because of tools issues. > > > > > > > > > > > > > > --Erika > > > > > In article <979567585.218715@news2.cybercity.dk>, > > > > > "Rune Baeverrud" <fpga@no.spam.iname.com> wrote: > > > > > > Hello, > > > > > > > > > > > > Xilinx Virtex-II has now been officially announced. > > > > > > > > > > > > Check out the press release: > > > > > > http://www.xilinx.com/prs_rls/vtx2ship.htm > > > > > > > > > > > > and the Virtex-II Handbook: > > > > > > http://www.xilinx.com/products/virtex/handbook/index.htm > > > > > > > > > > > > Some highlights are: > > > > > > - digitally controlled impedances for input and output pins > > > > > > - new resources for clock management and clock synthesis > > > > > > - digital spread spectrum clocking > > > > > > - encrypted bitstreams > > > > > > - dedicated multipliers > > > > > > > > > > > > Go and see for yourself! > > > > > > > > > > > > Regards, > > > > > > Rune Baeverrud > > > > > > > > > > > > > > > > > > > > > > Sent via Deja.com > > > > > http://www.deja.com/ > > > > > > > > -- > > > > -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 or http://www.fpga-guru.com -- -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 or http://www.fpga-guru.comArticle: 28715
Ray, Good points. For those who can take the time to hand place and route and tweak, the fabric can be pipelined to take advantage of the speed. The area penalty is large, however, as you note. If you can do sustained 18 X 18 multiplies at 300 MHz with the multiplier/bram, how fast do you think you can make it go when you hand tweak it in LUT's? Austin Ray Andraka wrote: > Austin Lesea wrote: > > > > Allan, > > > > There is a register before the last partial product accumulator that can be > > used to make the multiplier synchonous, and aid in pipelining it and getting > > much higher speed from it. > > > > Unfortunately, software does not support this feature initially. (I know, I > > know...but we got almost everything else in and working so don't be too > > unhappy). If this is a requirement initially, I am sure we can work > > something out (e.g. a core or something). > > > > The idea behind the multiplieres is that they are parked next to the bram's > > so FIR filters, FFT's, etc are easy to implement at incredible clock rates. > ^^^^^^^^^^ > > Hmmm... Those multipliers coupled with the BRAM look like the *SLOWEST* part of > the > VirtexII architecture, especially if we don't have access to the multiplier's > pipeline > registers. I think we can already match the performance for FIRs and FFTs > in the Virtex architecture, perhaps even in the slower speed grades, granted at > a > higher area cost and using techinques that may not be obvious to the software > DSP guy. > For example, Andraka Consulting is now offering a 16 point fft core for virtex > which > will run at clock/sample rates of better than 140 MS/s in the slow virtex-4 > parts. Looks like > that is already faster than you can make the multipliers in V2 go. Go to a > VirtexE-8, and the > speed advantage of not using the multipliers is substantial. > > > > > This is all part of the Xtreme DSP initiative that is rolling in to town. > > > > With all of those 18X18 multipliers, BRAM's, and gates, these things blow > > the doors of any DSP out there by a factor of about 80 times faster. > > > > Austin > > > > Allan Herriman wrote: > > > > > Hi Peter, > > > > > > Can you please let me know if there's an option to allow the multipliers > > > to be clocked? The picture in the datasheet makes it look like the > > > multiplier is a purely combinatorial function of the inputs. The timing > > > information supports this. > > > > > > I am concerned that the relatively slow clock to output delay of the > > > block rams coupled with the multiplier delay will limit the clock speed > > > to about 100MHz in filter applications. > > > > > > Thanks, > > > Allan. > > > > > > Peter Alfke wrote: > > > > > > > > Ray, this may be the rare case where your long ( and distinguished ! > > > > ) experience misleads you. > > > > In the 13 years I have been at Xilinx, I have never seen us as well > > > > prepared for the introduction of a new family, as we are today with > > > > Virtex-II. > > > > We have had software since last October, silicon since late > > > > November, and have been testing it furiously ever since. We finished > > > > writing a 536-page Virtex-II Handbook in December, and shipped many > > > > thousands of printed copies in early January. We have had extensive > > > > training for our FAEs last fall, and we are putting together the > > > > slides for a public seminar right now. > > > > Highest on my list of exciting features is the Digitally Controlled > > > > Impedance, which effectively puts the series termination resistor > > > > right into the output driver, or the parallel termination right into > > > > the input buffer ( all optionally of course). It will be a gods-end > > > > for people putting >500-pin packages on a pc-board, not having to > > > > bother with resistor packs... > > > > Hundreds of 18 x 18 multipliers (<4ns) are nice, as are 16 global > > > > clocks in all devices, each with an input mux that can glitch-free > > > > select between two sources. Ripple carry delay is 45 ps per bit, a > > > > 24-bit synchronous counter runs at 300 MHz, etc. > > > > Exciting stuff. As I mentioned,earlier, I am working on a 1 GHz > > > > frequency counter, on a 200 MHz asynchronous FIFO, and on > > > > metastability testing. > > > > > > > > Sorry for the blatant propaganda. Got carried away by my enthusiasm. > > > > > > > > I had been impatiently waiting for the Ides of January, for a long > > > > time ! > > > > > > > > Peter Alfke, Xilinx Applications > > > > ===================================== > > > > Ray Andraka wrote: > > > > > > > > > erika_uk@my-deja.com wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > Does the tool handle it well ? > > > > > > > > > > Like any other new architecture, I suspect it will take a while > > > > > for the tools to catch up to the new silicon. In the past, > > > > > it has taken about a year after the introduction of the > > > > > silicon before the tools were close to ready for prime time. > > > > > Macro libraries lag even further behind. In the case of Virtex, > > > > > I didn't start recommending them for customers until a little > > > > > over a year ago...because of tools issues. > > > > > > > > > > > > > > > > > --Erika > > > > > > In article <979567585.218715@news2.cybercity.dk>, > > > > > > "Rune Baeverrud" <fpga@no.spam.iname.com> wrote: > > > > > > > Hello, > > > > > > > > > > > > > > Xilinx Virtex-II has now been officially announced. > > > > > > > > > > > > > > Check out the press release: > > > > > > > http://www.xilinx.com/prs_rls/vtx2ship.htm > > > > > > > > > > > > > > and the Virtex-II Handbook: > > > > > > > http://www.xilinx.com/products/virtex/handbook/index.htm > > > > > > > > > > > > > > Some highlights are: > > > > > > > - digitally controlled impedances for input and output pins > > > > > > > - new resources for clock management and clock synthesis > > > > > > > - digital spread spectrum clocking > > > > > > > - encrypted bitstreams > > > > > > > - dedicated multipliers > > > > > > > > > > > > > > Go and see for yourself! > > > > > > > > > > > > > > Regards, > > > > > > > Rune Baeverrud > > > > > > > > > > > > > > > > > > > > > > > > > > Sent via Deja.com > > > > > > http://www.deja.com/ > > > > > > > > > > -- > > > > > -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 or http://www.fpga-guru.com > > -- > -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 or http://www.fpga-guru.comArticle: 28716
The AT6000 has a tool which supports automatically changing constants. This is used to update filters. It is hard to reconfigure on the fly, and there are some = research/development going on with some customers. So far, info is only available under NDA. --=20 Best Regards Ulf at atmel dot com These comment are intended to be my own personal view and may or may not be shared by my Employer Atmel Sweden. <pawel5732@my-deja.com> skrev i meddelandet = news:949ph3$kbq$1@nnrp1.deja.com... : Hi, : What FPGAs do support a partial reconfiguration? : What FPGAs can be reconfigured "on-the-fly"? : Is this possible to use this feature with a tool? : Thank you, : Pawel :=20 :=20 : Sent via Deja.com : http://www.deja.com/Article: 28717
Jim Granville wrote:
> Slow edges can do strange things, as can data undershoot,
^^^^^^^^^^^^^^^
> but for a register to miss MORE than one cycle is
> strange in the extreme.
I am not familiar with the term 'data undershoot' (sorry):
Does that mean data lines going below GND or above Vcc?
With my oscilloscope probe (100MHz BW) no heavy 'ringing'
is visible and the chips are located close together without
long transmission lines between.
The edges rise and fall within at most 10 nanoseconds.
They come from other digital logic. Nevertheless, as they are
asynchroneous to the 'master.clk', a transition might occur
just while clocking.
> After all, when a NEW clock arrives, a new state-pair occur in
> the register follow/hold latch
That also was my idea. Well, I learned from ECL devices that when
ECL-FFs are clocked and the DATA is in transition, that the device
could be entering a metastable state (not knowing whether to go
to 1 or to 0). Then it might take a considerably long time for the
FF to recover from that - by orders longer than the normal setup
time. I wonder if that applies to CPLD, too.
Then: how to /safely/ synchronize signals?
> Can you run just this register, without the BUS or any other
> activity ?
It /looks/ so, as this might help. I tried that for test purpose
and switchted off all BUS activities and indeed I did *not* find
abnormal behaviour.
Unfortunatelly, during normal operation, the circuit cannot be used
without BUS activity. It is easy to detect the failure when the
whole circuit (including the BUS) is operating, but without that
I have to use extra oscilloscope probe circutery (storage scope,
large persinst time). As the failure occurs seldom, I am not
really sure if I just /miss/ one of the failures.
> Unused pins are ??
floating... (10 pins) But they are not in the neighbourhood of
clock, BUS oder the FF.
I have not enought macrocells left to drive them with any dummy
signal. Can they be driven to GND/Vcc by a special ABEL statement?
I would like them to be a reserve for future extentions.
Or do I really have to place 60 Pullups around the chip for prevent
the inputs from floating?
I learned recently from the Xilinx datasheet that each I/O block has
an internal Pull-Up which is activated during programming and idle
during normal operation. Can I activate this for normal operation?
BTW: should the JTAG-Pins be clamped to a special level?
(write-protect is set to 'on')
> (...) All Power pins connected ?
Yep! Did *really* double-check that ;-) From Schematic:
| GND: Pins 8,16,27,42,49,60
| 5V : Pins 38,73,78 (each blocked with 100nF to GND plane)
| 3V3: Pins 22,64 (each blocked with 100nF to GND plane)
Many thanks for your help;
Ralf.
--
Ralf A. .Eckhardt
a.eckhardt@t-online.de
Article: 28718Austin, fg256 is die facing up. there is no "cavity" per se. there is a cap over the die and bondwires to protect them. the fg256 is a 4-layer laminate package (little pcb) Austin Austin Franklin wrote: > It appears that the FG456 parts are cavity UP, but I want to make sure > before doing my pinouts... > > The floorplanner gives the low number, low letter in the upper left. The > FPGA Editor gives the low number, low letter in the upper left. The package > drawing shows low number, low letter in the upper left (top view of > package). That to me, means this is a cavity up part. > > The BG352 is a cavity down part...since the floorplanner gives the low > number low letter in the in the upper RIGHT . The FPGA Editor gives the low > number, low letter in the upper RIGHT. The package drawing shows the low > number, low letter in the upper left (top view of package). That, to me, > means this is a cavity DOWN part...since the die has to be flipped to line > up the die pins with the package pins. > > Both the FPGA Editor and the Floorplanner are both 'die' view, it would > appear. When doing floorplanning, at least for me, I would prefer the > Floorplanner be a TOP view (or give you the option of die view or top view), > so I can lay my chip out without having to flip everything over to really > see how it lines up with the outside world... > > I REALLY wish they had a chart that showed the orientation of the die in > each package...and I've mentioned this to them many a time. > > Any comments?Article: 28719
Theron Hicks wrote: > 1. I am a university student with access to Foundation 2.1. What > tools/downloads are available for me to look at the VirtexII parts? None, AFAIK. Only the latest 3.x SP seems to support Virtex-II. Even then you need an update CD with device files, I think (haven't received that one, yet). > 3. My actual goal is 819.2 MHz. Thus the VirtexII is a very good > technology. Is it going to be packaged such that small users (>50 > pieces) can utilize it in the smallest device size? This means can a > good solderer hand solder the package. No chance. Xilinx chose to drop the flat packs, so the small guys will have to face the task of mounting those terrible BGA's... - ReinoudArticle: 28720
--------------F9FD0CB52B9D4C6BC74ED24A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Austin, I will eventually get it right. The fg456 is also die up. Austin Austin Franklin wrote: > It appears that the FG456 parts are cavity UP, but I want to make sure > before doing my pinouts... > > The floorplanner gives the low number, low letter in the upper left. The > FPGA Editor gives the low number, low letter in the upper left. The package > drawing shows low number, low letter in the upper left (top view of > package). That to me, means this is a cavity up part. > > The BG352 is a cavity down part...since the floorplanner gives the low > number low letter in the in the upper RIGHT . The FPGA Editor gives the low > number, low letter in the upper RIGHT. The package drawing shows the low > number, low letter in the upper left (top view of package). That, to me, > means this is a cavity DOWN part...since the die has to be flipped to line > up the die pins with the package pins. > > Both the FPGA Editor and the Floorplanner are both 'die' view, it would > appear. When doing floorplanning, at least for me, I would prefer the > Floorplanner be a TOP view (or give you the option of die view or top view), > so I can lay my chip out without having to flip everything over to really > see how it lines up with the outside world... > > I REALLY wish they had a chart that showed the orientation of the die in > each package...and I've mentioned this to them many a time. > > Any comments? --------------F9FD0CB52B9D4C6BC74ED24A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Austin, <p>I will eventually get it right. <p>The <b>fg456</b> is also die up. <p>Austin <p>Austin Franklin wrote: <blockquote TYPE=CITE>It appears that the FG456 parts are cavity UP, but I want to make sure <br>before doing my pinouts... <p>The floorplanner gives the low number, low letter in the upper left. The <br>FPGA Editor gives the low number, low letter in the upper left. The package <br>drawing shows low number, low letter in the upper left (top view of <br>package). That to me, means this is a cavity up part. <p>The BG352 is a cavity down part...since the floorplanner gives the low <br>number low letter in the in the upper RIGHT . The FPGA Editor gives the low <br>number, low letter in the upper RIGHT. The package drawing shows the low <br>number, low letter in the upper left (top view of package). That, to me, <br>means this is a cavity DOWN part...since the die has to be flipped to line <br>up the die pins with the package pins. <p>Both the FPGA Editor and the Floorplanner are both 'die' view, it would <br>appear. When doing floorplanning, at least for me, I would prefer the <br>Floorplanner be a TOP view (or give you the option of die view or top view), <br>so I can lay my chip out without having to flip everything over to really <br>see how it lines up with the outside world... <p>I REALLY wish they had a chart that showed the orientation of the die in <br>each package...and I've mentioned this to them many a time. <p>Any comments?</blockquote> </html> --------------F9FD0CB52B9D4C6BC74ED24A--Article: 28721
Can I simulate a Verilog model of a RAMB4_S8_S8 element of Virtex-E in a VHDL testbench? Not succeeded in that yet. RAMB4_S8_S8 is in $XILINX/verilog/src/unisims and this Verilog code requires $XILINX/verilog/src/glbl.v to be compiled correctly. In typical Verilog testbench following must be done: glbl my_glbl (); In VHDL, its equivalent I can figure out would be: my_glbl : glbl; But when I choose "Design->Load Design..." and architecture of VHDL testbench, Modelsim tells me that it cannot resolve glbl in glbl.GSR assignment in RAMB4_S8_S8 element, although I had compiled it into work library. The reason why I have use Verilog models of Xilinx macros instantiated in VHDL testbench is that there are plenty of VHDL codes which call Xilinx macros. VHDL models can be used by using: LIBRARY UNISIM; USE UNISIM.all; ... which are not typed in original VHDL codes. But if I do it, then Synplify will be angry with that, because it will try to compile VHDL simulation models of Xilinx macros, which is nonsense. Is it possible to use LIBRARY and USE constructs with GENERATE?: IF SIMULATION=TRUE GENERATE LIBRARY UNISIM; USE UNISIM.all; END IF; UtkuArticle: 28722
A few questions about High speed counters in general and VirtexII in particular. 1. I am a university student with access to Foundation 2.1. What tools/downloads are available for me to look at the VirtexII parts? 2. I am considering a project that will be looking at high speed counters (16 bit equivalent resolution). (target frequency is anything better than I am getting right now. i.e. >200MHz) Does anyone have any recomendations as to material I ought to look at for references? 3. My actual goal is 819.2 MHz. Thus the VirtexII is a very good technology. Is it going to be packaged such that small users (>50 pieces) can utilize it in the smallest device size? This means can a good solderer hand solder the package. Thanks for your assistance. Theron HicksArticle: 28723
peter.alfke@xilinx.com wrote: > Rick Collins wrote: > > Anyone know of the > > expected availability and price of a low end VirtexII? > I will check prices and availability, obviously I personally encounter no > problem in that regard :-) Hmm. Low end parts. I was just told, by insight/memec germany, that XC2S30 and XC2S15 are scheduled to be available December 2001. So, a XC2V40 will be available earlier than that? At a similar price? (less than $10) Also, what happend to master parallel mode? I would like to get rid of the CPLD to read my FlashROM. It's a little anyoing to almost double the FPGA price due to the configuration ROM circuitry. Kolja Sulimma Sent via Deja.com http://www.deja.com/Article: 28724
> The three North American distributors have fairly good stock. They > have online stock and prices. At least some of them refuse to ship overseas. But remeber, that from the UK you can order anywhere within the european union. (You remeber the 200 M Euro fine to volkswagen for not selling there cars to foreign customers?) Insight/Memec germany seems to have xc9536xl in stock. (also XC2S200) Last time i had trouble, insight norway was very helpful in resolving problems with insight in the UK. CU, Kolja Sent via Deja.com http://www.deja.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