own board, design considerations?

[Altera_Forum]

Hi 

 We are going to design own FPGA board based on Cyclone II chip. I have two questions which are confusing us. http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/blink.gif   1. We want to use EPCS64 memory chip as a configuration memory and reset memory of a multiple Nios II processor system. Is this possible? If it is, how should we make the HW-design.  2. Does the EPCS-memory need own programming interface, like in developments kits, or is it possible to use EPCS via Cyclone II JTAG?  Regards,  CoolMan

[Altera_Forum]

--- Quote Start ---  originally posted by coolman@Jan 2 2006, 03:58 AM hi  we are going to design own fpga board based on cyclone ii chip. i have two questions which are confusing us.  http://forum.niosforum.com/work2/style_emoticons/<#emo_dir#>/blink.gif   1. we want to use epcs64 memory chip as a configuration memory and reset memory of a multiple nios ii processor system. is this possible? if it is, how should we make the hw-design.  2. does the epcs-memory need own programming interface, like in developments kits, or is it possible to use epcs via cyclone ii jtag?  regards,  coolman <div align='right'><{post_snapback}> (index.php?act=findpost&pid=11880)  --- quote end ---    --- Quote End ---     I am busy with something similar.   I am assuming that you won&#39;t have external RAM or FLASH ( just the FPGA and EPCS)  During development add a serial port for each CPU. There is just no way it is going to be fun recompiling the code into the FPGA every time you want to test something. You will thus access it very much like a NIOS 1 design.  For code space insert embedded RAM blocks (one for each CPU). For development add the GERMS monitor to each block. The monitor uses about 1.5kb but you can hack out all the flash code (seeing that you will probably not use it). The rest will be available for your own code. Note that C code will create large executables, even for a simple hello-world.  After you have completed your code the (created) SREC can be put in the place of the GERMS monitor. Then just recompile and load the new EPCS data. The chip will start up, load the CPUs and (each) start executing at address 0. Make sure that your code initializes everything (required) that the GERMS monitor does. Make sure that the development SREC is compiled at a location greater than the last monitor byte and that the production SREC is compiled at address 0 (compile option nb -b [address] xxx.c)   As for programming the EPCS: It is not JTAG compatible. If you want to program it directly then buy a ByteBlasterII cable. It is difficult to build yourself. I bought a few units from a friend that did some serious research. Here in South Africa it sold for R400 (about $62 US). You have to route an AS port and download the software directly to the EPCS (very fast).  If you want to go the JTAG route then generate a design with an AS component, write some code to program the EPCS via the Active Serial port. Infact there is an NIOS1 example where you take your POF file and embed it in a C file that is then written to the EPCS. The problem is that you need as much (even more) RAM than the size of the EPCS chip. Not good. A similar option is to write a core, download via JTAG and then feed the EPCS via a serial port (very slow)  Before spending too much time and unsuccessful efforts rather try and obtain a ByteBlasterII cable. But maybe some bright sparky has written something that can translate directly from JTAG to ASMI?   Just remember to optimize your development path. If you skip the UART (or similar- even it is slow) development upload route then you will have very little feedback and you will have to recompile your FPGA each time with the new SREC files. By using something like the GERMS monitor you will lose 1k to 1.5k of precious RAM but you can very quickly change/check something. Here is a suggestion: Build a board with the next biggest device you intended to use, i.e. more RAM. Write the code so that the monitor&#39;s size won&#39;t have any influence(i.e. bigger chip&#39;s memory block size = GERMS size + target code size + bit extra for good luck). Set a target for the final code size. Having more than enough will speed up development. (I have just completed a project where I had too little RAM left and spent 2 weeks optimizing down on a constantly crashing system). When you are finished then port the code to address zero on the target device. I don&#39;t know if you are doing this for fun or for money but remember that your time is worth much more than the hardware. Skimp and you will have a rotten time developing it.   Good luck.  VictorS

[Altera_Forum]

--- Quote Start ---  originally posted by victors@Jan 3 2006, 01:45 PM just remember to optimize your development path. if you skip the uart (or similar- even it is slow) development upload route then you will have very little feedback and you will have to recompile your fpga each time with the new srec files. by using something like the germs monitor you will lose 1k to 1.5k of precious ram but you can very quickly change/check something. victors  --- Quote End ---    You don&#39;t need the GERMS anymore since you can download across the JTAG cable. This takes a processor that is a little bit bigger due to the JTAG debug interface, but is much quicker to download. You can also do the printf thing trough the JTAG clable, but I prefer the UART approach here.  Stefaan

[Altera_Forum]

--- Quote Start ---  originally posted by svhb@Jan 3 2006, 06:51 AM you don&#39;t need the germs anymore since you can download across the jtag cable. this takes a processor that is a little bit bigger due to the jtag debug interface, but is much quicker to download. you can also do the printf thing trough the jtag clable, but i prefer the uart approach here.  stefaan <div align='right'><{post_snapback}> (index.php?act=findpost&pid=11902)  --- quote end ---    --- Quote End ---     True. My guess is that the RAM required will cause the choice of a fairly powerful FPGA thus making it possible to waste a few hundred LEs for the bigger JTAG debugger designs.  BUT :-) with a multiple CPU design you will want each CPU&#39;s input and output under your control. This will imply using more than one JTAG port. The serial port uses less LEs and (with enough serial ports available on the PC, or using more than one PC) you can have a monitor window open for each one.  BTW, to get more serial ports on your PC have a look at the FDTI chip: FT2232. It is a USB to serial (dual) converter. I think it is about $10. You must just clamp the Rx pin on the FPGA as the output is 5V from the FT2232.   The designer has to tradeoff costs and ease of development. I personally would design a board with all external RAM and FLASH, get the code done quickly and then miniaturize it to infinitesimal.   This is infact what I have done so far. My project is now 50% complete. I did the initial design with small Cyclone I device, 128 kb SRAM, 1MB flash and support electronics. The final design will either be targeted for a 2C20 or 2C35 (depending on the final code size) and the appropriately sized EPCS chip.   VictorS