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 108350

Article: 108350
Subject: Re: Performance Appraisals
From: David Ashley <dash@nowhere.net.dont.email.me>
Date: 8 Sep 2006 18:52:41 +0200
Links: << >>  << T >>  << A >>
Michael A. Terrell wrote:
>    It was either do the work or be fired.  I didn't do it to help him,
> in any way.  I needed the job, because there was nothing else available
> in my field at the time.  The only open job I could find was chief
> engineer at WRGT TV, Ch 45 in Dayton, Ohio which was an even longer
> drive.  They were only offering minimum wage for a 40 hour a week
> salary, and you would be on call 24/7.  They also demanded that I live
> no more than 2 miles from the studio and transmitter sites which didn't
> have any reasonably priced homes.  Would you take a loss on the sale of
> your home and buy one at five times the price, while taking a 70% cut in
> pay?  I couldn't, and I didn't.  I just suffered though another of his
> messes, and made a lot in overtime.

Hopefully it'll even out. The higher ups will probably be aware of the
extra overtime they needed to spend to solve this problem. Ideally
they'll know who to blame for the problem.

Often if you care for the overall health of the company, you need to
solve a crisis and in so doing bail out some incompetent.
C'est la vie.

-Dave



-- 
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture

Article: 108351
Subject: Re: Why No Process Shrink On Prior FPGA Devices ?
From: "jacko" <jackokring@gmail.com>
Date: 8 Sep 2006 10:04:19 -0700
Links: << >>  << T >>  << A >>
hi

i was thinking hardwired reset of device sets up via reset and set as a
i2c microprocessor, which serial loads from something like a 256Kbit
(or larger)
24AA256/24LC256/24FC256 EEPROM.

after the load, the circuit is clocked in to configure the fpga, and it
provides automatic on chip i2c interface. which along with a few fast
comparator inputs, and some RAM blocks, LUTS and a few mul blocks would
be a nice two chip solution for many applications.

having a manufacturer specific load up chip with resulting larger area
may not be good for an efficient bootstrap, and you loose the option to
have user code and data in the EEPROM, and a high level macro
specification of the logic interconnect.

having such a low cost standard boot would be a boon for fpga demand.

cheers.

p.s. don't forget the electron bolus on chip which extracts power
potential from inward spiral corriolis acceleration of high mobility
electrons in n-type spiral, using substrate zener effect for voltage
stabilization. (They work better when smaller)


Article: 108352
Subject: Re: Why No Process Shrink On Prior FPGA Devices ?
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 08 Sep 2006 10:26:04 -0700
Links: << >>  << T >>  << A >>
David,

http://www.itrs.net/

It is a bit hard to swallow, but if you really are interested, you have
to read their entire plan (conspiracy theory is a good analogy -- it
really is a plain in view world wide conspiracy!).

And, not just Xilinx must follow:  the equipment Intel, ST Micro, TI,
IBM, UMC, TSMC, etc all buy comes from the same "roadmap."

If it isn't in the roadmap, well, it has no support, and eventually, it
will not exist.

Now, that may be too harsh, as some technology variants (such as 3-D
circuits, a la Matrix Semi, purchased by SanDisk) did make use of the
existing roadmap, with some minor tweaks.  Even there, is this
profitable?  The jury is still out.

As for what to invest in?  Wow.  As an engineer I made a rule for
myself:  let someone else do the investing!  My judgment in that regard
has been proven to be absolutely TERRIBLE.  Any engineer who thinks they
are a good investor, I haven't seen one yet!  It is hard enough to stay
current and be an expert in what I am supposed to be an expert in, let
alone deciding to be an expert in something unrelated.

Good luck,

Austin

Article: 108353
Subject: Re: Performance Appraisals
From: "Michael A. Terrell" <mike.terrell@earthlink.net>
Date: Fri, 08 Sep 2006 17:28:24 GMT
Links: << >>  << T >>  << A >>
David Ashley wrote:
> 
> Michael A. Terrell wrote:
> >    It was either do the work or be fired.  I didn't do it to help him,
> > in any way.  I needed the job, because there was nothing else available
> > in my field at the time.  The only open job I could find was chief
> > engineer at WRGT TV, Ch 45 in Dayton, Ohio which was an even longer
> > drive.  They were only offering minimum wage for a 40 hour a week
> > salary, and you would be on call 24/7.  They also demanded that I live
> > no more than 2 miles from the studio and transmitter sites which didn't
> > have any reasonably priced homes.  Would you take a loss on the sale of
> > your home and buy one at five times the price, while taking a 70% cut in
> > pay?  I couldn't, and I didn't.  I just suffered though another of his
> > messes, and made a lot in overtime.
> 
> Hopefully it'll even out. The higher ups will probably be aware of the
> extra overtime they needed to spend to solve this problem. Ideally
> they'll know who to blame for the problem.
> 
> Often if you care for the overall health of the company, you need to
> solve a crisis and in so doing bail out some incompetent.
> C'est la vie.
> 
> -Dave
> 
> --
> David Ashley                http://www.xdr.com/dash
> Embedded linux, device drivers, system architecture


   That was 20 years ago, and Ernie was forced to quit over sexual
harassment charges, filed by then current and former female employees.

   I always worked my ass off at any job.  The big bosses weren't
stupid.  When major problems go away right after someone new is hired,
they know it's not a long term employee who suddenly started working
harder, smarter, or both.  After the sudden changes the owner came for a
visit to see what had happened.  Of course, Ernie tried to take the
credit. The owner turned to me and said, Great!  Now tell me exactly
what you did to fix the problems Ernie couldn't.  I described what I had
done to take us from the lowest customer service rated CATV system in
the area, to the number one in under six months.  Ernie was quite
pissed!


-- 
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida

Article: 108354
Subject: Re: Virtex4FX12 and Spartan3 lead time
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 08 Sep 2006 10:41:11 -0700
Links: << >>  << T >>  << A >>
Antti,

I am sure that there are those who try to make money by buying and
selling (called "horse traders" in English).  And I am sure that they
are a headache for just about anyone who is trying to meet all their
obligations, warranties, etc. as a supplier.  Even more of a headache if
you are trying to buy from one.

