Honored Contributor
Honored ContributorHi,
--- Quote Start --- originally posted by lucky@Nov 8 2005, 06:09 AM in the paper you said, the erika enterprise utilized the mutex in their design, which is no problem. however, if the erika enterprise utilized the mailbox in their design, i think which mayber have some problem.
since :
1 mutex can only allow one cpu to operate the shared memory (including read and write),but, only one cpu can read or write the shared memory at the same time by binary semaphores. it is no problem to the shared memory.
mailbox is basically equal to two mutex. one mutex can only allow one cpu to read the shared memory, and the other mutex can only allow one cpu to write the shared memory. in fact, mailbox is equal to allow two cpu to operate the shared memory at the same time. therefore, the operation confusion maybe appear to same address at the same time.
for example : the digital collecting and analysing instrument have two task, one task which use one cpu to do collecting work will write data from a/d tranlator to shared memory whose address is 0xc0000000, the other task which use the other cpu to do analysing work will read data from the address is 0xc0000000 to the cpu. if two tasks will run at the same time, the operation confusion problem will turn forth about the 0xc0000000 address. therefor, i think mailbox maybe have some problem to protect the address. probably, we can use some software to solve the problem by mutual
excluding mechanism . --- Quote End --- About the mailbox not working when one CPU wants to write from an address and another wants to read the same address: I think there should be no problem, because the altera_avalon_mailbox_pend is a blocking call that only returns when there is data to read, whereas altera_avalon_mailbox_get is a non-blocking primitive that will return EWOULDBLOCK if there is no data to read. About ERIKA Enterprise and the mailbox: The idea is that using ERIKA Enterprise there is no real need to use a mailbox, because a mailbox: - tends to impose a fixed assignment between "who reads" and "who writes" (the mailbox is needed only on a multiprocessor system, and you probably need to change your hardware and application structure if you want to change it, e.g. moving the two tasks to the same CPU to reduce costs) - requires to manually specify the mailbox addresses (this can require some effort and bookeeping if you have a lot of mailboxes) The ideal scenario is that users should be able to write the code in a way as much independent as possible from the CPU that will execute it, without taking care of allocations of memory regions and so on (the linker should do the job). I perfectly understand that the last statement is kind of fuzzy; for that reason, I'll prepare a small example that implements a FIFO queue without requiring any bookkeeping. I'll post a message again on this thread when it will be ready. --- Quote Start --- originally posted by lucky@Nov 8 2005, 06:09 AM 2 seem, there have some problem in the software about startup barrier when resets the multi-core cpu.
<div align='right'><{post_snapback}> (index.php?act=findpost&pid=10833)
--- quote end ---
--- Quote End --- Can you be more specific about the issue you had? In general, there are some aspects that have to be set up when using the startup barrier, in particular: - the mutex should be configured to have an initialization value that is different from 0 - the debugger does not reset the Altera mutex when the debugger start a new program... That means the FPGA have to be reprogrammed each time you want to restart debugging the system - to start an application, you have to start -all- the CPU, that will block at the StartOS() primitive. When all CPUs reach the StartOS primitive,all the CPU will unblock. As the last thing, the next version of ERIKA Enterprise (planned in around 2 weeks) will have the startup barrier separate from the StartOS primitive as well as the support for Nios II 5.1. bye Paolo
