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 25275

Article: 25275
Subject: Re: XC3000A Configuration data
From: Thomas Karlsson <thomas.karlsson@emw.ericsson.se>
Date: Mon, 04 Sep 2000 17:43:34 +0200
Links: << >>  << T >>  << A >>
Hello again

The programmable logic data book (1998) explains that in more detail on
page 4-315 to 4-318, but not down to the level where each bit in the
data frame is explained. That is probably a big secret. At least to me
it is. I agree that it would be interesting to know, though. 

/Thomas

Anthony Tekatch wrote:
> 
> Hello,
> 
> That file only shows how the preamble data is generated. I would like to
> know how to construct the entire configuration data block (something that
> the Foundation software does).
> 
> In article <39B37AB7.3730F97B@emw.ericsson.se>, Thomas Karlsson
> <thomas.karlsson@emw.ericsson.se> wrote:
> > Hi,
> >
> > I think this appnote might be what you are looking for
> >
> > http://www.xilinx.com/appnotes/bus_conf.pdf
> >
> > Thomas
> >
> > Anthony Tekatch wrote:
> >>
> >> Which Xilinx APP note/pdf shows the details of the Configuration Data
> >> for the XC3000A series?
> >>
> >> I would like to dynamically program that device with a microprocessor.
> >>
> >> Thanks in advance.
Article: 25276
Subject: Re: Slow routing of PWR/GND (Virtex)
From: Johan Petersson <Johan.Petersson@uab.ericsson.se>
Date: Mon, 04 Sep 2000 17:52:53 +0200
Links: << >>  << T >>  << A >>
Hi Richard,

All I can say is that the problem does not remain in
3.1i, which improves par times enormously!

Johan, 
email vhdl_ninja@yahoo.com


news@rtrussell.co.uk wrote:
> 
> The problem of very slow routing of PWR/GND nets is
> supposed to be fixed in 2.1i Service Pack 6, but I
> am still suffering from it (running the Unix tools
> on a Sun Ultra 10 workstation).  An XCV600 is taking
> about 8 hours to build, of which over 7 hours is the
> PWR/GND routing (all signals are successfully routed
> in under 40 minutes).  Does the problem remain in SP6,
> or is this a specific issue related to the use of the
> Unix version ?
> 
> Richard.
> http://www.rtrussell.co.uk/
Article: 25277
Subject: Re: Balls!
From: "Elftmann" <elftmann@pacbell.net>
Date: Mon, 4 Sep 2000 12:02:04 -0700
Links: << >>  << T >>  << A >>
Ray,

With the cost of the larger SRAM devices (XCV1000 and up) I have seen
several customers recently who have chosen to socket the SRAM BGA devices
(Xilinx/Altera) to allow the devices to be reused.   IMHO this makes sense
in a prototype environment.  If a proto board has to be scrapped or has
out-lived it's usefullness, at least the cost of the parts can be recovered.
It's a trade-off between the removal and re-balling of the device versus a
socket.  If a high quality socket is used this is a reasonable trade-off.
The BGA sockets I've seen are better than the QFP sockets and tend to induce
very few problems when properly used.

I believe if you look back into this thread, this reasoning is consistent
with the original posters thinking.

Daniel Elftmann
Actel Area Technical Manager (ATM that does not dispense cash, except to my
wife)

"Ray Andraka" <ray@andraka.com> wrote in message
news:39B2D090.455347C7@andraka.com...
> Why would you do this on an SRAM based FPGA?  The socket just adds one
more
> thing that can go wrong, and nothing sucks quite as much as socket induced
> problems.  With the SRAM based parts, just make sure you leave a way to
laod a
> program in directly instead of in a PROM or buried in the processor ROM
build.
>
> "Nicholas C. Weaver" wrote:
> >
> > In article <QpOyOTTKnsWfbM=MacxXqtYEDVgb@4ax.com>,
> > John  Larkin  <jjlarkin@highlandSNIPTHIStechnology.com> wrote:
> > >Ben,
> > >
> > >thanks, but I have a situation where all the data must be available to
> > >the core algorithm at once, and, besides, I'd lose pins faster than
> > >I'd gain them if I were to partition things into multiple chips.
> > >
> > >This chip has to be connected to nine 12-bit flash ADCs, two big banks
> > >of SRAM, a 68332 uP (to do the slow stuff!) and the PCI bus. The core
> > >algorithm must do massively nasty pipelined parallel stuff on the ADC
> > >data streams at 60 MHz or so.
> >
> >         One suggestion:  BGA sockets.  Several manufacturers make BGA
> > sockets, semi-custom jobs, around $50 each (minimum quantity 5) which
> > will fit various FPGAs.  They have the nice property of they also BGA
> > mount, with an identical profile, so you can use a socket during
> > development and then solder down the parts when the board goes into a
> > higher level of production.
> > --
> > Nicholas C. Weaver
nweaver@cs.berkeley.edu
>
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com  or http://www.fpga-guru.com


