Register Automation for a DDR PHY Design

Several months ago, I interviewed Anupam Bakshi, the CEO and founder of Agnisys. I wanted to learn more about the company, so I listened to a webinar that covered their latest products and how they fit together into an automated flow. I posted my thoughts and then I became curious about their customers, so I asked Anupam to arrange an interview. Following are my notes from a nice talk with Ricky Lau, CTO and one of the founders at The Six Semiconductor.

Who is The Six Semiconductor and what does the company name mean?

We’re an analog mixed-signal integrated circuit IP startup. Our initial focus is on physical (PHY) layer IP for DDR memory applications. Our headquarters are in Toronto, which the rapper Drake nicknamed “The 6” several years ago. A lot of people use the term now, so we chose a name that reflects our location.

What is your typical IP development flow?

We provide optimized circuit design with a full custom design flow to achieve best performance in a minimal footprint. We’re experts in schematic-layout co-design optimization, which is rather a lost art in many modern design flows. This enables us to customize the IP quickly and efficiently to meet the needs of our customers. On the digital side, we follow a standard RTL-based design and verification flow, and that’s my main responsibility.

Are your designs “big A/little D” or “little A/big D?

Our IP is split about equally between analog and digital, so I guess you could say that we are “medium A/medium D” for the most part.

What are your biggest digital design and verification challenges?

Since our designs must interface with memory devices, we use digital techniques to compensate for non-ideal effects in the system, such as board skews and voltage/temperature variations. Our logic calibrates the system so that the DDR interface can communicate with the memory chips reliably and at the highest frequency possible. Verifying this functionality in simulation is challenging because we have to model the sensing and adjusting circuits and the conditions in the system.

What role do control and status registers (CSRs) play in your designs?

Registers in the digital portion directly control much of the circuitry in the analog portion. For example, timing adjustments are calculated in the digital logic based on the sensor inputs, and the results are written into registers that feed the analog circuits. The calculation algorithms have tuning “knobs” that can be tweaked, and these are also controlled by registers that can be programmed by end-user software. Registers make our IP flexible and customizable, able to be used for multiple target processes with no changes.

Why did you consider a register automation solution?

Even before our first project, we knew that we needed a register-generation flow. Our design has enough registers that we wanted to be able to generate the RTL from a specification rather than coding it all by hand.

How did you end up selecting Agnisys for a solution?

We did consider developing our own register flow, but we are a small company and it didn’t make sense to spend our precious engineering resources unless we had to. I did some investigation and evaluations of commercial solutions, and ended up choosing IDesignSpec (IDS) from Agnisys. We really liked its ability to generate register verification models and documentation in addition to the RTL design.

How do you use IDS in your development process?

We define our registers and fields in spreadsheets and use the standard comma-separated-value (CSV) format to communicate our specification to IDS. Then IDS automatically generates the register RTL, which we verify in simulation along with the rest of our logic. We have a testbench based on the Universal Verification Methodology (UVM), and we include the UVM register models that IDS also automatically generates. Simulation verifies that our register specification is correct and that the rest of our design properly interfaces with the registers. Finally, we use the Word file produced by IDS as the official register documentation provided to our end users.

Can you quantify the value of IDS in your process?

We have used IDS on every project, so I really can’t compare time and resources saved by the automated flow versus a manual process. We estimated that developing our own register flow would have taken at least six engineer-months, plus ongoing maintenance and support. Add to that the time saved by not having to write RTL, UVM models, and documentation, and it’s clear that IDS is a big win for us.

Do you run IDS multiple times on a project?

Yes we do, and that’s a really important point. Our register specification changes constantly during most of our IP project schedule, and we simply re-run IDS to propagate those changes and re-generate the output files. Without IDS, every time that a register or field changes, we would have to hand-edit the RTL, the UVM models, and the documentation. That would take a lot of effort, run the risk of typos and coding errors, and make it hard to keep all the files in sync. I think the biggest value of IDS and register automation is this repeated usage. While I can’t give a precise number, clearly it saves many engineer-weeks of effort across the duration of a project.

How has your experience working with Agnisys been?

Overall, I’d say that I am happy. Just like any piece of software, we have found some bugs and requested some new features in IDS. Agnisys always gets back to us within a day or two, and they have a smooth process to ship us a “hot fix” so we don’t have to wait until the next general release to address our issues.

What’s in your future?

We have new projects underway and will be using IDS on all of them. As our design complexity grows, we’re looking into some of its more advanced features so I expect that we will continue to work closely with the Agnisys team.

Thank you for your time!
You’re welcome, and thanks to you as well.

Press Source: https://semiwiki.com/eda/agnisys/294947-register-automation-for-a-ddr-phy-design/

Overcoming the weaknesses of traditional natural language specifications requires writing the specifications in a precise format rather than natural language, and making this format executable so that tools can generate as many files as possible for the design, verification, programming, validation, and documentation teams. Learn how Agnisys approaches a solution to this challenge that is available today.