Dual clock memory

[hdr81]

Hi,

I need to implement a dual clock synchronous RAM on clock-driven logic.

In other words, the RAM is written in one clock domain and read on another clock domain.

I was not successful placing “Write Memory” and “Read Memory” nodes on different clock-driven loops. It is not synthesizable (see attached file).

I also tried the "Block Memory Generator" Xilinx IP and was not successful as well.

The problem with the Xilinx IP is that it generates a single block for both ports. Therefore, I can’t place “half” the node in one clock-driven loop and the other “half” on a different clock-driven loop referring to the same memory.

To use a FIFO is not a valid option. I need to control write and read address.

Need help!

Regards,

Henry.

[ks30]

Hi Henry,

From the LabVIEW Communications Help for the Write Memory VI:

Write Memory (Clock-Driven Logic)

http://www.ni.com/documentation/en/labview-comms/2.0/cdl-node-ref/write-memory/

"You can use a target-scoped or VI-defined memory item to store data and access it from a different clock domain only if you implement the memory item using block memory. In this implementation, you can use only one writer node and one reader node for each memory item."

Is implementing the memory item using block memory feasible for you?

Regards,

Kyle S.

[hdr81]

Hi Kyle!

In fact, it is already configured to be implemented as block memory and is not working out.

In the Shared Resource Collection file (.grsc), the memory storage is configured as “Block RAM”, and not as “Look-Up Table”. See the attached .png file.

I’m also send you a sample LVCOmms project, so you can try it out.

Regards!

Henry.

[ks30]

Hi Henry,

We are looking into this behavior.

As a workaround, would it be feasible for you to use register(s) instead of memory items?

There is an example of using registers to transfer data between clock domains at the following location in Comms 2.0:

Programming FPGAs>>Clock-Driven Logic>>Multiple Clock Domains

One drawback of this would be of course that this wouldn't scale well. 

Regards,

Kyle S.

[hdr81]

Hi Kyle,

Unfortunately, for my application it has to be a memory, which is used a Look-Up Table for a Digital Pre-Distortion (DPD) linearization design.

Please let me know whenever you have a solution.

Regards!

Henry.

[ks30]

Hi Henry,

Unfortunately it looks like the documentation is incorrect in this case and using memory items to cross clock domains is not currently possible in Comms 2.0.

Can you elaborate on how much data you would be transferring from one domain to another?

You could potentially do bit packing to transfer the data using FIFO(s), and then store it in a memory item in the second clock domain only.

Regards,

Kyle S.

[hdr81]

Hi Kyle,

I need 3 U32 memories with 1024 addresses each.

I'll try some workaround.

Is this feature planned to be included in the next Comms version?

Regards,

Henry.

[ks30]

Hi Henry,

It is on our roadmap but, right now, I unfortunately can’t commit to a specific release for this feature.

Did you have any success identifying a workaround?

Regards,

Kyle S.