Hi,FPGA: Cyclone V SoC On-chip Memory: Ram, True Dual Port, single clock, Old_data Two NIOS will have access to the ram (NIOS A to Ram port S1, NIOS B to Ram port S2) In Altera documentation of On-chip memory implementations page 8 (link: http://www.altera.com/literature/hb/cyc/cyc_c51007.pdf) it is written that True Dual Port Mode support "two write operations". Also in Altera documentation (link: http://www.altera.com/literature/ug/ug_ram_rom.pdf) Page 4-8, shows that if two Write operations to the same address happened at the same time, an unknown data will be written to that address. Conclusion: the two write operations to the same address at the same time should be avoided. Question: How to avoid write/write collision? My suggested solution: create 1 bit bidirectional PIO and connect it to the both NIOS's (without exporting it to outside Qsys) https://www.alteraforum.com/forum/attachment.php?attachmentid=8962 For example: NIOS A should read(check) this bit if it is "1" (1 means write in progress) and wait till it goes to "0", then NIOS A will set this bit to 1 and make the required writing, after that it returns the bit to "0" ....same for NIOS B Is this an efficient solution? How can I implement similar behavior in Quartus? (not in NIOS) Best Regards hbs
Hi HBS:The most efficient solution is to limit memory ranges, so NIOS A can write, only X range but read Y range, and NIOS B can only Write Y range but Read X range. Now you eliminate the issue where both write to the same address (unless you have a coding memory leak) If you are going to allow both processors to write to all the memory, then I suggest you make one the Memory Manager, where the second processor must request, then receive approval for that memory access from the "Master" processor. This avoids timing conflicts, where Processor A and B both want to write, they check, and the other processor is not writing, so they both set their write bit and start writing at the same time.. Pete
Hello Pete,The idea of connecting both NIOS to the same Ram is to let them exchange data between each oother. I mean, both of processors needs some data from each other, and each defined data will be saved in a predefined address in the Ram, and Processor A will write to this predefined address, at the same time(or later) Processor B could read or write also to the same address. My question was if it is really efficient to implement such memory manager in C code? I am talking here in the aspect of timing. In C code I know how to do it, but if it should be done in HDL, I can not imagine how to do it. Best Regards
You cant really avoid it in HDL code. If both sides were using the same clock, you could give one side preference over the other, and disable the write enable for the other side. But on different clocks, the clock domain crossing would prevent that.The easiest way would be to have just two memories. A -> B comunication and B -> A communication.
You only have to worry about concurrent writes to the same memory cell.Read up on Dekker's algorithm, and use it to get the required exclusive access. Or just arrange the interface so that the code ensures that both cpus are never going to write to the same location at the same time. I just found http://cs.stackexchange.com/questions/12621/understanding-petersons-and-dekkers-algorithms The 'turn' location could be written concurrently by both cpus, but if you just test odd/even in the Peterson case that won't matter.
Xilinx embedded memories have the same problem, of course. However, it has an attribute RDADDR_COLLISION_HWCONFIG to mitigate the effect of a collision.It's described on page 33 of this user guide: http://www.xilinx.com/support/documentation/user_guides/ug363.pdf
No - that Xilinx constraint is an additional one (I don't think and Altera memory has that constraint), the link to page 17 gives the equivalent to the altera constraint.
Thanks all for your inputsI think the easiest way would be, to make an exclusive ram or address range for each CPU to write into it. However it would be nice if Altera implement such collision prevention in thier IP core.
I think the collision prevention would be quite a logic burdon, hardly used and difficult when the two processors are on different clock domains. Unless some major customers asked for it, I cant see it making it into the core.
You'll probably need some kind of mutual exclusion lock anyway - most likely if two fields must be updated together.Commenting in the code which cpu writes to which variables (or structure members) will highlight any places where you might have a write-write collision. Separating things out completely will generate ugly unmaintainable code.