Endless Abstractions?

By Frank SchirrmeisterHaving started my own career doing full custom layout, then moving though gates and RTL to transactions and embedded software, I always was a little bit concerned whether the industry would eventually run out of abstraction levels for me to adopt further upwards. It looks like there is plenty of head room.Last week I was in Munich attending the CDNLive! EMEA event. I was helping to launch the 2012 edition of our System Development Suite. As part of CDNLive! we had a system-level track with presentations of customers and partners. The presentation given by Duolog’s CTO David Murray especially caught my attention because it introduced a concept that may represent at least an intermediate next step of abstraction for verification.

David’s presentation was called “Sequences: Formalizing software programming sequences to enhance HW/SW integration.” He started with an introduction of “SID,” a member of the species of insidious bugs that proceed in a gradual, subtle way, but with potentially very harmful effects. They are caused by changes to specifications, ambiguities in specifications, flawed team communication, translation errors when coding, and potential implementation mismatches. To avoid those, a clear, golden specification of the hardware/software interface is required. One graph David used struck home with me and brought me right home to my design days.

Register Interface for a UART

This graph outlines how a processor accesses a memory map which identifies different sub-systems in the chip, eventually leading to the register map of an UART. In my design days of audio/video/transport decoders we kept a word document called “interfac.doc” — yes, with a deliberately missing “e,” something about 8 characters, not to date myself too much 😉 — to which only the two top architects of the design had write access. It was the golden reference.

Well, times have progressed since then and we have tools from Duolog and others to define those and to create a single, golden top-level specification, and to create documentation and implement code from it. This is what Gary Smith defines as the “Silicon Virtual Prototype,” and I fully agree with him that in order to faster move up further to the system-level, this level of RTL definition needs to be fully defined and adopted by the mainstream designers.

From here it is easy to understand what a transaction really is. Simply writing in the code “read(address, data)” is much simpler than having to individually wiggle all the signals to access the appropriate memory address and trigger an event in a peripheral component.

David then proceeded to point to the limitations of current EDA solutions, which focus on the register infrastructure, and for which programming use cases are still defined in an informal format. As a result it is very difficult to formally define register usage intent, which in exchange can lead to a loss of quality and efficiency. He called for ways to be able to define programming sequences formally!

What is a “Programming Sequence”? Well, it is a combination of transactions to define the register usage for a specific use mode. Here is an example, using one of ARM’s most licensed IP blocks, the famous PL011 UART:

A UART Programming Sequence