As for what is legal, and what is not, I will leave that to the lawyers
(as it varies by country, region, etc.).  I am not a lawyer.

My only point was that if someone did find a source of Xilinx FPGAs, not
through an authorized distributor, the "worst" that can happen is that
they get bogus parts.  The best that can happen, is that they really are
as marked, and they work.

Our only concern is that if someone wants to send one back on an RMA for
analysis and replacement, they will get a "gee, you have been had" if it
turns out to be a part from someone else, with its markings sanded off,
and counterfeit Xilinx markings painted on...(something I have seen!).
If it is our part, but it has passed out of the authorized chain of
control (we do check on RMAs), then we can not honor the warranty.
'Pop-corn' packages are often the result of mis-handling as I described,
and we are not going to replace the parts under warranty!

Austin

Article: 108355
Subject: Re: Virtex4FX12 and Spartan3 lead time
From: "Antti" <Antti.Lukats@xilant.com>
Date: 8 Sep 2006 10:56:02 -0700
Links: << >>  << T >>  << A >>
Austin Lesea schrieb:

> Antti,
>
> I am sure that there are those who try to make money by buying and
> selling (called "horse traders" in English).  And I am sure that they
> are a headache for just about anyone who is trying to meet all their
> obligations, warranties, etc. as a supplier.  Even more of a headache if
> you are trying to buy from one.
>
> As for what is legal, and what is not, I will leave that to the lawyers
> (as it varies by country, region, etc.).  I am not a lawyer.
>
> My only point was that if someone did find a source of Xilinx FPGAs, not
> through an authorized distributor, the "worst" that can happen is that
> they get bogus parts.  The best that can happen, is that they really are
> as marked, and they work.
>
> Our only concern is that if someone wants to send one back on an RMA for
> analysis and replacement, they will get a "gee, you have been had" if it
> turns out to be a part from someone else, with its markings sanded off,
> and counterfeit Xilinx markings painted on...(something I have seen!).
> If it is our part, but it has passed out of the authorized chain of
> control (we do check on RMAs), then we can not honor the warranty.
> 'Pop-corn' packages are often the result of mis-handling as I described,
> and we are not going to replace the parts under warranty!
>
> Austin

so PLEASE PLEASE open up again online shop :)
for those who are in a hurry to get prototypes done!

Antti


Article: 108356
Subject: Re: microblaze programm doesn't fit into bram...
From: Siva Velusamy <siva.velusamy@xilinx.com>
Date: Fri, 08 Sep 2006 11:01:09 -0700
Links: << >>  << T >>  << A >>
> 
> Analyzing file TestApp_Peripheral/executable.elf...
> WARNING:MDT - Elf file TestApp_Peripheral/executable.elf does not
> reside
>    completely within BRAM memory of processor microblaze_0.
> WARNING:MDT - The sections of  ELF residing outside BRAMs must be
> initialized
>    separately using a debugger, a bootloader, or an ACE file
> INFO:MDT - BRAM lmb_bram will be initialized with ELF of processor
> microblaze_0

This means that your program is bigger than the amount of BRAM you have. 
So you have store your program in external memory. TestApp_Peripheral is 
usually bigger than TestApp_Memory, so it is not surprising that one fit 
into BRAM while the other doesn't.

To fix this you should create a design with external memory, and 
generate a linker script where you say that all sections reside in 
external memory. Then download the program to external memory and run.

For how to use ethernet, take a look at some of the examples here:

http://www.xilinx.com/ise/embedded/edk_examples.htm

-Siva

Article: 108357
Subject: Re: Why No Process Shrink On Prior FPGA Devices ?
From: Kolja Sulimma <news@sulimma.de>
Date: Fri, 08 Sep 2006 20:59:34 +0200
Links: << >>  << T >>  << A >>
Austin Lesea schrieb:

> And, not just Xilinx must follow:  the equipment Intel, ST Micro, TI,
> IBM, UMC, TSMC, etc all buy comes from the same "roadmap."

Actually the semiconductor roadmap is the best example of a
selffulfilling prophecy that I ever encountered.
It is a widely accepted estimate of how fast semiconductor technology
will progress.

The cost with semicon manufacturing is almost completely in R&D and
building the fab and the livetime of a technology node is very short.
This means that progressing faster than the competitors is EXTREMELY
expensive. For beeing faster you need more R&D and at the same time you
have less time to pay for the R&D of your previous technology.

On the other hand, beeing slower than you competitors can also be very
expensive because the same chip can be manufactured cheaper in the newer
technolgy and at the same time will be faster.

This situation is similar for many technologies, and technology progress
will vary from company to company because nobody knows the speed of the
competitors. But for semicon the costs are extreme, and there is this
convenient roadmap that everybody seems to have agreed on.
For that reason semiconductor progress is more or less in sync between
all manufacturers.


Kolja Sulimma

Article: 108358
Subject: Re: ddr with multiple users
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 8 Sep 2006 12:37:02 -0700
Links: << >>  << T >>  << A >>
David Ashley wrote:
> KJ wrote:
> >>Would be workable/advisable to instead just have each device
> >>control the ddr itself, and use the ddr's own interface directly?
> >>
> >
> > Probably not.  Arbitration by nature needs 'global' knowledge of the scope
> > of what it is arbitrating in order to be effective:  Some things needed are
> > - It needs to know about the 4 (or however many) users
> > - Preferred burst sizes for each port
> > - How long the other ports should wait while they're waiting for their turn
> > (i.e. how important is latency).
> > - Arbitration scheme (round robin, etc.)
> > KJ
>
> The arbitration is separate from the interface.
We may not be meaning the same thing when we say 'interface'.  In your
example, you have four 'users' who need to share a common resource, the
DDR.  Maybe you're seeing this as all one 'interface' but in reality it
consists of several of what I would call 'interfaces'.  One way to
approach this problem would be to use a single DDR controller code and
arbitrate access to the input.  In that scenario you would have 11
interfaces:

#1-4 are the individual master interfaces out of each of the four
'users'.
#5-8 are the individual slave interfaces that are single, individual
targets of #1-4.
#9 is a single master interface that connects to #10.
#10 is the slave side interface of a DDR controller code.
#11 is the master side interface from your DDR controller that is
intended to hook up to the actual DDR itself.

