Dual port memories utilization

[mattsini1]

Hi, I am working on the physical ASIC implementation of this IP. I am integrating this IP into a new chip and I am having issue with the xilinx dual ports dual clock memories instantiated into dualmem_widen8.sv and dualmem_widen.sv
I would like to know how this memories are used by the IP and if the two ports 2 clocks mem are strictly necessary for it.
Thank you

[jrrk2]

The basic Xilinx block memory is 16K or 32K by 1 bit. Obviously for an ASIC implementation you would want to maximise the size of your RAM macro to reduce the overhead of power stripes etc. With regard to the dual porting it comes for free in Xilinx so there is no reason not to use it. On ASIC there will be a power and area overhead, and possibly limitations on size. Data arrives on the Ethernet asynchronously to the CPU and though you will not access a packet before it is completely received, there is the issue of contention between reading one packet and the Ethernet writing the next. The widening function maps an 8-bit data stream from the Ethernet onto the 64-bit bus of the CPU. You can achieve the same function using a multiplexer and write-enable bits to your ASIC memory. You can operate the RAM at double the clock speed to avoid contention between Ethernet writes and CPU writes. Another issue is that on FPGA the Ethernet write speed will be fast relative to the CPU, on ASIC the CPU will be much faster but the Ethernet will be much the same. This could lead to verification issues that would have to be sorted by lengthy ASIC simulations. In an ideal world the Ariane would have a DMA slave port that could be interfaced to the Ethernet stream. This is the way Rocket does it in some instances. It is more efficient since it avoids the copy. This requires a coherence protocol that Ariane does not support either. Taking all that into account it should be easily possible to prototype your single-port/double clock speed RAM replacement on the FPGA with appropriate allowances for the limitations of Xilinx and your ASIC ram generator.

[luca-valente]

Hi @jrrk2
as I work with @mattsini1, I'll just jump into the conversation. 😄
Our ASIC generator can produce double-port/double-clock RAMs. The only limitation we actually have is that one port is read-only and the other one is write-only. If my understanding is correct, that should suffice to ensure the functionality of the module. Right?
Thank you very much,
Luca

[jrrk2]

You still need a byte-write mask, and to emulate your new solution to be sure. The Linux device driver doesn’t need access to write to Ethernet device receive packet memory but it is desirable to improve test coverage, which is usually important in an ASIC.

[luca-valente]

I see. Our generator also provides the byte-write enable signals.
Is there a way you could share a verilog testbench for the module? Or is it something that cannot be open-sourced?
Thanks,
Luca

[jrrk2]

I don’t have a test bench, I would recommend putting existing and new versions together in a test bench and send packets from one to the other. You can use the Linux device driver as a template for the testbench.

[luca-valente]

Hi @jrrk2 thanks for the inputs and the information.
One last question 😄 , what about these delay lines?
We have some delay lines for other IPs and we can easily substitute them. Do you recommend any particular delay value (1ns, 2ns ...)? We tried to have a look to the Xilinx specifications but without much success.

Thanks again,
Luca

[jrrk]

Those delays arise due to the hold time requirements of the PHY. You could obtain or develop a model of the PHY to ensure hold time will be satisfied over all scenarios. The complexity of this flow is obviously beyond what I can support in this forum. For this reason ASICs often include variable delays or clock inversions to allow various different PHYs to be used.

…

Sent from my iPhone On 21 Dec 2021, at 15:20, Luca Valente ***@***.***> wrote:  Hi @jrrk2<https://github.com/jrrk2> thanks for the inputs and the information. One last question 😄 , what about these delay lines<https://github.com/lowRISC/ariane-ethernet/blob/master/rgmii_soc.sv#L95>? We have some delay lines for other IPs and we can easily substitute them. Do you recommend any particular delay value (1ns, 2ns ...)? We tried to have a look to the Xilinx specifications but without much success. Thanks again, Luca — Reply to this email directly, view it on GitHub<#4 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAEALVY42KMFDTJRYU3OQ43USCLLPANCNFSM5KDKQJUA>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[mattsini1]

Hi @jrrk2 could please explain me more in detail how the 2 ports are used and who directly interact with these 2 modules? The operations on B port is not so clear to me
From the interfaces of the modules I understand that:

• dualmem_widen8 (RX) uses the port A only for writing and the port B for W/R.
  In this case, who write on A and who R/W from/to B?