Article: 25278
Subject: Re: Balls!
From: Ray Andraka <ray@andraka.com>
Date: Mon, 04 Sep 2000 21:48:09 GMT
Links: << >>  << T >>  << A >>
>>From the apps I've dealt with, by the time you finish playing with the
prototype, the part prices are a fraction of what you paid for them, and the
extra debug time due to one faulty socket more than pays for that part. 
Besides, with SRAM based devices, you can often reuse a prototype on the next
project at least for early development.

Elftmann wrote:
> 
> Ray,
> 
> With the cost of the larger SRAM devices (XCV1000 and up) I have seen
> several customers recently who have chosen to socket the SRAM BGA devices
> (Xilinx/Altera) to allow the devices to be reused.   IMHO this makes sense
> in a prototype environment.  If a proto board has to be scrapped or has
> out-lived it's usefullness, at least the cost of the parts can be recovered.
> It's a trade-off between the removal and re-balling of the device versus a
> socket.  If a high quality socket is used this is a reasonable trade-off.
> The BGA sockets I've seen are better than the QFP sockets and tend to induce
> very few problems when properly used.
> 
> I believe if you look back into this thread, this reasoning is consistent
> with the original posters thinking.
> 
> Daniel Elftmann
> Actel Area Technical Manager (ATM that does not dispense cash, except to my
> wife)
> 
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:39B2D090.455347C7@andraka.com...
> > Why would you do this on an SRAM based FPGA?  The socket just adds one
> more
> > thing that can go wrong, and nothing sucks quite as much as socket induced
> > problems.  With the SRAM based parts, just make sure you leave a way to
> laod a
> > program in directly instead of in a PROM or buried in the processor ROM
> build.
> >
> > "Nicholas C. Weaver" wrote:
> > >
> > > In article <QpOyOTTKnsWfbM=MacxXqtYEDVgb@4ax.com>,
> > > John  Larkin  <jjlarkin@highlandSNIPTHIStechnology.com> wrote:
> > > >Ben,
> > > >
> > > >thanks, but I have a situation where all the data must be available to
> > > >the core algorithm at once, and, besides, I'd lose pins faster than
> > > >I'd gain them if I were to partition things into multiple chips.
> > > >
> > > >This chip has to be connected to nine 12-bit flash ADCs, two big banks
> > > >of SRAM, a 68332 uP (to do the slow stuff!) and the PCI bus. The core
> > > >algorithm must do massively nasty pipelined parallel stuff on the ADC
> > > >data streams at 60 MHz or so.
> > >
> > >         One suggestion:  BGA sockets.  Several manufacturers make BGA
> > > sockets, semi-custom jobs, around $50 each (minimum quantity 5) which
> > > will fit various FPGAs.  They have the nice property of they also BGA
> > > mount, with an identical profile, so you can use a socket during
> > > development and then solder down the parts when the board goes into a
> > > higher level of production.
> > > --
> > > Nicholas C. Weaver
> nweaver@cs.berkeley.edu
> >
> > --
> > -Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com  or http://www.fpga-guru.com

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com

Article: 25279
Subject: Re: Slow routing of PWR/GND (Virtex)
From: Ray Andraka <ray@andraka.com>
Date: Mon, 04 Sep 2000 21:52:34 GMT
Links: << >>  << T >>  << A >>
3.1 does seem to fix that problem.  One bugger with 3.1 is if the placement
isn't going to meet timing, it spends an awful long time trying a little harder
before it gives up.  That's a bit of a bugger if you are trying to push
something to see how fast it'll go as opposed to meet timing for a particular
target.  If your placement makes meeting timing relatively easy, the tool runs
very quickly...I've got a very full 97%)XCV400 that's placing and routing in
under 5 minutes, with all the datapahth stuff but not control logic
floorplanned.

Johan Petersson wrote:
> 
> Hi Richard,
> 
> All I can say is that the problem does not remain in
> 3.1i, which improves par times enormously!
> 
> Johan,
> email vhdl_ninja@yahoo.com
> 
> news@rtrussell.co.uk wrote:
> >
> > The problem of very slow routing of PWR/GND nets is
> > supposed to be fixed in 2.1i Service Pack 6, but I
> > am still suffering from it (running the Unix tools
> > on a Sun Ultra 10 workstation).  An XCV600 is taking
> > about 8 hours to build, of which over 7 hours is the
> > PWR/GND routing (all signals are successfully routed
> > in under 40 minutes).  Does the problem remain in SP6,
> > or is this a specific issue related to the use of the
> > Unix version ?
> >
> > Richard.
> > http://www.rtrussell.co.uk/

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com
Article: 25280
Subject: Re: XC3000A Configuration data
From: "Anthony Tekatch" <tekatch@idirect.com>
Date: Mon, 04 Sep 2000 22:47:56 GMT
Links: << >>  << T >>  << A >>

