Who needs design automation?

[Amnon Parnass]

Chip design automation, is naturally linked to the large tool makers, selling simulation tools, synthesis, timing and physical design. The answer in that case is clear, everybody need them to develop any chip of any size and complexity. The real debate revolves around the local efforts to develop low level design automation tools.

Those tools are mainly scripts, written by overloaded design engineers for the purpose of alleviating some of the more tedious, repetitive and error prone tasks of logic design. The development of such tools is never considered important enough for management to allocate resources but in many cases have a significant positive impact on both schedule and quality.

The initiative to develop low level design automation tools such as configuration register sets, memory wrappers, interrupt controllers, top level connectivity, IO and JTAG connectivity and many more, usually comes from capable engineers on their available time and not as a concentrated effort driven by managers.


The result is that after some time, every design team will have some level of automation which is really “design automation” helping the design and verification engineers perform their tasks. The question to be asked is why is this effort not given its place in the development process? Why not use good processes to develop such tools, and why not invest some resources and funds to establish those tools as an infrastructure of logic design?

The main advantages of those tools come not only from saving valuable time, but also from the uniformity of design which enables chip wide standardization. A good register set code generator can produce verification tests, software infrastructure and documentation and also maintain coherency between all this information throughout the development. A good memory wrapper, handling BIST, soft errors and reliability modes, enables tight control of the memories in production.

The critics of such approach would say that it takes away some of the designer’s fun and creativity, but I believe that the creativity can be channeled to more productive aspects, those that differentiate the design and make it unique and valuable to the customers.


Automation of simple tasks in chip design has huge benefits which are not used to their full productivity potential.

[daniel_payne]

Amnon,

I agree, there's a lot of glue scripts that make life easier for design and verification engineers. These scripts are almost design specific, or group specific, so don't give and EDA vendor much hope to create a product around.

I recall that there are 10+ million lines of Skill code written by Cadence customers to glue together their flows, so having a tool with scripting is powerful (however you are on your own).

[simguru]

That's partially what the open-source community is for: if you don't want to (or can't) spend money on a project, donate your scripts etc. to (say) SourceForge or GitHub and list it on gEDA, maybe someone else can add to it.

https://github.com/
SourceForge - Download, Develop and Publish Free Open Source Software
gplEDA: All things GPL and EDA

Is there an open-source SKILL interpreter?

Maybe we should start an EDA tools wish-list page.

[LinkedIn]

Actually, I cannot imagine any professional ASIC design without in-house EDA scripts. If you are going to outsource any part of design, I think you should ask first if the team has an experience in writing the scripts. If they never did it before, you'd better to talk to another.
Posted by Dmitry Fomin

[BarryB]

To be commercially viable EDA tools have to be able to work in a number of different workflows however once tools are installed on a site they only have to work with the specifics of that team and using workflow automation has produced tremendous gains in efficiency and productivity, positively impacting the bottom-line in thousands of companies. In contrast, human intervention in a process opens it up to inconsistencies, delays, and errors.
You could be forgiven for thinking that with so many chips having now been designed that it would be a very repeatable and predictable workflow. This is rarely the case as design is a creative process with too many variables in the workflow to make it easily reusable and this may well result in it be an impossible target for EDA companies

[Amnon Parnass]

Commercial EDA vendors require standardization, so tools can be effective for many applications. but some parts of the design flows and structure can be standardized. in fact, alignment of methodology and even alignment of reusable designs is a way to handle the increasing complexity of current chips.

the same way EDA vendors could come up with standards that helped them develop productivity tools, they can do the same for some of the low level design tasks, allowing the engineers to use their creativity where it has higher impact on the resulting device and its unique features.

it seems that the EDAs refrain from "forcing" standard methods for common design tasks but there is no harm if devices from several vendors would have the same register set design and interrupt mechanism, it is a natural extension of the IP trend which is growing anyway.

[dogmattic]

Since SKILL is a cousin of Scheme - which has dozens of freeware implementations, such an interpreter would primarily require 1) license from Cadence, 2) API's to OpenAccess using Skill function names - such as dbOpenCellViewByType. But, writing those thousands of API functions to mimic what Cadence already provides in SKILL would be retarded. What we need is a collective campaign to get Cadence to release the SKILL interpreter to GNU, using the argument that, hey - if thousands of freelancers could write SKILL stuff from home or school, all of that is going to have a major net boost to sales of Cadence licenses. The alternative is, we all move to the free C++ API from Ciranova ... and leave Cadence in the dust.

[simguru]

...would primarily require 1) license from Cadence, 2) API's to OpenAccess using Skill function names - such as dbOpenCellViewByType...

Can't see why you would need a license from Cadence, and OpenAccess is (well supposed to be) open.

[daniel_payne]

Getting Cadence to agree to loosen their grip on a de-facto and proprietary standard is a low probability pursuit, however if the top 5 Cadence customers demanded that Cadence open up SKILL functions then you will have more of a chance to persuade the decision makers at Cadence.

As an analogy why would Microsoft give Apple any source code to Windows, or why would Apple give Microsoft any source code to OS X?

Direct software competitors rarely cooperate fully with each other unless convinced by a standards body or large customers.

[dogmattic]

Can't see why you would need a license from Cadence, and OpenAccess is (well supposed to be) open.

The entire SKILL function set is copy-write protected. And yes, OA is free (donated by Cadence), and so is the C++ api (for members). Also: Correction - Ciranova provides the freeware PyCells (Python Pcells). Si2 provides the open C++ API.

In any case, I believe Cadence had to write Skill/C++ interfaces. Keeping Skill is just a matter of keeping the Scheme simplicity and safety.