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 80200

Article: 80200
Subject: Re: Spartan3E
From: "Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com>
Date: Wed, 2 Mar 2005 10:48:23 -0800
Links: << >>  << T >>  << A >>
Hi Laurent,

> Very interested for my new embedded product.
>
> Some questions:
>
> for when the first samples?

Samples of the XC3S100E are available now to early access customers.
General sampling of the XC3S100E FPGA starts in May, followed roughly a
month later by the XC3S500E and so on.

Stay tuned in the coming weeks for some of the first Spartan-3E
demonstration and development boards from the Xilinx sales partners.

> for when on the production market?

The answer depends on the specific part number but volume production for the
XC3S100E FPGA starts 3Q 2005.  The entire product family is scheduled to be
in volume production in 4Q 2005.  Spartan-3E FPGAs are built on the same
process technology as Spartan-3 devices so the time from first samples to
volume production will be much shorter than it was for Spartan-3.

> are the s3 and s3e FPGA pin compatible?

Unfortunatley no.  One of the goals of Spartan-3E was to maximize I/O count
in a given package.  In order to squeeze those last few I/Os into the
package, we had to sacrifice footprint compatibility.  There is still,
however, full footprint compatibility within the Spartan-3E family in a
given package.
---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
Spartan-3/-3E FPGAs
http://www.xilinx.com/spartan3e
---------------------------------
The Spartan-3 Generation:  The World's Lowest-Cost FPGAs.



Article: 80201
Subject: spartan3E price
From: "Amontec, Larry" <laurent.gauch@ANTI-SPAMamontec.com>
Date: Wed, 02 Mar 2005 19:51:03 +0100
Links: << >>  << T >>  << A >>
spartan3E price

For the same quantity, package and kgates, the s3E will be more or less 
expensive than the S3 ?

Thanks,
    Laurent
    www.amontec.com
------------ And now a word from our sponsor ---------------------
For a secure high performance FTP using SSL/TLS encryption
upgrade to SurgeFTP
----  See http://netwinsite.com/sponsor/sponsor_surgeftp.htm  ----

Article: 80202
Subject: Re: spartan3E price
From: "Antti Lukats" <antti@openchip.org>
Date: Wed, 2 Mar 2005 19:53:41 +0100
Links: << >>  << T >>  << A >>

"Amontec, Larry" <laurent.gauch@ANTI-SPAMamontec.com> schrieb im Newsbeitrag
news:42260b14$1@news.vsnet.ch...
> spartan3E price
>
> For the same quantity, package and kgates, the s3E will be more or less
> expensive than the S3 ?

less.
that is what has been told, but make sure the availability for your project
it may come too late

Antti



Article: 80203
Subject: Re: Signal Integrity, ground bounce, crosstalk, SSOs, BGA pin-outs, parasitic inductance...
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Wed, 2 Mar 2005 19:57:33 +0100
Links: << >>  << T >>  << A >>
"Peter Alfke" <peter@xilinx.com> schrieb im Newsbeitrag
news:1109786492.673401.81320@f14g2000cwb.googlegroups.com...

> Still no comments on the newsgroup.

Nevously waiting??

> Those of you who want to (re)visit Howard Johnson's presentation can do
> this by clicking on
>
> http://www.xilinx.com/products/virtex4/pdfs/BGA_Crosstalk.pdf

Another strike against Altera. Hmm, the differences are clearly visible,
explinations sound reasonable. If we assume that PR had not too much
possibilities to fake, aeehhh, arrange the data, this looks like a clear
victory for Xilinx, does it?

Regards
Falk




Article: 80204
Subject: Re: spartan3E price
From: "Peter Alfke" <peter@xilinx.com>
Date: 2 Mar 2005 10:59:20 -0800
Links: << >>  << T >>  << A >>
Less! That's the whole idea...
But watch whether your package and density is available. If it is, it
will be chaeper.
Peter Alfke


Article: 80205
Subject: Re: spartan3 development board in Europe?
From: "Antti Lukats" <antti@openchip.org>
Date: Wed, 2 Mar 2005 20:02:32 +0100
Links: << >>  << T >>  << A >>
"Jens Baumann" <annonce05_nospam@web.de> schrieb im Newsbeitrag
news:42260dc0$0$29271$14726298@news.sunsite.dk...
> Hi,
> I'd like to buy the Spartan3 board from Digilent
> https://www.digilentinc.com/Sales/Product.cfm?Prod=S3BOARD
>
> However, it seems not to be available in Europe, as previous discussions
in
> this group show.
>
> Another oprion would be Memec
> http://www.memec.com/uploaded/Spartan3LC_4.pdf
> although I'd prefer Digilent for several reasons (on board ram,
recommended
> by Xilinx).
>
> Is there any possibility to order the digilent board, clones of this
board,
> or at least a board with equivalent specifications in Europe?
>
> Thanks
> Jens

