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
I have spent the past few months slowly trying to get a PCI design with Linux 2.6 on the Virtex 4. I have been able to overcome some of the hurdles; however, I am still unable to boot up a working system. If anyone has tried to do this (or has already done this) I would apprecaite any help or suggestions. I can go into more detail as to what I have done and where I am stuck if there is anyone who would be willing to guide me! Thanks, BinArticle: 130301
Hi Mark, markmcma...@hotmail.com wrote: > My project has several ADC channels with 16bit data up to 24kSPS. > > There is no need for each ADC sample to be sent ASAP to the > microblaze, as the data is processed in chunks of 200 samples. A > previous (non-xilinx) version of this project used a FIFO and a burst > read over a PCI bus to a pentium processor. > > Now, reading about FSL it seems that the microblaze has to execute an > instruction to get every sample of data? > What I want is the lowest overhead - given that I can use a FIFO, > would the FIFO with DMA route be better suited to my needs than FSL? As of EDK9.2, there is an plb2fsl_bridge, basically a single channel bridge between the PLB and FSL. So,. combine that with an xps_central_dma and you can DMA directly to an FSL-based peripheral. I really like FSL but the requirement for all data to pass through the CPU is a performance problem, particularly in OS environments such as Linux. Standalone dedicated apps maybe not so bad. If the data is truly sourcing or sinking in the CPU, then direct FSL is OK. But, if memory is your source or sink, DMA is necessary. Regards, JohnArticle: 130302
Walter Banks wrote: > > Jim Granville wrote: >>With the COP800 well past it's commercial life, what >>is the status of 'abandonware' C Compilers for it ? > > We have a COP8 compiler. The COP8 certainly fits the description > because it original implementation was almost identical. Do you still sell any ? > > 8051, Z8 and 6804 would also be on my historical short list. The target has to be smaller than PicoBlaze/Mico8 - otherwise, why bother ? So, 8051 are too large for this project, and I thought of the Modern RS08 (as that does have C compilers ;), but I get the feeling all the multi-byte opcodes, and address variants would not map well onto a FPGA. (so it would fail size) ) Z8 - Nice Reg-Reg scheme, but likely to be close to 8051 in FPGA resource usage. 8048 ? maybe, but no compilers for this ? The best-mapped FPGA small CPUs use 18 bit opcodes, so that makes finding some old chip, with a C-Compiler, unlikely! There is CoolRisc 816, which uses a 22 bit opcode, and does have a GNU C compiler, and some infrastructure ? Again, could be too large... A 24 bit opcode is also possible. It WOULD give faster operation, and more opcodes/KB, than 32 bit opcodes. Not sure how many C compilers, for 24 Bit opcodes ? -jgArticle: 130303
Patrick Dubois wrote:
> I found the source code that was available at edif.org through
> archive.org:
> http://web.archive.org/web/20031204114425/http://www.edif.org/lpmweb/more/vhdl.htm
The internet never forgets ;)
> It looks like complete source code, I'm not sure what additional
> support I would need from vendors. It seems to me that I could just
> use lpm_fifo_dc from 220model.vhd. Am I missing something?
The code is synthesizable as is,
but I would at least clean up the
non-standard libraries and the
odd-ball string generics.
-- Mike Treseler
ps: here's a first cut:
http://home.comcast.net/~mike_treseler/sync_fifo.vhd
Article: 130304On Mar 19, 8:36 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Walter Banks wrote: > > > Jim Granville wrote: > >>With the COP800 well past it's commercial life, what > >>is the status of 'abandonware' C Compilers for it ? > > > We have a COP8 compiler. The COP8 certainly fits the description > > because it original implementation was almost identical. > > Do you still sell any ? > > > > > 8051, Z8 and 6804 would also be on my historical short list. > > The target has to be smaller than PicoBlaze/Mico8 > - otherwise, why bother ? > > So, 8051 are too large for this project, and I thought of the Modern RS08 > (as that does have C compilers ;), but I get the feeling > all the multi-byte opcodes, and address variants would > not map well onto a FPGA. (so it would fail size) ) > > Z8 - Nice Reg-Reg scheme, but likely to be close to 8051 > in FPGA resource usage. > > 8048 ? maybe, but no compilers for this ? > > The best-mapped FPGA small CPUs use 18 bit opcodes, > so that makes finding some old chip, with a C-Compiler, > unlikely! > > There is CoolRisc 816, which uses a 22 bit opcode, > and does have a GNU C compiler, and some infrastructure ? > Again, could be too large... > > A 24 bit opcode is also possible. It WOULD give faster operation, > and more opcodes/KB, than 32 bit opcodes. > Not sure how many C compilers, for 24 Bit opcodes ? Maybe I am missing something, but I have seen CPUs in FPGAs as small as 600 LUTs. I am pretty sure the picoBlaze is about that size. Isn't there a C compiler for that? The OP asked for something that would use no more than 25% of the smallest FPGA in a given family. That is still nearly 1000 LUTs. So why go with anything else? A bit serial CPU might be smaller than an 8 bit CPU, but what is the driving need for something that small? 600 LUTs is not much in a 3000 LUT FPGA!Article: 130305
rickman wrote: > Maybe I am missing something, but I have seen CPUs in FPGAs as small > as 600 LUTs. I am pretty sure the picoBlaze is about that size. I think it is smaller, about 200 LUTs: http://www.embeddedrelated.com/groups/fpga-cpu/show/2028.php > A bit serial CPU might be smaller than an 8 bit CPU, but what is the > driving need for something that small? 600 LUTs is not much in a 3000 > LUT FPGA! Could be interesting to pack it in a Max II, where the smallest device has 240 LEs. Sometimes you need some high speed logic and some more complex tasks, but which can be low speed (keyboard sampling, output to LCD text display). If you can get an additional low speed CPU for free, you could save an external microcontroller. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 130306
Frank Buss wrote: > rickman wrote: > > >>Maybe I am missing something, but I have seen CPUs in FPGAs as small >>as 600 LUTs. I am pretty sure the picoBlaze is about that size. > > > I think it is smaller, about 200 LUTs: > > http://www.embeddedrelated.com/groups/fpga-cpu/show/2028.php And also the similar Mico8 ~240-323 LUT http://www.latticesemi.com/products/intellectualproperty/referencedesigns/8bitmicrocontrollermico8.cfm > >>A bit serial CPU might be smaller than an 8 bit CPU, but what is the >>driving need for something that small? 600 LUTs is not much in a 3000 >>LUT FPGA! > > > Could be interesting to pack it in a Max II, where the smallest device has > 240 LEs. Sometimes you need some high speed logic and some more complex > tasks, but which can be low speed (keyboard sampling, output to LCD text > display). If you can get an additional low speed CPU for free, you could > save an external microcontroller. The serial code memory is part of the appeal. FPGA cores are easy enough, but they are like stone soup, and you need to add code execution storage, = many pins, and EMC and PCB area issues. Single chip uC are a tough nut to crack, as they have FLASH+Analog, and higher volumes and growths than the FPGA sector. -jgArticle: 130307
On 20 Mrz., 06:55, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Frank Buss wrote: > > rickman wrote: > > >>Maybe I am missing something, but I have seen CPUs in FPGAs as small > >>as 600 LUTs. I am pretty sure the picoBlaze is about that size. > > > I think it is smaller, about 200 LUTs: > > >http://www.embeddedrelated.com/groups/fpga-cpu/show/2028.php > > And also the similar Mico8 ~240-323 LUThttp://www.latticesemi.com/products/intellectualproperty/referencedes... > > > > >>A bit serial CPU might be smaller than an 8 bit CPU, but what is the > >>driving need for something that small? 600 LUTs is not much in a 3000 > >>LUT FPGA! > > > Could be interesting to pack it in a Max II, where the smallest device has > > 240 LEs. Sometimes you need some high speed logic and some more complex > > tasks, but which can be low speed (keyboard sampling, output to LCD text > > display). If you can get an additional low speed CPU for free, you could > > save an external microcontroller. > > The serial code memory is part of the appeal. > FPGA cores are easy enough, but they are like stone soup, > and you need to add code execution storage, = many pins, and EMC and PCB > area issues. > Single chip uC are a tough nut to crack, as they have FLASH+Analog, > and higher volumes and growths than the FPGA sector. > > -jg Hi all I wasnt online yesterday (was in Tirol/Austri-not for fun) so I answer all in one "serial implementations of the past" - have worked with COP800 and I had hard days optimizing DES for ST62T10 - none of those is suitable directly, maybe there is something to look and learn, but not much to direct use small FPGA soft-cores (existing ones) - too large - not flexible in configuration options - no real C compilers exist - can not address "flat word" 32bit addressing now some additional considerations: 32 bit ALU for serial implementation cost the same as 1 bit ALU 32 bit registers if implemented in BRAM or data buffer of Atmel Dataflash cost very little (0 FPGA fabric resource) code data memory space cost very little, so opcode density is almost least priority number of cycles per instruction is also very low priority (at least for some optimization options) lets look sone special targets 1) device S3AN-50 ============= if we use picoblaze, we use 30% of BRAM and some small % of FPGA, but we only get 1KW of code and 8 bit processor/ALU a S3/Dataflash optimized SPU could use Dataflash dual ram buffers for registers,ram,stack those not use BRAM at all. Say it would run at 512 clock per instruction, so what? It would be 32 bit processor with 0.1 MIPS leaving ALL BRAMs to the user and almost all of the fabric as well. And it would not cost anything extra as it the Dataflash is already present in the S3AN 2) Actel A3P060/IGLOO60+SD card ========================== SPU should be configured to use half-BRAM for registes, ram,stack and could be executing either from SD-card, again this would be 32 bit processor with c compiler. Actel has no LUT ram option and any known small 8 but softcore would already too be too large also. the code memory price on SD card is virtually 0 3) XXX + Winbond Quad SPI ==================== here we could also achieve some not so bad performance despite the serialized code memory if all of the above special cases would be support by the same C compiler (with settings to adapt to config differences) ? single chip MCU's are hard to crack, but that isnt the goal, in many cases there are "unused" resources present, so the SPU could really come virtually free, besides an extra IC + extra 0.80 USD is still extra cost for additional MCU in the system AnttiArticle: 130308
On Mar 18, 11:28 pm, Antti <Antti.Luk...@googlemail.com> wrote: > 1) VERY small when implemented in any modern FPGA (less 25% of > smallest device, 1 BRAM) > 2) be supported by high level compiler (C ?) > 3) execute code in-place from either serial flash (Winbond quad speed > SPI memory delivers 320 mbit/s!) or from file on sd-card I can see cases where this could be useful, where there's a need for a complex state machine, but not necessarily super fast processing. IMO, the most critical aspect of such a core is that it's easy to target a real C compiler, like LLVM, for it. Thus I strongly suggest a plain-jane orthogonal *32- bit* RISC, ideally without delay slots or special purpose registers, etc. Maybe one of the existing ones (MIPS, MB, Nios II, Mico32, etc) is already suitable enough, which would save the effort of building a new tool chain, but they may be too big. AVR is an interesting example as it was explicitly designed to support C compilation (and it does, far better than PIC). However, 32-bit code ends up suffering badly from having to do everything in 8-bit steps and there aren't really enough registers. Finally, the most impressive little core I've seen is Bernd Paysan's b16: http://www.jwdt.com/~paysan/b16.html It appears there was some effort to port GCC to it, but I don't know the status. Good luck, TommyArticle: 130309
On 19 Mrz., 22:29, Jecel <je...@merlintec.com> wrote: > Antti, > > my impression is that a subset of the 32 bit Transputers with a serial > implementation would be the best tradeoff in terms of complexity and > performance. Or something similar, more modern: http://www.intellasys.net/index.php?option=com_content&task=view&id=35&Itemid=63 9mW per core at 1GHz. Kolja SulimmaArticle: 130310
>single chip MCU's are hard to crack, but that isnt the goal, in many >cases there are "unused" resources present, so the SPU could really >come virtually free, besides an extra IC + extra 0.80 USD is still >extra cost for additional MCU in the system I don't think the 0.80 USD is so bothersome. As having to make space on a already tight pcb for another chip. Arranging powersupply, decouple, route properly without crosstalk etc.., find a reliable component source etc.. are the factors that makes it attractive to use the least number of components as possible.Article: 130311
In article <47e1a2f1$1@clear.net.nz>, Jim Granville <no.spam@designtools .maps.co.nz> writes >8048 ? maybe, but no compilers for this ? Nooooo... please, please noooo... I still have nightmares.... -- Steve Goodwin... www.p2cl.co.uk (includes contact details)Article: 130312
You may read the device idcode. If received idcode equals to EPM7032S idcode then JTAG is OK. On Mar 19, 10:15 pm, "maxi" <maxit...@virgilio.it> wrote: > Hi, > > is it possible to read a checksum of a > EPM7032S with Byteblaster an Max Plus II without having any information of > how and what can be inside only for test the Jtag is ok? > > If yes how can i do? > > Thanks for any help > > MAX > > EPM7032SEPM7032SArticle: 130313
I just noticed one can get SDHC (SD-card 2.0) with 16 GB capacity for 89 EUR. The limit according to the v2.0 standard for SD-Card is 32 GB. But the layout of the configuration memory (CSD) allows representation of 2048 GB. Guess they have to remove that limit soon..Article: 130314
kennheinrich@sympatico.ca writes: > - Xilinx DLLs and DCM tend to exhibit peculiar behaviour in that their > LOCK output can assert even though the output clock is completely > unstable, or possibly just running at a harmonic, like half-rate. Really!? What's the point of the LOCKED output then? Do that flaw not make them a bit useless? Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 130315
I think someone here mentioned the possibility to configure an Xilinx Spartan-3E fpga with an SD-Card (MMC) in SPI mode. However when checking on this by chance today I found that it seems to not work because: Read commands are defined as: http://www.sdcard.org/about/memory_card/pls/Simplified_Physical_Layer_Spec.pdf READ_SINGLE_BLOCK 0x51 READ_MULTI.. 0x52 But Spartan-3E SPI uses the commands: http://direct.xilinx.com/bvdocs/publications/ds312.pdf Page79 Fast read 0x0B Read 0x03 Read array 0xE8 Or did I miss something?Article: 130316
On 20 Mrz., 13:07, sky46...@trline4.org wrote: > I think someone here mentioned the possibility to configure an Xilinx > Spartan-3E fpga with an SD-Card (MMC) in SPI mode. However when checking on > this by chance today I found that it seems to not work because: > > Read commands are defined as:http://www.sdcard.org/about/memory_card/pls/Simplified_Physical_Layer... > READ_SINGLE_BLOCK 0x51 > READ_MULTI.. 0x52 > > But Spartan-3E SPI uses the commands:http://direct.xilinx.com/bvdocs/publications/ds312.pdf Page79 > Fast read 0x0B > Read 0x03 > Read array 0xE8 > > Or did I miss something? think you missed something. FPGA's can get configured from DATAFLASH mounted in SDCARD plastic (atmel sells those!) and sure mmc-sd can be used in spi or sd mode, but there is extra circuitry required, either mcu or cpld AnttiArticle: 130317
>think you missed something. >FPGA's can get configured from DATAFLASH mounted in SDCARD plastic >(atmel sells those!) >and sure mmc-sd can be used in spi or sd mode, but there is extra >circuitry required, either mcu or cpld I think my point was to accomplish this without adding an extra chip.. Using a MCU/CPLD it would ofcourse work.Article: 130318
On Mar 20, 6:25 am, Martin Thompson <martin.j.thomp...@trw.com> wrote: > kennheinr...@sympatico.ca writes: > > - Xilinx DLLs and DCM tend to exhibit peculiar behaviour in that their > > LOCK output can assert even though the output clock is completely > > unstable, or possibly just running at a harmonic, like half-rate. > > Really!? What's the point of the LOCKED output then? Do that flaw not > make them a bit useless? > > Cheers, > Martin > > -- > martin.j.thomp...@trw.com > TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://www.conekt.net/electronics.html There are input clock specifications for which the the DCM operation is guaranteed, including the operation of the locked signal. Violate those specs, and the DCM is no longer guaranteed to function "properly". This is no different than any other clocked electronic device, and is far from rendering the device/function "a bit useless". AndyArticle: 130319
On 20 Mrz., 13:48, sky46...@trline4.org wrote: > >think you missed something. > >FPGA's can get configured from DATAFLASH mounted in SDCARD plastic > >(atmel sells those!) > >and sure mmc-sd can be used in spi or sd mode, but there is extra > >circuitry required, either mcu or cpld > > I think my point was to accomplish this without adding an extra chip.. > Using a MCU/CPLD it would ofcourse work. well dont think it can be done, would be too good to be true ;) AnttiArticle: 130320
Jim Granville wrote: > Walter Banks wrote: > > > > Jim Granville wrote: > >>With the COP800 well past it's commercial life, what > >>is the status of 'abandonware' C Compilers for it ? > > > > We have a COP8 compiler. The COP8 certainly fits the description > > because it original implementation was almost identical. > > Do you still sell any ? Actually yes, the COP8 is still being used as the core of some special purpose self contained devices. The COP8 has low analog noise and works well hybrid systems. A main stream part as Ulf said it is now rarely used. Walter..Article: 130321
On Mar 20, 1:07 pm, sky46...@trline4.org wrote: > I think someone here mentioned the possibility to configure an Xilinx > Spartan-3E fpga with an SD-Card (MMC) in SPI mode. However when checking on > this by chance today I found that it seems to not work because: > > Read commands are defined as:http://www.sdcard.org/about/memory_card/pls/Simplified_Physical_Layer... > READ_SINGLE_BLOCK 0x51 > READ_MULTI.. 0x52 > > But Spartan-3E SPI uses the commands:http://direct.xilinx.com/bvdocs/publications/ds312.pdf Page79 > Fast read 0x0B > Read 0x03 > Read array 0xE8 > > Or did I miss something? SPI bus means to have one Master and one Slave. SD card cannot be master, you need to have a Master to get the data from! FPGA CONFIG RAM cannot be master, you need to have a master to write the data to the FPGA RAM ! For programming FPGA, you need a master getting the data from SD and writing to FPGA RAM. Larry, http://www.amontec.comArticle: 130322
Jim Granville wrote: > So, 8051 are too large for this project, and I thought of the Modern RS08 > (as that does have C compilers ;), but I get the feeling > all the multi-byte opcodes, and address variants would > not map well onto a FPGA. (so it would fail size) ) Might want to look at 6804. Jack Ganssle's newsletter was recently talking about bit serial processors and I dug out the documentation for the 6804 and was surprised just how similar it was to RS08. The interesting thing about multibyte opcodes is they are generally either address or data fields that get routed to some register or alu and I don't think would be all that complex to implement. Walter..Article: 130323
Andy <jonesandy@comcast.net> writes: > On Mar 20, 6:25 am, Martin Thompson <martin.j.thomp...@trw.com> wrote: >> kennheinr...@sympatico.ca writes: >> > - Xilinx DLLs and DCM tend to exhibit peculiar behaviour in that their >> > LOCK output can assert even though the output clock is completely >> > unstable, or possibly just running at a harmonic, like half-rate. >> >> Really!? What's the point of the LOCKED output then? Do that flaw not >> make them a bit useless? >> >> Cheers, >> Martin >> >> -- >> martin.j.thomp...@trw.com >> TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://www.conekt.net/electronics.html > > There are input clock specifications for which the the DCM operation > is guaranteed, including the operation of the locked signal. Violate > those specs, and the DCM is no longer guaranteed to function > "properly". This is no different than any other clocked electronic > device, and is far from rendering the device/function "a bit > useless". Ahh, that makes more sense. I misunderstood the original statement to be a bit wider than that! Thanks, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 130324
Steve Goodwin <ng@p2cl.co.uk> writes: > In article <47e1a2f1$1@clear.net.nz>, Jim Granville <no.spam@designtools > .maps.co.nz> writes > >>8048 ? maybe, but no compilers for this ? > > Nooooo... please, please noooo... I still have nightmares.... You too? Perhaps we should start a support & recovery group. Didn't you just *love* how you could insert a line of assembler, and trigger half a dozen errors elsewhere due to code crossing the page boundaries? -- John Devereux
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