> The programmable logic data book (1998) explains that in more detail on
> page 4-315 to 4-318, but not down to the level where each bit in the
> data frame is explained.

I do not have any printed manuals and cannot find that one on their web
site.


> That is probably a big secret. At least to me it is. I agree that it
> would be interesting to know, though. 

I certainly hope it's no secret.. I'm sure there must be a market for
programming the devices from uP generated data rather than predefined
layouts.

I have a "support" request in to Xilinx, hopefully I'll get an answer
shortly and post the results here.

Anthony

Article: 25281
Subject: Re: Balls!
From: emanuel stiebler <emu@ecubics.com>
Date: Mon, 04 Sep 2000 17:54:00 -0600
Links: << >>  << T >>  << A >>
Elftmann wrote:
> 
> Ray,
> 
> With the cost of the larger SRAM devices (XCV1000 and up) I have seen
> several customers recently who have chosen to socket the SRAM BGA devices
> (Xilinx/Altera) to allow the devices to be reused. 

Sorry to jump in here, but do you have any prices for the bigger BGA
sockets ?
The last time I checked ( two years ago) the sockets were MUCH more
expensive than the parts.

cheers,
emanuel

Article: 25282
Subject: Model for 8101 - 8104
From: "Ron" <skalarv@usa.net>
Date: Tue, 5 Sep 2000 10:43:01 +0200
Links: << >>  << T >>  << A >>
Looking for simulation model (VHDL) for 8101 or 8104

Regards
Ron


Article: 25283
Subject: StateCAD ?
From: "Danijel Sebalj" <dsebalj@myokay.net>
Date: Tue, 5 Sep 2000 11:02:30 +0200
Links: << >>  << T >>  << A >>
Hello,

does somebody have experience about using the tool Statecad from VSS ?
Is ist suitable for more complex design and why there is no affordable
version for students??

Thanx for more

Danijel Sebalj, Hamburg




Article: 25284
Subject: XC4013 available
From: kolja@prowokulta.org
Date: Tue, 05 Sep 2000 09:44:04 GMT
Links: << >>  << T >>  << A >>
This Saturday I can get up to 720 Pieces XC4013XL-PQ208CFN9925 for a
very low price froma customs auction.
They are new but come without any waranty.

I will buy 50 or so for myself, but I will happily take your orders and
buy more for $5 a piece plus international shipping (and customs to some
countries)
10 Pieces minimum.

Please send me your orders via email with your full email and
postal address.

CU,
	Kolja Sulimma




Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 25285
Subject: Re: Slow routing of PWR/GND (Virtex)
From: news@rtrussell.co.uk
Date: 5 Sep 2000 10:52:40 GMT
Links: << >>  << T >>  << A >>
Johan Petersson <Johan.Petersson@uab.ericsson.se> wrote:

: All I can say is that the problem does not remain in
: 3.1i, which improves par times enormously!

Actually it turns out that the problem I am having is
related to the use of very large numbers of SRL16 shift-
registers, which is resulting in over 25000 VCC routes!
I have confirmed that the problem is just the same in
3.1i; it is described at support.xilinx.com thus:

"Currently map generates a GLOBAL_LOGIC1 and GLOBAL_LOGIC0
 signal to drive constants onto the F & G inputs of LUT RAM
 used in the SRL library element. The extreme number of VCC
 loads that can occur in such designs will often lead to
 excessive router run time as well as poor circuit performance
 due to route congestion."

The solution recommended is to add the environment variable
XIL_MAP_NOSHIFTONES, but when I do this 'bitgen' aborts with
over 25000 errors telling me that the F and G inputs are not
connected!  If I ignore these errors (bitgen -d) the device
doesn't work, exhibiting all the symptoms of the shift-
registers not operating correctly.

Richard.
http://www.rtrussell.co.uk/

Article: 25286
Subject: Re: Slow routing of PWR/GND (Virtex)
From: Johan Petersson <Johan.Petersson@uab.ericsson.se>
Date: Tue, 05 Sep 2000 13:17:31 +0200
Links: << >>  << T >>  << A >>
Hi Ray,

I agree 100% about the long routing times when you have a "bad"
placement.
A good idea to avoid that situation is to run the par with the -n 0 flag
which
tells it to perform loads and loads of place'n'route runs with different
-t values.

There is also a flag that disables the router so that you can let the
placer 
run with different "cost table entries" as a background job - when the
check sum
is low enough you kill the bastard and run with -t x, no -n and WITH the
router
enabled....... I don't remember the name for the "disable router" flag
:)

Finally you can tell the router explicitly how many iterations to run.
If you
constrain it with for example -i 1, it will only run one iteration
regardless
of how ugly the placement might be!

There is always much to discuss about FPGA's, isn't it!!??