The task then would be to...
- Implement the function Arb() performs the translation from interfaces
#5-8 to create #9.
- Connect up all of what are now point to point connections.

Now, there is some function that I'll call f() that implements whatever
is necessary to go from interface #10 to interface #11.  Presumably
this is simply the OpenCores DDR controller or some other commercial
controller.  In any case, those cores all fit the basic interface
structure that I've defined above to get from #10 to #11.  They don't
fit mapping more than one input to the DDR directly.

What I thought you were suggesting is that you take this function f()
and replicate it 4 times and then add the arbitration between the
outputs of those four f() functions before applying it to the physical
DDR and putting this code in with the four users.

You could implement it this way, but if you do I'm confident that
you'll be chewing up many more logic resources than you would if you
instead focused on creating the arbitration function Arb() which
performs the magic to connect interfaces #5-8 to interface #9.

> Wishbone probably already
> has an arbitor capability built in, I'd guess.

Guess again.  Wishbone is strictly a point to point interface.  By that
I mean that it simply defines the signals to/from the master, the
signals to/from the slave and how those signals accomplish data
transfer.  The logic for multiple masters off a slave or multiple
slaves off of a master is outside of the Wishbone specification.

What Wishbone brings to the table is a common interface.  This is handy
since by my definition of 'interface' that are 11 of them in
play...with the exception of #11, all can be Wishbone or any other
standard you want to code to.  Wishbone doesn't bring a lot of baggage
so that IF you need to have multiple masters/slaves that you don't have
cumbersome extra logic.  Altera's 'Avalon' and OpenCores 'SimpCon'
interfaces are all similar in that regard.  They are all point to point
but can be used in a multi-master/multi-target system quite easily.

My point was that, viewed in this light, the arbitration function which
connects #5-8 to #9 can be both somewhat generic (i.e. could be used to
arbitrate other devices besides DDR) and yet still be parameterized to
handle the pecularities for your particular application (i.e. bursting
whenever possible to DDR).

<snip>
> Actually the arbitration logic is not really *in* the chain, it just
> selectively allows the USER to access the next stage on the other
> side.
Again, considering what I consider to be an 'interface' puts this
directly into the chain.  If you go the route of implementing multiple
f() functions inside the four users you still end up with the same 11
interfaces but now some of them are buried inside each of the four
users so they are only going away in the sense that you're drawing the
border line around a slightly bigger area.  Now you would have four
'users' that do not have native Wishbone interfaces but instead have a
native DDR interface that then needs to be arbitrated and translated
into the same final output interface to the DDR.

>
> It's critical that bursts be handled well. DDR effectively has a minimum
> burst of 2, and the 2 addresses are always at A and A+1. Probably A
> is even also, but I don't remember at the moment.
>
> Also a burst within DDR can't cross a row. Then there is arbitrary
> CAS latency.
>
> Wishbone supports bursting, but there probably aren't any restrictions.
> That is, bursts probably don't need to start on an even address, and
> they don't have to end before they cross some arbitrary boundary.
>
Still using the approach that I suggested, all of that can be handled
with the Arb() function as well.

> But I can easily make the 4 users of the DDR work within the DDR's
> limitations.
At the expense of now making those 4 users tuned specifically to the
nuances of DDR.  If you migrate this to some other memory technology
then you have to retune each of these four for the new nuances of that
memory.

> With the wishbone approach I get a generic piece of logic I can reuse
> with other DDR's. But at what cost?
Good question.  I can't really give details, but I'll say that I've
implemented the approach that I mentioned for interfacing six masters
to DDR and the logic resources consumed were less than but roughly
comparable to that consumed by a single DDR controller.  I had all the
same issues that you're aware of regarding how you need to properly
control DDR to get good performance and all.

The Arb() function that I implemented is also paramterized so that I
could use it to interface effectively with a PCI bridge as well without
changing any code (only the parameter settings when instantiating the
entity).

>
> Complications:
> 1) To support bursting, it needs to have some sort of fifo. An easy way
> would be the core stores up the whole burst, then transacts it to the
> DDR when all is known.
I'd suggest keeping along that train of thought as you go forward but
keep refining it.

> But to reduce latency, the DDR transaction
> probably ought to start while the USER is still pushing data into the
> wishbone interface. The whole goal is to get as close to 2 memory
> accesses per clock, since that's what DDR supports.
Here is where Wishbone lets you down a bit.  There was a discussion on
this newsgroup called 'JOP on Avalon' or something like that.  It was
primarily between myself and two others where we discussed the relative
merits of Wishbone, Avalon and SimpCon.  You might want to peruse that
a bit since with Wishbone you have to go a bit outside of the normal
spec by using what Wishbone calls 'tags' to get the full performance on
the DDR.  It's not really violating Wishbone, it's just not built into
it as cleanly as it is with Avalon or (from my limited knowledge of)
SimpCon.  The issue is that 'tags' are not required to be implemented
in any specific way but Wishbone has sort of set aside a particular way
of tagging that will help you get the full performance.

The key in any of this though is the realization that the address phase
and the data phase of any transaction are independent.  A master device
can initiate a second command on the address bus even before the first
has completed.  Even if you're not considering Altera's Avalon as a bus
for your design, their documentation of that bus and how those two
phases of a bus cycle are treated is very good and worth the read.  Pay
attention to the section regarding 'slave side read latency' and then
compare that to Wishbone.  It's good reading and may give you a
somewhat different perspective and can certainly help with this
arbitration function even if you don't implement using Avalon.

>
> 2) The wishbone core must deal with page crossing bursts somehow.
Nope, that's up to the arbitrator...if it has been given the knowledge
of the concept of 'bursts' and further parameterized by 'burst sizes'
and 'address boundaries'.

> This would mean breaking up a burst into 2 ddr bursts. Otherwise
> if I impose address/burst restrictions on the wishbone core, it's
> not 100% compliant, I'd expect.
Shouldn't need to go that way though....crossing a page boundary should
at worst cause wait states on the user's master side if it is hammering
memory.  If the user is lightly touching it then it shouldn't even
cause that.

