Hi everyone, I hope this is not too far off-topic.. I have quite some experience with microcontrollers, particularly AVR, and am now starting an FPGA-based project, likely on the Spartan-3E evaluation board with an XC3S500E. One reason for the FPGA was that we need a lot of IO lines there. To make the transition easier, I was thinking if I could just put one of the AVR-based cores into the Spartan and then continue to program it in C. Now, the questions: - Does that approach make sense at all? - How would I update the AVR code for the softcore? Does it reside in the external flash? - How can I access the additional IO lines from the AVR core? Many thanks for your answers, Yours, Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.opencores.org/forums.cgi/cores/attachments/20081111/e1f21a56/attachment.pgp

Hi it depend on if you can find compatible AVR HDL core. If you can find it you can program your FPGA to simulate AVR core in hardware but you need also to change it's behaviour for the additional IO that you want. I believe that this work can not does not suitable for you and the better way is directly program your FPGA with your application. I think that you have a C description of your appliction and you don't want to redescribe it with a HDL. So I suggest you to use High-level synthesis tool which give your C description, synthesis it on your FPGA and then Gereate HDL description of your application. then you can easily program the HDL description on the FPGA. I have many research on High-Level Synthesis tool and there are only one Free synthesis tool. I talked about NISC toolset. this toolset give your application description in ANSI C then generate HDL code for application specific processor which do the behaviour of your C model. this toolset also have a free online version and you could test it's output before downloading. the link is here : http://www.ics.uci.edu/~nisc/ hope it helps Best regards, Alireza Haghdoost 2008/11/11 Florian Echtler echtler at in.tum.de> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/cores/attachments/20081111/f8a34364/attachment.htm

Florian Echtler wrote:


Yes, it does!

You could also put this kind of questions on the
newsgroup "comp.arch.fpga".



If it is not too large you could follow the guidelines
in Xilinx synthesis manual "xst.pdf" to instantiate
some internal RAM or ROM with your desired initial
value.

That device (XC3S500E) has 40 KBytes of Block RAM
available on chip, accessible as 20 blocks of 2 KBytes
each.



The simpler solution is to use a GPIO core from OpenCores.

You are welcome, Fabrizio -- ========================================== Fabrizio Fazzino fabrizio at fazzino.it http://www.fazzino.it/ Simply RISC fabrizio.fazzino at srisc.com http://www.srisc.com/ University of Catania fabrizio.fazzino at diit.unict.it http://www.diit.unict.it/users/ffazzino/ ========================================== -- > Occam's Razor (XIV century)

Actually I did something similar, created a custom AVR-like uC with a spartan 3e, mostly for custom IO. Two easy choices for code generation, both rely on merging init code into declared working SRAM cells. 1. Minimal bootstrap code, enough to set up memory and interrupts before jumping to flash memory for code executing. This is good if you don't want to recompile the FPGA core too much and modifying flash is easier. 2. All code merged into SRAM, there are tools in the xilinx pack for this, but it means you have to regenerate the bitstream every update, which is either very easy or very hard depending on your test/debug setup. If you're more software biased I'd go with the flash path, because pure SRAM can make debugging a little more involved as a process. Alternately, depending on your board, you can use the board SRAM for data and flash for pure execution by mapping flash to the interrupt vector directly and writing simple bootstrap from there to initialize memory locations and interrupts. For IO, you have to create a IO controller, basically have a module connected to the bus, which has its chip select triggered by a particular address range (ie CS is activated when A bus = "111111xxxx", then have the rest of the address bus determine which IO line is read/written. Depending on cycle time you might want to add a data valid bit in there to tell the uC the read is complete, until which the uC should stall. It is a different approach to software design, but personally it's a lot more fun, especially the ability to play with IO simultaneously. Best of luck ----- Original Message ----- From: Florian Echtlerechtler at i...> To: Date: Tue Nov 11 18:08:28 CET 2008 Subject: [oc] Some questions from an FPGA newbie