Regards,
Johan Petersson,
Engineering Manager,
Wireless Digital Intelligence ltd, Sweden

email (private) vhdl_ninja@yahoo.com :)


Ray Andraka wrote:
> 
> 3.1 does seem to fix that problem.  One bugger with 3.1 is if the placement
> isn't going to meet timing, it spends an awful long time trying a little harder
> before it gives up.  That's a bit of a bugger if you are trying to push
> something to see how fast it'll go as opposed to meet timing for a particular
> target.  If your placement makes meeting timing relatively easy, the tool runs
> very quickly...I've got a very full 97%)XCV400 that's placing and routing in
> under 5 minutes, with all the datapahth stuff but not control logic
> floorplanned.
> 
> Johan Petersson wrote:
> >
> > Hi Richard,
> >
> > All I can say is that the problem does not remain in
> > 3.1i, which improves par times enormously!
> >
> > Johan,
> > email vhdl_ninja@yahoo.com
> >
> > news@rtrussell.co.uk wrote:
> > >
> > > The problem of very slow routing of PWR/GND nets is
> > > supposed to be fixed in 2.1i Service Pack 6, but I
> > > am still suffering from it (running the Unix tools
> > > on a Sun Ultra 10 workstation).  An XCV600 is taking
> > > about 8 hours to build, of which over 7 hours is the
> > > PWR/GND routing (all signals are successfully routed
> > > in under 40 minutes).  Does the problem remain in SP6,
> > > or is this a specific issue related to the use of the
> > > Unix version ?
> > >
> > > Richard.
> > > http://www.rtrussell.co.uk/
> 
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com  or http://www.fpga-guru.com
Article: 25287
Subject: Re: StateCAD ?
From: Johan Petersson <Johan.Petersson@uab.ericsson.se>
Date: Tue, 05 Sep 2000 14:32:45 +0200
Links: << >>  << T >>  << A >>
Hi Danijel,

I have not used the tool you mention. But if you want something that is 
"state of the art" for student prices I would like to recommend you to
visit 

www.xilinx.com

where you can get Modelsim - for free. In my opinion, Modelsim is the
best
simulator around these days.
You'll also get lots of backend things for CPLD's and Xilinx own
synthesis
tool from xilinx.com. I haven't tested their synthesis tool myself, but
from
what I have heared it's GOOD except for that it doesn't understand all
of
the synthesizable subset of VHLD. I don't think that it understands
RECORDs for
example.

If you want a true state of the art synth. tool for FPGAs for free, I
would 
recommend you to go to www.exemplar.com and get the evaluation copy (1
month)
of Exemplar Logics Leonardo Spectrum. 

Good luck with your project,
/Johan,
Engineering Manager WDI ltd, sweden

email: vhdl_ninja@yahoo.com


Danijel Sebalj wrote:
> 
> Hello,
> 
> does somebody have experience about using the tool Statecad from VSS ?
> Is ist suitable for more complex design and why there is no affordable
> version for students??
> 
> Thanx for more
> 
> Danijel Sebalj, Hamburg

Article: 25288
Subject: Re: XC4013 available
From: Ray Andraka <ray@andraka.com>
Date: Tue, 05 Sep 2000 12:40:46 GMT
Links: << >>  << T >>  << A >>
Not that I'm going to buy any, but you missed a very important part of the part
number...the speed grade.  That is a single digit stamped on the device in a
different ink than the base part number.

So what is a very low price?  For a reference point, these are equivalent, but
possibly slower speed, to a Spartan XCS30.

kolja@prowokulta.org wrote:
> 
> This Saturday I can get up to 720 Pieces XC4013XL-PQ208CFN9925 for a
> very low price froma customs auction.
> They are new but come without any waranty.
> 
> I will buy 50 or so for myself, but I will happily take your orders and
> buy more for $5 a piece plus international shipping (and customs to some
> countries)
> 10 Pieces minimum.
> 
> Please send me your orders via email with your full email and
> postal address.
> 
> CU,
>         Kolja Sulimma
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com
Article: 25289
Subject: Re: More than 4 clocks in virtex
From: Johan Petersson <Johan.Petersson@uab.ericsson.se>
Date: Tue, 05 Sep 2000 14:44:17 +0200
Links: << >>  << T >>  << A >>
Hi Hannah,

There is a USELOWSKEWLINES command that you put in the .ucf . There is
also
some way (i don't remember what it is called) to constrain the skew on a
wire - it might be set maxskew = xxx :)

I have used that stuff with Leonardo Spectrum without problem. The thing
is that
the par router will take MUCH longer time to complete if you use the set
maxskew
constraint, but maybe you can live with that.

What I would do myself is to put 
'par ... -i 200 ..."
as a background job with those constraints and see how far you can get
with
your favourite placement :)

Good luck,
Johan P,
WDI ltd Sweden

email vhdl_ninja@yahoo.com