>
> The disadvantages of involving wishbone are
> 1) More complicated, more work, later time to market
> 2) Almost certainly will introduce latency in pipeline
> 3) To implement, I've got to learn wishbone AND ddr,
> as opposed to just ddr now and perhaps wishbone at
> a later date.
>
> The advantages are
> 1) Single logic driving DDR pins, so supposedly clock timing can
> be met easier.
> 2) More general for code reuse, since lots of things already
> support wishbone.
>
It will probably consume more logic resources your way which could
impact price.

>
> Also of note that the end result of all this is a system meant
> to be released as open source. That's why if I were going to
> use wishbone I'd feel compelled to do it right.
Guess I'm confused a bit.  If it's needs to be 'open source' than it
would seem that standarding on Wishbone would be a good thing and
having tuned the 'users' to a DDR interface would be less flexible.
This might be just a case of where you draw the boundary around the
'box'.  Maybe from the perspective of someone using your widget they
don't care directly about 'user1'...'user4' just that there are 4 of
them and they can all talk to DDR and whether or not you use a standard
interface to implement them is about as relevant as whether you code
your state machines in the 'two process' template or the 'one process'
template.

What I've found though is that using a logically complete handshaking
protocol does not impose much if any extraneous logic resource usage,
and using that protocol even on internal interfaces that nobody really
cares about is actually an aid in getting everything debugged and
workng properly with the added benefit being that other people can more
readily understand those internal interfaces (if needed) since it
conforms to an established protocol.

>
> Anyway it still isn't clear to me the wishbone approach is
> automatically right for this particular application.
>
It may not be given your particular constraints.

> Thanks for everyone's input on this so far.
> 
You're welcome.  Good luck on your design

KJ


Article: 108359
Subject: Re: Altera CPLD 7128S heating up
From: John <bogus@bogus.ema>
Date: Fri, 08 Sep 2006 19:44:13 GMT
Links: << >>  << T >>  << A >>
Hi,

In article <45007526$0$21146$7a628cd7@news.club-internet.fr>, 
jfhasson@club-internet.fr says...
> Hi,
> 
> I work on a board with an Altera 7128S part (5V quite old but still used 
> ...). It seems the part is most of the time working just fine but 
> depending on when it is powered on it overheats a lot and does not seem 
> to be well configured : an input acts as an output, and the component is 
> not working fine at all. Does anyone havea clue as to what could be 
> going wrong ? It does not happen all the time.

I read some errata from Altera's site about a MAX3k family.  I had a 
MAX3128 do something like what you're experiencing -- it was a power 
sequencing issue.

As someone else suggested, check the power sequence and perhaps avoid 
driving the 7128S's inputs if it's not fully up yet.

John.

Article: 108360
Subject: Re: ddr with multiple users
From: "jacko" <jackokring@gmail.com>
Date: 8 Sep 2006 13:38:41 -0700
Links: << >>  << T >>  << A >>
hi

in/out busses: low-master, high-master, bottleneck-chain

and you would need three instances.

cheers


Article: 108361
Subject: Re: Why No Process Shrink On Prior FPGA Devices ?
From: "Peter Alfke" <peter@xilinx.com>
Date: 8 Sep 2006 13:51:58 -0700
Links: << >>  << T >>  << A >>
I agree with Kolja and Austin: technology moves ahead synchronously and
on rails, and everybody has access to the same technology.
That makes creative architecture and circuit design an ever more
important distinction between us competitors... Long live creative
ideas, for they are not shackled by the roadmap!
Peter Alfke, Xilinx
==========================
Kolja Sulimma wrote:
> Austin Lesea schrieb:
>
> > And, not just Xilinx must follow:  the equipment Intel, ST Micro, TI,
> > IBM, UMC, TSMC, etc all buy comes from the same "roadmap."
>
> Actually the semiconductor roadmap is the best example of a
> selffulfilling prophecy that I ever encountered.
> It is a widely accepted estimate of how fast semiconductor technology
> will progress.
>
> The cost with semicon manufacturing is almost completely in R&D and
> building the fab and the livetime of a technology node is very short.
> This means that progressing faster than the competitors is EXTREMELY
> expensive. For beeing faster you need more R&D and at the same time you
> have less time to pay for the R&D of your previous technology.
>
> On the other hand, beeing slower than you competitors can also be very
> expensive because the same chip can be manufactured cheaper in the newer
> technolgy and at the same time will be faster.
>
> This situation is similar for many technologies, and technology progress
> will vary from company to company because nobody knows the speed of the
> competitors. But for semicon the costs are extreme, and there is this
> convenient roadmap that everybody seems to have agreed on.
> For that reason semiconductor progress is more or less in sync between
> all manufacturers.
> 
> 
> Kolja Sulimma


Article: 108362
Subject: Re: Negative slack
From: "KJ" <kkjennings@sbcglobal.net>
Date: Fri, 08 Sep 2006 22:39:18 GMT
Links: << >>  << T >>  << A >>

<dhruvakshad@gmail.com> wrote in message 
news:1157728453.205266.321290@d34g2000cwd.googlegroups.com...
>I am using virtes II pro pci card .The card has a pci bridge with a bus
> linking processor in the bridge to the fpga. The constraints on the
> processor bus signals were givent by the vendor. My design gives me a
> negative slack on 2 of the signals on the processor bus.  Will this
> affect the design ? I am doing dma from the fpga to the host RAM along
> the bus. The transfer rate is low.
> I was googling for links to read on negative slacks but could not find
> good ones for a starter.

Not knowing what tool you're using that is reporting the slack makes it 
impossible to be certain but the basic defintion of  'slack is roughly....

'Slack' is the amount of time you have that is measured from when an event 
'actually happens' and when it 'must happen' .. The term 'actually happens' 
can also be taken as being a predicted time for when the event will 
'actually happen'.

When something 'must happen' can also be called a 'deadline' so another 
defintion of slack would be the time from when something 'actually happens' 
(call this Tact) until the deadline (call this Tdead).

Slack = Tdead - Tact.

Negative slack implies that the 'actually happen' time is later than the 
'deadlin' time...in other words it's too late and a timing violation....you 
have a timing problem that needs some attention.

KJ 