digilent is s3-200 too SMALL
memec is s3-400 ok soso

xess XSA 3S1000 is S3-1000 !! way larger

really recommend best bang for the bucks at the moment.
they deliver almost immediatly, you will get tracking number confirmation
not any problems at all

Antti













Article: 80206
Subject: spartan3 development board in Europe?
From: Jens Baumann <annonce05_nospam@web.de>
Date: Wed, 02 Mar 2005 20:05:54 +0100
Links: << >>  << T >>  << A >>
Hi,
I'd like to buy the Spartan3 board from Digilent
https://www.digilentinc.com/Sales/Product.cfm?Prod=S3BOARD

However, it seems not to be available in Europe, as previous discussions in
this group show.

Another oprion would be Memec
http://www.memec.com/uploaded/Spartan3LC_4.pdf
although I'd prefer Digilent for several reasons (on board ram, recommended
by Xilinx).

Is there any possibility to order the digilent board, clones of this board,
or at least a board with equivalent specifications in Europe?

Thanks
Jens

Article: 80207
Subject: Re: Spartan-3E and SPI Flash bootstrap
From: "Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com>
Date: Wed, 2 Mar 2005 11:08:29 -0800
Links: << >>  << T >>  << A >>

"Pablo Bleyer Kocik" <pablobleyer@hotmail.com> wrote in message
news:1109751233.384425.271710@l41g2000cwc.googlegroups.com...
>
>  The SP-3E datasheet only talks about external programming hardware
> regarding the SPI configuration Flash. Is there a bootstrap programming
> method planned for these Flash memories (eg. using the JTAG interface
> with the usual ISE configuration tools)?

We recommend the direct programming approach for SPI Flash PROMs as it is
the simplest and fastest.  As you pointed out though, it is not the only
method.  There is a forthcoming application note that provides additional
SPI programming options.

The direct programming approach is also useful with some third-party SPI
Flash programmers that support in-system programming using a socket adapter
(example:  Needam's Electronics).

We already have a similar, documented approach for programming attached
parallel NOR Flash via JTAG as part of the MicroBlaze EDK software.  See the
following link.
http://www.xilinx.com/ise/embedded/est_rm.pdf

One advantage of Spartan-3E FPGAs is that _all_ of the configurations pins
can be reclaimed as full-featured user-I/O after configuration.  This means
that you can easily access external SPI or parallel NOR Flash.  This means
that you can program the attached memory from the FPGA.  This also means
that your FPGA application can have readable/writeable, random-accessible,
byte-addressable, non-volatile storage without adding yet another PROM to
the board.  A single SPI or parallel NOR Flash can configure the FPGA,
contain all the code for an embedded MicroBlaze processor, and store any
design information such as serial numbers, Ethernet MAC IDs, etc.

Stay tuned for details.
---------------------------------
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: 80208
Subject: Fault Tolerant FPGA design
From: "Prad" <paruchuri@gmail.com>
Date: 2 Mar 2005 11:12:05 -0800
Links: << >>  << T >>  << A >>
Hi all,
I was trying to search for fault tolerant FPGA design for a real time
embedded system on the web
As I understand
Transient error - mostly taken care of by TMR which addds a lot of
overhead or some other methods like the"direct-load" which doesent take
care of multiple faults.

Can anybody please help me with information regarding what is currently
being done about this?

Also regarding Permanent faults, my guess is that we would need a
redundant FPGA for enhanced reliability, because other methods like
partial reconfiguration by rerouting around the faulty elements assumes
there are a whole lot of free elements available

Any information would be a great help to me!

Thanks
Venkata Paruchuri


Article: 80209
Subject: Re: Hardcopy Vs ASIC
From: "Ulf Samuelsson" <ulf@a-t-m-e-l.com>
Date: Wed, 2 Mar 2005 20:12:07 +0100
Links: << >>  << T >>  << A >>
digari@dacafe.com wrote:
> For me it really doesn't matter whether the solution is ASIC
> (hardcopy) or FPGA (Easypath) because both are not (re)configurable.
>
> But i see a performance and power gain in using hardcopy solution,
> which is welcome in most of the cases. On the other hand   immediate
> availability of easypath solution is a plus because structured
> ASIC/FPGA user is always TTM hungry.
>
>> By their own figures, somewhere between 16% and 70% of conversions
>> will 'suceed". (Or somewhere from 30 to 84% will FAIL).
>
> this is what will increase the cost of hardcopy solution.

You can go the Atmel ULC route where Atmel
converts FPGAs to ASIC with a working guarantee!

You need to provide
* The design
* The specification in form of testvectors
* The order
and Atmel fixes the rest.

If the part meets the testvectors, it is assumed working.
If it doesn't, there is no payment.

You do have to have good testvectors though...

> So a direct question:
> If the volume is 30K-to -50K, who will be cheaper ??  Hardcopy or
> easypath ???




> An indirect question:
> What is the volume range where hadrcopy is cheaper and what is the
> volume range where easypath is cheaper, if I don't consider TTM and
> power/performance gains.

You have to look at each design to determine what is cheaper.
Normally, these conversions are based on base dies,
and if your design will fit a base die, then it can be realatively cheap
and NREs can be written off, on the chip sales.
If it is needs a full mask set, then you might see NREs.

If the design is working in an FPGA, then you can
sometimes use an older process, where the mask set is not
too expensive, and the part will still function to spec.

It may not make sense to convert a MAX7064 to a 90 nm process...
It might make sense to convert it to a 0,35u gate array.



>
> -- Digari

-- 
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB



Article: 80210
Subject: Re: Lattice lowcost flash FPGAs announced
From: "Amontec, Larry" <laurent.gauch@ANTI-SPAMamontec.com>
Date: Wed, 02 Mar 2005 20:12:22 +0100
Links: << >>  << T >>  << A >>
Antti Lukats wrote:
> http://www.latticesemi.com/products/fpga/xp/index.cfm
> 
> Lattice XP is announced, pretty much at same time as S3E
> :)
> 
> Antti
> 
> 
Salut Antti,

