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
"PeteS" <PeterSmith1954@googlemail.com> wrote in message news:1169564272.442783.20420@d71g2000cwa.googlegroups.com... > > linear even from 5V is ok. I feed linear regulators all over the place > from switchers, and only in the most sensitive caes (which *can* > include the DCM if I have to ensure ultra low jitter) do I add extra > filtering beyond normal bypassing and perhaps a series inductor. > Hi Pete, OK, maybe I got the wrong end of the stick, but from your post I thought you meant you used the linear regulator to generate a special quiet supply. I usually have a 2.5V rail in my designs for things other than Vccaux, which made me go off on one! Whatever, just to clarify my point, it's important to note that the only _filtering_ the linear regulator is providing above a few 10's of kHz is due to the resistance of its pass element together with the bypass caps after it forming an RC filter. If you _already_ have 2.5V on your board, e.g. for LVDS banks' I/O supply, I contend that it's better all round to generate Vccaux by filtering this 2.5V rail with passives than to include a separate linear device to regulate down a supply which comes from a switcher. Linear regulators make rotten filters as spending some time playing with Linear Technology's free simulator will quickly show! Cheers, Syms.Article: 114726
Kunil, http://www.xilinx.com/products/design_resources/power_central/ Use the "XPower Estimator" tool to find the intended power requirements. Then scroll down to "Partners" and pick your favorite vendor. Follow the links. Really quite simple. Not sure why others are making such a big deal out of this. It is really a trivial issue. The power requirements which require very low noise, are the MGT analog supplies, and there is a huge user's guide to help you there (as well as manufacturer part numbers, and sample schematics). Every one of these vendors has met with Xilinx, and had their products reviewed. These vendors are used on our own boards. The only really difficult part is estimating the power you will use, because we have no control over what you program into our parts. All we can do is provide the tools to make estimates (which are based off the quality of information you give them). So, if you put garbage in, you get garbage out. AustinArticle: 114727
bgshea wrote: > I'm looking for POSITIVE feedback on Xilinx ISE. Yes i realize it has > it problems, but It's free. So, I've been looking round the WWW to find > some tips on what type of system (Windows, Linux, Intel x86 or EM86_64, > AMD, etc) that might result in better software preformace. > > Also, considering the effects of the Java RTE. > > I would like to post these suggestions to a page on my site, but if > this turns in to a flaming war, i will cease and go elsewhere. > > So, here is what I have, and my problems: > > I have a Windows XP based system with Xilinx 8.2.03 and Chip Scope Pro. > AMD Athlon 64 3000+ > 1GB DDR RAM > > Here are my issues: > > During the hardware validation process, i tend to make many small > changes to several projects (i have 4 FPGAs in my system on seperate > cards all being developed in parallel), esp to CSP which requires many > rebuilds and downloads. Since I'm working with Spartan 2 I cannot take > advantage of Partitioned designs. After about 10 or so builds and > downloads my physical ram usage is 1.5GB and my system is swappping > consistanly. Reviewing the windows resource usage, it shows only about > 150MB for _PN.exe, however, closing the ISE will free up nearly 1GB of > ram. > > So, is this a Java issue, should I upgrade my JRE, or does ISE use it's > own JRE? > > Is it a System issue, should I switch to a Linux based environment? or > Drop back to an older version of Windows such as w2k. > > Could it be a design flaw in my Design. I use a TLD with only IO Logic > and Global Clock buffers, all modules/sub modules contain related > functional logic. TLD only provides wired interconnect between modules, > no tri-state buses. Modules register inputs and outputs on clock edges. > > I haved contacted Xilinx on this matter, and will leave it at that to > stay imparital. > > Thanks for any feedback. > > Brian Brain, I have the same memory leak problem. But it doesn't seem like many people have this issue. At least not posted to this news group or on the Xilinx help. I can not use any 8.2 because of the memory leaks and since it is "free" you really can't complain to anyone at Xilinx. I have been using 7.1.04i which does the job for me. Version 9.1 is out and I am going to see it it is any better. Dave ColsonArticle: 114728
Does anyone know if it is possible to permanently harm a Xilinx FPGA internally through a bad (accidental or malicious) bitstream? I realize the DRC would catch any problems, but DRC can be turned off potentially permitting multiple drivers on the same long line or clock net. Thanks. StephenArticle: 114729
Brian, http://tinyurl.com/367qnf Details the technical answer on this subject. AustinArticle: 114730
"stephen.craven@gmail.com" <stephen.craven@gmail.com> wrote: >Does anyone know if it is possible to permanently harm a Xilinx FPGA >internally through a bad (accidental or malicious) bitstream? YES. Been there done that. I've cooked 2 Spartan2 fpgas that way when developing JTAG download software. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 114731
I am the main hardware designer for the company I work for. I inherited a lot of old, badly written, poorly documented VHDL designs and vendor tool project files. Over the course of the time that I have worked here, I have been trying to take care to go back and document things and better organize them, to make them easier to use and reuse, along with trying to write well-documented, reusable new code. I don't have any training as a software engineer or code "maintainer" (I'm an EE). I was wondering if there was a good resource out there (maybe a website or book on amazon) that would clue me into some good code writing and maintenance strategies that I wouldn't have learned in school. I know that there are a lot of software engineering resources available, but it would be nice if there was something more specific to hardware design (HDL Code) reuse and maintenance. thanksArticle: 114732
Stephan, In the past, before Virtex architecture, it was possible to create contention in the bitstream (connect two outputs together). With Virtex, and its new methods of interconnect (fully buffered, no tristate), we had fewer and fewer places where contention could occur. Now with Virtex 5, it is almost impossible to create intentional contention. There are still some structures where the wrong bits will connect two outputs together, but these are very few, and do not amount to a large heat load (device will not be damaged, the currents in the metal does not even exceed the EM rules!). The loading of a random bitstream does create some issues, as there are other bits which are part of the stream that can, and do affect power. For example, by turning ON all of the parallel DCI impedance matching circuits, one could have 200 ohms from Vcco to ground, on every IO pin! Given 500 to 800 IO's, that is 200/500 ohms, or 200/800 ohms (0.25 ohms) from Vcco to ground. At 3.3 volts, that is 13 amperes, or 40 watts! If you intentionally made a 500 MHz clock, and then connected all the CLB's in a shift register chain (including SRL32's in V5 or SRL16's in V4), and shifted a 1,0 pattern, I am sure you could melt the solder of a part! The design rule check will check for an unsupported combination of bits, but not an intentional set of connections: the onus is on the user to know what they are doing, and not exceed the junction temperature specification. SO an "attack" using DCI or a giant shift register would succeed. In that sense, a "denial of service" attack on an FPGA is much simpler if you have physical access -- just hit it with a hammer and be done with it! If you hacked into a network management system, and knew that you could download bitstreams to network elements, I would hope that there are sufficient security protocols in place so that you could not destroy a system remotely by downloading a pattern with all DCI turned ON. For example, if bitstream encyption is used, if you do not know the key, the bitstream is garbage, the CRC32 does not match, and the device never starts up (DONE does not go high). Unlike a microprocessor, there is no possibility of a single "halt and catch fire" instruction. AustinArticle: 114733
wallge wrote: > I am the main hardware designer for the company I work for. I inherited > a lot of old, badly written, poorly documented > VHDL designs and vendor tool project files. Over the course of the time > that I have worked here, I have been trying to take care to go back and > document things and better organize them, to make them easier to use > and reuse, along with trying to write well-documented, reusable new > code. > > I don't have any training as a software engineer or code "maintainer" > (I'm an EE). I was wondering if there was a good > resource out there (maybe a website or book on amazon) that would clue > me into some good code writing and maintenance strategies that I > wouldn't have learned in school. I know that there are a lot of > software engineering resources available, but it would be nice if there > was something more specific to hardware design (HDL Code) reuse and > maintenance. > > thanks Take a look at the "Reuse Methodology Manual" by Keating and Bricaud. http://tinyurl.com/3atmd3 or http://www.amazon.com/s/ref=nb_ss_gw/104-2090338-2355130?url=search-alias%3Daps&field-keywords=reuse+methodology+manual&Go.x=0&Go.y=0&Go=Go Regards, John McCaskill www.fastertechnology.comArticle: 114734
stephen.craven@gmail.com wrote: >Does anyone know if it is possible to permanently harm a Xilinx FPGA >internally through a bad (accidental or malicious) bitstream? > >I realize the DRC would catch any problems, but DRC can be turned off >potentially permitting multiple drivers on the same long line or clock >net. > > > Note that the bitstream is checked on-chip by CRC before the configuration is alowed to take place. So, unless the "bad" bitstream was carefully constructed to have a valid checksum, it would just keep the chip disabled. JonArticle: 114735
There was a Paper at FPL 1999 about destryoing FPGAs by implementing many internal ring oscillators. http://www.springerlink.com/content/9wnbm5eqgpjvlcug/ They were using Altera FPGAs and the Xilinx crowd in the auditorium burst into spontaneous applause. But the speaker pointed out that the same would be possible with Xilinx FPGAs. Kolja Sulimma stephen.craven@gmail.com wrote: > Does anyone know if it is possible to permanently harm a Xilinx FPGA > internally through a bad (accidental or malicious) bitstream? > > I realize the DRC would catch any problems, but DRC can be turned off > potentially permitting multiple drivers on the same long line or clock > net. > > Thanks. > StephenArticle: 114736
wallge wrote:
> I am the main hardware designer for the company I work for. I inherited
> a lot of old, badly written, poorly documented
> VHDL designs and vendor tool project files. Over the course of the time
> that I have worked here, I have been trying to take care to go back and
> document things and better organize them, to make them easier to use
> and reuse, along with trying to write well-documented, reusable new
> code.
I organize source files as vhdl-mode projects.
It's free, see:
http://www.iis.ee.ethz.ch/~zimmi/emacs/vhdl-mode.html
-- Mike Treseler
Article: 114737Hello, I am having a very strange problem with NIOS II not running a specific application. We are using DDR memory running at 100MHz on a Cyclone II FPGA. The memory was setup in SOPC builder. The clock looks good going to memory on the PCB. We have tested memory and we have seen an issue but yet we can see out to 128Megs (on all boards) The application downloads to DDR and verifies. The application seems to start to run but then stops at the same address (I believe). We can get the application to run some what reliably on one board but not the other 6 boards we have. One board would run the application some of the time. It seems that it stops working when I add something new to the FPGA design. We have written a smaller application and it works everytime out of DDR memory. Our first run of boards never had this problem. We saw something at the beginning when we were bringing up the second boards and application wouldn't run. The way we corrected this was start a new project then bring everything in again. After that we never saw any problems until we started putting more in the FPGA. I have looked at hardware, how Nios was setup, what is in Nios, the clocks, the PLLs, how Quartus connects to the pins, etc. I am not sure what to look at now. Has anyone had a problem like this before and how was it fixed? Does anyone have any other ideas? We are currently running Quartus 6.1. Thanks for any help. RobArticle: 114738
Rob wrote:
> I am having a very strange problem with NIOS II not running a specific
> application.
> We are using DDR memory running at 100MHz on a Cyclone II FPGA. The
> memory was setup in SOPC builder.
> The clock looks good going to memory on the PCB. We have tested memory
> and we have seen an issue but yet we can see out to 128Megs (on all
> boards)
Deal with the issue.
Every bit of the RAM has to work.
Run full walking ones then zeros tests
on all the address and data lines.
Put a scope on the memory and check for ringing and noise.
-- Mike Treseler
Article: 114739>>>> Now all you need is a Gerber-driven solder paste dot printer! They >>>> exist, and news of an affordable unit for prototyping would be interesting. >> >>>Following up myself, the Essemtec CDS6700 solder paste printer seems to >>>cost around $25,000. Not quite affordable ;-) >> >>Makes me wonder what it would cost to build x-y table and reuse a inkjet >>cartridge ;) >Maybe with a DVD inkjet printer (like Epson R200), should hold a Eurocard 100x160. >DVD is 120mm wide, it is in a tray that slides through the printer, no length limit. >Costs 80 Euro to try... Do you think the solderpaste would get through the ink channels ..? Maybe it's viscosity is too high. I also think that any ordinary underpriced inkjet will be just fine. Just bring the screwdriver. On a more serious side, increasing the distance between printheads and printer bottom. Then add some wagon to fasten the pcb into which is driven by the paperfeed mechanism. I think the real blocker is the ink channel mechanism, once that is solved it depend mainly on precision of x-y table + diameter of the solderpaste drop. 5-10 mil should be enough precision on the maximum side?Article: 114740
I agree in principle, but it sometimes gets a little more complicated. > Note that the bitstream is checked on-chip by CRC before the configuration > is alowed to take place. Technically, the CRC is computed on a frame by frame basis, so errors might indeed prevent startup for a full bitstream, but for a partial active reconfiguration the frames that passed CRC would still be reconfigured. > So, unless the "bad" bitstream was carefully constructed to have a > valid checksum, it would just keep the chip disabled. Yes, for a full bitstream that was corrupted by accident. But recomputing the CRCs on a deliberately modified bitstream, or just disabling CRC checking altogether, is easy to do, even though Austin tells us it would be unlikely to harm the device.Article: 114741
My bad. I was trying to respond to Jon Elson.Article: 114742
I agree in principle, but it sometimes gets a little more complicated. > Note that the bitstream is checked on-chip by CRC before the > configuration is alowed to take place. Technically, the CRC is computed on a frame by frame basis, so errors might indeed prevent startup for a full bitstream, but for a partial active reconfiguration the frames that passed CRC would still be reconfigured. > So, unless the "bad" bitstream was carefully constructed to have a > valid checksum, it would just keep the chip disabled. Yes, for a full bitstream that was corrupted by accident. But recomputing the CRCs on a deliberately modified bitstream, or just disabling CRC checking altogether, is easy to do, even though Austin tells us it would be unlikely to harm the device.Article: 114743
Oh, I get it. I just don't know how to use my news reader.Article: 114744
Steven P wrote: > PS: I can not find the abel to vhdl convert in ISE 8.1. You find it in ISE 8.2.03i when you create a project, select the device in the Sources window, and select 'HDL Converter' from 'Design Utilities' in the Processes window. ThomasArticle: 114745
Steven P wrote: > PS: I can not find the abel to vhdl convert in ISE 8.1. You find it in ISE 8.2.03i when you create a project, select the device in the Sources window, and select 'HDL Converter' from 'Design Utilities' in the Processes window. ThomasArticle: 114746
Hi Austin, This raises intersting questions: > For example, if bitstream encyption is used, if you do not know the key, > the bitstream is garbage, the CRC32 does not match, and the device never > starts up (DONE does not go high). Sorry for not reading the docs, is encryption only used on frame data in the bitstream? - If encryption is for the full bitstream, then there's not even one chance that the random garbage will make sense to the bitstream microcontroller, so you're safe. - If encryption is limited to the data stream, then on the virtex2, it's very easy to disable CRC checking and load random garbage for which I'd guess frying configurations on long lines would not be uncommon (let's do the math !). On virtex4 and virtex5, I'd expect that each frame's Hamming SECDED code is checked by the loading state machine and encrypted, so random garbage would be rejected ? Or does Hamming Code sits there for nothing at load-time ? JBArticle: 114747
WOW, thanks everyone for the input. I'm going to dig though this info and esp. the links provided. I would love to see some linux build scripts. I love EMACS!! and use it for all my c/c++ developement in linux. However, i don't have a PC to space in my office for linux yet. But i can certainly try on one of my personal Linux boxes. ISE has been, IMHO, going down hill. With each new release the projects become backward incompatible. So what i end up with is many copes of projects for each new release. I'm not one to binldly trust any software so when upgrading i always copy my project directory to /projects/Xilinx_version/project_xxx ensuring a quick esacpe if something goes wrong. I can't say i've had many problems with accessing files on network shares, was that Samba or NFS that was used? This would be nice to know, if you already stated, i appoligize for not reading everthing 100%. I going to post this thread on my site, when i get it done, I'll post the link. Regards, Brian doug wrote: > Austin Lesea wrote: > > Brian, > > > > http://tinyurl.com/367qnf > > > > Details the technical answer on this subject. > > > > Austin > I am a long time lurker on this newgroup and have learned > a lot from it. I very much appreciate the presence of Austin > and Peter and the help that they provide. > > However, what got me to post this is that the url above just > adds insult to injury regarding ise. I am a long time user of > Xilinx software starting in about 1991. For most of that period > the software has been terrible. The XACT software required you > to reboot after every run, either voluntarily or it would do it > for you. By the time of the Foundation series, the software was > getting reasonable. I even bought a copy for my personal use. > > ISE has been an experience. By version 6.3 it was reasonably > good. It did what I wanted and did not cause too much trouble. > Version 7 was a huge step backwards. Project navigator got user > surly and very slow. Whoever did the design never used it for > anything. Version 8 reached a new low. The stupid design to > change the project files, later partly removed, made for lots of > headaches. > > Fortunately I was spared a lot of the headaches of version 8 since > it would not compile my design. For a variety of reasons, mostly > historical, a large part of my design is schematics. There is a > major memory leak in the schvhdl module. It leaks at about 1mb > per second of cpu time. Version 7 would complete the xst portion > in about five minutes with a peak memory useage of around 120mb. > Version 8 took an hour or so of time and then crashed at just over > 2gb of useage. There was no way to compile the project and this > was confirmed by Xilinx tech support. The only "workaround" was > to tell it to compile to verilog instead of vhdl since that memory > leak was not as bad. Unfortunately this was not an option since > the peak memory useage was just about the 2gb point where the vhdl > conversion failed and blew up the program. > > The memory leak was a problem in version 8.1 > It was not fixed in 8.1 sp1 > It was not fixed in 8.1 sp2 > It was not fixed in 8.1 sp3 > It was not fixed in 8.2 > It was not fixed in 8.2 sp1 > It was not fixed in 8.2 sp2 > It was not fixed in 8.2 sp3 > It was not fixed in 9.1 > It was not fixed in 9.1 sp1 > > So the latest and greatest version 9.1 and its service pack have done > nothing to help make a relatively small design work. If they are not > going to improve things, why break stuff that was working ok? > > Memory leaks come from sloppy programmers. Not fixing memory leaks > comes from lazy or incompetent programmers. It is clear that the > programmers did not test their code. They seem to think that "testing" > means looking to see if it blows up in the first ten seconds. This is > not some exotic hard to reproduce bug. Take an 2 input and gate and > put iopins on it. The memory leak is about 3mb as I recall. This is > not subtle or hard to find. They did not even look. They have not > been looking since it was pointed out and there is no reason to believe > that they have any intention of looking for the leaks. > > At one point I sent in a list of fourteen bugs in ise for version 7. > They are all still there plus lots of new ones I have seen in the > little I have been able to use the newer versions. > > The conclusion of this is that pointing to a url which just points > out that the programmers did not bother to test their code does > not help the users. What is needed is to get programmers who know > what they are doing and FIX the problems. > > Xilinx support recommended vhdl as it is more portable. That is true > and will make it easier to take designs to other manufacturers.Article: 114748
> Memory leaks come from sloppy programmers. Not fixing memory leaks > comes from lazy or incompetent programmers. Even incompetent programmers can manage this. The use of valgrind [http://www.valgrind.org] will pinpoint memory leaks right to the line where the allocation was made. It runs on unmodified software. This would be, oh, one hour work maximum if you have the source. JBArticle: 114749
"Rob" <robd@novacatv.com> wrote in message news:1169582073.870785.304790@l53g2000cwa.googlegroups.com... > Hello, > > I am having a very strange problem with NIOS II not running a specific > application. > > > We are using DDR memory running at 100MHz on a Cyclone II FPGA. The > memory was setup in SOPC builder. > The clock looks good going to memory on the PCB. We have tested memory > and we have seen an issue but yet we can see out to 128Megs (on all > boards) Your symptoms seem to indicate a timing problem or signal integrity issue or possibly a supply voltage issue (in that order would be my guess knowing nothing else about your particular design). Verify that the actual PCB delays on the board and the ddr part timings for the actual device match what is in the DDR Controller settings using the MegaWizard and that you can successfully run through the ddr timing verification TCL script that is (or at least was) an output of SOPC Builder when you do the generate. That script is supposed to verify that the ddr timing on the final routed FPGA design is correct. Other things to look for are just the basic things like.... - signal quality (are the nets properly termiated?) - Supply voltages (any dips?) If you haven't done so lately, peruse the ddr controller handbook again for something that you may have overlooked in the design process. As Mike suggested in his post, getting a simple memory test to walk 0 and 1 across the entire memory is an important test that absolutely must run without fail before even bothering to use the memory for any application. Kevin Jennings
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