Hanna Bruno wrote:
> 
> The problem faced here, was that the non global clock net was being split into 4
> groups. The synthesis tool must have done this and the resulting routing seemed
> to have skew between the 4 clock groups. The FAE said that there is a constraint
> that can be added in 3.1i to use low skewlines, I have to try that yet and
> prevent the synthesis tool from splitting the net.
> 
> Thank you for your comments Jamie.
> 
> Hannah

Article: 25290
Subject: Re: Slow routing of PWR/GND (Virtex)
From: Ray Andraka <ray@andraka.com>
Date: Tue, 05 Sep 2000 12:49:51 GMT
Links: << >>  << T >>  << A >>
It's not so much the "bad" placement that gets me, most of my stuff is
floorplanned to try to get the most speed and density practical.  In my cases it
is a deliberate overconstraining to keep the router from doing dumb things when
I am trying to evaluate what a particular structure is capable of.  A good
example is in the layout an evaluation of the 16 point FFT core I plan to offer
this fall.  Without constraints, the router does a fairly poor job, turning in
max frequencies around 85 MHz in a -4 part, but with an aggressive constraint it
does much better, better than 133 MHz.  This is a 100% floorplanned design. 
Once I know what the design will do when the router takes a long time, backing
off on the constraint to soething that is really close but not exceeding that
number router takes only a minute or two instead of the better part of an hour.

Johan Petersson wrote:
> 
> Hi Ray,
> 
> I agree 100% about the long routing times when you have a "bad"
> placement.
> A good idea to avoid that situation is to run the par with the -n 0 flag
> which
> tells it to perform loads and loads of place'n'route runs with different
> -t values.
> 
> There is also a flag that disables the router so that you can let the
> placer
> run with different "cost table entries" as a background job - when the
> check sum
> is low enough you kill the bastard and run with -t x, no -n and WITH the
> router
> enabled....... I don't remember the name for the "disable router" flag
> :)
> 
> Finally you can tell the router explicitly how many iterations to run.
> If you
> constrain it with for example -i 1, it will only run one iteration
> regardless
> of how ugly the placement might be!
> 
> There is always much to discuss about FPGA's, isn't it!!??
> 
> Regards,
> Johan Petersson,
> Engineering Manager,
> Wireless Digital Intelligence ltd, Sweden
> 
> email (private) vhdl_ninja@yahoo.com :)
> 
> Ray Andraka wrote:
> >
> > 3.1 does seem to fix that problem.  One bugger with 3.1 is if the placement
> > isn't going to meet timing, it spends an awful long time trying a little harder
> > before it gives up.  That's a bit of a bugger if you are trying to push
> > something to see how fast it'll go as opposed to meet timing for a particular
> > target.  If your placement makes meeting timing relatively easy, the tool runs
> > very quickly...I've got a very full 97%)XCV400 that's placing and routing in
> > under 5 minutes, with all the datapahth stuff but not control logic
> > floorplanned.
> >
> > Johan Petersson wrote:
> > >
> > > Hi Richard,
> > >
> > > All I can say is that the problem does not remain in
> > > 3.1i, which improves par times enormously!
> > >
> > > Johan,
> > > email vhdl_ninja@yahoo.com
> > >
> > > news@rtrussell.co.uk wrote:
> > > >
> > > > The problem of very slow routing of PWR/GND nets is
> > > > supposed to be fixed in 2.1i Service Pack 6, but I
> > > > am still suffering from it (running the Unix tools
> > > > on a Sun Ultra 10 workstation).  An XCV600 is taking
> > > > about 8 hours to build, of which over 7 hours is the
> > > > PWR/GND routing (all signals are successfully routed
> > > > in under 40 minutes).  Does the problem remain in SP6,
> > > > or is this a specific issue related to the use of the
> > > > Unix version ?
> > > >
> > > > Richard.
> > > > http://www.rtrussell.co.uk/
> >
> > --
> > -Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com  or http://www.fpga-guru.com

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com
Article: 25291
Subject: Re: Slow routing of PWR/GND (Virtex)
From: Ray Andraka <ray@andraka.com>
Date: Tue, 05 Sep 2000 12:54:44 GMT
Links: << >>  << T >>  << A >>
I've ran into this one first in v3.1.  You can get around it by explicitly
defining logic_1 and logic_0 signals. for smaller groups of SRL16's.  You may
need to put the appropriate attributes on the instances to keep them from beig
eaten in synthesis.