Do you know the price of these kind of XP FPGA ?

Laurent
www.amontec.com

Article: 80211
Subject: Re: Xilinx ISE7.1
From: Christian Schneider <please_reply_to_the@newsgroup.net>
Date: Wed, 02 Mar 2005 20:14:19 +0100
Links: << >>  << T >>  << A >>
They already call it 7.1 :-) Calling it version 7.0 would just do it, 
but some people refuse to install .0 versions :-) They just play the 
numbers game.

Cheers,
Chris

Symon wrote:
> "Austin Lesea" <austin@xilinx.com> wrote in message
> news:d04mpa$1as5@cliff.xsj.xilinx.com...
> 
>>Jim,
>>
>>Contact your FAE/hotline for upgrade.  A 'few weeks' is not a good
>>reason to not allow you to use the latest and best release.
>>
>>Austin
>>
> 
> Go for it all you early adopters of the 'latest and best'! And let me know
> when you've reported enough bugs to fill a service pack 2 release. ;-)
> In the depths of cynicism, Syms.
> 
> 

Article: 80212
Subject: Re: Hardcopy Vs ASIC
From: "Ulf Samuelsson" <ulf@a-t-m-e-l.com>
Date: Wed, 2 Mar 2005 20:18:42 +0100
Links: << >>  << T >>  << A >>

> Xilinx does not run extra wafers for EasyPath, until that business
> reaches a similar volume as the normal FPGA volume. Xilinx FPGAs are
> manufactured in very large volume (hundreds of thousands of devices
> per working day), and there should be no lack of candidates for
> EasyPath. It's all a matter of testing and logistics, and we are good
> at that... EasyPath is a win-win proposition for the customer and for
> Xilinx.
>
> Peter Alfke

Hi Peter,
So you are saying that the the key to Easypath success is
is dependent on bad yield or low sales ;-)

- Just kidding...

-- 
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB



Article: 80213
Subject: Re: Spartan-3E and SPI Flash bootstrap
From: "Antti Lukats" <antti@openchip.org>
Date: Wed, 2 Mar 2005 20:21:15 +0100
Links: << >>  << T >>  << A >>
"Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com> schrieb im Newsbeitrag
news:d0538e$1aa3@cliff.xsj.xilinx.com...
>
> "Pablo Bleyer Kocik" <pablobleyer@hotmail.com> wrote in message
> news:1109751233.384425.271710@l41g2000cwc.googlegroups.com...
> >
> >  The SP-3E datasheet only talks about external programming hardware
> > regarding the SPI configuration Flash. Is there a bootstrap programming
> > method planned for these Flash memories (eg. using the JTAG interface
> > with the usual ISE configuration tools)?
>
> We recommend the direct programming approach for SPI Flash PROMs as it is
> the simplest and fastest.  As you pointed out though, it is not the only
> method.  There is a forthcoming application note that provides additional
> SPI programming options.
>
> The direct programming approach is also useful with some third-party SPI
> Flash programmers that support in-system programming using a socket
adapter
> (example:  Needam's Electronics).
>
> We already have a similar, documented approach for programming attached
> parallel NOR Flash via JTAG as part of the MicroBlaze EDK software.  See
the
> following link.
> http://www.xilinx.com/ise/embedded/est_rm.pdf
>
> One advantage of Spartan-3E FPGAs is that _all_ of the configurations pins
> can be reclaimed as full-featured user-I/O after configuration.  This
means
> that you can easily access external SPI or parallel NOR Flash.  This means
> that you can program the attached memory from the FPGA.  This also means
> that your FPGA application can have readable/writeable, random-accessible,
> byte-addressable, non-volatile storage without adding yet another PROM to
> the board.  A single SPI or parallel NOR Flash can configure the FPGA,
> contain all the code for an embedded MicroBlaze processor, and store any
> design information such as serial numbers, Ethernet MAC IDs, etc.
>
> Stay tuned for details.
> ---------------------------------
> Steven K. Knapp
> Applications Manager, Xilinx Inc.

always :)