Article: 108363
Subject: Can a FPGA work like a microprocessor ?
From: "Srinu" <sinu.nayak2001@gmail.com>
Date: 8 Sep 2006 21:31:14 -0700
Links: << >>  << T >>  << A >>
Hi all, can a FPGA work like a microprocessor ? If yes upto what extent
? Please suggest.


Article: 108364
Subject: Anyone who have succeeded with BPI configuration on the Spartan-3E Starter Kit
From: jorgen.gade@gmail.com
Date: 9 Sep 2006 01:33:36 -0700
Links: << >>  << T >>  << A >>
Hi!

I've tried to explore the BPI (Byte Peripheral Interface) configuration
mode on the Spartan-3E starter kit without success.

I've followed the "EDK Flashwriter.ppt" I got from Xilinx and I've
managed to burn uClinux images and bin-files anywhere I want in the
StrataFlash, but my Spartan-3E Starter boards (rev c) never configure
themselves from the Intel StrataFlash device:

- I have strapped MODE(2:0) to "010" (BPI/UP) as well as "011"
(BPI/DOWN).
- I have stored my BIN-files generated from my bit-files with the
"promgen -p bin -c FF -o output.bin -u 0x0 input.bit" and "promgen -p
bin -c FF -o output.bin -d 0xFFFFF input.bit" commands at offset 0x2000
(BPI/UP) as well as offset 0xFBAA9F (BPI/DOWN) in the StrataFlash.
- When I configure the FPGA with bit-files via JTAG the MicroBlaze
starts executing the bootloader application from internal BRAM, moving
the uClinux image from the StrataFlash to the DDR SDRAM and then starts
to execute from there, but this never succeeds with my design stored in
StrataFlash.

There is a small CPLD (XC2C64) on the board connected to XC-A(23:20),
XC-DONE, etc.
I believe this device has to drive A(24:20) high or low during FPGA
configuration in order to have the FPGA fetch the bitstream from the
top/bottom of the StrataFlash. I don't have access to sourcecode for
this CPLD, but obviously have relied on it to do it's job. I guess that
the question is if it does so on a std revC Spartan-3E Starter board?

I've read the S3E/StrataFlash article
(http://www.xilinx.com/publications/xcellonline/xcell_54/xc_pdf/xc_strata54.pdf)
and compared to the Spartan-3E Starter schematics:
It appears as if the S3E-kit has too weak pulldown (4.7 kohm instead of
340 ohm) on the LDC2 signal so that the StrataFlash might not have time
to swap between *16 mode to *8 mode (takes up to 1000 ns) before the
S3E starts to fetch data from it. However both workaround #2 and #3
ought to make sure that the FPGA configures once it finds the right
"initialization sequence".

Regarding the configrate setting I haven't changed it since I believe
that the default configrate=6 => 1,5 MHz should be ok with the 110 -
150 ns accesstime of the StrataFlash.

I guess that offset 0x2000 and 0xFBAA9F applies for XC3S500E devices.
What offset values applies for XC3S1200E and XC3S1600E devices ..... or
can I use almost any offset in the StrataFlash since an S3E-device in
BPI-mode will search the StrataFlash until it finds the right
"initialization sequence" and then successfully configure from there?


The board:
http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=HW-SPAR3E-SK-US

I'm using EDK8.2i (SP1) and ISE8.2i (SP2) and Rev C boards.

Please help.


Article: 108365
Subject: Re: Can a FPGA work like a microprocessor ?
From: "John Adair" <g1@enterpoint.co.uk>
Date: 9 Sep 2006 01:40:42 -0700
Links: << >>  << T >>  << A >>
Some FPGA's like the Xilinx Virtex-4 (FX - PowerPC) come with a
hard(always there) processor within the programmable fabric. There are
also soft core microprocessors that use the general FPGA fabric for
their implementation like MicroBlaze.

In both cases the microprocessor cores generally can do what their
standalone equivalents can do. The difference comes in that unused FPGA
fabric can be used to implement the any digitial function or interface
you like within the bounds of the device size and speed. Some
interfaces will need external buffering depending on the voltage levels
e.g. a transceiver for CAN bus.

The one weak area is replacing a microcontroller that has analogue
interfaces. Currently there is virtually no analogue support in FPGA's
so any analogue functions like A to D tend to need add on devices.

John Adair
Enterpoint Ltd.

Srinu wrote:
> Hi all, can a FPGA work like a microprocessor ? If yes upto what extent
> ? Please suggest.


Article: 108366
Subject: FPGA Devices' stability and process parameters
From: "alterauser" <fpgaengineerfrankfurt@arcor.de>
Date: 9 Sep 2006 02:52:31 -0700
Links: << >>  << T >>  << A >>
I found the discussion "Why No Process Shrink On Prior FPGA Devices"
interesting and would like to add some words regarding working
stability of devices with shrinked geometry:

Beeing a consultant engineer, I work for various companies and in
different fields of application and thus often come across problems
with modern devices like RAM, FPGA and MCUs regarding their stability:
One can observe that smaller process geometrie quickly leads to a lower
tolerance against beam- and radiation influences, causing e.g. EMC
problems. Therefore, some companies have to spend much time and money
in searching for devices which are resistant enough to meet their
requirements. Doing so, "older" families of devices with a larger
scaling are sometimes prefered!

Do we run into problems when continously shrinking technologie and
finally remove older devices (her maybe FPGAs) from the market ?


Article: 108367
Subject: simplyrisc-s1 free core
From: Jan Panteltje <pNaonStpealmtje@yahoo.com>
Date: Sat, 09 Sep 2006 11:45:42 GMT
Links: << >>  << T >>  << A >>
Free S1 core with Linux tools (gcc) emu runs on iverilog:
 http://www.srisc.com/?s1
This is a RISC with 64 bit address and data bus, and Wishbone intereface.

Have not tried it, may be of interst to some here.

<quote>
The OpenSPARC T1 microprocessor (codename Niagara) features 8 SPARC CPU
Cores and several peripherals; the S1 Core takes only one 64-bit SPARC Core
from that design and adds a Wishbone bridge, a reset controller and a basic
interrupt controller, to make it easy for a system engineer to integrate the
design.
<end quote>


Article: 108368
Subject: Re: Virtex4FX12 and Spartan3 lead time
From: nico@puntnl.niks (Nico Coesel)
Date: Sat, 09 Sep 2006 13:05:16 GMT
Links: << >>  << T >>  << A >>
"Antti" <Antti.Lukats@xilant.com> wrote:

>Austin Lesea schrieb:
>
>> Antti,
>>
>> I am sure that there are those who try to make money by buying and
>> selling (called "horse traders" in English).  And I am sure that they
>> are a headache for just about anyone who is trying to meet all their
>> obligations, warranties, etc. as a supplier.  Even more of a headache if
>> you are trying to buy from one.
>>
>> As for what is legal, and what is not, I will leave that to the lawyers
>> (as it varies by country, region, etc.).  I am not a lawyer.
>>
>> My only point was that if someone did find a source of Xilinx FPGAs, not
>> through an authorized distributor, the "worst" that can happen is that
>> they get bogus parts.  The best that can happen, is that they really are
>> as marked, and they work.
>>
>> Our only concern is that if someone wants to send one back on an RMA for
>> analysis and replacement, they will get a "gee, you have been had" if it
>> turns out to be a part from someone else, with its markings sanded off,
>> and counterfeit Xilinx markings painted on...(something I have seen!).
>> If it is our part, but it has passed out of the authorized chain of
>> control (we do check on RMAs), then we can not honor the warranty.
>> 'Pop-corn' packages are often the result of mis-handling as I described,
>> and we are not going to replace the parts under warranty!
>>
>> Austin
>
>so PLEASE PLEASE open up again online shop :)
>for those who are in a hurry to get prototypes done!

