It's time to remove our blinkered attitudes towards hardware design, and think about a higher level of abstraction, says Simon Calder of SpiraTech

When I read the announcement from the EDA Consortium that Phil Moorby, creator of Verilog, was to be given the 2005 Kaufman Award, my immediate reaction was one of pride and optimism.

Here was a man from our neighbourhood, the north west of England, deservedly receiving the industry’s greatest accolade, showing everybody that you do not have to work or be educated in the Silicon Valley to achieve greatness.

As I read further, another fact really struck me. Moorby invented Verilog in 1985. This was during the very early days of CMOS, the age of five going to three-micron geometries and at a time when the largest chips contained 10,000 transistors.

The great Phil Moorby

I am sure Moorby and his contemporaries were aware of Moore’s Law and could envision 65nm lithography, 300 million transistor devices and one million transistor on-chip tools just to compress the test programme. But I am also certain that Moorby could not have predicted what has happened to the growth of the software requirement for ICs.

In 1985 the only software that most chips required was something to initialise the registers on power up. Today the software design effort has surpassed the hardware design effort for most ASSP products shipped. Verilog, by definition, is a ‘hardware’ description language and makes no attempt to address the needs of software or system design.

It is therefore doubly amazing that this unashamedly pure hardware design is still to the fore today. Even Moorby would admit that this was not meant to be.

Why has the EDA industry not been able to move smoothly from the ‘hardware centric’ design abstraction of RTL to a more abstract ‘system centric’ level?

I will argue it is for one reason and one reason alone - the EDA industry is still dominated by hardware engineers. Hardware engineers simply do not get systems, although most think they do, and still consider software engineering - other than EDA - to be a trivial pursuit.

Calder: "EDA still dominated by hardware engineers"

This is why all the recent initiatives of the EDA industry such as DFM, SystemVerilog, assertions, formal verification and behavioural synthesis have been aimed squarely at the hardware designers or implementers.

Even C++ has been hijacked by the ‘hardware-istas’ and turned into SystemC. Can you name one commercially successful product from that group? I doubt it. Why is this? It is because they are addressing the smaller and shrinking portion of the customers’ problems, hardware. The industry’s revenues are proof of this. The larger and growing problem is the software and its role in the complete system.

I am not making a case for the EDA industry to colonise the embedded software development tools market. There may be five million customers out there but 99 per cent of them do not need EDA technology.

The additional people who need EDA software are the 50,000 engineers who join the silicon and the embedded applications together. Middleware has to be written, operating systems must be optimised and custom device drivers developed. The system has to be validated to ensure that the hardware/software combination is meeting the functional and performance requirements of the specification. It is only then that we can be sure we have a ‘hardware’ design that is ready to ship or even implement.

In most cases today, the software development and system validation is carried out on a piece of hardware that is usually flawed in system terms, because it was developed using traditional RTL EDA tools. This results in many months and millions of dollars being wasted.

If it is not yet obvious, I will admit I am a representative of the ‘ESL’ wing of the EDA industry.

ESL is about providing customers with the ability to design and verify their hardware and software together as a system. This definition actually excludes most, if not all, behavioural synthesis tools, because they are still about designing hardware only or, in some cases, about designing software before hardware.

To design a system you need to represent the hardware at levels of abstraction that can be simulated fast enough (at least 500kcycle/s), be transaction sequence accurate and be aware of the resources available.

At last, thanks to the cajoling of our major customers, we are seeing the emergence of real - meaning useful - ESL tools.

The major IP vendors are actually providing transaction level models (TLMs) of CPUs and DSPs. CoWare, VirtuTech, Vast Systems and Virtio are promising to deliver even more. Companies like Tenison EDA have gone a long way to automating the process of creating TLMs from existing pre-verified custom RTL. Forte and Bluespec are producing efficient RTL from higher abstractions.

Using a combination of all these tools it is now possible to build a model of an entire system or device that will run 200-1000 times quicker than its RTL equivalent. This is fast enough for middleware development, RTOS design, performance and functional verification.

Thanks to state-of-the-art FPGA technology from Xilinx and Altera, and Synplicity’s partitioning and synthesis software, it is possible to build FPGA prototypes of even the largest SoCs. These prototypes can be used to finish the driver development and to verify the RTL implementation. It is now conceivable to tape-out a major SoC knowing it will meet all the requirements of its specification and that when it comes out of the fab, the required software will be there, ready and waiting.

‘Hang on a minute’, I hear you say, ‘all these companies and tools you mention have been around for years. What has suddenly made them so useful?’ The answer is ‘transactors’.

If you throw in SystemVerilog or ‘e’ test generation, the tool flow above contains at least five different levels of abstraction - untimed transactions, approximately timed transactions, timed transactions, RTL and gate level.

For this flow to work all these levels of abstraction must be able to interact or co-simulate with each other, the devices that enable this function are called transactors.

Anybody who has ever developed a checker using ‘e’ will testify how difficult it can be to link two levels of abstraction together, never mind five. Because transactors have been historically very difficult to build even for industry standard protocols, not to mention proprietary ones, very few exist. Therefore it is the solving of the transactor problem that is key to the widespread adoption of ESL methodologies and inevitable demotion of RTL to its best-suited role of implementation.

SpiraTech is addressing the transactor problem with an automated tool set and it seems in some way fitting that some men, also from the north west of England, have created the technology which will finally result in Moorby’s invention being replaced - two decades after its conception.

Simon Calder is CEO of SpiraTech

www.spiratech.com