1) the parallel flash programming from EDK doesnt work for most customers
for one or anther reasons.
2) the seperata SPI programming, I am an happy owner of the Memec V4LX
board that contains the xilinx SPI ip core and where the SPI is programmed
using XAPP 800 provided tools, the result is that that all stuff just doesnt
work
I can program the SPI from using some weird bat files, thats ok but config
is not ok.

so the original question was a good question, a completly integratated
approuch
that works and programs the attached (config) memories would be a good
thing.

any more app notes aga xapp800 would not be sufficient. if the working
programming solution is not integrated in the toolchain its a pain

Antti




























Article: 80214
Subject: Re: spartan3 development board in Europe?
From: "Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com>
Date: Wed, 2 Mar 2005 11:21:17 -0800
Links: << >>  << T >>  << A >>

"Jens Baumann" <annonce05_nospam@web.de> wrote in message
news:42260dc0$0$29271$14726298@news.sunsite.dk...
> Hi,
> I'd like to buy the Spartan3 board from Digilent
> https://www.digilentinc.com/Sales/Product.cfm?Prod=S3BOARD
>
> However, it seems not to be available in Europe, as previous discussions
in
> this group show.
>
> Another oprion would be Memec
> http://www.memec.com/uploaded/Spartan3LC_4.pdf
> although I'd prefer Digilent for several reasons (on board ram,
recommended
> by Xilinx).
>
> Is there any possibility to order the digilent board, clones of this
board,
> or at least a board with equivalent specifications in Europe?

I would assume that Digilent would happily ship the board to Europe.

If not, the same board is also available from the Xilinx Online Store.
http://tinyurl.com/6zfnl

The information link for the board is below.
http://www.xilinx.com/s3boards

---------------------------------
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: 80215
Subject: Re: Part of a ranged signal
From: Christian Schneider <please_reply_to_the@newsgroup.net>
Date: Wed, 02 Mar 2005 20:23:31 +0100
Links: << >>  << T >>  << A >>

If your question is only VHDL related, then the real gurus can be found 
in comp.lang.vhdl.

Anyway, using "to" is not recommended, but you can use a for .. loop to 
convert "downto" to "to" bit by bit.

Chris


KCL wrote:
> Hi,
> 
> I want to declare signal using range 0 to A
> and then only to take some MSB of this signal how can I do??
> 
> at the start my code was
> 
> generic(
>         B: integer
> )
> .....
> signal temp (B downto 0);
> signal temp2(B-3 downto 0);
> ....
> temp2<= temp(B downto 3);
> 
> and now I want that temp and temp2 to be ranged signal so I do
> 
> generic(
>         A: integer
> )
> .....
> signal temp (range 0 to A);
> signal temp2(range 0 to A/8);
> ....
> temp2<= temp(B downto 3); -- this is this part that I doesn't know how to 
> replace
> 
> does anyone know how to do??
> 
> Thanks
> 
> Alexis.
> 
> 

Article: 80216
Subject: Re: spartan3 development board in Europe?
From: "KCL" <kclo4_NO_SPAM_@free.fr>
Date: Wed, 2 Mar 2005 20:27:40 +0100
Links: << >>  << T >>  << A >>
Hi Digilent board is commonly distributed as xilinx starter kit spartan3

Personnaly I have bought digilent board spartan to a french distributor but 
I bought it a bit expensive comparatively to xilinx starter kit (with power 
supply & cable without documentation & software / no eval cd of ise 
=>160euros)

But You should wait to see the price of the next starter kit spartan3e that 
have more stuff on it , but for the price it's actually unknow :on board 
:S3e 500 -4,  32MByte SDRAM, usb2,ethernet phy , 2 lines LCD display.... 
sound great

Regards

Alexis


"Jens Baumann" <annonce05_nospam@web.de> a écrit dans le message de news: 
42260dc0$0$29271$14726298@news.sunsite.dk...
> Hi,
> I'd like to buy the Spartan3 board from Digilent
> https://www.digilentinc.com/Sales/Product.cfm?Prod=S3BOARD
>
> However, it seems not to be available in Europe, as previous discussions 
> in
> this group show.
>
> Another oprion would be Memec
> http://www.memec.com/uploaded/Spartan3LC_4.pdf
> although I'd prefer Digilent for several reasons (on board ram, 
> recommended
> by Xilinx).
>
> Is there any possibility to order the digilent board, clones of this 
> board,
> or at least a board with equivalent specifications in Europe?
>
> Thanks
> Jens 



