A recent press release related to the all-programmable initiative from Xilinx attracted my attention a few weeks back.
Essentially, the initiative showcases Xilinx's effort in abstracting system-level (hardware and software) design flows -- from algorithm to RTL development under one umbrella. With a closed and finite IP ecosystem based around FPGAs, it is now easy for FPGA companies to develop seamless and push-button flows that integrate hardware and software design. So, what about non-FPGA players? What kind of flow integration and abstractions can they shoot for?
Abstractions have become essential in almost all disciplines of engineering, and our EDA/IC industry is no different. With product engineering becoming complex, multi-disciplinary, and requiring short TTM (time to market), there is a need to manage and hide complexity at each delivery point. Or, on a lighter note, when complexity outstrips the understanding of a single human brain, there is a need for abstraction. The consumer of an abstraction is concerned only with the exposed interface's usability and performance.
If we look back a decade or more in the verification domain, engineering teams in many companies toiled at developing and maintaining their own BFMs (bus-functional-models) for different protocols. With standardization and the wide adoption of many interfaces, and with protocols getting ever-more complex in terms of states and timing, it became difficult for design houses to gather the right human talent. What happened? They started to lag on testbench development.
The opportunity was rightly spotted by the EDA industry. Consequently, we saw the birth of verification-IP (VIP), a development that I see as a common problem subsumed and solved by a few for the benefit of many. The economics of using VIP made sense, since design houses could now focus on differentiators. These days, VIPs are available much earlier, even before design IPs. The result? Engineers can now kick-start testbench development much, much earlier. The VIP hides all the gory details of the protocol in timing or framing and provides a high-level interface to work with. Also, it does much more than a regular BFM and is extensible.
There are other examples in design IPs as well, the best being CPU IPs from ARM and MIPS. Thanks to these companies, custom CPU development has gone out of vogue, and deploying a CPU becomes "just another IP" plugged onto a standardized bus. Few SoC vendors are interested in delving deep into instruction-set-architecture (ISA) and pipeline issues, while many feel differentiation can be achieved in other areas of system design.
So, when the EDA and IC industries play by standards, abstractions get crystallized and adopted easily. In other words, when external interface and usage overrides the need-to-know internal implementation detail, it makes it relatively easy to sell an abstraction.
Now, if we look at the software side of the design industry, especially the segment where low-level software is developed to enable an IP, be that for verification or system-software, things haven't changed in a decade. Engineers back then used to develop low-level driver software, and they still do so today. Each new implementation of an IP costs a design house valuable time and resources in porting or developing these drivers. As of now, there exists no means to generate or provide an abstraction on top of design-IP to enable verification or system-software development.
Consider this: There may be umpteen ways to implement an Ethernet-MAC IP in RTL, but the hardware-software interface or the programming register interface and the sequence of operations will roughly be similar. How can we exploit this commonality? What benefits can be reaped and who will be the beneficiaries?
If we take the case of USB-HOST, the xHCI protocol mandates conformance to a specified register-map set. With HW/SW interface clearly defined, it becomes relatively easy to create and port abstractions across IPs.
Now, suppose hardware and software IP architects had the means to capture the HW/SW interface in a standard specification. If this were not restricted to the register map alone, details on how to read or write to the device etc. were included, then a major chasm would have been bridged. It is certain that tools working on top of the formal specification can create the abstraction on top of the design IP. What if the specification becomes part of the IP exchange portfolio and flows downstream to the SoC integrators? Would the Verification process be expedited on their end?
As of today, reams of articles have been written about S/W costs being on the rise in IC fabrication, but not many about automation tools or methodology insight. So, why not attack the problem bottom-up from where it begins by putting in an essential abstraction? How would you attack this problem?