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
there is (almost) no standard for IP core generators (SPIRIT is only used by Actel so far) in ISE 5.1 it was possible to add custom IP cores to coregen but in later version this functionality is no longer available :( AnttiArticle: 103301
Both Xilinx and Altera make the assumption that their tools are being run on a ridiculously obsolete versions of Linux. The Quartus tools test to see if they are running on Redhat 8, if not they set the LD_ASSUME_KERNEL to 2.4. At one point the Xilinx tools had a requirement that you set the LD_ASSUME_KERNEL to 2.4.7. This didn't cause any problems in earlier version of Fedora Core but it does in FC5. If you set the LD_ASSUME_KERNEL to 2.4 it breaks everything, see below setenv LD_ASSUME_KERNEL 2.4 ls ls: error while loading shared libraries: librt.so.1: wrong ELF class: ELFCLASS32 The good news is that it appears that it's no longer necessary to set the LD_ASSUME_KERNEL for either tool. Both ISE 8.1sp3 and Quartus 6.0 seem to work without it. Xilinx assumed that the user was setting the LD_ASSUME_KERNEL variable so those of you who use scripts or set it in their .cshrc should remove it. Altera put it in one of their own scripts, $QUARTUS/adb/qenv.csh. In order to run Quartus on FC5 you should comment out the line, if ( "$REDHAT_VERSION" != "8" ) then # setenv LD_ASSUME_KERNEL 2.4 endifArticle: 103302
billu wrote: > Hi All, > > I have the following issues while trying to test a sample Aurora core. > I generated a core w/ the following specs: > HDL: Verilog, Lane: 1, Lane Width: 2, Interface: Streaming, Upper MGT > Clock: BREF_CLK, Upper MGT clock on GT_X0Y1 (from ucf file, corresponds > to MGT4 for a ML321 board) > > After using xilperl to compile the design files, I simulated it using > Modelsim, and uploaded the bit file using Impact to the board. > > I'm trying to test the core by feeding a 3.125Gbps (default data rate > based on onboard oscillator) PRBS signal onto MGT4(RXP & RXN). I test > the output signal from MGT4(TXP & TXN) by connecting it(TX ports)to a > oscilloscope and/or spectrum analyzer. Ideally, you would expect the > protocol to simply transmit that data that it received at the RX ports, > but the protocol fails to do that. I get an extremely weak signal on > the spectrum analyzer and bad eye on the scope. I also tried feeding in > a clock signal of 50MHz into BREF_CLK and testing the setup w/ 1Gbps > PRBS signal, but that didnt work either. > > Can you tell me where I might be going wrong? > > Thanks, > Billu > For starters the Aurora core implements the Aurora Protocol so feeding the receiver a raw PRBS pattern is seen as garbage as it doesn't match the protocol. You didn't mention what other logic you wrapped around the core to source and sink the Local Link TX/RX interfaces. If you left these unconnected in your design, then it's likely that almost everything has been trimmed. However you are getting something out of the TX pair so the bitstream is doing something (probably constantly sending the initialization portion of the protocol since it never gets a receiver lock). Since you are getting a bad eye on the scope I would suggest checking your scopes termination setting and set them to 50 ohm with AC coupling. You are using the ML321 and these boards are shipped with pre-compiled BERT designs on the SystemACE CompactFlash card. Have you tried just using these designs for your initial testing? Ed McGettigan -- Xilinx Inc.Article: 103303
> > Altera put it in one of their own scripts, $QUARTUS/adb/qenv.csh. In > order to run Quartus on FC5 you should comment out the line, > > if ( "$REDHAT_VERSION" != "8" ) then > # setenv LD_ASSUME_KERNEL 2.4 > endif I spoke to soon about Quartus, it doesn't work without the LD_ASSUME_KERNEL 2.4 variable. The Xilinx tools seem to run fine.Article: 103304
the bitstream contains some parameters that are optimized for given VCCIO standard. the actual VCCIO is supplied externally so settng iostandard to 1.8V and VCCIO to 3.3 will output 3.3V levels. This will not burn the FPGA but some parameters will not be optimal, etc..Article: 103305
On 2006-05-30, Antti <Antti.Lukats@xilant.com> wrote: > a <= b or c; > > the above as example is an IP core, in the matter of fact I have sold > such a IP core ! I might owe you some royalties. In the future I will use a <= ~(~b and ~c); -- Ben Jackson <ben@ben.com> http://www.ben.com/Article: 103306
On 2006-05-30, m_oylulan@hotmail.com <m_oylulan@hotmail.com> wrote: > Hello, > I am trying to program an RC-100 demo board, which contains a > Spartan-II chip. The board is supposed to send three logic outputs to > external devices through I/O pins provided on an expansion header. Did you actually set constraints to put the outputs of your top level module on the specific IO pins you want? -- Ben Jackson <ben@ben.com> http://www.ben.com/Article: 103307
Hi Austin, I have some questions about the static power in Virtex 5. You said that the gate leakage is same for V4 and V5. Could you tell me how is the sub-threshold leakage in Virtex 5? I have read that subthreshold leakage will increase at 65nm (distance between source and drain of transistor will decrease in 65nm). Also, Virtex 5 has lower effective voltage than Virtex 4 (1.2 V in V4 to 1.0 V in V5). This should increase the sub-threshold leakage (Vth would be more significant). Moreover, if we take same sized Virtex 4 and Virtex 5 (which I assume to mean as same number of CLBs), then number of gates in Virtex 5 would be higher than Virtex 4, which means more leakage. I am trying to find out how the static power could be saved in going from 90nm to 65nm. Did Xilinx do something new to prevent sub-threshold leakage? Thanks, Love SinghalArticle: 103308
hi, what is the difference for designing a PCI card for a desktop motherboard and with a Single Board Computer(SBC)? should a PCI card designed for Desktop PC work on SBC's? -k-Article: 103309
Love Singhai, What we are seeing is that the choice of using triple oxide at 65nm is again, a requirement. To have 65nm low Vt (very leaky source drain, leaky gate), 65nm high Vt (less leaky source drain, just as leaky gate); medium oxide 90nm low Vt (less leaky source drain, very little leakage gate), medium oxide high Vt (even less leaky source-drain, very little gate leakage -- these are used for all config memory, and all pass-gates); and finally both low and high Vt thick oxide for IO (no leakage at all to speak of) provides the IC designer with the best choices where they are needed. So, because we must use the low Vt 65nm and high Vt 65nm transistors for speed to achieve objectives, we end up with more static leakage for V5 than we would for V4. By "more" I mean that for the same number of CLBs, we still are seeing less, but with 65nm, we are doubling the logic per square area, so the same area chip now sees a similar static current, which now varies much less over temperature as the gate leakage has no temperature dependency. As an example, if a V4 chip is taken down to -40C (I grade, of course), it has practically no leakage at all! But, take a V5 of the same area, and take it down to -40C, and the leakage is roughly the same as when it was at room temperature. At hot, it is more, but on par with a V4 when it was hot. V4 was at 1.2V, V5 is at 1.0 volts (core), so the lower voltage on the core does help keep the leakage under control. So, in summary, what Xilinx did was specify a triple oxide process to two foundries that allows designers to use the right transistor for the right job. The result is the worlds first 65nm FPGA which still provides for an overall static savings in power for function, and keeps on par with static power per area. Dynamic power is 1.2 squared vs. 1.0 squared for voltage alone (3-0% less dynamic power) PLUS the use of low K for another ~ 5% less power (smaller C). The final dynamic power savings will be characterized and released with the new power estimation tools, as not all features have lo-K (for example, clock lines are near the top metal layers, which are not low-K). I hope that answers your questions, Austin Love Singhal wrote: > Hi Austin, > I have some questions about the static power in Virtex 5. You said that > the gate leakage is same for V4 and V5. Could you tell me how is the > sub-threshold leakage in Virtex 5? I have read that subthreshold > leakage will increase at 65nm (distance between source and drain of > transistor will decrease in 65nm). Also, Virtex 5 has lower effective > voltage than Virtex 4 (1.2 V in V4 to 1.0 V in V5). This should > increase the sub-threshold leakage (Vth would be more significant). > Moreover, if we take same sized Virtex 4 and Virtex 5 (which I assume > to mean as same number of CLBs), then number of gates in Virtex 5 > would be higher than Virtex 4, which means more leakage. > > I am trying to find out how the static power could be saved in going > from 90nm to 65nm. Did Xilinx do something new to prevent sub-threshold > leakage? > Thanks, > Love Singhal >Article: 103310
30% less dynamic power from voltage, excuse the typo... Austin Austin Lesea wrote: > Love Singhai, > > What we are seeing is that the choice of using triple oxide at 65nm is > again, a requirement. > > To have 65nm low Vt (very leaky source drain, leaky gate), 65nm high Vt > (less leaky source drain, just as leaky gate); medium oxide 90nm low Vt > (less leaky source drain, very little leakage gate), medium oxide high > Vt (even less leaky source-drain, very little gate leakage -- these are > used for all config memory, and all pass-gates); and finally both low > and high Vt thick oxide for IO (no leakage at all to speak of) provides > the IC designer with the best choices where they are needed. > > So, because we must use the low Vt 65nm and high Vt 65nm transistors for > speed to achieve objectives, we end up with more static leakage for V5 > than we would for V4. > > By "more" I mean that for the same number of CLBs, we still are seeing > less, but with 65nm, we are doubling the logic per square area, so the > same area chip now sees a similar static current, which now varies much > less over temperature as the gate leakage has no temperature dependency. > > As an example, if a V4 chip is taken down to -40C (I grade, of course), > it has practically no leakage at all! > > But, take a V5 of the same area, and take it down to -40C, and the > leakage is roughly the same as when it was at room temperature. At hot, > it is more, but on par with a V4 when it was hot. > > V4 was at 1.2V, V5 is at 1.0 volts (core), so the lower voltage on the > core does help keep the leakage under control. > > So, in summary, what Xilinx did was specify a triple oxide process to > two foundries that allows designers to use the right transistor for the > right job. The result is the worlds first 65nm FPGA which still > provides for an overall static savings in power for function, and keeps > on par with static power per area. > > Dynamic power is 1.2 squared vs. 1.0 squared for voltage alone (3-0% > less dynamic power) PLUS the use of low K for another ~ 5% less power > (smaller C). The final dynamic power savings will be characterized and > released with the new power estimation tools, as not all features have > lo-K (for example, clock lines are near the top metal layers, which are > not low-K). > > I hope that answers your questions, > > Austin > > Love Singhal wrote: >> Hi Austin, >> I have some questions about the static power in Virtex 5. You said that >> the gate leakage is same for V4 and V5. Could you tell me how is the >> sub-threshold leakage in Virtex 5? I have read that subthreshold >> leakage will increase at 65nm (distance between source and drain of >> transistor will decrease in 65nm). Also, Virtex 5 has lower effective >> voltage than Virtex 4 (1.2 V in V4 to 1.0 V in V5). This should >> increase the sub-threshold leakage (Vth would be more significant). >> Moreover, if we take same sized Virtex 4 and Virtex 5 (which I assume >> to mean as same number of CLBs), then number of gates in Virtex 5 >> would be higher than Virtex 4, which means more leakage. >> >> I am trying to find out how the static power could be saved in going >> from 90nm to 65nm. Did Xilinx do something new to prevent sub-threshold >> leakage? >> Thanks, >> Love Singhal >>Article: 103311
We had the top pop off of a VirtexII-Pro 2vp70 (1704BGA) and need to reattach it. The board and FPGA work fine. For some reason, Xilinx is refusing to tell us how to reattach the top correctly. Help please. What is the proper type of glue and the procedure?Article: 103312
I have a piece of IP that acts as a slave on the PLB. I would like writes to this IP to be 64bits, while reads from it are OK at 32bits. The sample driver that was generated by the IP wizard gives functions for reads/writes or 32 bits as expected (by mapping them to XIo_In/Out32). Do I need to do writes in two transfers? If not, how do I write 64bits? I've looked over the PPC 405 Block Reference Guide and it seems that it should be possible to read/write 64 bits all at once just by virtue of having that wide of a bus coming in and out of the block. The cacheline transfers are discussed in that document as possibly being doublewords. I am a bit confused by all of this (if that wasn't clear already). I would probably be able to find my answer after a good deal of time/pain, but hopefully someone out there can clarify things a little for me. Just knowing if it was possible or not for a user program to do the 64bit write would help me move forward. I'd appreciate any clarification and/or pointers to relevant documentation. I can provide more info about my design or my confusion if it is useful. Thanks in advance, JoeyArticle: 103313
Josh Rosen <bjrosen@polybuspleasedontspamme.com> wrote: >Both Xilinx and Altera make the assumption that their tools are being run >on a ridiculously obsolete versions of Linux. The Quartus tools test to >see if they are running on Redhat 8, if not they set the LD_ASSUME_KERNEL >to 2.4. At one point the Xilinx tools had a requirement that you set the >LD_ASSUME_KERNEL to 2.4.7. This didn't cause any problems in earlier >version of Fedora Core but it does in FC5. If you set the LD_ASSUME_KERNEL >to 2.4 it breaks everything, see below The Xilinx tools works fine in respect to this with Linux ELF-32 translated api under FreeBSD 6.x/i386. Infact the older software makes bugs to have been ironed out in this particular case. What works bad is tool integration and driver for hardware. .bit files have to be downloaded by a seperatly written tool. Installation precedure is horrible.Article: 103314
My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the best precision possible. Without considering clipping and range issues, I am using multiplication by 59/16, which gives 0.599% error. What better approach can I use? I am going to implement the calculation in ASIC, thus less complexity is what I am expecting.Article: 103315
Austin Lesea wrote: > Love Singhai, > > What we are seeing is that the choice of using triple oxide at 65nm is > again, a requirement. > > To have 65nm low Vt (very leaky source drain, leaky gate), 65nm high Vt > (less leaky source drain, just as leaky gate); medium oxide 90nm low Vt > (less leaky source drain, very little leakage gate), medium oxide high > Vt (even less leaky source-drain, very little gate leakage -- these are > used for all config memory, and all pass-gates); and finally both low > and high Vt thick oxide for IO (no leakage at all to speak of) provides > the IC designer with the best choices where they are needed. > > So, because we must use the low Vt 65nm and high Vt 65nm transistors for > speed to achieve objectives, we end up with more static leakage for V5 > than we would for V4. > > By "more" I mean that for the same number of CLBs, we still are seeing > less, but with 65nm, we are doubling the logic per square area, so the > same area chip now sees a similar static current, which now varies much > less over temperature as the gate leakage has no temperature dependency. > > As an example, if a V4 chip is taken down to -40C (I grade, of course), > it has practically no leakage at all! > > But, take a V5 of the same area, and take it down to -40C, and the > leakage is roughly the same as when it was at room temperature. At hot, > it is more, but on par with a V4 when it was hot. > > V4 was at 1.2V, V5 is at 1.0 volts (core), so the lower voltage on the > core does help keep the leakage under control. > > So, in summary, what Xilinx did was specify a triple oxide process to > two foundries that allows designers to use the right transistor for the > right job. The result is the worlds first 65nm FPGA which still > provides for an overall static savings in power for function, and keeps > on par with static power per area. > > Dynamic power is 1.2 squared vs. 1.0 squared for voltage alone (3-0% > less dynamic power) PLUS the use of low K for another ~ 5% less power > (smaller C). The final dynamic power savings will be characterized and > released with the new power estimation tools, as not all features have > lo-K (for example, clock lines are near the top metal layers, which are > not low-K). > > I hope that answers your questions, Some real/actual numbers could be a good idea, as all the info released so far seems to skirt this issue very deliberately.... -jgArticle: 103316
I assume your scaling factor is a constant, and your data is variable. Now we need to know the available time for one conversion and also the data rate (which can be significantly higher in a pipelined scheme). In the digital realm, anything and everything is possible, if there is enough time... Peter Alfke, Xilinx ========================= Mr. Ken wrote: > My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the > best precision possible. Without considering clipping and range issues, I > am using multiplication by 59/16, which gives 0.599% error. What better > approach can I use? > > I am going to implement the calculation in ASIC, thus less complexity is > what I am expecting.Article: 103317
Mike, That is because there is no known way to re-attach it. If it fell off because we did something wrong (quality, assembly fault, etc.), request to RMA the part, and we will replace it under warranty. If you removed the top, then you have violated any warranty, and you need to get another one. Sorry, but that is the simple truth. "All the King's horses, and all the King's men, couldn't put Humpty Dumpty together again..." The lid is a heatsink, and detaching it may have (usually does) damaged the die, and certainly can not be replaced such that Xilinx is able to stand behind it. We don't do it ourselves. We don't ask anyone else to. I hope you can appreciate this, Austin mike_la_jolla wrote: > We had the top pop off of a VirtexII-Pro 2vp70 (1704BGA) and need to > reattach it. The board and FPGA work fine. For some reason, Xilinx is > refusing to tell us how to reattach the top correctly. Help please. > What is the proper type of glue and the procedure? >Article: 103318
Mr. Ken wrote: > My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the > best precision possible. Without considering clipping and range issues, I > am using multiplication by 59/16, which gives 0.599% error. What better > approach can I use? > > I am going to implement the calculation in ASIC, thus less complexity is > what I am expecting. Use more bits. If you were looking at simple shift for the division you're on the right track but you need more digits such as 3799/10241. If ASICs have dedicated multipliers as a simple element, you probably have what you need with a multiplier. If you have loads of time, a bit-serial approach can give you tiny. If you want abstruse, you can do a 115/31 where the divide by 31 is a bunch of 5-bit adds and a few conditionals around the digit 31 (and a bit of latency). Where do you want to go?Article: 103319
Article: 103320
"mike_la_jolla" <mdini@dinigroup.com> wrote in message news:1149030402.633190.15550@u72g2000cwu.googlegroups.com... > We had the top pop off of a VirtexII-Pro 2vp70 (1704BGA) and need to > reattach it. The board and FPGA work fine. For some reason, Xilinx is > refusing to tell us how to reattach the top correctly. Help please. > What is the proper type of glue and the procedure? > Mike, It's really no big deal. Apply a dab of silicon grease (or equivalent) to the top of the die, but be very careful as this chunk of silicon cracks very easily. Apply some epoxy (or similar -- like E6000) along the top edge of the plastic case (that surrounds the little pcb and die). Now, just replace the little metal lid (the heat spreader) that popped off. BobArticle: 103321
Well, within a same clock cycle. I am unable to have pipelining at the moment. Anyway, pipelined divider will become an option in later stage of my assignment. "Peter Alfke" <alfke@sbcglobal.net> wrote in message news:1149040816.140172.179410@i39g2000cwa.googlegroups.com... > I assume your scaling factor is a constant, and your data is variable. > Now we need to know the available time for one conversion and also the > data rate (which can be significantly higher in a pipelined scheme). > In the digital realm, anything and everything is possible, if there is > enough time... > Peter Alfke, Xilinx > ========================= > Mr. Ken wrote: > > My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the > > best precision possible. Without considering clipping and range issues, I > > am using multiplication by 59/16, which gives 0.599% error. What better > > approach can I use? > > > > I am going to implement the calculation in ASIC, thus less complexity is > > what I am expecting. >Article: 103322
"John_H" <johnhandwork@mail.com> wrote in message news:Ae8fg.9896$ho6.9329@trnddc07... > Mr. Ken wrote: > > My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the > > best precision possible. Without considering clipping and range issues, I > > am using multiplication by 59/16, which gives 0.599% error. What better > > approach can I use? > > > > I am going to implement the calculation in ASIC, thus less complexity is > > what I am expecting. > > Use more bits. If you were looking at simple shift for the division > you're on the right track but you need more digits such as 3799/10241. > > If ASICs have dedicated multipliers as a simple element, you probably > have what you need with a multiplier. > > If you have loads of time, a bit-serial approach can give you tiny. > > If you want abstruse, you can do a 115/31 where the divide by 31 is a > bunch of 5-bit adds and a few conditionals around the digit 31 (and a > bit of latency). > > Where do you want to go? Thank you John_H. the 115/31 idea is interesting. I will make one and see how much resource it consumes. If resource consumption is fine, it will be greatly increase the precision of my design!Article: 103323
John_H wrote: > Mr. Ken wrote: > >>My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the >>best precision possible. Without considering clipping and range issues, I >>am using multiplication by 59/16, which gives 0.599% error. What better >>approach can I use? >> >>I am going to implement the calculation in ASIC, thus less complexity is >>what I am expecting. > > > Use more bits. If you were looking at simple shift for the division > you're on the right track but you need more digits such as 3799/10241. Wow, somehow this spawned ~100 posts, in 2 minutes.... Yes, but if the data starts life as 9 bits, then that's one part in 512, or 0.2% (2 e-3), so superb precison is not needed ? I make 475/128 a deviation of 3.33e-4, from the humber above, and so appx 1/7 the data quantize error ? -jgArticle: 103324
On Wed, 31 May 2006 09:04:57 +0800, "Mr. Ken" <Mr. Ken@asdf> wrote: >My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the >best precision possible. Without considering clipping and range issues, I >am using multiplication by 59/16, which gives 0.599% error. What better >approach can I use? > >I am going to implement the calculation in ASIC, thus less complexity is >what I am expecting. > 5316/1433 Error=0.0001133%
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