Article: 80217
Subject: Re: Part of a ranged signal
From: "KCL" <kclo4_NO_SPAM_@free.fr>
Date: Wed, 2 Mar 2005 20:32:28 +0100
Links: << >>  << T >>  << A >>
In fact the problem is not on the translation to downto to to that was for 
the bit extraction but I did'nt know comp.lang.vhdl so thank for the tip

I will ask there

Regards

Alexis

"Christian Schneider" <please_reply_to_the@newsgroup.net> a écrit dans le 
message de news: d053r3$elj$1@online.de...
>
> If your question is only VHDL related, then the real gurus can be found in 
> comp.lang.vhdl.
>
> Anyway, using "to" is not recommended, but you can use a for .. loop to 
> convert "downto" to "to" bit by bit.
>
> Chris
>
>
> KCL wrote:
>> Hi,
>>
>> I want to declare signal using range 0 to A
>> and then only to take some MSB of this signal how can I do??
>>
>> at the start my code was
>>
>> generic(
>>         B: integer
>> )
>> .....
>> signal temp (B downto 0);
>> signal temp2(B-3 downto 0);
>> ....
>> temp2<= temp(B downto 3);
>>
>> and now I want that temp and temp2 to be ranged signal so I do
>>
>> generic(
>>         A: integer
>> )
>> .....
>> signal temp (range 0 to A);
>> signal temp2(range 0 to A/8);
>> ....
>> temp2<= temp(B downto 3); -- this is this part that I doesn't know how to 
>> replace
>>
>> does anyone know how to do??
>>
>> Thanks
>>
>> Alexis.
>> 


Article: 80218
Subject: Re: Signal Integrity, ground bounce, crosstalk, SSOs, BGA pin-outs, parasitic inductance...
From: jaxato@gmail.com
Date: 2 Mar 2005 11:56:07 -0800
Links: << >>  << T >>  << A >>
It was a good presentation, got to learn a couple of new thing, and
have new ideas. Right now, I have a question though, about packaging
and interconnection. I was just looking at the old AFX prototype board
for the venerable XCV series of FPGA, and then I ask myself that
question of how does those P4 chip actually resolve their SI issues,
without using BGA and being placed on sockets! considering they draw
~50W (i might be wrong here, but its a lot of current...); wouldnt this
introduce parasitic inductance, hence ground loops and eventually noise
induce in "victims" pins?

thanks
Jacques


Article: 80219
Subject: [Promo] Danville releases SHARC kit for $199
From: Al Clark <dsp@danvillesignal.com>
Date: Wed, 02 Mar 2005 20:08:36 GMT
Links: << >>  << T >>  << A >>
Analog Devices, Altera and Danville Signal joined forces to create the 
ADDS-21261/Cyclone DSP & FPGA Evaluation Package featuring Danville's new 
dspstak 21261zx DSP Engine and dspstak c96k46 I/O Module.

The dspstak 21261zx combines the power of a SHARC DSP and a Cyclone FPGA. 
With a supporting cast of SDRAM, Flash, EEProm, SPI, Programmable Clocks, 
USB and RS-232, the dspstak is great for small and medium sized 
production requirements.

Development couldn't be easier, the dspstak 21261zx includes an Analog 
Devices' EZ-Kit LITE "style" debugger and is supported by Visual DSP++ 
4.0

For a limited time, the ADDS-21261/Cyclone DSP & FPGA Evaluation Package 
is available from Arrow Electronics for only $199. 

http://www.danvillesignal.com/index.php?id=zx_platform

Come see a demo at the Embedded Systems Conference in San Francisco. 
We'll be at the Analog Devices booth.



-- 
Al Clark
Danville Signal Processing, Inc.
--------------------------------------------------------------------
Purveyors of Fine DSP Hardware and other Cool Stuff
Available at http://www.danvillesignal.com

Article: 80220
Subject: sysACE load vs bootloader load of vxWorks on ML310
From: "Bo" <bo@cephus.com>
Date: Wed, 2 Mar 2005 14:09:04 -0600
Links: << >>  << T >>  << A >>
I have a problem with vxWorks boot on my ML310. If I boot, using an ACE file 
with my vxworks embedded through the sysACE controller, it works say 95% of 
the time. If I boot, using an ACE file (same HW download.bit in it--but no 
vxWorks elf--instead a bootloader), it fails 95% of the time. VxWorks begins 
to boot and then hangs on the first access (ie an fopen() call) in vxWorks 
on the compact flash.

We are seeing the same problems on 2 different ML310s and a Xilinx FAE was 
able to replicate the problem on his ML310 as well (although maybe not the 
intermittent sysACE load method). The boot loader method is >95% likely to 
hang/crash whereas the sysACE loader is more troublesome to replicate.

