Hello everybody!It's my first post on this forum so a quick presentation to start : I'm a french student in the engineering school Polytech'Paris UPMC and I'm actually working on FPGA for a telepresence robot project. The robot we are working on is a telepresence robot which will be controled by internet. This robot must enable the user to interact with the robot environment using bidirectional sound and video transmission between the robot and a computer. The robot is connected to the Internet using an Ethernet connection to a Wifi-Ethernet bridge. I'm working on a NiosII system running uCLinux and we are very satisfied by this solution which works perfectly for the moment. The problem is that we need a more powerful system to achieve some video compression for example, and a single NiosII processor running uCLinux will not be able to provide us the computation power we need for that. That's why I am thinking to the possibility of using a multi core system. My idea is to use only one NiosII running uCLinux, and an other to run a C program compiled with the Nios IDE just to perform some video compression and to stock the data in a shared memory between the two processor. I think that it is possible, and because we are working on DE2-70 board, we have enough memory to do it. It is possible to associate each processor with a JTAG UART Ip and to program them separately, but we will not be able to use this solution because we need the board to boot in autonomy. So after this long (long) introduction, here is my question. Is it possible, and if yes how can we do it, to use the flash memory of the board in order to program the RAM of each NiosII which will run two different and independent programs ? I think that it is impossible to share a CFI flash between the two NiosII due to read/write conflict. I've red that it could be possible to make one CPU programming the RAM of the second but I don't know how to do that? Thank you very much Nicolas
You could use the first nios to control the second.Just expose the 'soft reset' lines to an avalon slave, so it stays in reset until you've copied the code (presumably small) into the instruction memory.
Hi!Thank you for your answers! Concerning Sheldon you're right it's really similar ^^. I don't know where this idea come from, it was suggested by our school but I think that the idea come from the San Diego State University because we are working in partnership with them. Concerning my question, I understand what you suggest dsl. It certainly could be a solution. I'm thinking to another thing. Is it possible to share the Flash memory between the two CPU, and to lock one CPU in reset until the first finish reading the content of the flash. Next, when the first CPU is running and don't need more access to the flash, it unlock the second which can read from the flash without conflict. Could this be a solution? The problem with sharing the flash memory is that no mechanism enable the user to secure the access because the two CPUs are independent, but if the CPUs are not reading from the flash at the same time, it can work no? I don't know if I forget something... Thank you, Nicolas
If you need to assure uniform access and data caches coherence, the method you described will work if implemented correctly. If you only need to guarantee and arbitrate you just need one tristate bridge for both processors.
Thank you for your answer!Ok I think I understand the use of tristate bridge you suggest. In my case, I have no need to arbitrate flash access between processors because the flash memory will only be used in order to load the program for each processor. After both processors finish loading their code, they will never access the flash again. That's why I am looking for the easiest solution, and simply holding a CPU in reset until the first finish its access to the flash is quite simple. I can easily use a PIO linked to the first processor to lock the second in reset state until the first finish loading its code from the flash memory. I'll try this solution and I'll give you the results. Thank you, Nicolas
Hi Nicolas. I am very interested in this kind of a system. My project is a cpu custom designed to run C code such as you are proposing. I would like to see how it's performance will compare to Nios, but for now it looks like SOPC builder can be used to configure the system with 2 processors(in fact I think the SOPC video does just that. Possibly it would be better to have one processor to wait until the other finishes controlled by code rather than a hard reset. The Avalon fabric used by SOPC could have a master controlling the memory and the 2 Nios accessing the memory via an Avalon slave. Then by sending messages between the cpus one can wait until the other finishes.
I understand what you suggest but I think there is a problem. To send messages between CPUs, they need to have code loaded into their program memory. In my case, the target is just managing to program the Program memory of each processor using the same Flash with a system as simple as possible. So if I can leave one processor paused until the second finish reading from the flash, it will be ok.
The Avalon bus will arbitrate between the 2 cpus' (or any other master's) accesses to flash, the only issue with flash will be erases and writes.Intercommunication is probably best done through uncached accesses to an internal memory area (possibly tightly-coupled to both cpus). If you need a larger shared buffer (in external memory) then take care to flush/invalidate the caches and use the internal memory for synchronisation (etc). For synchronisation look upo Dekker's algorithm.
I took a look in the altera documentation and it's recommended to have a third NIOS just to read from the flash and write to ram the others two NIOS2 CPUs instructions
hi......you can put one cpu to write ...... and 2 cpus reads....... if cpu 2 want to write send data to onchip for example and send a flag for another cpu write to flash ...... at the starts one of then need to start first ........ the two cpus only can start at same time if you had more than one flash...... you can put a cpu_reset_request pin at cpu at sopc_builder and conect at a pio in another cpu......... one cpu starts normaly and the other start at reset..... after the first cpu starts you can set the pio and start second cpu using the same flash..... you can put two system at sopc buider and put a onchip memory with two cpus conect share data bus.......to communicate the two cpus.... no problem with share data bus because you put this onchip working with lower clock (tip) than cpus....... cheers Franz Wagner
What about making your compression some hardware blocks a la c-to-hardware compiler? There are other options especially around the internet that will do this type of compilation for you for free, but I can't speak to their actual performance. IF you can port your algorithm to hardware it will certainly be faster than a software implementation.
--- Quote Start --- What about making your compression some hardware blocks a la c-to-hardware compiler? There are other options especially around the internet that will do this type of compilation for you for free, but I can't speak to their actual performance. IF you can port your algorithm to hardware it will certainly be faster than a software implementation. --- Quote End --- can u explain ????? i cant underestand..... sorry......
Altera has a tool that can help you take a section of standard C code and turn it into a hardware accelerated module which you use in your FPGA instead of the code algorithm. I have seen other sources for c-to-hardware compilation but the links escape me right now.http://www.altera.com/devices/processor/nios2/tools/c2h/ni2-c2h.html You may also find an open source core that does video compression for you through OpenCores.org.