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 85375

Article: 85375
Subject: Re: VirtexII:DCM:CLKFX phase delay
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 08 Jun 2005 11:37:02 -0700
Links: << >>  << T >>  << A >>
Yes,

Much shorter than 2ns, but how much shorter is anyone's guess, as the 
CLKFX output can not have the phase cancelation at these frequencies as 
CLKFB is not connected (as the DLL doesn't work at these low frequencies).

Austin

al82 wrote:

> Thanks for your reply,
> 
>>From what you say I gather that:
> 
> - CLKFX will always be delayed (from associated CLKIN edge)
> - The delay will be short (not likely more than 2ns)
> 
> Is that correct?
> 
> Thank you
> 

Article: 85376
Subject: Re: Available under the terms of the SignOnce IP License
From: Roel <electronics_designer@hotmail.com>
Date: Wed, 08 Jun 2005 20:40:29 +0200
Links: << >>  << T >>  << A >>
Vladislav Muravin wrote:
> Marco,
> 
> sorry, could not resist...
> i think it means something like "no 30 days returning policy" :)
> 
Another one would be:
"PayAgain and again and again"

Roel


> V
> "Marco" <marcotoschi_no_spam@email.it> wrote in message 
> news:d87161$m79$1@news.ngi.it...
> 
>>Hallo,
>>I would buy a ip core. What does it means:  "Available under the terms of 
>>the SignOnce IP License" ???
>>
>>Thanks
>>Marco
>>
> 
> 
> 

Article: 85377
Subject: Re: Available under the terms of the SignOnce IP License
From: Philip Freidin <philip@fliptronics.com>
Date: Wed, 08 Jun 2005 18:57:34 GMT
Links: << >>  << T >>  << A >>
On Wed, 8 Jun 2005 16:13:01 +0200, "Marco" <marcotoschi_no_spam@email.it> wrote:
>Hallo,
>I would buy a ip core. What does it means:  "Available under the terms of 
>the SignOnce IP License" ???
>
>Thanks
>Marco 

Google is your friend, why didn't you ask google?

Here is a link that explains "SignOnce IP License":

   http://www.xilinx.com/ipcenter/signonce.htm




Philip
Philip Freidin
Fliptronics

Article: 85378
Subject: linker script
From: "kittyawake@gmail.com" <kittyawake@gmail.com>
Date: 8 Jun 2005 12:20:50 -0700
Links: << >>  << T >>  << A >>
hi,
   I am working with linker scripts for the first time.I want to
understand the linker script that the tool generates for my code.
what does *(.gnu.linkonce.t*) mean?
Thanx


Article: 85379
Subject: Re: Great Tutorial on Signal Integrity, SSOs, Ground Bounce etc
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Wed, 8 Jun 2005 21:24:00 +0200
Links: << >>  << T >>  << A >>

"Symon" <symon_brewer@hotmail.com> schrieb im Newsbeitrag
news:42a72697_1@x-privat.org...

> >
> Frankly, yes. Because FPGAs are general purpose devices, your kitchen
timer
> is my DDR RAM controller or ultra fast sampling circuit. The faster the
> edges, the greater the range of applications for a given FPGA. If this
means
> kitchen timer designers have to learn about SI, well that's the price I'm
> willing for them to pay! ;-)

OK, 99% agreed. The cutting edge parts shall have cutting edge speed. An no
one will argue about Virtex-4 beeing not cutting edge, right?

> But, again, Altera's parts have half(ish) the rise time, which means they
> can cope with more applications as RAMs go faster. My point is that fast
> edges don't preclude any applications; crap designers do.

;-)

> The point Dr. Johnson was trying to spin, I mean make, is, I think, that
> fast edges in combination with a bad package can be unusable. True, of
> course. That's why you can't get new FPGAs in PLCC packages. What I
dispute
> is whether Altera's packages are that bad at today's rise times.  That
said,
> Xilinx's package is superior in terms of ground bounce. What we need is
> Stratix silicon in a Xilinx package!

We can make it, IGOR. Charge me another megavolt.
HE IS ALIVE!!!
There can be only one Frankenstein.
;-)

Regards
Falk