The boot-loader method of vxWorks still almost always fails-even though 
before jumping to the vxWorks RAM image I do a checksum verification of 
actual file vs. RAM copied image and if mismatched-won't jump. But worse 
yet, now it seems that vxWorks also occasionally (well, more than 
occasionally-anywhere between 2.0% - 30.0% of tries) hangs even when booting 
via the sysACE controller load method (ie the JTAG). I begin to suspect a 
Xilinx driver issue or driver interaction issue with our CF card (same 
behavior also being observed on Xilinx provided CF that came with the 
ML310).

 Some data points to note:

 1)       When we hang, it appears the /wait line and rdy-/busy lines on the 
CF are permanently low-which is most assuredly not a good thing.

2)       Sometimes the hang generates sysACE error LED. Even if not lit, the 
signals /wait & /busy on the CF are always 0.

3)       I NEVER hang on CF accesses at the booter/ no vxWorks code level. 
However, I find myself asking "is the vxWorks crashing because some CF FAT 
lib operations at the booter level have left the CF or sysACE in a bad 
state?" I am using Xilinx's FAT Fs Library on a CF that's formatted FAT16. I 
also memset the 1st 64MB of DDR to 0 to ensure no leftovers from previous 
boot attempts.

4)       I caught one of these sysACE error LED conditions and then used XMD 
to query the CF registers. The following is the dump: (our sysACE core is at 
0xCF00 0000 base address):


               ****************XMD% mrd 0xCF000000 32 b

CF000000:   00              CF000001:   00

CF000002:   00              CF000003:   00

CF000004:   34   4         CF000005:   42   B

CF000006:   35   5         CF000007:   00

CF000008:   80   ?         CF000009:   00

CF00000A:   00             CF00000B:   00

CF00000C:   00             CF00000D:   00

CF00000E:   00             CF00000F:   00

CF000010:   6B   k         CF000011:   00

CF000012:   00              CF000013:   00

CF000014:   16   ?        CF000015:   03   ?

CF000016:   0C   ?        CF000017:   10   ?

CF000018:   0A             CF000019:   08

CF00001A:   00             CF00001B:   00

CF00001C:   02   ?       CF00001D:   00

CF00001E:   00             CF00001F:   00

 In particular the bits of interest in this dump are:

 STATUSREG @ 0x4-0x7 offset:  bit2: CFGERROR "error has occurred in the 
Compact Flash controller"

ERRORREG @ 0x8-0xB offset: bit7: CFGREADERR "an error occurred while reading 
configuration information from Compact Flash"

CONTROLREG @ 0x18-0x1B offset: LOCKREQ is set true and RESETIRQ is true.

 5)       When the error occurs, it's as if the PPC is no longer executing 
code.


So to summarize:

1)       Why the behavior of vxWorks boot seems to vary depending on whether 
the bin executable was loaded via the PPC using Xilinx FAT Fs library versus 
the vxWorks executable being loaded by sysACE controller (as an appended 
image to the ACE file)? What is sysACE doing to CF/himself after loading 
that the boot code/sysACE load of the boot code is not?

 2)       Why vxWorks hangs on std file i/o operations (intermittently)

 3)       Why even with errors occurring in the sysACE controller registers, 
does the system permanently hang-or put another way, "shouldn't the drivers 
recover gracefully when errors occur on the sysACE controller/core?"

At first I thought the issue had to be a problem with the Xilinx FAT calls 
or the loader itself--but after verifying checksums of actual file vs the 
RAM copy of vxWorks binary file, I would hope to have ruled this possibility 
out-- and now that sysACE loads are also hanging, albeit much less 
frequently, I'm thinking a HW or driver issue?

 Are there are any other signals I should be looking at? Anyone have any 
idea of other things to try? Or have the name/email of someone at Xilinx 
that could shed light on this issue? I've tried everything I can think of. 
Unfortunately it seems the FAEs are extremely overburdened and finding 
someone knowledagble of EDK and vxWorks is not easy to begin with..... (Is 
someone from Xilinx corporate listening????)



Thanks,

Paul



Article: 80221
Subject: Re: Signal Integrity, ground bounce, crosstalk, SSOs, BGA pin-outs, parasitic inductance...
From: "IgI" <igorsath@hotmail.com>
Date: Wed, 2 Mar 2005 21:09:57 +0100
Links: << >>  << T >>  << A >>
Hi!

I really enjoyed the presentation. I didn't realize how fast the time passed
and before I was able to write down all my questions it was all over. So
next time reserve at least 1/2 hour for QA session. Besides the comparison
between Virtex-4 and Stratix-2 I was hoping to see comparison between
Virtex-II/Pro and Virtex-4.

Regards,
Igor Bizjak

"Peter Alfke" <peter@xilinx.com> wrote in message
news:1109786492.673401.81320@f14g2000cwb.googlegroups.com...
> Still no comments on the newsgroup.
> Those of you who want to (re)visit Howard Johnson's presentation can do
> this by clicking on
>
> http://www.xilinx.com/products/virtex4/pdfs/BGA_Crosstalk.pdf
>
> Peter Alfke, Xilinx Applications
>



