Semiwiki on LinkedIn Semiwiki on Facebook Semiwiki on Twitter Register / Log in 
Array
(
    [content] => 
    [params] => Array
        (
            [0] => /forum/index.php?threads/who-needs-design-automation.1770/
        )

    [addOns] => Array
        (
            [DL6/MLTP] => 13
            [Hampel/TimeZoneDebug] => 1000070
            [SV/ChangePostDate] => 2010200
            [SemiWiki/Newsletter] => 1000010
            [SemiWiki/WPMenu] => 1000010
            [SemiWiki/XPressExtend] => 1000010
            [ThemeHouse/XLink] => 1000970
            [ThemeHouse/XPress] => 1010570
            [XF] => 2021370
            [XFI] => 1050270
        )

    [wordpress] => /var/www/html
)

Who needs design automation?

A

Amnon Parnass

New member
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.
 
Last edited by a moderator:
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).
 
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
 
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
 
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.
 
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.
 
dogmattic said:
...would primarily require 1) license from Cadence, 2) API's to OpenAccess using Skill function names - such as dbOpenCellViewByType...
Click to expand...

Can't see why you would need a license from Cadence, and OpenAccess is (well supposed to be) open.
 
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.
 
simguru said:
Can't see why you would need a license from Cadence, and OpenAccess is (well supposed to be) open.
Click to expand...

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.
 
dogmattic said:
The entire SKILL function set is copy-write protected....
Click to expand...

Google Prevails in Java Copyright Battle Against Oracle - you can't copyright a language.

The user and language reference manuals are probably protected by copyright, but what they describe isn't, and any patents expire at ~ 20years. The only thing stopping anyone replicating OA is the license agreement you sign to download the documents. Anybody got a copy of the OA schema and API docs?
 
simguru said:
Anybody got a copy of the OA schema and API docs?
Click to expand...

All documents, including API Reference, header files etc., need the signing of the License (https://www.si2.org/openeda.si2.org...ssInternalUseAndDistributionLic_v4_041001.pdf); I think I have some documents from before this requirement but the documents disallow reproduction so I can probably not share them with other people. I asked Software Freedom Law Center if signing the Si2 OpenAccess license would hamper future open source implementation of OpenAccess. They advised to not sign the license as it likely would forbid me working on an OpenAccess open source implementation. So I did not sign the license and did not download anything. I do have the source code of the oaScript bindings as they were released under Apache 2.0 license, but I think they are planning to close this loophole also (see http://www.si2.org/?page=1520). So in good UNIX tradition 'Open' actually does not mean open; Cadence are --self-censored--.
 
what few scripts , or a DA/EDA tools (which is just a wrapper with GUI around set fo scripts) can do to the productivity ius crucials... what ever is a repeated actoivity by layout designer... can be automated and free the layout designers to real art.. same for Asic.. mix of activities can be automated... from insertion of a nac-diode... to adding a design-for-silicon debug features and some buffers too .... yes.. there is always a job security for the in-house Design-Automation teams,, to EDA contractors and as last option,,,, go to the big vendors.. reminder writing a script/flow/ have some risk too.. as you can also put some hiden mistakes there... so Think Ahead.. on debugger, and how to debug your proposed solution.. so Design For Debug is an important mindset too. good luck
 
You must log in or register to reply here.
Back
Top