Stratix 10 Dual port ram with byte enable

[aesq]

Hello,

It is known that the Stratix 10 does not support true dual port ram with byte enable.

But would it be possible to have a dual port ram with 2 different clocks,

where one port uses the byte enable and the second port without the byte enable?

Idea is to have one port using the functional part of the design which requires the byte enable,

while the second port is used as a backdoor port to read or write the RAM content.

And for this we do not need the byte enable on the second backdoor access port.

Kind Regards,

Alex.

[sstrell]

No reason why you can't add additional logic to get the behavior you desire.  It wouldn't be part of the OCRAM itself but could mimic the behavior, similar to feedback logic that gets added to have new data writing.

[roeekalinsky]

Hi @aesq ,

You didn't say which of the available memory types you're referring to. I'm assuming you meant M20K block RAM.

The Stratix 10 M20K block RAM supports TDP operation in aspect ratios of either 1K deep X 20 bits wide or 2K deep X 10 bits wide. And multiple M20K block RAMs can be combined in various ways, depth-wise and width-wise, to construct larger memories.

You can physically construct your logical memory with byte enables by breaking it up width-wise into byte lanes. Implement the memory from multiple 8-bit wide lanes, where each lane is implemented using one (or more depending on depth) M20K block RAM, physically configured to use the 2K deep X 10 bit wide aspect ratio. And implement your byte enables by logically ORing them into the corresponding write enable of each lane.

Anyhow, this may even be a more detailed explanation than you need for your purpose, depends on what you're trying to accomplish. Ultimately, for most applications, you don't need to explicitly instantiate and configure M20K resources in your code. You'll be best off simply inferring the memory characteristics that you need in plain RTL, with the appropriate number of pipeline register stages, and then let Quartus map that inference efficiently to the the available physical resources. You should still go back and verify that Quartus implements it in an efficient manner as intended, but generally it should if you inferred your memory properly.

-Roee

[aesq]

What I do is that I provide a dual port RAM RTL code to Synplify and the generated verilog netlist is used by Quartus.

Synplify says that dual port ram is not supported in Stratix 10, which is the case.

Same RTL code also fails when synthesized in Quartus.

Do you have any other RTL code proposal that Could be used and Working for Synplify and Quartus?

I cannot copy my code or attach it, it is blocked by the company...

[roeekalinsky]

Hi @aesq ,

Upon closer inspection of your original question, I now see that the byte enable aspect of your question is actually just a red herring.

I believe that the fundamental limitation you're running into is that the Stratix 10 M20K block RAM does not physically support true dual port ("TDP") operation with independent clocks. That's even without byte enables.

The Stratix 10 M20K block RAM does support simple dual port ("SDP") operation, i.e. one read-only port and one write-only port, with independent clocks. But not true dual port, i.e. two independent read+write ports.

So, bottom line, you should consider taking a different approach to handling the clock domain crossing.

You could potentially emulate TDP behavior using logic around the physical block RAM. And in fact I think Intel may have canned IP available to do just that, although I can't attest to its quality or applicability, I've not used it.

There are also many other (arguably better) ways you can implement the exchange of data between your two clock domains, using a different approach at the design level, not requiring TDP RAM.  For example, using separate paths for each of the two directions of data flow, which could be implemented using SDP RAM.  But that's design architecture, a separate broader topic.

-Roee