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
Yes, this will work fine (it is what I did in my project). Be sure, though, that you properly handle the PLL pins. In my design, I tied both GNDA_PLL pins to ground and the VCCA_PLL pint to 1.5V with a .001uF capacitor. I believe I got the pinning information from the datasheet.Article: 93676
Was the attempt with 8.1 successful? I can try it as well... Paul mail@deeptrace.com wrote: > > I have used other VHDL simulators, but I am now trying to run the > Xilinx ISE simulator in Foundation 7.1 for the first time. As you can > see below, I'm not having much success. > > I get the following message: > > Compiling vhdl file "<expunged path>Match8.vhd" in Library work. > Entity <match8> compiled. > Entity <match8> (Architecture <behavior>) compiled. > Parsing "match8_lau.prj": 0.73 > ERROR:Simulator:222 - Generated C++ compilation was unsuccessful > Codegen UNISIM/VPKG: 0.13 > Codegen UNISIM/VPKG: 0.09 > Codegen UNISIM/VPKG: 0.09 > Codegen UNISIM/VPKG: 0.11 > Codegen UNISIM/VPKG: 0.11 > Codegen unisim/VPKG: 0.11 > Codegen unisim/VPKG: 0.09 > ERROR:Simulator:222 - Generated C++ compilation was unsuccessful > Codegen UNISIM/VCOMPONENTS: 0.03 > Codegen UNISIM/VCOMPONENTS: 0.00 > Codegen unisim/SRLC16E: 0.00 > Codegen unisim/SRLC16E: 0.02 > Codegen unisim/SRLC16E: 0.00 > Codegen unisim/MUXCY: 0.00 > Codegen unisim/MUXCY: 0.01 > Codegen work/MATCH8: 0.00 > ERROR:Simulator:222 - Generated C++ compilation was unsuccessful > Codegen unisim/SRLC16E/SRLC16E_V: 0.02 > Codegen unisim/SRLC16E/SRLC16E_V: 0.00 > ERROR:Simulator:222 - Generated C++ compilation was unsuccessful > Codegen unisim/MUXCY/MUXCY_V: 0.00 > Codegen unisim/MUXCY/MUXCY_V: 0.00 > ERROR:Simulator:222 - Generated C++ compilation was unsuccessful > Codegen work/MATCH8/BEHAVIOR: 0.01 > ERROR: Fuse failed > > When trying to simulate a simple 8 bit identity comparator that is > known to work fine. > Basically no matter what code I try to simulate, I get the ERROR: > Simulator:222 error. > > It looks that something very basic is wrong, like some environment > setting, but I have found no information on this error anywhere. The > code compiles into a bitstream without any problems, and the VHDL > syntax checker works fine, it just doesn't want to simulate. > > Any suggestions would be greatly appreciated. > > Thanks > > Chris JohnsonArticle: 93677
I see. As the backward compatibility must be executed in silicon level, not software level, I guess it will be a challenge job for your team. :-) Thank you very much! Engine Austin Lesea wrote, > Engine, > > Well, we did not invent stepping, Intel did. > > Stepping is just another way to keep track of what you are shipping. > > Let me give you an example: > > We go to production, even perhaps with errata: > > http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=14052 > > which is an example of an errata for Virtex 2 Pro. > > Errata are items that are presently not working as they are described in > the documentation. > > Errata can be cleared by: manual work-arounds with technical answers, or > product notices; changes to the silicon (very rare); changes to the > software (so that the problem is worked around automatically; and > everything works as documented); or changes to the data sheet (so that the > issue is described properly). > > The stepping system ensures "backward compatibility" which means that any > future chips MUST work with older bitstreams, in older designs. This means > that the customer does not have to worry that a new mask revision will > cause all of your previous IP to suddenly be "broken" and need to be > regenerated! > > Some other manufacturers are on their n-th revision of silicon, and have > no "stepping" system at all, nor any policy about what they are doing (to > you). > > If anything, I would require a properly documented stepping policy for > approval of any component, so that I would be sure that I would not be > "surprised" in any future shipment. > > To this end, Virtex 4 was one of the first products to have the fully > implemented stepping system in place. Eventually all products will use > the system. > > As always, if your company has its own policies, with their own > requirements, Xilinx is more than willing to work with you to establish > your own required flow to meet those needs. Some examples are customers > who require samples of the new stepping, and need 90 days before the new > stepping is allowed to be shipped to them as production. These > requirements are quite common with automotive suppliers, for example. > > If you have any other concerns or questions on stepping, please consult > your Xilinx FAE. As well, if you have any questions or concerns about > errata, also consult your FAE. > > Austin > > > Engine wrote: > >> A friend send me a document link. >> http://direct.xilinx.com/bvdocs/notifications/xcn05025.pdf >> >> He suggest we do not select Virtex4 in our projects. >> >> I am not sure the real meaning of this document. >> >> Does it mean that there are three bugs in the step 1 Virtex4 LX/SX? >> Why do not call the Step 2 LX/SX as the mass production LX/SX? >> Are there still bugs in step 2 LX/SX? >> Whether step 3 LX/SX will be relased later? >> Why FX is in step 0 now, what's the defination of step 0? >> >> Please help me! >> >> If it is ture, I would like to use the old VirtexII or Stratix on my >> projects. >> >> Thanks, >> Engine >> >> >> >>Article: 93678
Hallo, I have bought a Virtex-4FX Mini Module + Baseboard from Memec. On the board there is a USB to serial bridge, Silabs CP2101. May I use it to connect a printer? Many Thanks MarcoArticle: 93679
Hi Antti, What does 'EDK' stand for? WengArticle: 93680
Symon, The most recent 'ahshit' was the problem regarding a daisy-chained JTAG TCK line. This definitely would have shown up in simulation, but who would think to simulate a stinking JTAG port? Now, it's the only thing I think about :-) You're correct. Buffering, in itself, may cause a worse problem. However, if you buffer each clock input separately (so you only have point-to-point connections per clock drive/input pair) and add a source termination resistor, close to each buffer's output pin, then you shouldn't have any clock edge SI problems. This is what we do, now, for JTAG TCK's and FPGA CCLK's. We have grown to depend on HyperLynx, and most recently SiSoft. When in doubt -- simulate. When confident -- still simulate! Bob "Symon" <symon_brewer@hotmail.com> wrote in message news:43b27fd0$0$15785$14726298@news.sunsite.dk... > Hi Bob, > The answer is to do as Austin says and simulate the thing. No 'ahshits' or > bodged on caps needed. The Mentor marketing hype is pretty close when it > says that the tool pays for itself in just 1 or 2 PCB respins because the > SI is bad first time. > It also makes sure that your design isn't marginal. Two 'ahshits' may have > got your design working, but will it survive the next rev. of the silicon > because it only just worked? > BTW, another misconception is that buffering always fixes the problem. > Most buffers are very good at driving lines with faster rise times than > the original driver. This makes the problem even worse. > Best, Syms. > p.s. I chuckled at Brad's "I would suggest doing whatever they (Xilinx) > say."! I'd suggest maybe using their designs as a start, then think about > your own application. Remember, Xilinx has to suggest things that will > work for a multitude of designs. This may not be the most efficient for > your design. In fact I'd question whether a 'one size fits all' is even > possible at all for some situations. > > > "Bob" <nimby1_notspamm_@earthlink.net> wrote in message > news:7Bpsf.3534$R84.1704@newsread2.news.pas.earthlink.net... >> >> Yep, that's a common misconception that it's the frequency that causes >> reflections. >> >> We did a board that had a "double-pulse" problem on a 1MHz JTAG test port >> (one TCK buffer output driving multiple JTAG ports). Now, we distribute >> TCK like any other clock, and source terminate each buffer output. >> >> It all seems so easy, now, but it's taken a couple of 'ahshits' to get >> there. > > >Article: 93681
Hi, I read patent 6,914,453 by IBM and trying to follow the paper's claim pattern to write my claims. The next question is: What is the difference between Method and Apparatus in a patent claim area? The interesting thing happens with the claims: The patent repeats all sentences in claims for Method with a few changes to make up claims for Apparatus. I will follow their patterns, but I really don't realize why to do them repeatedly? Any patent precedents that if not repeated, a very serious consequences would follow? Thank you. WengArticle: 93682
Yes, You see exactly what this means. The advantage to us is that we go to production sooner (and our customers get full production qualified parts sooner), and it allows us to ship an initial stepping that may have some limitations, or bugs (with the errata to describe them, with any workarounds, etc.). But, when we fix the bugs, we must be sure that the new silicon can use the older bitstreams compiled ealier, and be equivalent. If the new software is used with a new stepping, then the new features are then enabled. One disadvantage is that the customer has to keep track of stepping of material shipped if they wish to generate new bitstreams, and reconfigure the parts that are already in the field. This should not be an issue, as most companies already keep track of their shipped products with revision controls, or issue numbers. Austin Engine wrote: > I see. > As the backward compatibility must be executed in silicon level, not > software level, I guess it will be a challenge job for your team. > :-) > > Thank you very much! > Engine > > > Austin Lesea wrote, > > >>Engine, >> >>Well, we did not invent stepping, Intel did. >> >>Stepping is just another way to keep track of what you are shipping. >> >>Let me give you an example: >> >>We go to production, even perhaps with errata: >> >>http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=14052 >> >>which is an example of an errata for Virtex 2 Pro. >> >>Errata are items that are presently not working as they are described in >>the documentation. >> >>Errata can be cleared by: manual work-arounds with technical answers, or >>product notices; changes to the silicon (very rare); changes to the >>software (so that the problem is worked around automatically; and >>everything works as documented); or changes to the data sheet (so that the >>issue is described properly). >> >>The stepping system ensures "backward compatibility" which means that any >>future chips MUST work with older bitstreams, in older designs. This means >>that the customer does not have to worry that a new mask revision will >>cause all of your previous IP to suddenly be "broken" and need to be >>regenerated! >> >>Some other manufacturers are on their n-th revision of silicon, and have >>no "stepping" system at all, nor any policy about what they are doing (to >>you). >> >>If anything, I would require a properly documented stepping policy for >>approval of any component, so that I would be sure that I would not be >>"surprised" in any future shipment. >> >>To this end, Virtex 4 was one of the first products to have the fully >>implemented stepping system in place. Eventually all products will use >>the system. >> >>As always, if your company has its own policies, with their own >>requirements, Xilinx is more than willing to work with you to establish >>your own required flow to meet those needs. Some examples are customers >>who require samples of the new stepping, and need 90 days before the new >>stepping is allowed to be shipped to them as production. These >>requirements are quite common with automotive suppliers, for example. >> >>If you have any other concerns or questions on stepping, please consult >>your Xilinx FAE. As well, if you have any questions or concerns about >>errata, also consult your FAE. >> >>Austin >> >> >>Engine wrote: >> >> >>>A friend send me a document link. >>>http://direct.xilinx.com/bvdocs/notifications/xcn05025.pdf >>> >>>He suggest we do not select Virtex4 in our projects. >>> >>>I am not sure the real meaning of this document. >>> >>>Does it mean that there are three bugs in the step 1 Virtex4 LX/SX? >>>Why do not call the Step 2 LX/SX as the mass production LX/SX? >>>Are there still bugs in step 2 LX/SX? >>>Whether step 3 LX/SX will be relased later? >>>Why FX is in step 0 now, what's the defination of step 0? >>> >>>Please help me! >>> >>>If it is ture, I would like to use the old VirtexII or Stratix on my >>>projects. >>> >>>Thanks, >>>Engine >>> >>> >>> >>> > >Article: 93683
motty wrote:
> Is there a way to do what I am trying to do? Basically, I want the EDK
> to synthesize the Xilinx IP and Synplicity to synthesize the user IP
> via the ISE.
I would use Synplicity to convert my code into .edf files
to add to the ISE place+route.
> I know I could probably black-box the user IP in the ISE first and then
> pull that into the EDK.
I would add an unbound component to my vhdl code
to match the xilinx supplied netlists. EDK no doubt
add some of it's own constraints, but I know
nothing about that.
> But I am just messing around, evaluating what
> can and cannot be done using Synpilcity. It is a VERY expensive tool
> that we are trying to see is worth justifying.
You can't answer that question without running a
sample design through all the tools with and
without Synplicity synthesis.
-- Mike Treseler
Article: 93684<wtxwtx@gmail.com> schrieb im Newsbeitrag news:1135784033.195372.48850@z14g2000cwz.googlegroups.com... > Hi Antti, > What does 'EDK' stand for? > > Weng > Embedded Development Kit - a bundle of program for Xilinx SoC design AnttiArticle: 93685
"Marco T." <marcotoschi@nospam.it> schrieb im Newsbeitrag news:doub1e$8qk$1@nnrp.ngi.it... > Hallo, > I have bought a Virtex-4FX Mini Module + Baseboard from Memec. > > On the board there is a USB to serial bridge, Silabs CP2101. May I use it > to connect a printer? > > Many Thanks > Marco > No if you plug the CP2101 into PC host then the host will see it as UART, thats all you can do. AnttiArticle: 93686
Is it possible to simulate an extremely simple VHDL design generated by
ispLEVER Starter?
It is composed of an EBR RAM block which implements a 512x8 ROM and several
wires. :-)
I would like to check whether it works, so even a very simple waveform-based
simulator will
do, but I can't find it in the package. Is there any?
Best regards
Piotr Wyderski
--
"If you were plowing a field, which would you rather use?
Two strong oxen or 1024 chickens?" -- Seymour Cray
Article: 93687Soenke wrote: > Hi All, > > Has anyone made some experiences with fpga and drm. I'm looking for > informations and papers to set up my own project based on the algorithms > of the DREAM-Project. > > Thanx > SB You could have a look at referreed journal pubs and conference proceedings regarding OFDM. OFDM processing is probably the performance bottleneck in DRM. Nikolaos KavvadiasArticle: 93688
Dear All, Many thanks for all your suggestions... I have tried dividing my incoming 25MHz clock by 2 and voilla! everything works, albeit 50% slower... So now I guess I will have to divide the incoming clock by 2, multiply it and re-divide it. Any ideas why this could be happening? Regards to all, PeterArticle: 93689
wtxwtx@gmail.com wrote: > Hi, > I read patent 6,914,453 by IBM and trying to follow the paper's claim > pattern to write my claims. > > The next question is: > What is the difference between Method and Apparatus in a patent claim > area? > > The interesting thing happens with the claims: > The patent repeats all sentences in claims for Method with a few > changes to make up claims for Apparatus. > > I will follow their patterns, but I really don't realize why to do them > repeatedly? > > Any patent precedents that if not repeated, a very serious consequences > would follow? > > Thank you. > > Weng The Apparatus claims cover the device itself: its component parts and their physical arrangement. The Method claims cover the way in which the gadget operates, the process performed by the parts. Regards, James Arthur (Disclaimer: IANAL)Article: 93690
Nitesh, There is nothing wrong with your bitstream or bitstream settings. The download is not even getting that far, anyway. I suggest that you follow the recommendations in the error message to begin: 1. Check that the cable, scan chain, and power connections are intact Is you cable powered? Is your board? Are TCK, TMS, TDI and TDO of the cable correctly connected to the board? 2. That the power supply is adequate and delivering the correct voltage. Is you power supply set correctly and delivering the required current? You should also run iMPACT in interactive GUI mode and build the chain manually. Try to read the IDCODE from any device. That should give additional diagnostic information. Nitesh wrote: > Hello, > I seem to have a problem while downloading the design on ML300 trough > the JTAG cable. I searched it over the net but found no solution. I > can download the design using the compact flash but with JTAG it gives > a problem. > > impact -batch etc/download.cmd > PM_SPEC -- Xilinx path component is <C:/EDK> > // *** BATCH CMD : setMode -bs > // *** BATCH CMD : setCable -port auto > AutoDetecting cable. Please wait. > Connecting to cable (USB Port). > Cable connection failed. > Connecting to cable (Parallel Port - LPT1). > Checking cable driver. > Driver windrvr6.sys version = 6.2.2.2. LPT base address = 0378h. > ECP base address = FFFFFFFFh. > Cable connection established. > // *** BATCH CMD : identify > Identifying chain contents ....done. > ERROR:iMPACT:585 - A problem may exist in the hardware configuration. > Check that the cable, scan chain, and power connections are intact, > that the specified scan chain configuration matches the actual > hardware, and > that the power supply is adequate and delivering the correct > voltage. > Elapsed time = 0 sec. > // *** BATCH CMD : identifyMPM > Elapsed time = 0 sec. > ERROR:iMPACT:589 - No devices on chain, can't assign file > make: *** [download] Error 1 > Done. > > > The following is y bitgen.ut file > -g ConfigRate:4 > -g CclkPin:PULLUP > -g TdoPin:PULLNONE > -g M1Pin:PULLDOWN > -g DonePin:PULLUP > -g DriveDone:No > -g StartUpClk:JtagCLK > -g DONE_cycle:4 > -g GTS_cycle:5 > -g M0Pin:PULLUP > -g M2Pin:PULLUP > -g ProgPin:PULLUP > -g TckPin:PULLUP > -g TdiPin:PULLUP > -g TmsPin:PULLUP > -g DonePipe:No > -g GWE_cycle:6 > -g LCK_cycle:NoWait > -g Security:NONE > -m > -g Persist:No >Article: 93691
Judging by the voltage swings I would say that the termination resistors are not there. That would explain why the steady DVAL does not show up. I have a case put in at Xilinx to find out how to turn them on. "Rob" <robnstef@frontiernet.net> wrote in message news:P8osf.2155$OU3.2038@news01.roc.ny... > I've never needed to pull-up LVDS signals that were being driven. I've > driven as far as 10feet, too. Remember, the voltage genereated is a > result of the current passing through the termination resistor. >Article: 93692
Thanks.Article: 93693
How do you turn the 100 ohm resistor on for an LVDS input? I am using the HDR2 header on an ML402 dev board. Brad Smallridge aivision.comArticle: 93694
Brad, If the part has them (look in data sheet, or keep reading), it would be the LVDS_DT IO primitive. LVDS_DT_p for the + terminal, LVDS_DT_N for the - terminal of the diff input pair. Or, you should be able to see the button in FPGA Editor to turn the termination ON (if it is in the part you have). The ML402 is for the Virtex 4, and all V4 parts have the DT option. Austin Brad Smallridge wrote: > How do you turn the 100 ohm resistor on for an LVDS input? > I am using the HDR2 header on an ML402 dev board. > > Brad Smallridge > aivision.com > >Article: 93695
Brad Smallridge wrote: > Judging by the voltage swings I would say that the termination resistors are > not there. > That would explain why the steady DVAL does not show up. I have a case put > in at > Xilinx to find out how to turn them on. You either need to instantiate IBUFDS_LVDS25_DT in your HDL-Code (instead of just IBUFDS) or attach the IOSTANDARD-attribute to your IBUFs, with the value LVDS25_DT. The _DT switches on the differential termination. See here: http://toolbox.xilinx.com/docsan/xilinx7/books/data/docs/lib/lib0210_196.html cu, SeanArticle: 93696
Hi, There is an appnote on Synplicity's Website that may help: http://www.synplicity.com/literature/pdf/Using_Synplify_with_EDK.pdf Happy New Year, Bob Synplicity FAE - Colorado.Article: 93697
Sean Durkin wrote: > You either need to instantiate IBUFDS_LVDS25_DT in your HDL-Code > (instead of just IBUFDS) or attach the IOSTANDARD-attribute to your > IBUFs, with the value LVDS25_DT. The _DT switches on the differential > termination. Sorry, my mistake: it either must be a IBUFDS_LVDS_25_DT in the HDL or the attribute value LVDS_25_DT. The link I posted earlier doesn't mention V4, but it should be the same for that. And I just read that there's a new attribute "DIFF_TERM" for V4, that should work as well. You'd have to check the Xilinx Constraint Guide in the ISE Documentation for that. I suppose you need to set it to "TRUE" or something. cu, SeanArticle: 93698
Hi everyone, I'm building a circuit that will be driving quite a few (>100) LEDs, multiplexed into 3 or 4 groups, so up to 40 at the same time. Can I use the Spartan 3 'Current drive' option to limit drive current to these LEDs to e.g. 24 mA ? I'm hoping to limit the number of external components that I'll need. I've set the IO standard of the ports in question to LVCMOS33 and set 24mA, but the port drives at least 70mA trough a LED and amp-meter connected to ground. Setting a lower value for drive current does decrease the drive, but it stays significantly above the value I set - and I'd rather not ruin my LEDs or, even worse, FPGA. So I'm probably misunderstanding the way 'drive limit' is set or supposed to be used. Could anyone enlighten me? Regards, Paul Boven.Article: 93699
Recently posted on our website: http://www.xilinx.com/products/silicon_solutions/fpgas/virtex/virtex4/resources/Virtex-4_Power_Case_Study.pdf Is a case study in which the latest claims of power savings by the competitor's software are debunked. I had intended to post this as part of the earlier thread, but I couldn't find the link to the above white paper. If you ignore the superiority of Virtex 4, and just concentrate on the improvement in power from the tool, going from ~ 2.8 watts to ~ 2.6 watts, or an improvement of 200 mW, is roughly an improvement of 7% less power. So, routing and placement can really save some power. Or perhaps, one should say poor routing and poor placement can increase power? Or should one say that Virtex 4 uses so much less power, that talking about how much is 'saved' by the software tool is just a distraction to fool the unwary? Austin
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