Article: 85380
Subject: Re: ISE/EDK 6.3 vs 7.1...
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 09 Jun 2005 07:37:20 +1200
Links: << >>  << T >>  << A >>
dima2882 wrote:
> I also noticed that the fitter for ISE 7.1 isn't as efficient. I had a legacy design for an XC9500, and I called Xilinx tech support on an unrelated issue. I was using 6.3, the tech support guy used 7.1, and he couldn't fit my design to the chip. He had to install 6.3 to be able to work on it. It really does seem that the new fitter isn't as efficient.

  What puzzles me is WHY they would change the 9500 fitter between 6.3 
and 7.1 releases. Surely the 9500 qualifies as ancient/'highly stable' ?
  ie Was there a reason for the change/fit failures ?
-jg


Article: 85381
Subject: Re: Available under the terms of the SignOnce IP License
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 08 Jun 2005 12:43:09 -0700
Links: << >>  << T >>  << A >>
Philip,

Thanks for replying to this one.  We seem to have some disgruntled users 
out there who are in a "let's bash Xilinx today" mood.

Not very useful to the newsgroup, and not productive at all.

Nice to have folks like you come to our defense.

Austin



Article: 85382
Subject: Re: General gripe session ....
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 09 Jun 2005 08:02:24 +1200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:

> Erik,
> 
> The parts are not discontinued.  Digikey carries them, and we still sell 
> them.  And, we still make them, too.  We use our website to showcase the 
> new products, not the old ones.

So when will Xilinx add FPGAs (back?) to their BuyOnline ?
-jg


Article: 85383
Subject: Re: Great Tutorial on Signal Integrity, SSOs, Ground Bounce etc
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Wed, 08 Jun 2005 20:03:24 GMT
Links: << >>  << T >>  << A >>
Symon - 

On Wed, 8 Jun 2005 10:21:08 -0700, "Symon" <symon_brewer@hotmail.com>
wrote:

>> That's what I had in mind for the problem statement.  But once the
>> designer is made aware of the problem, he needs some help in dealing
>> with it.  That's where a list of recommendations would come in handy.
>>
>OK, I'll bite. How about this?
>1) Group sets of I/Os common to a clock domain together in I/O banks.
>Minimise sharing of I/O banks between clock domains.

What if a bank has to be shared?  Does it help to have an unused
buffer zone of pins between clock domains?  Does it help to have
(hard) ground pins between domains?

And just how much does putting different domains into different banks
buy in the way of reduced susceptibility?  I've been doing that for
years, but I have no hard data to tell me what I'm buying, if
anything. 

>2) Isolate the Vccos for each of these banks.

Is it better to cut the power plane into separate mini-Vccos, or have
a single, low-impedance Vcco plane?  (I'm guessing on the latter for
all but quasi-analog stuff, such as Vccaux for the DCMs.)

At any rate, these are the kinds of questions I'd like to see the
vendors tackle, preferably backed up by some lab work.

By the way, I've been looking through one of the Xilinx V4 demo board
schematics, and it turns out the designers created pseudo-differential
I/O signals (i.e., differential signals, one side of which goes only
to a termination) in an attempt to lower SSO.  I recall hearing that
such a thing wouldn't work with Xilinx chips.  Guess the story changes
from day to day.  

Take care,
Bob Perlman
Cambrian Design Works

Article: 85384
Subject: Re: General gripe session ....
From: Erik Walthinsen <omega@vcolo.com>
Date: Wed, 08 Jun 2005 13:53:28 -0700
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
>> The parts are not discontinued.  Digikey carries them, and we still 
>> sell them.  And, we still make them, too.  We use our website to 
>> showcase the new products, not the old ones.
Then why, when I try to search for various part numbers found on Digikey 
on Xilinx's site do I get no useful results? (specifically anything 
under ~$50 as appropriate for my projects)  For the sole reason that ISE 
runs on Linux I would prefer to use Xilinx parts.  But when Digikey is 
the only way to get any parts in small quantity, and I can't even 
determine if the parts they actually do sell have a hope of handling my 
project, I start looking at putting up with Windoze and Quartus (better 
interface than ISE anyway, from my limited experience) and going with 
Altera parts.

Not to mention that all the parts on Digikey are afaict ludirously 
expensive for their capbilities, because they are built with such old 
processes.

