Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 114725

Article: 114725
Subject: Re: FPGA power supply design
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 23 Jan 2007 15:40:07 -0000
Links: << >>  << T >>  << A >>
"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
Subject: Re: FPGA power supply design
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 23 Jan 2007 07:59:04 -0800
Links: << >>  << T >>  << A >>
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.

Austin

Article: 114727
Subject: Re: Xilinx ISE 8.2
From: "dscolson@rcn.com" <dscolson@rcn.com>
Date: 23 Jan 2007 08:19:14 -0800
Links: << >>  << T >>  << A >>

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 Colson


Article: 114728
Subject: FPGA damage from bad bitstream
From: "stephen.craven@gmail.com" <stephen.craven@gmail.com>
Date: 23 Jan 2007 08:45:22 -0800
Links: << >>  << T >>  << A >>
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.
Stephen


Article: 114729
Subject: Re: Xilinx ISE 8.2
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 23 Jan 2007 08:58:41 -0800
Links: << >>  << T >>  << A >>
Brian,

http://tinyurl.com/367qnf

Details the technical answer on this subject.

Austin

Article: 114730
Subject: Re: FPGA damage from bad bitstream
From: nico@puntnl.niks (Nico Coesel)
Date: Tue, 23 Jan 2007 17:07:05 GMT
Links: << >>  << T >>  << A >>
"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.nl

Article: 114731
Subject: Good hardware design code re-use strategies, reference book
From: "wallge" <wallge@gmail.com>
Date: 23 Jan 2007 09:35:40 -0800
Links: << >>  << T >>  << A >>
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


Article: 114732
Subject: Re: FPGA damage from bad bitstream
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 23 Jan 2007 09:36:16 -0800
Links: << >>  << T >>  << A >>
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.

Austin

Article: 114733
Subject: Re: Good hardware design code re-use strategies, reference book
From: "John McCaskill" <junkmail@fastertechnology.com>
Date: 23 Jan 2007 09:51:58 -0800
Links: << >>  << T >>  << A >>

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.com


Article: 114734
Subject: Re: FPGA damage from bad bitstream
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Tue, 23 Jan 2007 13:24:49 -0600
Links: << >>  << T >>  << A >>


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.

Jon


Article: 114735
Subject: Re: FPGA damage from bad bitstream
From: "comp.arch.fpga" <ksulimma@googlemail.com>
Date: 23 Jan 2007 11:43:25 -0800
Links: << >>  << T >>  << A >>
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.
> Stephen


Article: 114736
Subject: Re: Good hardware design code re-use strategies, reference book
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 23 Jan 2007 11:43:35 -0800
Links: << >>  << T >>  << A >>
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: 114737
Subject: NIOS II Application startup issues
From: "Rob" <robd@novacatv.com>
Date: 23 Jan 2007 11:54:34 -0800
Links: << >>  << T >>  << A >>
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)

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.

Rob


Article: 114738
Subject: Re: NIOS II Application startup issues
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 23 Jan 2007 12:36:19 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: Surface mount ic's
From: pbFJKD@ludd.invalid
Date: 23 Jan 2007 20:47:59 GMT
Links: << >>  << T >>  << A >>
>>>> 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
Subject: Re: FPGA damage from bad bitstream
From: Neil Steiner <neil.steiner@vt.edu>
Date: Tue, 23 Jan 2007 16:10:59 -0500
Links: << >>  << T >>  << A >>
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
Subject: Re: FPGA damage from bad bitstream
From: Neil Steiner <neil.steiner@vt.edu>
Date: Tue, 23 Jan 2007 16:12:56 -0500
Links: << >>  << T >>  << A >>
My bad.  I was trying to respond to Jon Elson.

Article: 114742
Subject: Re: FPGA damage from bad bitstream
From: Neil Steiner <neil.steiner@vt.edu>
Date: Tue, 23 Jan 2007 16:16:38 -0500
Links: << >>  << T >>  << A >>
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
Subject: Re: FPGA damage from bad bitstream
From: Neil Steiner <neil.steiner@vt.edu>
Date: Tue, 23 Jan 2007 16:18:15 -0500
Links: << >>  << T >>  << A >>
Oh, I get it.  I just don't know how to use my news reader.

Article: 114744
Subject: Re: ABEL to VHDL translate
From: "Thomas W." <Thomas_W_@gmx.de>
Date: Tue, 23 Jan 2007 22:37:19 +0100
Links: << >>  << T >>  << A >>
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.

Thomas

Article: 114745
Subject: Re: ABEL to VHDL translate
From: Thomas Wesenberg <no@spam.de>
Date: Tue, 23 Jan 2007 22:45:13 +0100
Links: << >>  << T >>  << A >>
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.

Thomas

Article: 114746
Subject: Re: FPGA damage from bad bitstream
From: "jbnote" <jbnote@gmail.com>
Date: 23 Jan 2007 13:49:44 -0800
Links: << >>  << T >>  << A >>
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 ?

JB


Article: 114747
Subject: Re: Xilinx ISE 8.2
From: "bgshea" <bgshea@gmail.com>
Date: 23 Jan 2007 13:56:52 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: Xilinx ISE 8.2
From: "jbnote" <jbnote@gmail.com>
Date: 23 Jan 2007 13:57:02 -0800
Links: << >>  << T >>  << A >>

> 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.

JB


Article: 114749
Subject: Re: NIOS II Application startup issues
From: "KJ" <kkjennings@sbcglobal.net>
Date: Tue, 23 Jan 2007 21:57:09 GMT
Links: << >>  << T >>  << A >>

"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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search