It would be even better if Xilinx would supply all of their devices
through distributors like Farnell, Digikey, etc, etc, etc. I prefer to
buy from these type of companies (one stop shopping) or manufacturors
directly. Distributors usually aren't any cheaper when you buy large
quantities.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 108369
Subject: Re: Virtex4FX12 and Spartan3 lead time
From: "John Adair" <g1@enterpoint.co.uk>
Date: 9 Sep 2006 07:14:22 -0700
Links: << >>  << T >>  << A >>
Digikey do have some Virtex-4 and Spartan-3. They are even a reasonable
place to buy Platform Flash.

There are a number of grey market suppliers. We get them regularly
trying to sell to us but do take heed of Austin's comments in the
previous post.

As to legal the biggest problem is actually export control regarding
onward shipping. This is especially true if you are a company that
either is US based or has subsiduary within US control. If you fall
foul of EAR (someone please  in the exact words) there can be very
severe finacial penalties and I believe even jail for office holders.
Not supplying to the wrong persion or organisation does take some
sorting out. There is a document, in very small text and 500 pages or
so, of names of people and organisations that are deemed dubious to
supply anything to.

John Adair
Enterpoint Ltd.

Nico Coesel wrote:
> "Antti" <Antti.Lukats@xilant.com> wrote:
>
> >Austin Lesea schrieb:
> >
> >> Antti,
> >>
> >> I am sure that there are those who try to make money by buying and
> >> selling (called "horse traders" in English).  And I am sure that they
> >> are a headache for just about anyone who is trying to meet all their
> >> obligations, warranties, etc. as a supplier.  Even more of a headache if
> >> you are trying to buy from one.
> >>
> >> As for what is legal, and what is not, I will leave that to the lawyers
> >> (as it varies by country, region, etc.).  I am not a lawyer.
> >>
> >> My only point was that if someone did find a source of Xilinx FPGAs, not
> >> through an authorized distributor, the "worst" that can happen is that
> >> they get bogus parts.  The best that can happen, is that they really are
> >> as marked, and they work.
> >>
> >> Our only concern is that if someone wants to send one back on an RMA for
> >> analysis and replacement, they will get a "gee, you have been had" if it
> >> turns out to be a part from someone else, with its markings sanded off,
> >> and counterfeit Xilinx markings painted on...(something I have seen!).
> >> If it is our part, but it has passed out of the authorized chain of
> >> control (we do check on RMAs), then we can not honor the warranty.
> >> 'Pop-corn' packages are often the result of mis-handling as I described,
> >> and we are not going to replace the parts under warranty!
> >>
> >> Austin
> >
> >so PLEASE PLEASE open up again online shop :)
> >for those who are in a hurry to get prototypes done!
>
> It would be even better if Xilinx would supply all of their devices
> through distributors like Farnell, Digikey, etc, etc, etc. I prefer to
> buy from these type of companies (one stop shopping) or manufacturors
> directly. Distributors usually aren't any cheaper when you buy large
> quantities.
>
> --
> Reply to nico@nctdevpuntnl (punt=.)
> Bedrijven en winkels vindt U op www.adresboekje.nl


Article: 108370
Subject: Re: Can a FPGA work like a microprocessor ?
From: Austin Lesea <austin@xilinx.com>
Date: Sat, 09 Sep 2006 09:09:11 -0700
Links: << >>  << T >>  << A >>
Further,

The hard IBM 405 PowerPC in Virtex II Pro, and Virtex 4 is optimized for 
low power, not for high speed.  Generally speaking, the FPGA will get 
hot from doing all of the other things it needs to do, that having a uP 
on the same die requires that uP to be low power, not super high speed.

The soft uP (PicoBlaze, MicroBlaze) which is a uP optimized to be built 
from the fabric of the Xilinx architectures is optimized for area, and 
speed.  But the area may be reasonably small, the the performance is 
perhaps 4 or 5 times slower than the hard processor, and many times 
slower than a speed optimized uP in its own package.

Regardless, since the 405 PowerPC exisits as up to two cores in a single 
part, and you may stuff as many PicoBlazes, or MicroBlazes as will fit 
in a part, the need for performance or speed may be addressed by 
multiprocessing.

However, if there is something needed to be done fast, then use of the 
raw gates to implement a massively parallel logic solution is superior. 
  For example, a uP DSP program may be able to execute 100 times faster 
in logic, as opposed to on the uP.  Interfacing to the uP is done with 
the  auxiliary processor unit interface (build your own coprocessor to 
do exactly what you need) on the Virtex 4 FX parts.  In the earlier 
parts, the hardened functions can be added to the interface buses (but 
are not as fast as the APU bus).