Can some give an explanation as to why Digikey does not even offer the 
newer parts in the first place?  I gather there are apparently problems 
producing the chips in sufficient quantity, but that's never stopped 
Digikey from at least listing a part as non-stock before.

Jim Granville wrote:
> So when will Xilinx add FPGAs (back?) to their BuyOnline ?
That's all Xilinx would have to do to keep me (and many others from what 
I read) from jumping to Altera.  For the record I have nothing against 
Altera, but without Quartus running "easily" in Linux, they're mostly 
out of the running otherwise.  I plan on actually using Makefiles and 
CVS to manage heavily co-dependent C and Verilog, and that gets almost 
prohibitively annoying and hard with Windoze.

Article: 85385
Subject: Re: General gripe session ....
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 08 Jun 2005 14:09:22 -0700
Links: << >>  << T >>  << A >>
Jim,

Good question.  I have already asked this internally.  I, like you, are 
awaiting the results...

Austin

Jim Granville wrote:

> Austin Lesea wrote:
> 
>> Erik,
>>
>> The parts are not discontinued.  Digikey carries them, and we still 
>> sell them.  And, we still make them, too.  We use our website to 
>> showcase the new products, not the old ones.
> 
> 
> So when will Xilinx add FPGAs (back?) to their BuyOnline ?
> -jg
> 

Article: 85386
Subject: Re: Great Tutorial on Signal Integrity, SSOs, Ground Bounce etc
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 09 Jun 2005 09:10:58 +1200
Links: << >>  << T >>  << A >>
Bob Perlman wrote:

> Symon - 
> 
> On Wed, 8 Jun 2005 10:21:08 -0700, "Symon" <symon_brewer@hotmail.com>
> wrote:
> 
> 
>>>That's what I had in mind for the problem statement.  But once the
>>>designer is made aware of the problem, he needs some help in dealing
>>>with it.  That's where a list of recommendations would come in handy.
>>>
>>
>>OK, I'll bite. How about this?
>>1) Group sets of I/Os common to a clock domain together in I/O banks.
>>Minimise sharing of I/O banks between clock domains.
> 
> 
> What if a bank has to be shared?  Does it help to have an unused
> buffer zone of pins between clock domains?  Does it help to have
> (hard) ground pins between domains?
> 
> And just how much does putting different domains into different banks
> buy in the way of reduced susceptibility?  I've been doing that for
> years, but I have no hard data to tell me what I'm buying, if
> anything. 

  Where the effects are common-mode inductance, and even cap-crosstalk,
this grouping all helps.

  As Peter A. has said, it is the cross-domain noise that has the 
potential for inflicting most damage.

-jg



Article: 85387
Subject: In-system configuration
From: "ernie" <ernielin@gmail.com>
Date: 8 Jun 2005 14:13:53 -0700
Links: << >>  << T >>  << A >>
Hi All,

I would like to use an FPGA to reconfigure another FPGA by loading the
new configuration into the other FPGA's EPC configuration device via
JTAG.  Is this possible?  If so, how would I go about doing this?

Thanks!


Article: 85388
Subject: Re: Pissed off with Xilinx - Spartan 3
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Wed, 08 Jun 2005 16:29:00 -0500
Links: << >>  << T >>  << A >>


Erik Walthinsen wrote:

> Jim Granville wrote:
>
>> Try mentioning this link, might hurry them along a bit...
>> http://www.altera.com/buy/devices/buy-devices.html
>
> Except that they have '0' stock of most chips themselves. ;-(
>
>> Xilinx only have CPLDs here :
>
> As of a month ago, they listed a reasonable selection of in-stock 
> Spartan3 parts for prototyping work.  Apparently they decided they 
> don't like people actually *buying* their parts.
>
> I'm pretty much newbie to FPGAs, but I've got in mind a decent-sized 
> project that needs quantity *1* of a TQ144 or PQ208 chip of no 
> particular size (an XC2S50 would be underutilized and running at 
> 48MHz) as glue between a bunch of parts.  Unless I can find a way to 
> get a part for this project, I'll be looking at other vendors.

Digi-Key stocks this exact part. OOPs, is is the XC2S50E.   I got 5 of 
them a month ago to start a migration
from 5 V Spartan parts.  I think they now have some Spartan-3 parts, too.

Jon


Article: 85389
Subject: Re: Great Tutorial on Signal Integrity, SSOs, Ground Bounce etc
From: Ben Twijnstra <btwijnstra@gmail.com>
Date: Wed, 08 Jun 2005 23:35:44 +0200
Links: << >>  << T >>  << A >>
Hi Symon,

> "Ben Twijnstra" <btwijnstra@gmail.com> wrote in message
> news:8ae63$42a22d01$d55db008$8159@news.chello.nl...
>> Wednesday. I've been to Dr Johnson's lectures before, and I've even found
>> his material appliccable to designs running as low as 32MHz.
>>
> Ben,
> Indeed, if you'd read the book ;-) , you'd know it's the rise time and
> length of the path that matters, not the toggle rate.

Don't I know it... Actually, it's easy to deduct the length of the trace
from the ringing frequency.

I even ran in to this in 1994 when we had a 16MHz design and used a few
74HCT244 buffers on a bus. We could in the end only get the design working
by replacing the buffers with 74LS244s because of all the noise the high
slew rate was causing.

So no, this is not an FPGA-only problem.

Best regards,


Ben


Article: 85390
Subject: Re: Great Tutorial on Signal Integrity, SSOs, Ground Bounce etc
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 08 Jun 2005 14:39:42 -0700
Links: << >>  << T >>  << A >>
Bob,

Great thread.  See below for my comments,

Austin

Bob Perlman wrote:

> Symon - 
> 
> On Wed, 8 Jun 2005 10:21:08 -0700, "Symon" <symon_brewer@hotmail.com>
> wrote:
> 
> 
>>>That's what I had in mind for the problem statement.  But once the
>>>designer is made aware of the problem, he needs some help in dealing
>>>with it.  That's where a list of recommendations would come in handy.
>>>
>>
>>OK, I'll bite. How about this?
>>1) Group sets of I/Os common to a clock domain together in I/O banks.
>>Minimise sharing of I/O banks between clock domains.
> 
> 
> What if a bank has to be shared?  Does it help to have an unused
> buffer zone of pins between clock domains?  Does it help to have
> (hard) ground pins between domains?
> 
> And just how much does putting different domains into different banks
> buy in the way of reduced susceptibility?  I've been doing that for
> years, but I have no hard data to tell me what I'm buying, if
> anything. 

Yes, isolation is a good thing.  More unused pins between domains is 
also a good thing, as there are more ground/Vcco pairs for return currents.

But, it is true that adding all the grounds in the world don't help 
after the first set are added.  Maxwell's equations show that return 
currents always flow next to the source conductor, so adding conductors 
around the existing return conductor offer little or no benefit, unless 
the return currents are split between return paths, taking advantage of 
the extra returns.

BART (the rapid transit system of the SF Bay Area) illustrates the 
common misconception:  the third rail is close to one side of the track. 
  1000V DC:  The engineer said that when a train is on the train 
section, return current is split equally from the supply rail through 
the train motors back to the returns exactly by 1/2 and 1/2.

Wrong.  Maxwell's equations (for DC) show that the return current is 
based on fields, which is based on geometry, so the return current is 
2/3 in the closest rail, and 1/3 in the far rail.

Just because the engineer said so, did not make reality change, and as a 
result when the first train location system was activated it showed that 
there was a train in every section where there was not a train, and no 
train in the sections that had trains in them (true story).  The traffic 
control center freaked out.

The problem could have been solved easily with programmable logic (just 
invert), but alas, there was no programmable logic in those days.

Back to the topic at hand -

Virtual grounds are almost useless in the new V4 SparseChevron package, 
as the grounding is so good, using an IO as a poor man's ground is of 
little to no benefit.

> 
> 
>>2) Isolate the Vccos for each of these banks.
> 
> 
> Is it better to cut the power plane into separate mini-Vccos, or have
> a single, low-impedance Vcco plane?  (I'm guessing on the latter for
> all but quasi-analog stuff, such as Vccaux for the DCMs.)