Article: 80222
Subject: Re: sysACE load vs bootloader load of vxWorks on ML310
From: "newman" <newman5382_nospam@yahoo.com>
Date: Wed, 02 Mar 2005 20:59:20 GMT
Links: << >>  << T >>  << A >>

"Bo" <bo@cephus.com> wrote in message 
news:edf7e$42261ce7$18d6ec55$15380@KNOLOGY.NET...
>I have a problem with vxWorks boot on my ML310. If I boot, using an ACE 
>file with my vxworks embedded through the sysACE controller, it works say 
>95% of the time. If I boot, using an ACE file (same HW download.bit in 
>it--but no vxWorks elf--instead a bootloader), it fails 95% of the time. 
>VxWorks begins to boot and then hangs on the first access (ie an fopen() 
>call) in vxWorks on the compact flash.
>
> We are seeing the same problems on 2 different ML310s and a Xilinx FAE was 
> able to replicate the problem on his ML310 as well (although maybe not the 
> intermittent sysACE load method). The boot loader method is >95% likely to 
> hang/crash whereas the sysACE loader is more troublesome to replicate.
>
> The boot-loader method of vxWorks still almost always fails-even though 
> before jumping to the vxWorks RAM image I do a checksum verification of 
> actual file vs. RAM copied image and if mismatched-won't jump. But worse 
> yet, now it seems that vxWorks also occasionally (well, more than 
> occasionally-anywhere between 2.0% - 30.0% of tries) hangs even when 
> booting via the sysACE controller load method (ie the JTAG). I begin to 
> suspect a Xilinx driver issue or driver interaction issue with our CF card 
> (same behavior also being observed on Xilinx provided CF that came with 
> the ML310).
>
> Some data points to note:
>
> 1)       When we hang, it appears the /wait line and rdy-/busy lines on 
> the CF are permanently low-which is most assuredly not a good thing.
>
> 2)       Sometimes the hang generates sysACE error LED. Even if not lit, 
> the signals /wait & /busy on the CF are always 0.
>
> 3)       I NEVER hang on CF accesses at the booter/ no vxWorks code level. 
> However, I find myself asking "is the vxWorks crashing because some CF FAT 
> lib operations at the booter level have left the CF or sysACE in a bad 
> state?" I am using Xilinx's FAT Fs Library on a CF that's formatted FAT16. 
> I also memset the 1st 64MB of DDR to 0 to ensure no leftovers from 
> previous boot attempts.
>
> 4)       I caught one of these sysACE error LED conditions and then used 
> XMD to query the CF registers. The following is the dump: (our sysACE core 
> is at 0xCF00 0000 base address):
>
>
>               ****************XMD% mrd 0xCF000000 32 b
>
> CF000000:   00              CF000001:   00
>
> CF000002:   00              CF000003:   00
>
> CF000004:   34   4         CF000005:   42   B
>
> CF000006:   35   5         CF000007:   00
>
> CF000008:   80   ?         CF000009:   00
>
> CF00000A:   00             CF00000B:   00
>
> CF00000C:   00             CF00000D:   00
>
> CF00000E:   00             CF00000F:   00
>
> CF000010:   6B   k         CF000011:   00
>
> CF000012:   00              CF000013:   00
>
> CF000014:   16   ?        CF000015:   03   ?
>
> CF000016:   0C   ?        CF000017:   10   ?
>
> CF000018:   0A             CF000019:   08
>
> CF00001A:   00             CF00001B:   00
>
> CF00001C:   02   ?       CF00001D:   00
>
> CF00001E:   00             CF00001F:   00
>
> In particular the bits of interest in this dump are:
>
> STATUSREG @ 0x4-0x7 offset:  bit2: CFGERROR "error has occurred in the 
> Compact Flash controller"
>
> ERRORREG @ 0x8-0xB offset: bit7: CFGREADERR "an error occurred while 
> reading configuration information from Compact Flash"
>
> CONTROLREG @ 0x18-0x1B offset: LOCKREQ is set true and RESETIRQ is true.
>
> 5)       When the error occurs, it's as if the PPC is no longer executing 
> code.
>
>
> So to summarize:
>
> 1)       Why the behavior of vxWorks boot seems to vary depending on 
> whether the bin executable was loaded via the PPC using Xilinx FAT Fs 
> library versus the vxWorks executable being loaded by sysACE controller 
> (as an appended image to the ACE file)? What is sysACE doing to CF/himself 
> after loading that the boot code/sysACE load of the boot code is not?
>
> 2)       Why vxWorks hangs on std file i/o operations (intermittently)
>
> 3)       Why even with errors occurring in the sysACE controller 
> registers, does the system permanently hang-or put another way, "shouldn't 
> the drivers recover gracefully when errors occur on the sysACE 
> controller/core?"
>
> At first I thought the issue had to be a problem with the Xilinx FAT calls 
> or the loader itself--but after verifying checksums of actual file vs the 
> RAM copy of vxWorks binary file, I would hope to have ruled this 
> possibility out-- and now that sysACE loads are also hanging, albeit much 
> less frequently, I'm thinking a HW or driver issue?
>
> Are there are any other signals I should be looking at? Anyone have any 
> idea of other things to try? Or have the name/email of someone at Xilinx 
> that could shed light on this issue? I've tried everything I can think of. 
> Unfortunately it seems the FAEs are extremely overburdened and finding 
> someone knowledagble of EDK and vxWorks is not easy to begin with..... (Is 
> someone from Xilinx corporate listening????)
>
>
>
> Thanks,
>
> Paul
>