Generally speaking, if a uP solves the problem, then it is unlikely you 
would consider a FPGA.  The reason to use a uP in a FPGA must have some 
other justification.  For example, an automotive electronics supplier 
decided that providing maintenance for a new uP every year (that is 
subsequently obsoleted in less than 5 years) was far more expensive 
thaqn using an entirely soft uP solution in a Spartan device.  Speed is 
no issue, cost is no issue (in fact the Spartan device soft processor 
combined with other functions they required was similar in per socket 
cost).  This way the design is in HDL and c code, and can be ported to 
any new FPGA.  And we also maintain a supply for our components for much 
much longer than the merchant uP industry.

We have supplied components for 20 years before last time buy notices.

Austin

Austin

John Adair wrote:

> Some FPGA's like the Xilinx Virtex-4 (FX - PowerPC) come with a
> hard(always there) processor within the programmable fabric. There are
> also soft core microprocessors that use the general FPGA fabric for
> their implementation like MicroBlaze.
> 
> In both cases the microprocessor cores generally can do what their
> standalone equivalents can do. The difference comes in that unused FPGA
> fabric can be used to implement the any digitial function or interface
> you like within the bounds of the device size and speed. Some
> interfaces will need external buffering depending on the voltage levels
> e.g. a transceiver for CAN bus.
> 
> The one weak area is replacing a microcontroller that has analogue
> interfaces. Currently there is virtually no analogue support in FPGA's
> so any analogue functions like A to D tend to need add on devices.
> 
> John Adair
> Enterpoint Ltd.
> 
> Srinu wrote:
> 
>>Hi all, can a FPGA work like a microprocessor ? If yes upto what extent
>>? Please suggest.
> 
> 

Article: 108371
Subject: Re: FPGA Devices' stability and process parameters
From: John_H <newsgroup@johnhandwork.com>
Date: Sat, 09 Sep 2006 16:14:48 GMT
Links: << >>  << T >>  << A >>
Todays generation of FPGAs are significantly better than yesteryears in 
beam and radiation tolerance.  As geometries shrink, the EMC toloerance 
should be improved by smaller "antenna" loop area.  Beeeing someone who 
has seen poor designs in the past hurt by improved chips, are you sure 
these problems weren't due to shoddy design?

alterauser wrote:
> I found the discussion "Why No Process Shrink On Prior FPGA Devices"
> interesting and would like to add some words regarding working
> stability of devices with shrinked geometry:
> 
> Beeing a consultant engineer, I work for various companies and in
> different fields of application and thus often come across problems
> with modern devices like RAM, FPGA and MCUs regarding their stability:
> One can observe that smaller process geometrie quickly leads to a lower
> tolerance against beam- and radiation influences, causing e.g. EMC
> problems. Therefore, some companies have to spend much time and money
> in searching for devices which are resistant enough to meet their
> requirements. Doing so, "older" families of devices with a larger
> scaling are sometimes prefered!
> 
> Do we run into problems when continously shrinking technologie and
> finally remove older devices (her maybe FPGAs) from the market ?

Article: 108372
Subject: Xilinx ISE ver 8.2.02i is optimizing away and removing "redundant" logic - help!
From: james7uw@yahoo.ca
Date: 9 Sep 2006 11:39:19 -0700
Links: << >>  << T >>  << A >>
Hello All,

I am writing a VHDL design for a Xilinx FPGA using
ISE ver 8.2.02i (8.2 SP 2) and I'm trying to get
post-map simulating correctly now that I have
post-translate simulating correctly. I put "keep"
attributes on every single signal, including those
in the ports (editor keystroke macros help a lot).
I also ran the following command line in a command
(DOS) window: (just run the following three lines
together with spaces at the line breaks; it is a
copy from the DOS window): Note the added -u to
try to prevent logic removal, which is why I had
to run this in the command window; it's not
available as a setting in map properties.

map.exe -ise ppcaesh.ise -intstyle ise -p xc4vfx12-ff668-10 -cm speed
-detail
-pr b -k 4 -c 100 -u -o user_logic_map.ncd user_logic.ngd
user_logic.pcf

I have the map optimization now set for speed in
my project, reflected in this command. I tried
setting "no optimization" as well as all the other
optimization choices. The above command made the
post map files for me. Now, at least all the red
is gone from Post-Map simulation and some of the
bytes are right in my first section of output. I
think this is due to all the "keep" attributes I
added. My removed "redundant logic" list was made
a little smaller. Here is the syntax for "keep":

    signal mysignal : std_logic; -- declare a signal

    attribute keep : string;           -- you just need this once
    -- then you can do the next line for each signal you want.
    attribute keep of mysignal : signal is "true";
    -- this goes in the architecture section after the signal
declarations and
    --  before the "begin".