To cut, or not to cut?  That is the dilemna.  A cut up plane will have 
much less good high quality capacitance (which is good for byapssing 
above 100 MHz where bypass caps are almost worthless).  But, sometimes 
you are layer limited, and you just have to do it (cut things up).

> 
> At any rate, these are the kinds of questions I'd like to see the
> vendors tackle, preferably backed up by some lab work.

If you work with one of our FAE SI experts, we can show you the 
effectiveness of pcb interplane capacitance on bypassing, and then it is 
just a question of how good do you really want your bypassing solution 
to be?

More solid planes, results in fewer, or less exotic caps.  For example, 
the X2Y caps (look like a standard surface mount cap with two center 
electrodes) has remarkably lower self inductance/ESR, and can go a long 
way to improving the bypassing solution at the expense of ... expense. 
But often fewer caps are needed, and you can use the split planes as a 
result.  My group (the FPGA Lab) is happy to talk to your FAE and help 
them with extreme design solutions (where things get tough, and 
compromises have to be made).

> 
> By the way, I've been looking through one of the Xilinx V4 demo board
> schematics, and it turns out the designers created pseudo-differential
> I/O signals (i.e., differential signals, one side of which goes only
> to a termination) in an attempt to lower SSO.  I recall hearing that
> such a thing wouldn't work with Xilinx chips.  Guess the story changes
> from day to day.  
> 

Just because we have folks who like to experiment doesn't mean we 
endorse something, or that it works.  They are (were) trying to find 
ways to improve things.  Pseudo-differential has a lot of reasons why it 
doesn't work, which start with the fact that they are single ended, and 
the load is not balanced at all.  Imagine there is 0.5 pF mis-match 
between the two IO's:  that immediately leads to significant common 
currents at the edge rates.  It turns out if you force the differential 
balance, you can make such an arrangement better, but it will still be 
inferior to a real balanced differential driver (like LVDS, or CML of 
the MGTs).  One also has to look at the mismatch in time of two single 
ended IOs (they are not switcing at the same time like a differential 
IO), as well as the mismatch at the receiver end:  is the receiver 
perfectly differential balanced?  Do the two received waveforms overlap 
in time 100%?  Only "real" LVDS pairs are routed in the package with 
flight time matching (it is part of the LVDS specification).

Article: 85391
Subject: Re: General gripe session ....
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 08 Jun 2005 14:48:43 -0700
Links: << >>  << T >>  << A >>
Erik,

What is vcolo.com doing with FPGAs?  Looks like you re-sell computer 
resources virtually?

See below,

Austin

Erik Walthinsen wrote:

> Austin Lesea wrote:
> 
>>> The parts are not discontinued.  Digikey carries them, and we still 
>>> sell them.  And, we still make them, too.  We use our website to 
>>> showcase the new products, not the old ones.
> 
> Then why, when I try to search for various part numbers found on Digikey 
> on Xilinx's site do I get no useful results? (specifically anything 
> under ~$50 as appropriate for my projects)  For the sole reason that ISE 
> runs on Linux I would prefer to use Xilinx parts.  But when Digikey is 
> the only way to get any parts in small quantity, and I can't even 
> determine if the parts they actually do sell have a hope of handling my 
> project, I start looking at putting up with Windoze and Quartus (better 
> interface than ISE anyway, from my limited experience) and going with 
> Altera parts.
> 
> Not to mention that all the parts on Digikey are afaict ludirously 
> expensive for their capbilities, because they are built with such old 
> processes.
> 
> Can some give an explanation as to why Digikey does not even offer the 
> newer parts in the first place?  I gather there are apparently problems 
> producing the chips in sufficient quantity, but that's never stopped 
> Digikey from at least listing a part as non-stock before.

All parts are in stock here at the factory (I checked).  That a 
distributor doesn't order them is of course troubling, and another 
issue.  That Digikey doesn't carry the latest and greatest products may 
be because they offer little to no support.  We prefer our distributors 
to earn their percentages (that they make on the parts).