news@rtrussell.co.uk wrote:
> 
> Johan Petersson <Johan.Petersson@uab.ericsson.se> wrote:
> 
> : All I can say is that the problem does not remain in
> : 3.1i, which improves par times enormously!
> 
> Actually it turns out that the problem I am having is
> related to the use of very large numbers of SRL16 shift-
> registers, which is resulting in over 25000 VCC routes!
> I have confirmed that the problem is just the same in
> 3.1i; it is described at support.xilinx.com thus:
> 
> "Currently map generates a GLOBAL_LOGIC1 and GLOBAL_LOGIC0
>  signal to drive constants onto the F & G inputs of LUT RAM
>  used in the SRL library element. The extreme number of VCC
>  loads that can occur in such designs will often lead to
>  excessive router run time as well as poor circuit performance
>  due to route congestion."
> 
> The solution recommended is to add the environment variable
> XIL_MAP_NOSHIFTONES, but when I do this 'bitgen' aborts with
> over 25000 errors telling me that the F and G inputs are not
> connected!  If I ignore these errors (bitgen -d) the device
> doesn't work, exhibiting all the symptoms of the shift-
> registers not operating correctly.
> 
> Richard.
> http://www.rtrussell.co.uk/

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com
Article: 25292
Subject: Re: Error during synthesis
From: Johan Petersson <Johan.Petersson@uab.ericsson.se>
Date: Tue, 05 Sep 2000 14:54:49 +0200
Links: << >>  << T >>  << A >>
Tomasz Brychcy wrote:
Hi,

do you really have to use Write2CWR as an asynchronous reset??

If you can live with having the Write2CWS acting on the negedge CLK,
it will be very easy I believe:

  always @(negedge CLK or posedge YourGlobalReset) begin
   if(YourGlobalReset)
      YourGlobalReset_Action :)
   else if (Write2CWR)
     OUT=OUT_mode_after_CWR;
   else
     OUT=OUT_mode;
  end

This code should hopefully synthesize to what you intended only that 
changes in Write2CWR will affect your design on the good old clock edge.

If you HAVE to use exactly what your code does timingwize you could use
a
gated clock of course - but you should generally be rather careful with
gated
clocks and keep an eye on how your tool implements them. Advice is to
constraint
them carefully in the x.ucf (if you are using Xilinx that is :) )

Good luck,
Johan P,
WDI ltd Sweden

mailto: vhdl_ninja@yahoo.com

> 
> Hello,
> 
> Why the code below is incorrect to synthesis for FPGA Express:
> 
> always @(negedge CLK or posedge Write2CWR)
> 
>  if (Write2CWR)
>   OUT=OUT_mode_after_CWR;
>  else
>   OUT=OUT_mode;
> 
> Error during synthesis is:
> 
> Sequential mapping has detected that the cell '/ver1-optimized/OUT_reg' uses
> both the asynchronous 'set' and 'clear' pins.
> 
> What should I correct in this code?
> 
> With regards
> 
> Tomek
> 
> T.Brychcy@ime.pz.zgora.pl

-- 
APZ FOR MEN BECAUSE FIRST IMPRESSIONS LASTS
Article: 25293
Subject: PCB design for Xilinx FPGAs
From: "Dan" <daniel.deconinck@sympatico.ca>
Date: Tue, 05 Sep 2000 13:12:38 GMT
Links: << >>  << T >>  << A >>
Hello,

I use PADs software (PowerPCB)  to design my PCBs (PADS logic for schematic
entry) for Xilinx designs. It takes a lot of time to create PCB decals and
gate decals. I have several to swap. I am looking for the gate and PCB decal
for a XCV150-nFG456t ( where n is any speed
grade, t is any temp grade)

I have the following available for swap:
XC3195-nPG233t
XC30(30|40)([A])-nPC84t
XCS(20|30|40)-nPQ208t
XCV(50| upto 300)-nPQ240t
XC5210-nHQ304t
XC5204-nTQ144t

Sincerely
Daniel DeConinck




Article: 25294
Subject: Re: Balls!
From: Johan Petersson <Johan.Petersson@uab.ericsson.se>
Date: Tue, 05 Sep 2000 15:26:15 +0200
Links: << >>  << T >>  << A >>
Right,

As Ray points out, your big-big gate array will be very cheep when you
have
finished prototyping unless you are about to release your product very
soon.
Virtex2 is coming in newer process from UMC - I don't think the
0.18/0.22
will be expencive in a couple of months. Try to speek to your favourite
Xilinx
person about their plans!

By the way, have you concidered to put the "slow" things
(microprocessor)
inside the FPGA as well? Xilinx have an agreement with IBM - which will
lead
to PowerPC cores for Virtex2 if I remember the press release correctly.
Also the Virtex2 devices are rumored to have a much more aggressive
memory
to gate ratio - so maybe some of your memory could fit into the gate
array
as well!

Good luck with the thing your designing!
Regards,
Johan, mailto: vhdl_ninja@yahoo.com


