Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
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"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 AnttiArticle: 80203
"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 FalkArticle: 80204
Less! That's the whole idea... But watch whether your package and density is available. If it is, it will be chaeper. Peter AlfkeArticle: 80205
"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 AnttiArticle: 80206
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 JensArticle: 80207
"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
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 ParuchuriArticle: 80209
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 ABArticle: 80210
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.comArticle: 80211
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
> 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 ABArticle: 80213
"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 AnttiArticle: 80214
"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
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
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 > JensArticle: 80217
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
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 JacquesArticle: 80219
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.comArticle: 80220
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: 80221Hi! 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
"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 -NewmanArticle: 80223
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 AlfkeArticle: 80224
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:
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