Other distributors do not want to be undersold by someone who offers no 
services (and we don't see any benefit in that either).

If all you need are some samples, you should develop a better 
relationship with your local X distributor or X representative.

Article: 85392
Subject: Re: Great Tutorial on Signal Integrity, SSOs, Ground Bounce etc
From: Ben Twijnstra <btwijnstra@gmail.com>
Date: Wed, 08 Jun 2005 23:51:34 +0200
Links: << >>  << T >>  << A >>
Hi Symon,


> From the first demo, the conclusion is :-
> 
> The Altera package suffers from two issues:
> 
>   1.. . Excessively fast signal rise/fall time

This is a software setting. Altera for some reason insists on 'standard'
slew rates being the fastest, and has had a 'Slow Slew rate' setting ever
since the Flex10K. This 'Slow Slew Rate' setting can be set on a per-pin
basis and pretty much limits your I/O switching frequency to ~750MHz, but
then again, I wouldn't want to use a single-ended standard higher than
350-400MHz anyway unless I had some serious simulation software, a few
weeks to spare to get the layout right, and a large supply of aspirin. With
differential standards there's no need to turn on the slew rate limiter, so
LVDS and other protocols don't cause problems.

>   2.. . Over-concentration of power/ground balls in core region
> I'd argue that 1) isn't a problem; fast rise time is good, as long as you
> know what you're doing. (BTW Xilinx can't compete on risetime because of
> their 12.5pF pin capacitance.) Now, 2) could be a SI problem, for which
> the Xilinx package is a solution, but I question whether the data
> presented are a realistic 'real world' set up. If they are, no-one would
> be able to drive DDR ram from an Altera part.

Also, the power/ground concentration in the center allows for less headaches
when minimizing the number of PCB layers - you can pretty much forget about
the inner few rows because they'll be power and ground anyway.

Best regards,


Ben


Article: 85393
Subject: Re: linker script
From: DJ Delorie <dj@delorie.com>
Date: 08 Jun 2005 18:02:04 -0400
Links: << >>  << T >>  << A >>

"kittyawake@gmail.com" <kittyawake@gmail.com> writes:
> what does *(.gnu.linkonce.t*) mean?

.gnu. means it's a GNU extension.

.linkonce. means the linker will collect all sections with the same
name, compare the contents, and only include one of each set of
matching sections in the output.  I.e. if each object had a
.gnu.linkonce.text.foo47 and they were all the same, the final
executable would only have one copy of it.

The .t* means, essentially, all the text (executable code) sections.
.d* would be data, .b* would be bss, etc.  The "*" is a wildcard which
matches anything.

Article: 85394
Subject: Re: Pissed off with Xilinx - Spartan 3 [The Rest of the Story]
From: "Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com>
Date: Wed, 8 Jun 2005 15:54:16 -0700
Links: << >>  << T >>  << A >>
Hi Fred,

"Fred" <Fred@nospam.com> wrote in message
news:42a4814e$0$2594$da0feed9@news.zen.co.uk...
> 14 week lead time for samples for the XC3S200.  How can you prototype with
> that?
>
> It makes worry even more when it comes to manufacture where I might need
> quantity.

Wow!  I miss reading comp.arch.fpga's for a few days ...

SUMMARY:  Spartan-3 FPGAs are readily available.  To speed delivery of
Spartan-3 before 1-AUG-2005, append the part number with the four-number
code "0974".

THE DETAILS:
================================
I did some checking and from appearances, you're right.  But as the
illustrious U.S. radioman Paul Harvey used to say, "stay tuned for the rest
of the story."

Xilinx is transitioning the lower-density Spartan-3 FPGAs (XC3S50 through
XC3S1500) from the 200 mm wafer production line to the 300 mm line.  The
larger density Spartan-3 FPGAs (XC3S2000 through XC3S5000) are already built
exclusively on the 300 mm line.  Xilinx has a policy where we notify
customers 90 days in advance of such a change and we cannot ship product
from the new fab unless you specifically order us to.  This gives customers
90 days to evaluate the new material to see if it affects their production
systems.  The details are in the following change notice.
http://www.xilinx.com/bvdocs/notifications/xcn05009.pdf

Starting 1-AUG-2005, all orders will be shipped from the 300 mm line. Until
then, all production orders for lower-density Spartan-3 FPGAs are still
shipped from the 200 mm line.  As a consequence, lead times are artificially
increasing during the transition.  There are plenty of 300 mm devices in
stock.  However, due to our notification policy, we can't ship you one of
the 300 mm devices unless you specifically ask.  You can dramatically
improve delivery by appending the part number with the four-number code
"0974".  For example, "XC3S200-4PQ208C" would become "XC3S200-4PQ208C0974".