Ray Andraka wrote:
> 
> From the apps I've dealt with, by the time you finish playing with the
> prototype, the part prices are a fraction of what you paid for them, and the
> extra debug time due to one faulty socket more than pays for that part.
> Besides, with SRAM based devices, you can often reuse a prototype on the next
> project at least for early development.
> 
> Elftmann wrote:
> >
> > Ray,
> >
> > With the cost of the larger SRAM devices (XCV1000 and up) I have seen
> > several customers recently who have chosen to socket the SRAM BGA devices
> > (Xilinx/Altera) to allow the devices to be reused.   IMHO this makes sense
> > in a prototype environment.  If a proto board has to be scrapped or has
> > out-lived it's usefullness, at least the cost of the parts can be recovered.
> > It's a trade-off between the removal and re-balling of the device versus a
> > socket.  If a high quality socket is used this is a reasonable trade-off.
> > The BGA sockets I've seen are better than the QFP sockets and tend to induce
> > very few problems when properly used.
> >
> > I believe if you look back into this thread, this reasoning is consistent
> > with the original posters thinking.
> >
> > Daniel Elftmann
> > Actel Area Technical Manager (ATM that does not dispense cash, except to my
> > wife)
> >
> > "Ray Andraka" <ray@andraka.com> wrote in message
> > news:39B2D090.455347C7@andraka.com...
> > > Why would you do this on an SRAM based FPGA?  The socket just adds one
> > more
> > > thing that can go wrong, and nothing sucks quite as much as socket induced
> > > problems.  With the SRAM based parts, just make sure you leave a way to
> > laod a
> > > program in directly instead of in a PROM or buried in the processor ROM
> > build.
> > >
> > > "Nicholas C. Weaver" wrote:
> > > >
> > > > In article <QpOyOTTKnsWfbM=MacxXqtYEDVgb@4ax.com>,
> > > > John  Larkin  <jjlarkin@highlandSNIPTHIStechnology.com> wrote:
> > > > >Ben,
> > > > >
> > > > >thanks, but I have a situation where all the data must be available to
> > > > >the core algorithm at once, and, besides, I'd lose pins faster than
> > > > >I'd gain them if I were to partition things into multiple chips.
> > > > >
> > > > >This chip has to be connected to nine 12-bit flash ADCs, two big banks
> > > > >of SRAM, a 68332 uP (to do the slow stuff!) and the PCI bus. The core
> > > > >algorithm must do massively nasty pipelined parallel stuff on the ADC
> > > > >data streams at 60 MHz or so.
> > > >
> > > >         One suggestion:  BGA sockets.  Several manufacturers make BGA
> > > > sockets, semi-custom jobs, around $50 each (minimum quantity 5) which
> > > > will fit various FPGAs.  They have the nice property of they also BGA
> > > > mount, with an identical profile, so you can use a socket during
> > > > development and then solder down the parts when the board goes into a
> > > > higher level of production.
> > > > --
> > > > Nicholas C. Weaver
> > nweaver@cs.berkeley.edu
> > >
> > > --
> > > -Ray Andraka, P.E.
> > > President, the Andraka Consulting Group, Inc.
> > > 401/884-7930     Fax 401/884-7950
> > > email ray@andraka.com
> > > http://www.andraka.com  or http://www.fpga-guru.com
> 
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com  or http://www.fpga-guru.com

-- 
APZ FOR MEN BECAUSE FIRST IMPRESSIONS LASTS

Article: 25295
Subject: Re: run time doubled with Xilinx 3.1i upgrade
From: Johan Petersson <Johan.Petersson@uab.ericsson.se>
Date: Tue, 05 Sep 2000 15:32:08 +0200
Links: << >>  << T >>  << A >>
Hi,

My advice would be to try Leonardo Spectrum and Synplify. I have not
used 
Synplify, but I have very good experience from using Exemplar Logic
Leonardo
with Xilinx FPGAs (mainly virtex things)

There is an evaluation copy available for 1 month usage if you visit
www.exemplar.com

good luck,
Johan P, mailto:vhdl_ninja@yahoo.com


Christian Mautner wrote:
> 
> On Tue, 29 Aug 2000 18:09:48 -0700, Andy Peters <@> wrote:
> >
> >Check in the FPGA Express constraints GUI, and make sure you didn't set
> >that attribute to FALSE there.  Also, *never* forward-annotate timing
> >constraints from FPGA Express (that is, one of the FPGA Express options
> >is "Export Timing Constraints").  That puts lots of constraints into
> >your EDIF that don't need to be there, especially when most of your
> >constraints will be covered by a simple PERIOD attached to the clock.
> >
> 
> You should try FPGA Express 3.4. Much improvement there, they create now a
> *.ncf file, and don't put the timing constraints in the edif file anymore.
> And, they use simple PERIOD statements in the ncf file. I define (most) timing
> constraints in fexp (in tcl, not in the GUI, of course), and I am quite
> satisfied.
> 
> chm.
> 
> --
> cmautner@  -  Christian Mautner
> mail.com   -  Vienna/Austria/Europe