Paul,
  I saw something somewhere on the net, looked but could not find it again, 
saying that they were having lots of trouble writing to the CF.  They 
thought the sysace interrupt was firing all the time, and they could not 
turn it off and or handle it correctly.  I had some problems getting my 
little program going.  I ended up having the EDK generate the sysAce file 
and dragging the file into the compact flash rather than doing it via 
impact.  I also had another problem where sector 0 on the CF got trashed, 
and I had to redo stuff with fdisk via a linux system to get it "write" 
again. excuse the pun.  In a former life, I did some VxWorks stuff and filed 
a problem report.  They pretty much called me every few days to status 
whether I had made any progress solving the problem. ;,)  It sounds like you 
are at a higher level of sophistication than I am.  I was thinking that heh, 
SysAce ain't so bad, but it sounds like more fun is waiting for me.

regards
-Newman 



Article: 80223
Subject: Re: Signal Integrity, ground bounce, crosstalk, SSOs, BGA pin-outs, parasitic inductance...
From: "Peter Alfke" <peter@xilinx.com>
Date: 2 Mar 2005 13:03:19 -0800
Links: << >>  << T >>  << A >>
There was no hanky-panky.
We designed the dual-board to be as good as possible, and strictly
identical (or fair) on both halves.
And Howard did his analysis with no pre-conceived answers.
Marketing was completely out of the loop (doesn't always work that way)
and Howard Johnson has obviously too much invested in his own
reputation to even think of risking that on any shady deals...
This was pure science, and a fun project.
That the results are heavily in our favor is a just reward for having
designed things the proper way.
Peter Alfke


Article: 80224
Subject: Re: Signal Integrity, ground bounce, crosstalk, SSOs, BGA pin-outs,
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 02 Mar 2005 13:05:58 -0800
Links: << >>  << T >>  << A >>
Jacques,

A socket makes things worse, but only by the dimension of the distance 
as a ratio to the total distance.

So, for HJ, he assumed a 0.035" trip into the pcb, and a smaller number 
for the package (because packages are thinner).

Add another ? inches (or cm, mm, or whatever) and that makes the 
vertical loop larger, and will increase the noise in the proportion of 
the added distance. Yes, a socket makes it worse.

That is why there are (very expensive) low profile sockets (to reduce 
the inductance of the socket path).

Sockets just make everybody worse.  If the toal loop is small to start 
with, then doubling it doubles the noise.

If the loop was terrible to start with, adding the same distance to it 
as before hardly makes anything worse.

One thing is true:  once you start with a good package, you can make it 
worse (with a socket, or bad pcb layout).

It is also ture that once you start with a marginal or poor package, 
there is nothing at all you can do to make it better (and hardly 
anything makes it worse because it is so bad already).

A comment that was made, but HJ couldn't get to answer was: "If you use 
virtual grounds (IOs as ground), won't that improve the noise (make it 
smaller)."  The answer is yes, it will.  But, using IOs as grounds is 
not as effective as a real ground, and any part that uses IOs as grounds 
improves (does not uniquely apply to a bad package only).

Prior to the V4 packages, we had made as many improvements as we could 
have made at that time, knowing what we knew.  Those V2, V2P packages 
don't fare (all that) poorly in comparison to the new SparseChevron 
packages (worse by ~2:1 in terms of inductance of loops), but are still 
better than other 'competitive' FPGA packages.  As HJ said, it is all in 
the number of power and ground pins, their arrangement, and the 
bypassing on chip (to make power and ground pins equivalent from a 
signal return point of view).

Austin

jaxato@gmail.com wrote:
> It was a good presentation, got to learn a couple of new thing, and
> have new ideas. Right now, I have a question though, about packaging
> and interconnection. I was just looking at the old AFX prototype board
> for the venerable XCV series of FPGA, and then I ask myself that
> question of how does those P4 chip actually resolve their SI issues,
> without using BGA and being placed on sockets! considering they draw
> ~50W (i might be wrong here, but its a lot of current...); wouldnt this
> introduce parasitic inductance, hence ground loops and eventually noise
> induce in "victims" pins?
> 
> thanks
> Jacques
> 



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