I've also copied the various Xilinx logistics groups to make sure that our
distribution product managers are aware of this issue.  The lead-times need
to be updated to reflect the 1-AUG-2005 change-over date.

While I have your attention (I hope), I'd also like to promote a free
feature from the Xilinx MySupport web site that automatically notifies you
be E-mail whenever Xilinx issues a change notice.  You can also sign up to
receive notices whenever we update a data sheet, application note, errata,
etc.  Just visit the following link.
http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=18683

---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
General Products Division
Spartan-3/-3E FPGAs
http://www.xilinx.com/spartan3e
---------------------------------
The Spartan(tm)-3 Generation:  The World's Lowest-Cost FPGAs.





Article: 85395
Subject: Re: FPGA I/O pin current sink
From: Jeff Cunningham <jcc@sover.net>
Date: Thu, 09 Jun 2005 00:04:38 GMT
Links: << >>  << T >>  << A >>
Berty wrote:
> Better use external transistor / Fet as multiple pin can get all burned
> due to the fact that they do not open and close at the same exact

Or when transitioning, go to Z for a clock between driving high and low 
in a "break before make" sort of way.

Jeff

Article: 85396
Subject: Re: Why do VHDL gate level models simulate slower than verilog
From: Jeremy Stringer <jeremy@_NO_MORE_SPAM_endace.com>
Date: Thu, 09 Jun 2005 12:25:55 +1200
Links: << >>  << T >>  << A >>
abilashreddy@yahoo.com wrote:
> Hi Group,
>          Iam not sure if this is the right group to post my query
> on,butI would appreciate any kind of information.I am relatively new to
> VHDL and am tring to understand whyVHDL gate level descriptions
> simulate slower than verilog models.I was told that it was because how

Just a random guess, but I would have thought that it could be simply 
the amount of logic - there's a lot more elements that are simulated 
post-synthesis, as it's broken down into luts and 'flops.  If you 
simulate at a higher level, then you can skip simulating all these 
elements, and simply simulate the behavior of the language -

For instance (making a few assumptions) - if you have a 32 bit counter, 
you could model that in a simulator as a uint32_t - taking one 
instruction on a 32 bit processor to add a number.  If you break that 
down into one-bit operations spread across 32 batches of elements, then 
it would intuitively take longer, unless there was some optimisation 
going from netlist to simulation.

My 2c,

Jeremy

Article: 85397
Subject: Re: FPGA/CPLD trend
From: Jeff Cunningham <jcc@sover.net>
Date: Thu, 09 Jun 2005 00:30:59 GMT
Links: << >>  << T >>  << A >>
Another disadvantage of schematics is that they are generally in a 
proprietary format. Which means an old design might not be readable in 
the latest version of a vendor's schematic tool, while a text file is 
forever. Also, targeting a different vendor's fpga usually means 
re-entering the schematic from a different symbol library, while HDL is 
retargetable with much fewer changes (like none if you're lucky). And 
thirdly, simulation of a schematic based design is 1-2 orders of 
magnitude slower than simulating RTL VHDL. The difference between 1 
minute and 30 minutes in the iterative design process is huge.

Jeff

Article: 85398
Subject: Re: Boot problem Stratix Kit EP1S25
From: "neoh" <hsneoh@gmail.com>
Date: 8 Jun 2005 17:38:03 -0700
Links: << >>  << T >>  << A >>
Hi Patrick,
   Altera has an updated utility that allows you to set up for
non-volatile configuration on the DSP Stratix 1S25 board.

   To obtain these files, please contact Altera mySupport at:
   https://mysupport.altera.com/eservice/


Regards,
HS


Article: 85399
Subject: [Vir2] Can I use a 18k ram as 2 single-port ram?
From: "Davy" <zhushenli@gmail.com>
Date: 8 Jun 2005 18:25:14 -0700
Links: << >>  << T >>  << A >>
Hi all,

I use Xilinx Vertex2 FPGA. Can I use a 18k ram as 2 single-port ram?

Best regards,
Davy




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