Concurrent writes in multi-ported memories

Use the MegaWizard to instantiate a dual-ported RAM. I recall there are some settings towards the end regarding whether you want to read old or new data. Those parameters get translated into generics. You can read the generics from the altsyncram instance that gets created.

I typically do this to get the generics correct, instantiate the altsyncram directly, and delete the megawizard instance.

Cheers,

Dave

Hi Dave,

I think what you are saying is about the read-during-write behavior right? But I was looking for conflicting writes ( what happens when more than 1 port, say in a 4W/8R memory try write to the same location in the same clock cycle).

There are algorithms for concurrent writes in a "shared memory" . But I couldn't find anything for multi-ported memories..

--- Quote Start ---

I think what you are saying is about the read-during-write behavior right?

--- Quote End ---

I guess that must have been what I was recalling :)

--- Quote Start ---

But I was looking for conflicting writes ( what happens when more than 1 port, say in a 4W/8R memory try write to the same location in the same clock cycle).

There are algorithms for concurrent writes in a "shared memory" . But I couldn't find anything for multi-ported memories..

--- Quote End ---

An FPGA has at most dual-ported memory. If you wanted to emulate more ports, then you could, using a higher-frequency for the memory controller. If the memory only needed to be operated at one frequency, then your controller could perform two writes every clock, except for the case of a write to the same location. In that case, you would just discard the one that would have been over-written. If your ports are all at different clock frequencies, then you will need a FIFO on every port. Those FIFOs would contain the transaction type, transaction address, and for writes, transaction data.

You could probably construct a Qsys system with clock domain crossing bridges to a single memory.

Cheers,

Dave

Hi,

If you simultaneously write to the same address of a dual-ported memory from both ports, the output port value is unknown in read/write clock mode.

However, Altera 7014[/attach]https://www.alteraforum.com/forum/attachment.php?attachmentid=7015 ltera.com/literature/hb/stratix-v/stx5_51003.pdf"]embedded memory documentation (http://www.a[attach=) doesn't list any restrictions on the contents of the memory (at least I didn't see any in the documentation).

Interestingly enough, Xilinx does have such a restriction described in a Conflict Avoidance section of its embedded memory documentation (http://www.xilinx.com/support/documentation/user_guides/ug383.pdf) on page 15.

I'd assume there has to be such a restriction, unless Altera implemented some sophisticated mechanism to handle this case.

Thanks,

Evgeni

Hi,

Dave... Yeah most FPGA s have a dual ported memory. But the author of the paper that I have attached has come up with techniques to build memories for FPGA having more ports using these dual ported memories as building blocks. I have done the same. All the ports operate at the same frequency. So now that I can build a nW/nR memory I was thinking about handling concurrent writes to same memory location.

Evgeni .. I went through the ' Xilinx - Conflict avoidance for synchronous clocking' . It says : When one port performs a write operation, the other port must not write into the same location, unless both ports write identical data. I too did not find any such restrictions in Altera documentation. I was thinking of implementing some algorithms to handle this situation on Altera fpgas.

I think adding additional user logic to handle concurrent writes to the same memory location from two ports is going to affect performance. What if both sides are doing writes every clock, and what if that clock is very fast (e.g. 300+ MHz).

I've done tricks like implementing byte-enables in Xilinx memories by taking advantage of rising and falling clock edges and doing read-modify-write. But I'm unsure how to handle concurrent writes in general case by simply adding user logic.

Thanks,

Evgeni

--- Quote Start ---

the author of the paper that I have attached has come up with techniques to build memories for FPGA having more ports using these dual ported memories as building blocks. I have done the same. All the ports operate at the same frequency. So now that I can build a nW/nR memory I was thinking about handling concurrent writes to same memory location.

--- Quote End ---

Keep in mind that page 43 of that paper has the statement: "we assume that multiple writes to the same address are prevented by the system using the multi-ported memory, and that the result of

doing so is undefined"

Why try to handle concurrent writes to the same memory location, when such writes make no sense?

Can you provide a use-case of a system where two writes to the same location should be allowed (for a memory, not an I/O port)? As soon as you make the statement that a write on port A always wins, you have a priority for the multiplexing control.

Just an observation ...

Cheers,

Dave

Hi,

Yeah I guess we could solve it using 1) Priority 2) Let the ports write if they are writing the same data 3) Arbitrarily select one of the ports and let it write. I have read that Parallel Random Access Machines (PRAM) use these technique to solve the conflicts. But I don't know if there have been any hardware implementation of PRAMs!

In a multicore environment with shared memory when multiple threads are issued thread , if a thread is accessing critical section other threads are made to wait. Synchronisation mechanism like atomic instructions , locks etc are implemented. I was thinking if some analogy of that sort would work for a multi-port memory where there are multiple ports instead of multiple threads accessing the same memory. Am I thinking in the right direction? I want to do a hardware implementation (not software) to resolve the issue.

Thanks...

--- Quote Start ---

In a multicore environment with shared memory when multiple threads are issued thread , if a thread is accessing critical section other threads are made to wait. Synchronisation mechanism like atomic instructions , locks etc are implemented. I was thinking if some analogy of that sort would work for a multi-port memory where there are multiple ports instead of multiple threads accessing the same memory. Am I thinking in the right direction? I want to do a hardware implementation (not software) to resolve the issue.

--- Quote End ---

The hardware generally provides "features" for the multiple processors to coordinate their shared access to a resource.

This type of issue comes up with PCI/PCIe device drivers too, eg., motherboard/host processor and peripheral board processor communications. Multiprocessor (eg., multiple NIOS II instances). Read the stuff on p7 of this document:

http://www.ovro.caltech.edu/~dwh/correlator/pdf/cobra_driver.pdf

The hardware interlock discussed there is used to implement a Linux device driver on the PCI host side, and a uC/OS-II driver on the peripheral board side. In both cases, the software has to use operating system primitives like semaphores and mutexes, eg., for the interrupt handler to restart a task that deals with communications.

You cannot avoid doing this type of thing when addressing a common resource.

Another typical scenario is communications using a scatter-gather DMA controller. The hardware implements the movement of data based on scatter-gather lists configured by software. When a list entry is moved between the software (eg., filling or removing data) to the hardware (eg., here's your empty list entry to re-use) then hardware interlocks are used, eg., the controller is disabled.

Cheers,

Dave

Since the M9K are synchronous it ought to be possible to add external logic to supress the write signal from one side.

It is also probable that only the bits that are written differently are undefined.

It may even be true that a 0 always wins (or v.v.) - but I suspect that memory blocks may contain inverted data.

We had some problems because SOPC silently ignored the request for 'old data' on 'read during write'. This was a 'Heisenbug' - a rebuild of the fpga with a minor change (anywhere) caused different board to fail.