(Thanks to the thread "Looking for ways to keep
diagnostic signal from being optimized out
(Xilinx)" here in comp.arch.fpga)

This syntax is found in the Constraints Guide,
cgd.pdf.

Here is a partial list of the removed logic:
Section 5 - Removed Logic
-------------------------
Optimized Block(s):
TYPE        BLOCK
GND         XST_GND
VCC         XST_VCC

Redundant Block(s):
TYPE        BLOCK
LOCALBUF        u0/my_sub_mod_128_0_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_10_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_12_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_11_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_13_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_14_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_15_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_16_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_17_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_18_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_19_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_1_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_20_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_21_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_22_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_23_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_24_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_25_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_26_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_27_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_28_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_29_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_2_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_30_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_31_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_3_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_4_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_5_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_6_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_7_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_8_xo<1>1/LUT3_D_BUF
LOCALBUF        u0/my_sub_mod_128_9_xo<1>1/LUT3_D_BUF
LUT1        myrst_inv1
LUT1        dcnt_Msub__sub0000_xor<0>11
INV         Bus2IP_Clk_inv_INV_0
LOCALBUF        Mxor__xor0019_Result1/LUT3_L_BUF
LOCALBUF        Mxor__xor0055_Result1/LUT3_L_BUF
LOCALBUF        Mxor__xor0127_Result1/LUT3_L_BUF
LOCALBUF        Mxor__xor0083_Result1/LUT3_L_BUF
LOCALBUF        user_logic_010_xo<2>1/LUT4_L_BUF
LOCALBUF        user_logic_012_xo<2>1/LUT4_L_BUF
LOCALBUF        user_logic_014_xo<2>1/LUT4_L_BUF
LOCALBUF        user_logic_018_xo<2>1/LUT4_L_BUF
LOCALBUF        user_logic_019_xo<2>1/LUT4_L_BUF
LOCALBUF        user_logic_01_xo<2>1/LUT4_L_BUF
LOCALBUF        user_logic_020_xo<2>1/LUT4_L_BUF
LOCALBUF        user_logic_022_xo<2>1/LUT4_L_BUF
LOCALBUF        user_logic_023_xo<2>1/LUT4_L_BUF
LOCALBUF        user_logic_024_xo<2>1/LUT4_L_BUF
LOCALBUF        user_logic_028_xo<2>1/LUT4_L_BUF
LOCALBUF        user_logic_02_xo<2>1/LUT4_L_BUF
LOCALBUF        user_logic_032_xo<2>1/LUT4_L_BUF
LOCALBUF        user_logic_033_xo<2>1/LUT4_L_BUF
LOCALBUF        user_logic_035_xo<2>1/LUT4_L_BUF
LOCALBUF        user_logic_036_xo<2>1/LUT4_L_BUF
LOCALBUF        user_logic_039_xo<2>1/LUT4_L_BUF
LOCALBUF        user_logic_03_xo<2>1/LUT4_L_BUF
LOCALBUF        user_logic_040_xo<2>1/LUT4_L_BUF
LOCALBUF        user_logic_043_xo<2>1/LUT4_L_BUF
LOCALBUF        user_logic_044_xo<2>1/LUT4_L_BUF
LOCALBUF        user_logic_045_xo<2>1/LUT4_L_BUF
LOCALBUF        user_logic_046_xo<2>1/LUT4_L_BUF
etc... (93 more lines)

As you can see from this list from the file
user_logic_map.mrp in the project directory, there
is still logic being removed. The optimized blocks
are still removed if you set "no optimization" and
the "redundant" blocks are still being removed
even with -u "Do Not Remove Unused Logic" command.
Could we have a "Do Not remove Any Logic" option?
-and have the "no optimization" setting respected
fully (when set)?

The key, I have learned, is to use the correct
Xilinx VHDL style, which is different for FPGAs
and ASICs. Once you follow that, you won't have
any more problems. Can someone advise me on this
correct syntax from this list of "optimized" and
"redundant" logic? Meanwhile I am reading the
xst.pdf manual, section on VHDL style to try some
things. The style to avoid latches I already used,
which really worked. Also the style to clock ROMs
so that they won't be optimized away as
asynchronous RAMs I already used, which did the
trick in post- translate.

Best regards,
-James


Article: 108373
Subject: Re: FPGA Devices' stability and process parameters
From: Austin Lesea <austin@xilinx.com>
Date: Sat, 09 Sep 2006 12:50:46 -0700
Links: << >>  << T >>  << A >>
alterauser,

On the contrary,  the smaller geometries also result in a smaller cross 
section, and less probability of upset.

The "problem" is that the device size may shrink, but then people put on 
more devices!

Thus, the susceptibility to upset MUST (by design -- there are ways to 
lessen the cross section that designers need to use now, and geometry) 
be kept smaller than the increase in memory or logic size.

For example, if at 0.15u, you have ~365 FIT/Mb for the configration 
memory (real numbers, by the way, for Virtex II xc2v6000), and the 
device is ~ 20 Mb, that makes for a total of 365 X 20 = 7300 failures 
per billion hours (really upsets, not every upset causes a "failure" so 
it is better than that --- see all the stuff we have on SEUs on our 
website).

Then, at 90nm, we have ~50 FIT/Mb for the configuration memory (again, 
real number), but we now have 60 Mb for the largest device (xc4vfx140, 
or xc4vlx200).  That is again 50 X 60 = 3000 FIT/device.

Bottom line, we are "winning" the race to reduce soft failures due to 
cosmic ray upsets faster than the technology allows more density.  This 
is the Xilinx pledge: we MUST get better faster than the shrink allows 
us to get worse.

And, if you problem is solved by a 2V2000, or 2VP20, or 4VLX25, then 
your actually failure rates per device are getting much smaller, as 
these devices are all about the same density.  Virtex 4 is ~ 6 to 8 
times better than Virtex II in soft error failure rate (less failures).

Then, as a totally different subject, there is "Total Dose" which is 
only a concern to devices that experience ionizing radiation all the 
time (medical equipment, nuclear reactors, space, etc.).

Total dose is an area I really don't want to talk about.

The total dose issue is a bit touchy, as the US governement realizes 
that most (perhaps all) 90nm technology is very tolerant of total dose, 
and they need to change their rules in order to deal with reality.

I suggest you do some research, and follow up with RADECS, SELSE, MAPLD, 
and other conferences, and the papers that are being published.

EMI/RFI was not, and is not an issue in terms of affecting the devices 
as far as I am able to learn.  We have our FPGAs in MRI machines, and 
railroad engine controls:  both extreme magnetic and electric field 
applications.  Just don't create a loop in the external pcb wiring that 
is a problem, and the device takes care of itself (too small!).

The rest of the industry is having a hard time keeping their soft 
failure rate below 1,000 FIT/Mb, so that is why we are so willing to 
publish our results.

Austin (virtexicdesigner)

Article: 108374
Subject: Re: Xilinx ISE ver 8.2.02i is optimizing away and removing "redundant" logic - help!
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sat, 09 Sep 2006 20:21:00 GMT
Links: << >>  << T >>  << A >>
I guess the most obvious question I would have for you first off is "Why are 
you bothering with this?"  Let the tool do it's job which is to turn 
VHDL/Verilog design source files into the properly formatted bitstream 
needed to program the device.

Don't waste your time trying to prevent the tool from optomizing your 
code...trust me even the best code written by an experience person can be 
optomized to target a specific device.

I realize that doesn't address your question, just thought I'd save you what 
seems to me to be a fruitless exercise on your part.

KJ 





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