• dualmem_widen (TX) uses the port A only for reading and the port B for W/R too.
  In this case, who read from A and who R/W from/to B?
  As @luca-valente already said we have a 2 ports memory that uses the port A only for reading and the port B only for writing.
  Starting from what You already said to us and what I could understand from the instantiation of these modules I thought to instantiate our 2 ports 2 clock memory like that:
• from the RX side on dualmem_widen8 the core reads only from A and someone from outside writes only on B
• from the TX side on dualmem_widen the core writes only on B and someone from outside read only from A
  What do You think about? It could work?

Thank You so much for your time.
Mattia

[jrrk2]

Functionally speaking the tx buffer has a 64-bit r/w interface to the cpu and an 8-bit r/o interface to the Ethernet block. Likewise the rx buffer is the same except w/o from the Ethernet block. But it could be redesigned such that the device driver only needs the type of two-port memory that you have. But to help you further I would need access to your cad system, it cannot be done via this forum.

[mattsini1]

Hi @jrrk2, to be able to switch to our kind of memories and have only one op (R or W) for each B ports, I removed one operation from it ( RX: port B only R , TX: port B only W ) and I ran the simulation on the FPGA.
As the simulation goes wrong and the IP doesn't work properly I would like to ask You what we should do to make it work by removing the W (RX side) and R (TX side) on B ports.
If I well understood, the IP could work with this memory configuration only by modifying the linux driver.
Could we have a meeting to discuss about that also with my team?

Thank You.

[jrrk2]

Sure, we can have a meeting, but you need to share access to your modified database with the modified Ethernet code for review, also what geometry, digital libraries and fab you are using, your preferred toolchain and methodology, and also results from running the FPGA build. I also need to know your milestones for RTL freeze and layout freeze, when you expect to tape out, what the particular skills of your team members are. This is mostly to establish credibility that this is a serious effort that deserves my support. Furthermore there are various improvements to Ariane since my work was done, we need to be sure we use a stable, well tested but fully functional CPU core. Finally, are you in touch with the ETHZ team in case subtle issues arise ?

[daviderossi1982]

Hi Jonathan,

We are all members of the PULP team on Bologna side: https://pulp-platform.org/team.html (Davide Rossi, Luca Valente, Mattia Sinigaglia not yet on the website) hence we have links with all the people in ETH (basically we are the same group) but also OpenHW group where we are actively contributing to the evolutions of CV32E40P (former RI5CY) and CVA6 (former Ariane). For the time being we would just need a short meeting (e.g. less than one hour) to understand what we need to touch on the hw and drivers, and we can take care of the changes. Than if you are interested in establishing a collaboration we can share with you all the changes done (not on github since we integrate technology dependent IPs that cannot be open sourced). In any case we will be happy to back contribute to the IP in case we find issues or ways to improve it in some way. In case you accept to have the meeting we can provide you all the informations you are asking for and more insight about our project roadmaps and plans.

Regards,
Davide

[jrrk]

Dear Davide, That sounds grand, I should like to see silicon for this. Do you prefer Zoom or MS Teams for the meeting, I am flexible about schedule. Regards, Jonathan

…

Sent from my iPhone On 13 Jan 2022, at 14:10, Davide Rossi ***@***.***> wrote:  Hi Jonathan, We are all members of the PULP team on Bologna side: https://pulp-platform.org/team.html (Davide Rossi, Luca Valente, Mattia Sinigaglia not yet on the website) hence we have links with all the people in ETH (basically we are the same group) but also OpenHW group where we are actively contributing to the evolutions of CV32E40P (former RI5CY) and CVA6 (former Ariane). For the time being we would just need a short meeting (e.g. less than one hour) to understand what we need to touch on the hw and drivers, and we can take care of the changes. Than if you are interested in establishing a collaboration we can share with you all the changes done (not on github since we integrate technology dependent IPs that cannot be open sourced). In any case we will be happy to back contribute to the IP in case we find issues or ways to improve it in some way. In case you accept to have the meeting we can provide you all the informations you are asking for and more insight about our project roadmaps and plans. Regards, Davide — Reply to this email directly, view it on GitHub<#4 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAEALV4KQ6A36TC46NFOG7TUV3MOPANCNFSM5KDKQJUA>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>