The Holy Grail of EDA has been the ability to go directly from an abstracted version of the design (such as RTL or System C) to the physical implementation, that is GDSII.
The result is that many players in the chip design business are hawking their own canned methodologies or flows. The idea is that you can take a fairly junior engineer, put him in front of the terminal, and tell him to push the "Big Green Button". It reads in the RTL and in just a few hours the completed physical design pops out the other end.
There are two main problems with this idea. The first is that very few designs are "typical". There tend to be issues that are specific to any particular design that require unique attention. Therefore, it is very difficult to construct the tool that will handle all cases.
If this was the only problem, it would be OK for the tools team on any given project to spend an inordinate amount of time solving it. But the second big issue deals with the fact that the effort to create the Big Green Button actually makes using the tools more difficult. Specifically, the "environment" generally abstracts the user from the tools he is using. Now the poor soul trying to implement the design needs to not only know what he wants the tools to do, but he needs to know how to make the environment make the tool do what he wants it to do.
What do I mean? Let's talk about something simple like trying to read the RTL into the synthesis tool. If you were driving the tools, you would know that the tcl command read_verilog does a pretty good job of reading Verilog into Design Compiler. One company I worked with did not want you to touch the scripts; therefore you needed to call a perl script to run the tcl to read the Verilog. Not a big deal, but it is a level of unnecessary abstraction.
I worked on another project, building an environment, and the process of reading in a Verilog file called a pointer that pointed to a pointer, ad nauseam. By the time the process was over, there were 13 levels of indirection to get to the Verilog file. It may have made sense to the developer, but it was a little difficult for the user to understand what was going on.
This brings us to fact that tools vendors tend to document their tools pretty well. The environment development team seldom does. As a result, not only is your job more difficult, there is no easy way to find out what needs to be done.
In my opinion, a good tool flow is a directory structure, a set of scripts, and a method to reliably rerun the scripts. It should allow the designer to be able to experiment with a myriad of strategies to complete the required tasks. The tool flow should not abstract the designer from the tools themselves.
Maybe some day, the tools will be so sophisticated that they will not require much human intervention. They are not there yet.
The result is that many players in the chip design business are hawking their own canned methodologies or flows. The idea is that you can take a fairly junior engineer, put him in front of the terminal, and tell him to push the "Big Green Button". It reads in the RTL and in just a few hours the completed physical design pops out the other end.
There are two main problems with this idea. The first is that very few designs are "typical". There tend to be issues that are specific to any particular design that require unique attention. Therefore, it is very difficult to construct the tool that will handle all cases.
If this was the only problem, it would be OK for the tools team on any given project to spend an inordinate amount of time solving it. But the second big issue deals with the fact that the effort to create the Big Green Button actually makes using the tools more difficult. Specifically, the "environment" generally abstracts the user from the tools he is using. Now the poor soul trying to implement the design needs to not only know what he wants the tools to do, but he needs to know how to make the environment make the tool do what he wants it to do.
What do I mean? Let's talk about something simple like trying to read the RTL into the synthesis tool. If you were driving the tools, you would know that the tcl command read_verilog does a pretty good job of reading Verilog into Design Compiler. One company I worked with did not want you to touch the scripts; therefore you needed to call a perl script to run the tcl to read the Verilog. Not a big deal, but it is a level of unnecessary abstraction.
I worked on another project, building an environment, and the process of reading in a Verilog file called a pointer that pointed to a pointer, ad nauseam. By the time the process was over, there were 13 levels of indirection to get to the Verilog file. It may have made sense to the developer, but it was a little difficult for the user to understand what was going on.
This brings us to fact that tools vendors tend to document their tools pretty well. The environment development team seldom does. As a result, not only is your job more difficult, there is no easy way to find out what needs to be done.
In my opinion, a good tool flow is a directory structure, a set of scripts, and a method to reliably rerun the scripts. It should allow the designer to be able to experiment with a myriad of strategies to complete the required tasks. The tool flow should not abstract the designer from the tools themselves.
Maybe some day, the tools will be so sophisticated that they will not require much human intervention. They are not there yet.
No comments:
Post a Comment