Article: 25296
Subject: Re: Balls!
From: bstelle@my-deja.com
Date: Tue, 05 Sep 2000 14:03:05 GMT
Links: << >>  << T >>  << A >>
In article <Ef+nOWncm0n9eQJ6FlkHRIdiJ15y@4ax.com>,
  John  Larkin <jjlarkin@highlandSNIPTHIStechnology.com> wrote:
> Well, I want to do a really cool image-processing gadget, and I'll
> need an FPGA with 300 I/O pins or so. Peter Alfke was kind enough to
> send me a couple of sample Xilinx BGA parts. I showed them to my
> manufacturing people and actually escaped with my life.
>
> So, if any of you have experience with BGAs, I'd appreciate some help:
>
> 1. Is it necessary to go with gold-plated (or maybe bare copper) pads
> to ensure planarity? Anybody having success with regular FR-4,
> solder-coated SMOBC stuff?
>
> 2. Assuming I send the boards out for assembly, I'd still like to
> verify that all the BGA soldering is intact. I could code up a special
> FPGA design to just configure the chip as a lot of I/O latches, and
> then run test patterns (from the uP that configures and supervises the
> FPGA). Clearly, I can detect shorts between pins this way. Any ideas
> on how to detect open ball-to-PCB solder joints?
>
> 3. What sorts of PCB line/spacings are needed for something like a
> 460-ish pin 1.27 mm BGA?
>
> 4. Any other advice or cautions?
>
> Thanks,
>
> John
>
>

John, I have been working with 356 pin PBGAs for the past 4 years, and
what a relief it has been.  You should be able to non solder mask
defined pads in most cases without any difficulty on standard FR4
copper type boards.  I have never worked with thinner than 1/2 oz.
copper, but I know of folks that have.  The coplanarity issue is likely
only to be an issue with extreme board flex (i.e.: imbalance in the
internal copper layers of the board).  I have never seen a board yet
that had such coplanarity problems.  By the way coplanarity is just as
big an issue if not bigger with QFP style parts since the points of
contact are actually spread further from the device centroid.  BGAs are
to some degree self centering after placement during reflow.  One must
use a convection type reflow as the contacts are hidden.  The biggest
thing that MUST happen to ensure your success, is to get a BGA
competent contract manufacturer to not only place the BGA resonably
accurately, but also to inspect the solder balls prior to placement.  I
have seen a few cases where solder ball deformation has caused a short
under the part to an adjacent solder ball.  The other thing they must
check for is missing or insuficient solder balls, which will lead to
open circuits.  XRAY inspection will allow the CM to check for proper
ball colapse and to check for adjacent ball shorting.  If they have the
capability to perform other angles, additional solder joint information
can be gleaned, such as cold solder, bubbles, etc..  I would not let
any of this scare you, I have seen more problems with QFP style
packages, than with BGAs.
   As for the joint testing, JTAG is a great help if your particular
part has it, if not, one can often emulate it in different ways with
minimal effort.  I have used JTAG whenever, and wherever possible, and
it has been a BIG benefit.  Your CM may even have an ICT that is JTAG
compliant and can do this testing for you.

I appologize for the overly verbose and poorly spelled response.

Ben Stelle
Design Engineer
Trilithic, Inc.


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 25297
Subject: Re: XC4013 available
From: "S. Ramirez" <sramirez@nospam.com>
Date: Tue, 05 Sep 2000 14:08:27 GMT
Links: << >>  << T >>  << A >>
Besides the speed grade that RA pointed out, you also forgot to tell
everyone what country you are in.  In other words, what is considered
international shipping?
-Simon Ramirez, Consultant
 Synchronous Design, Inc.

<kolja@prowokulta.org> wrote in message news:8p2f92$347$1@nnrp1.deja.com...
> This Saturday I can get up to 720 Pieces XC4013XL-PQ208CFN9925 for a
> very low price froma customs auction.
> They are new but come without any waranty.
>
> I will buy 50 or so for myself, but I will happily take your orders and
> buy more for $5 a piece plus international shipping (and customs to some
> countries)
> 10 Pieces minimum.
>
> Please send me your orders via email with your full email and
> postal address.
>
> CU,
> Kolja Sulimma
>
>
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>


Article: 25298
Subject: DCT implementation using FpgA
From: "Seb C" <Seb@stien.bizland.com>
Date: Tue, 05 Sep 2000 14:13:06 GMT
Links: << >>  << T >>  << A >>
Hi, I'm interested by pictures compressions, if someone know how to do a DCT
into an FPGA i take all what you have !!

Thx


Article: 25299
Subject: DCT implementation using FPGA
From: "Seb C" <Seb@stien.bizland.com>
Date: Tue, 05 Sep 2000 14:14:20 GMT
Links: << >>  << T >>  << A >>
Hi,

I'm interested by pictures compressions, especially DCT, and if someone know
how to do a DCT into an FPGA, i take all what you have !!

Thx


SEB




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