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
Francesco, Thank you. The level of activity on this board is a good indicator of the number of engineers that are designing with our chips at any given time. This group is also invaluable for us to get feedback on how well we are treating our customers. I would prefer that feedback be directed to our hotline; but, for those who are not getting the service they feel they deserve, I have also encouraged people to contact me (or Peter) directly. Many people read this board like a stockbroker reads the morning news: it is where folks go to see "what's happening." Austin francesco_poderico@yahoo.com wrote: > Austin, > seems that Xilinx is always one step in advance! > I'm impressed to see how many people in this newsgroup uses Xilinx. > well done, > Francesco > > > Austin Lesea wrote: > >>All, >> >>http://tinyurl.com/clzqh >> >>Details the latest readouts for actual single event upsets for Virtex 4, >>and Spartan 3. >> >>The improvements (6 times fewer upsets for Virtex 4, and 2.4 times fewer >>upsets for Spartan 3 as compared to Virtex II) shows our commitment to >>making this a non-issue for our customers. >> >>Make sure you demand from you ASIC/ASSP/FPGA vendor reports on their SEU >>susceptibility! This is not an area where you should take this for >>granted. Reducing SEU susceptibility is not something the foundry >>builds in to their process; it is something that takes time and effort >>on the part of IC designers to implement, and more time and effort to >>verify. >> >>For a vendor to claim "oh, we do what Xilinx does..." is completely >>insufficient. We certainly are not telling anyone how we did this (6X >>improvement): just that we have done this. >> >>The only other company that we are aware of with a "Rosetta"-like >>program (work with foundry on process; design, simulation, and analysis >>by IC designers; measurements in neutron and proton beams; actual >>atmospheric testing in multiple locations at multiple altitudes) is Cypress. >> >>Imitation is the sincerest form of flattery. >> >>Additionally, Cypress has a good book on the effects of cosmic ray >>neutrons and protons on memories. >> >>http://tinyurl.com/72mvw >> >>For more details, contact your FAE. They have materials accessible to >>them for customer presentations on this issue. >> >>Austin > >Article: 90651
Sorry just read through that and realised I didn't do a very good job on the flow: 1) Enter the design in LSI RapidWorx 2) Check the design in TeraSystems Teraform 3) Synthesize the design in Synplicity Amplify 4) Check STA in Synopsis primetime 5) Hand off netlist to LSI or 3rd party. John (john.burton@octera.com)Article: 90652
Try using the -u param on ngdbuild. It should at least make it to the mapper at that point. Do you have a file named fpmulIE24mw_8ew.ngc (or .edf or .edn or .ngo)? Can you determine what type of block it is by digging into the code? It should match something here if it is a built-in block: http://toolbox.xilinx.com/docsan/xilinx6/books/data/docs/lib/lib0024_10.html Otherwise, there should be code for it in one of the files Xilinx gave you for the multiplier. It's possible you did not get all the necessary files from Xilinx.Article: 90653
Wow. Good thing I looked at the rest of the thread before posting. I thought you were talking about adders using the carry chain (also known as ADC). Anyway....Article: 90654
Today I had a talk with the representant of Xilinx in russia. He adviced me to use Parallel cable 4 and not USB cable butwhen I asked why he told me that US Xilinx guys told him so. Can some one explain me? I need concrete examples. Perhaps he is only interested to sell ... one day he'll sell parallel cable ... and than I'll discover that I need the USB and come back to him to buy it :))Article: 90655
Hi, I thought about that too. Is that a common practice or bad coding with evil side-effects? regards, BenjaminArticle: 90656
Hi Benjamin, I've included comments. "Benjamin Menküc" <benjamin@menkuec.de> wrote in message news:dj30ji$58q$03$1@news.t-online.com... > Hello, > > Okay, I want to latch all my data that goes to the lcd (via the external > lvds serializer). Or should I use a FF? So, use FFs and clock them all with the rising edge of your 66MHz masterclock. This clock should be driven by a BUFG. > I need something that takes the data on rising edge and has it available > on the output on the next rising edge with enough sample and hold time. > > Is it possible to do that with the IOB or do I have to build a latch in > VHDL? > Just write it as normal VHDL, but make sure your synthesis tool packs the FFs into the IOBs. This ensures you have very little timing skew between your outputs as each FF is clocked by the low skew masterclock. If the data came from CLB FFs you are at risk of the vagaries of the P&R software; each individual data signal could have a different delay before emerging from the device. Now you also need to pass a clock to your serialiser, as well as the data. The data's easy, as we said, and comes from the output FF in each data IOB. The clock is also sourced from the IOB FFs, but this time we use the DDR registers. Look at figure 11. of XAPP622. This ensures minimal skew between the clock output and the data output. If you just wire the clock straight out, you have to contend with routing delays. You may have to instantiate this DDR primitive in your code, although I vaguely recall that Synplify can infer this operation. > > Sorry for my basic questions :=) > Sorry for my basic answers!! Hopefully they give you enough info to try searching the Xilinx site for more detailed stuff. > > PS: In theory my rising and falling edge thing should work, why is it so > bad? Is it not possible to set a timing contraint so that a process that > is triggered by rising edge has every output available on falling edge? > The problem is the delays from the masterclock to the outside world signals are variable due to the routing, unless you can use something like I describe above. > > regards, > Benjamin HTH, Syms.Article: 90657
jerryzy@gmail.com wrote: > Hi, > I am a FPGA newbie. Here's my question: > How do you count the gates in Xilinx FPGA? I have a XC3S400 board, > which is supposed to have 400K gates. But when I synthesize the > following code, the synthesizer report 68 LUTs were used, compared to > total of 7168 LUTs, I would say that about 1% of the 400K gates, which > is about 4000 gates, were used to synthesize my code. How ever, my > following code only uses 150 "AND" gates and 142 "XOR" gates, why does > it take XC3S400 take 4000 "gates" to handle my code? > Is there any setting trick need to be done in the synthesizer or in > the code? > At the risk of being embroiled in the great comp.arch.fpga FPGA gates debate, I will attempt to answer this. Your are mixing up some terms here and there in your analysis. First of all a gate is considered a 2-input basic function block (AND, OR) and for instance a D Flip/Flop register with a clock enable and reset function would require multiple (6-8) gates to be implemented. A two input XOR requires 2 inverters, 2 AND gates and 1 OR gate to be implemented or 4-5 gates depending on how you count the inverters (0.5 or 1 gate each). The FPGA gate counts include not only the logic that can be built in the LUTs, but also the registers, the carry logic, the CLB muxes, the BlockRAMs, the clock DCMs, the IOB registers, DSP logic (not in the XC3S400). At the most basic level we count a "Logic Cell" as 12 gates where a logic cell is a LUT and register combination. So simply taking the 1% LUT utilization and multiplying it by the gate count for the device is not accurate as you are missing a wide number of other functions in the device are included in the total that are 0% in utilized in your design. Your HDL code was comprised of 8 similar functions of 16-19 2-input ANDs and 16-19 input XOR functions. The 2-input ANDs are straight forward and would amount to 32-38 gates per function. The XOR functions however have to be cascaded as 2-input XOR tree generating 15-17 2-input XORS or 60-85 gates each. In total you have 8 * (32 to 38) + 8 * (60 to 85) or 736-984 gates in total. You synthesized the design to 68 LUTs which if we used the 12 gates/LC would equal 816 gates. But you aren't using registers should this should be discounted by 6-8 gates. I'll pick the lower 6 to get just 6 gates per LUT or 408 FPGA gates for your design. In Summary: Hand Calculated Gates: 736-984 FPGA LUTs : 68 FPGA LUTs as gates : 408 You are getting a really efficient FPGA design in this case as a single LUT can implement a 4-input XOR directly which would take 15 gates to implement in an ASIC using 3 2-input XORs in a tree. EdArticle: 90658
Let me explain. Suppose you have written enough data to fill the FIFO completely (248 words in your case) You will not yet see the FULL flag go active immediately, but rather see it go active one write clock tick later. If (and only if) you use this clock to write more data into the FIFO, you will "write into mid-air", the FIFO will never receive this entry. So this problem only occurs when you write on the two consecutive clocks. Applications work-around: Run the write clock at twice the write rate, and WE only on every other clock tick. Or, as I wrote before, use ALMOST FULL as a wite inhibitor. FULL then goes inactive a few write clock ticks after something has been read out of the FIFO ( just like on the read side). Also remember: The flag manipulation uses every one of its clock ticks (read for EMPTY, write for FULL), whether enabled or not. That improves the flag response time. And the clocks can be up to 500 MHz. I hope this makes it clear. Peter Alfke, Xilinx ApplicationsArticle: 90659
If you are looking for a basic tutorial on creating an OPB peripheral look at "Designing a Custom Processor Peripheral Using Xilinx EDK" by Richard Griffin on the Xilinx website under TechXclusives. After that you could use the "Create - Import Peripheral wizard" tool included with Xilinx EDK to easily create your custom peripherals. It also has documentation on OPB/PLB IPIF specs. KunalArticle: 90660
The USB cable is a recent product and may not be a 100% happy experience. I purchased one a couple weeks ago and found a few things. 1) I think it properly works at USB2.0 hi-speed but Windows XP reports the device is a high-speed device plugged into a full-speed port and that the device can go faster. I spent too much time trying to get the speed out of the device when it is probably already up to speed. 2) Because it's new, Synplicity's Identify tool doesn't have the driver for this "proprietary interface." Maybe in the next software rev (or two) but not now. From what I've seen physically, I think the interface to the electronics are the same for the two cables. Both have the ability to work with low I/O voltages at the device side so, for instance, a 1.8V JTAG chain could be accessed with either cable. Both are powered from the PC, the USB cable via the USB power and the Parallel-IV cable through a keyboard power jumper. My board-powered Paralell-III didn't work so well with a 2.5V powered JTAG chain. If you have reliable USB2, can ignore the Windows warning messages, don't need to work with non-Xilinx tools, and the cable is available, go for the USB. - John_H "GaLaKtIkUsT" <taileb.mehdi@gmail.com> wrote in message news:1129649777.329624.51660@g43g2000cwa.googlegroups.com... > Today I had a talk with the representant of Xilinx in russia. > He adviced me to use Parallel cable 4 and not USB cable butwhen I asked > why he told me that US Xilinx guys told him so. > Can some one explain me? I need concrete examples. > Perhaps he is only interested to sell ... one day he'll sell parallel > cable ... and than I'll discover that I need the USB and come back to > him to buy it :))Article: 90661
Thanks for the push in the right direction -- there is a file "fpmul24mw_8ew.ngc" somewhere in the Coregen directory hierarchy, but the "IE" is missing. Hm, strange problem, I have to examine the installation -- perhaps something went wrong when updating. Best, Simon "Brannon" <brannonking@yahoo.com> wrote in message news:1129649568.948234.12370@o13g2000cwo.googlegroups.com... > Try using the -u param on ngdbuild. It should at least make it to the > mapper at that point. Do you have a file named fpmulIE24mw_8ew.ngc (or > .edf or .edn or .ngo)? Can you determine what type of block it is by > digging into the code? It should match something here if it is a > built-in block: > > http://toolbox.xilinx.com/docsan/xilinx6/books/data/docs/lib/lib0024_10.html > > Otherwise, there should be code for it in one of the files Xilinx gave > you for the multiplier. It's possible you did not get all the necessary > files from Xilinx. >Article: 90662
Carry chain compares are done all the time. They work great. Your definition is how they're implemented If your single bit "a" and single bit "b" are considered: if( a<b ) force b (which is high) onto the chain if( a>b ) force b (which is low) onto the chain if( a==b ) pass the carry in to carry out. A comparison is just a subtraction. "Brannon" <brannonking@yahoo.com> wrote in message news:1129648479.566094.268650@z14g2000cwz.googlegroups.com... > The carry chains in current Xilinx FPGAs are insufficient for > comparison logic. I propose some changes for future chip designs: > > First, if this can be done on a Stratix 2 carry chain, please state > how. > > We are going to do a LT or GT comparison. The plan for LT: > > chop the thing into 2 bit chunks > for the most significant chunk: > if (a < b) switch the chain high > if (a > b) switch the chain low > if (a == b) passthrough > repeat for next most significant chunk > tie the bottom of the chain low > > So you see the problem? I can't force the chain high or low at run time > and still allow for passthrough. I can only do one or the other. >Article: 90663
The Platform USB Cable is only officially supported with Red Hat Enterprise Linux 3. There are a number of solution records on the Xilinx site (20762 & 18612) that could be used for a different kernel or distro. The farther you are from RHEL3, though, the more likely there are to be issues. Paul Waage wrote: > > Thanks Sylvain. > > I am not having much luck myself and am also a bit miffed!! > > What Linux Kernel are you running? > > Thanks, ChrisArticle: 90664
Robert wrote: > I am writing a verilog code whereby I read data from a txt file and use > it in one of the modules. I want to store the data from the .txt file > on to FPGA, where it can be used by other modules. How can I embedd the > .txt file in synthesis? Does Xilinx have a way of doing it so that the > .txt file information is included in the .bit file which is burned on > the FPGA? Others have pointed out most of the pieces. 1) With XILINX, for the actual FPGA use a BMM file and data2mem to initialize the rom contents in the bitstream. It's a pain to figure out and I last did it a year ago so I don't remember the details, but when you get it all worked out put it in a makefile that runs your table generator, updates the bit file and downloads to the FPGA. 2) For simulation, write a program that generates verilog code to initalize the memory. Yes, XILINX makes you initalize it a different way for simulation than for synthesis. Unlike apparently VHDL, verilog has an include directive, so you don't have to have your code generator recreate an actual verilog file each time, it can just spit out the file with the initialization commands. Put this in a makefile too... This is pretty much the same problem as how to load ROM contents for a custom embedded processor (ie, one where you aren't using embedded development tools that handle the whole deal for you)Article: 90665
"John_H" <johnhandwork@mail.com> schrieb im Newsbeitrag news:KU95f.21$9O6.178@news-west.eli.net... > The USB cable is a recent product and may not be a 100% happy experience. > I purchased one a couple weeks ago and found a few things. > > 1) I think it properly works at USB2.0 hi-speed but Windows XP reports the > device is a high-speed device plugged into a full-speed port and that the > device can go faster. I spent too much time trying to get the speed out > of the device when it is probably already up to speed. > > 2) Because it's new, Synplicity's Identify tool doesn't have the driver > for this "proprietary interface." Maybe in the next software rev (or two) > but not now. > > From what I've seen physically, I think the interface to the electronics > are the same for the two cables. Both have the ability to work with low > I/O voltages at the device side so, for instance, a 1.8V JTAG chain could > be accessed with either cable. Both are powered from the PC, the USB > cable via the USB power and the Parallel-IV cable through a keyboard power > jumper. My board-powered Paralell-III didn't work so well with a 2.5V > powered JTAG chain. > > If you have reliable USB2, can ignore the Windows warning messages, don't > need to work with non-Xilinx tools, and the cable is available, go for the > USB. > > - John_H > > > "GaLaKtIkUsT" <taileb.mehdi@gmail.com> wrote in message > news:1129649777.329624.51660@g43g2000cwa.googlegroups.com... >> Today I had a talk with the representant of Xilinx in russia. >> He adviced me to use Parallel cable 4 and not USB cable butwhen I asked >> why he told me that US Xilinx guys told him so. >> Can some one explain me? I need concrete examples. >> Perhaps he is only interested to sell ... one day he'll sell parallel >> cable ... and than I'll discover that I need the USB and come back to >> him to buy it :)) Xilinx USB Cable is high speed device so WinXP gives warning if you plugit into FS host port or hub. this normal. A HS device can not operate at HS in FS port. Cable IV vs USB Cable, the pld inside is either XCR3384 (Cable IV) or XC2C128 (usb cable). usb cable uses cypress hs usb chip. note that sub cable can update its PLD (cable IV can not in the factory shipped sate), also usb cable loads its firmware after enumeration, it does not contain firmware eeprom, only VID/PID eeprom. that makes usb cable upgragedable. And that is also one of the reasons why it is very likely that 3rd party products will never support xilinx usb cable. :(, as soon as any 3rd party implements usb cable support then it is only good as long as next impact service pack updates the usb cable usb cable is annoying as it usually requires to replug the usb cable each time you replug the jtag cable or power off the fpga. this is really annoying sometimes. so my favorite is still cable IV, IF it works, unfortunatly my home workstation has no LPT port and on the new workstation there is standard ECP port but xilinx cable IV drivers dont work in high speed mode. so: 1 cable IV, use it if you can 2 usb cable, use if you cant use cable IV as xilinx is pushing usb cable, it is very likely that xilinx never fixes the issues with the cable IV driver installation. AnttiArticle: 90666
CMOS (manusha@millenniumit.com) wrote: : here we go again...showing off stupidity.... Yay veriily, showing off with an understanding of capitalisation no less, and even providing an on topic response to someone who's heading for my usenet killfile... ---Article: 90667
John McCluskey wrote:
>I read this thread about initializing FPGA memory with some interest.
>Well over a year ago, I asked the XST developers in Grenoble to add
>support for File I/O during VHDL elaboration. This actually works in ISE
>7.1! You can write a VHDL function that opens a file (using the TextIO
>package), reads data out of it, and returns an array that can be used to
>initialize a signal array that has memory inferred on it. You can also
>write files, if you feel like you have a need for it. I argued that
>there exists a subclass of File I/O operations that can fit into the model
>of constant propagations that occur during elaboration. I've used this
>to write a VHDL function that will read an Intel MCS file into a ram array
>initial value during synthesis. In principal, anything you can parse in
>VHDL is fair game, although in practice, I've found the file IO a little
>fragile, especially when dealing with access types. Read the XST
>documentation to see how it's done.
>
>
Cool! I didn't know that they had actually implemented it. Now if
Synplify would follow suit, it would
surely get filtered into the other fpgA tools over time. The write
seemed like a logical extension, although
I'm not sure how useful it is beyond writing a serial number or key to a
file at compile time. Hmm, it
may be a (albiet, kludgey) way to pass a propagation delay or latency
back up to a higher level in the design hiearchy.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 90668You have a good point. I should have clarified. The subtraction only uses two inputs per LUT. The same is the case with what you're proposing for the compare. It seems to me you could double the density by adding an extra switch bit to the MUXCY because the LUT already supports four inputs.Article: 90669
Well, I got over this problem. Now if anyone knows how to use XMD to get xilmfs files/filesystems back out of the RAM after my embedded program has run, I would love to hear about it. JoeyArticle: 90670
"Antti Lukats" <antti@openchip.org> wrote in message news:dj3del$v5h$1@online.de... > > "John_H" <johnhandwork@mail.com> schrieb im Newsbeitrag > news:KU95f.21$9O6.178@news-west.eli.net... <snip> >> 1) I think it properly works at USB2.0 hi-speed but Windows XP reports >> the device is a high-speed device plugged into a full-speed port and that >> the device can go faster. I spent too much time trying to get the speed >> out of the device when it is probably already up to speed. <snip> > Xilinx USB Cable is high speed device so WinXP gives warning if you plugit > into FS host port or hub. this normal. A HS device can not operate at HS > in FS port. <snip> I can't plug my american hair dryer into the european socket? I can make it fit! ... The point I was trying to make is that I take my HS device (Platform Cable - USB), plug it into a HS port (Dell Optiplex GX280 USB2.0 Root Hub), and WinXP (Service Pack 2) complains that a HS device is plugged into a non-HS port and gives suggestions on HS ports to plug into... the ports I'm trying to use. Something appears to be messed up in the implementation such that Win XP gets confused as to what is HS and what isn't. It appears that - despite the warning - I am running at HS.Article: 90671
"John_H" <johnhandwork@mail.com> schrieb im Newsbeitrag news:opb5f.23$9O6.377@news-west.eli.net... > "Antti Lukats" <antti@openchip.org> wrote in message > news:dj3del$v5h$1@online.de... >> >> "John_H" <johnhandwork@mail.com> schrieb im Newsbeitrag >> news:KU95f.21$9O6.178@news-west.eli.net... > > <snip> > >>> 1) I think it properly works at USB2.0 hi-speed but Windows XP reports >>> the device is a high-speed device plugged into a full-speed port and >>> that the device can go faster. I spent too much time trying to get the >>> speed out of the device when it is probably already up to speed. > > <snip> > >> Xilinx USB Cable is high speed device so WinXP gives warning if you >> plugit into FS host port or hub. this normal. A HS device can not operate >> at HS in FS port. > > <snip> > > I can't plug my american hair dryer into the european socket? I can make > it fit! > ... > > The point I was trying to make is that I take my HS device (Platform > Cable - USB), plug it into a HS port (Dell Optiplex GX280 USB2.0 Root > Hub), and WinXP (Service Pack 2) complains that a HS device is plugged > into a non-HS port and gives suggestions on HS ports to plug into... the > ports I'm trying to use. > > Something appears to be messed up in the implementation such that Win XP > gets confused as to what is HS and what isn't. It appears that - despite > the warning - I am running at HS. hm ok, in that case yes it strange, it could be that the xilinx usb cable FW is not fully compliant to the usb spec and that triggers the warning, even though the cable operates at HS. I get this same warning myself but I havent bothered to check if the port is HS or not, I guessed its FS, and assumed that is the reason why I see the same warning. hum no, that cant be it, if the device is recogniyed as HS and FS root hub warning is geiven then this more likely an issue of mr Bill. AnttiArticle: 90672
Ok thanks a lot for answers. Remains one question abour usb cable. I plan to use Xilinx BaseX and Xilinx EDK in Linux. Can some one make a Parallel IV vs. USB cable in Linux ?Article: 90673
Look for the comp.arch.fpga newsgroup thread entitled "Linux and Platform USB Cable" that was started on October 13th, 2005. "GaLaKtIkUsT" <taileb.mehdi@gmail.com> wrote in message news:1129667070.546887.37230@f14g2000cwb.googlegroups.com... > Ok thanks a lot for answers. > Remains one question abour usb cable. > I plan to use Xilinx BaseX and Xilinx EDK in Linux. > Can some one make a Parallel IV vs. USB cable in Linux ?Article: 90674
Antti Lukats wrote: > And that is > also one of the reasons why it is very likely that 3rd party products will > never support xilinx usb cable. :(, The "Dynamic FPGA Probe" software on our Agilent Logic Analyzer does support the USB-cable. At least it says that it detects a "Platform USB Cable" and specifically lists both parallel and USB cables for connections to FPGAs But the device only has a USB1.1-port on which I've never been able to get the thing running (not even with iMPACT or Chipscope on other machines). > usb cable is annoying as it usually requires to replug the usb cable each > time you replug the jtag cable or power off the fpga. this is really > annoying sometimes. I've had no problems with that so far. But I do have to close the cable connection and reconnect each time I power down the FPGA. Otherwise it works fine (at least when you use Chipscope to program, haven't tried with iMPACT). cu, Sean
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