High Capacity Memory Subsystem Development
Introduction
This project aims to design and implement a high capacity memory subsystem for A series CPU based SoCs.
Project Milestones
-
Architectural Design
Design FlowTarget DateDetermining the information needed to begin architectural design (Specification)
The team are reviewing the JEDEC DDR4 specification. The team are also reviewing available resources and projects with the DDR3 protocol. One resource extends understanding of the JEDEC timing specification with explanation on the timing information of signals.
A final Specification will need to include a list of proposed use cases, specific algorithms to be implemented, data movement requirements, time critical operations, etc.
Separation of Concerns:
Separate aspects of the design task to specific parts of the system by defining a unique sub-system. Srimanth Tenneti produced an initial subsystem breakdown.
Identify reusable design patterns:
To be determined. The AXI and APB interfaces to the System buses are well known and architected.
Identify existing third party blocks:
To be determined.
Identify that need to be developed uniquely:
To be determined.
System Throughput Considerations:
Review JEDED specifications.
Design Decomposition / Partitioning:
Once the set of IP parts has been identified the work tasks of considering the interfaces between them will begin. Starting with the connections internally between subsystems, and those to the external system environment.
-
APB interface
Navya Deepika is working on the definition of the APB interface and the interactions with the external SoC and internal interactions with blocks such as the Timing Parameters Module being worked on by Dhanaji Pawar.
-
AXI Interface
Sandeepan Roy is working on the main data flow to/from the rest of the SoC via the AXI interface.
Comments
Introductory meeting Friday 3pm (BST)
Hi All,
Could you please use this link to join the introductory meeting this friday at 3pm UK time (BST)
https://teams.microsoft.com/l/meetup-join/19%3ameeting_NzJmOWMzZjQtMTYxNi00NTA3LTlhMTQtMjMwNDY4N2NhMDQw%40thread.v2/0?context=%7b%22Tid%22%3a%224a5378f9-29f4-4d3e-be89-669d03ada9d8%22%2c%22Oid%22%3a%22da03259c-2f3e-4038-96bb-de5e01994a6c%22%7d
I just started with soclabs…
I just started with soclabs. Looking forward to contributing
Collaboration for this project
Hi,
I am interested in collaborating for this project. I am skilled in the area of Functional Verification. I am skilled in SystemVerilog and UVM. I look forward to be a part of of this group.
Hi I am interested in being…
Hi I am interested in being part of the group
Joining the group
As soon as Srimanth makes this project live then people can join it. Srimanth can add you to the group while he has it in a draft form.
When he makes it live then the Join button will appear instead of ...
I believe it should be live…
I believe it should be live now. I will work with John and his team to get the basic spec for this system as a lot of people have this as a common agenda and will update the page. Then all of us can start working on this.
Collaboration for the project
I'm interested in being part of the group
Virtual Meeting 2
Hi,
We have just finished our 2nd video call for the project. We did not record it. Not everyone has signed up on the slack channel which will be a location for frequent communication. We will make a regular update to the project so that everyone can keep aware of the weekly drum beat. Srimanth said we would share the meeting summary so hopefully we will draft that up and share it later.
Srimanth discussed his rough block diagram of the DDR Command Generation module.
An initial design decomposition focusing on the signal interchange was felt to be a good start to allow people to engage.
Various blocks need fleshing out and we need to assign people have a first look and then we can see why the blocks are misaligned.
We will continue to meet weekly and try and move things forward. Look out for the more details meeting summary.
John.
Regarding email notification for this comment
Hi John,
I just checked the group and found this comment added here. I have not received this as a notification via email despite ticking the "comments added" box for notification. Can you please look into this issue?
notification via email for comments
Hi,
To try and reduce the amount of email notifications we have added a moderation step. The owner of the project will get all comments and they can decide if the comment should be forwarded to all of the project team via email. We hope this way that important comments will flow via email and you can catch up on other minor comments when you visit.
Let us know if this works as we can change things if needed.
Virtual Meeting 3
Hi,
We have just finished our 3rd video call for the project. Last weeks meeting we stated that various blocks need fleshing out and people assigned to do the initial work so we can see why the blocks are misaligned.
@Sandeepan Roy had put his hand up for the Host Interface Logic - AXI. Work has progressed on the initial external interface but more needed on the internal interfacing but that need other blocks to form. There was discussion on potential separation of responsibility between the AXI interface with a primary responsibility on data movement and the potential use of APB interface for configuration. This led on the a discussion on address translation and the various registers that will need to be accessed.
@Srimanth had taken the Command Module. There was some discussion on the hand off from the AXI interface and the Command Module and the form of address to be expected by the Command Module. This led to a need to define the responsibilities for each of the blocks.
People where directed to following on line book on System on Chip Design with Arm Cortex M Processors.
@Dhanaji Pawar was to look at the Timing Parameters Module. The meeting did not get around to discussing this block.
Some new team members joined the call and it was good for them to get involved. @Srimanth said he will produce some more initial statements of block functionality to help people decide how best to engage on investigation of the various blocks.
Thanks all,
Virtual Meeting Nov 29
We have just finished another virtual meeting.
@Sandeepan Roy talked people through his memory system architecture document allowing the meeting to review it and use the question and answers to help everyone with a shared understanding of the design. The architecture extends the initial subsystem breakdown adding two new blocks
Specification:
The controller architecture is based on DDR4 as specified in the JESD79-4.
Separation of Concerns:
@Sandeepan Roy in the period worked on defining the AXI interface block and interactions with the other blocks. A Memory Arbiter which samples the address and sends them in the address queue. A Memory Scheduler that passes address requests whenever requested by the command module. A good discussion was had on how data read/write requests flow through the AXI interface.
@Sandeepan Roy and @Srimanth need to finalise the hand off from the AXI interface and the Command Module.
Not much definition has happed on the APB interface. The start up sequence and how the information held in the Params module is to be established in combination with the system boot sequence was discussed to help determine some of this blocks interactions.
Verification:
A discussion on the verification strategy occurred and we agreed that the second meeting in December would be dedicated the verification.
Verification Methodology
One of the tasks within the Architectural design flow is the definition of the verification methodology. This is an interesting paper of a Framework for Formal Verification of DRAM Controllers.
Perhaps we should dedicate one of our meetings to looking at verification.
Some additional papers
Work by Kirill Bykov on acceleration of the RTL simulation of any memory controller.
Project needs a more detailed description
I think the project needs an updated description. There is a nice level of detail in this project:
GitHub - AngeloJacobo/UberDDR3: Opensource DDR3 Controller
John.
UberDDR3
Angelo has made the point that if the controller is for AI/ML applications, then the controller needs to be fast. He believes UberDDR3 is fast compared to commercial DDR3 controllers like the Memory Interface Generator (MIG) in Vivado, but uses much less area than the MIG.
His recent blogpost discusses a Dhrystone Test comparing the performance of MicroBlaze with UberDDR3 against MicroBlaze with MIG.
Dhrystone test performance results:
MicroBlaze with UberDDR3 = 0.3154 DMIPS/MHz
MicroBlaze with MIG = 0.3061 DMIPS/MHz
UberDDR3 uses 32.63% fewer Slice LUTs and 32.33% fewer Slice Registers than MIG.
The PHY used by UberDDR3 is specific to Xilinx 7-series FPGA.
Code reading and Comments
I must draw the attention of the team to the quality of comments Angelo has put in the UberDDR3 project. It is an example to all to follow.
Newly Joined to the Project - Justin Das
Name: Justin Das
Area of Interest: RTL Design(Verilog, System Verilog), IP and SoC Design.
Please help me with the steps to ramp up this project.
Hi I am interested in being…
Hi I am interested in being part of the group
Add new comment
To post a comment on this article, please log in to your account. New users can create an account.