Honored Contributor
Honored ContributorHi,
--- Quote Start --- originally posted by lucky@Nov 8 2005, 03:24 PM 1 i have had a looked the <altera embedded peripherals handbook_v5> and <creating multiprocessor nios ii systems tutorial>, but, i can not find the explicit explain about mailbox how to avoid operation confusion to the same between multi-core cpu. since, i always worry about the problem. i think that only "altera_avalon_mailbox_pend" can not account for the problem. "altera_avalon_mailbox_pend" is only a function we can call. we do not know how to design the hardware in the mailbox. therefor, i only doubt the problem, and i can not sure the problem exist, but i can also not deny the problem do exist. --- Quote End --- I do not see big concurrency problems in using the Altera Mailbox. It's a quite simple hardware (basically a concatenation of 2 mutexes), and if you look at the HAL C source code the routines are quite simple too. The only point where there may be race conditions is when they update the read and write pointers, but in general supposing a 32 bit bus width the write accesses are done in an atomic way by the Avalon Bus so there should be no problem... Another point is whether to use it or not. IMHO although for small designs it is for sure a good solution, in general the solution does not scale to larger designs because it forces the modification of the hardware and of the software to modify the message passing structure of the application, and forces the manual accounting for the mailbox space... --- Quote Start --- originally posted by lucky@Nov 8 2005, 03:24 PM 2 erika enterprise use the mutex in its design. the software is based upon the mutex which control cpus to the one and only. it is right when the multi-core resets. but, if erika enterprise use the mailbox in its design when the multi-core resets, there maybe some problem about cpus initialization early or late. since, mailbox can not control cpus to the one and only to access. this is only the guess.<div align='right'><{post_snapback}> (index.php?act=findpost&pid=10849)
--- quote end ---
--- Quote End --- Sorry but I did not understand the statement... We propose the usage of a single Altera Mutex, which is used only when needed (that is, when multiprocessor issues comes in the game). Its usage is hided to the programmer, that only have to think at the functionality that have to be implemented. The code generator and the kernel code will take care of the rest. Just to give you an idea of what I mean, I wrote a simple FIFO message passing demo (you can download it at http://www.evidence.eu.com/nios2/literature.asp (http://www.evidence.eu.com/nios2/literature.asp)). If you try it, you will find that in the demo there is no need to take care of which CPU the tasks using the FIFO are allocated to (you can even move tasks around the various CPUs without changing the code), and there is no need to account for the space allocated to the Mailbox data (the code configurator will take care of the allocation of the data and of the cache disabling for -all- the access to the shared data structure). bye Paolo
