• Article
[ Printer Friendly ]
In the 25-year history that I have been developing EDA software tools, there is one message that I have constantly strived to listen to. It is the message: "Listen to your customers!" This is easier said than done – unfortunately, not all of my customers have actually known what they want, and even when they do, they often have not been able to express themselves well enough for me to know what to build. Having said this, my most successful products have always been rooted in doing what the customer asked for, nothing more, nothing less.
In the early days of my EDA career, specification writing was always done by hardware designers. They knew what they were doing and all they wanted was to automate some fairly repetitive and time-consuming tasks. They knew the parameters within which they wanted to solve this problem and created fairly good bounds for the problem to solve.
Today's large commercial EDA tools are big, solve complex problems, and carry a lot of legacy. They support layers of bug fixes and support multiple platforms through a series of complex conditions. This raises the complexity of the code base, thereby making it difficult to manipulate and modify easily. If I look into the details of any one of the complex releases from EDA companies, there is probably a very good reason why they do what they do, but if you look into the details of how these tools are architected and built, they are all aimed at reducing the support burden or maximizing the use of a single code stream, an extremely important goal for the software developer but of marginal value to the end customer. I really can't fault the EDA companies for what they do; it is a way to make a business out of our complex industry.
Throwing the baby out along with the bath water?
However, in all this innovation, we seem to have left no room to solve the simplest of problems – namely, the ones the designer needs solved in his or her daily work life. Where does he or she turn to solve them? The smart algorithm developers are far removed from the end customer and are plagued by internal deadlines and processes that ensure that all their time is spent on the design, so that there is very little time to see or feel the pain of the end customer. The recognition they strive for and get is from their peers and managers.
The big design houses can afford a CAD engineering team that can at least try to resolve the issues that their engineers bring them with scripts or simple fixes or mostly by beating up on their EDA tools suppliers, but those that don't either have the clout or are not big enough, have no recourse but to live with this problem, or as we are hearing from the pundits – a lot of companies are turning to build tools or augment their in-house CAD groups as they did in the early days or electronic design automation.
We as an EDA industry can help this situation.
The engineering answer to solving a problem always starts with breaking it down into simpler problems. Internally, we all do that, but we don't publish the partials as the value at the end of the day is represented by who builds and owns the complete solution. This is counter to what the end-customer wants. If we were to publish all the simpler tasks and provide a "tool-box" of solutions, then the customer himself (or a paid service provider) can integrate these pieces into elegant solutions.
Does it really work?
Ask any hardware design engineering manager about what they like most about their EDA vendor, and it invariably is the AE that comes with the tool. Why? Because it is this individual who can work wonders with the tools their company develops – but even more than that, they can often tailor the tool to solve the problem. Let's call this the customization engineer.
Now what does this customization engineer use for his toolbox? It turns out that it is not just skill, but the toolkits they share amongst their colleagues, and tools they get from their tool developers. These goodies are invaluable for keeping customers happy. These tools never see the light of day in a price book, but without this effort (which it turns out is usually trivial for a tool developer), a large number of deals would collapse. These tools are toolkits that embody core algorithms, but are used in ways that often were not originally thought to be the mainstream use of the tool.
If you look at the software industry, the process, of breaking a solution into its internal components, has been proven to work over and over again. Whether it is in the Web world of today (Java components, Java Beans et al) or in the C++ world (class libraries and toolkits), this is known as component-based design.
Closer to home, the IP industry has blossomed with the exact same idea. Building IP to solve specific but simpler problems and integrating it into a SoC has finally taken hold after a few initial hiccups. We can surely learn from those mistakes and build a solid foundation for this type of activity.
A specific example
Here is a specific example of how something like this would work. In the context of the emerging market of programmable fabrics, or the plethora of semiconductor fabrics with both FPGA like and ASIC like qualities, Clive Maxfield has done an admirable job of classifying these in his book The Design Warrior's Guide to FPGAs
In this book, Maxfield classifies programmable architectures based on three different axis, namely, their technology basis (SRAM, Antifuse, Flash), the granularity of the basic building block (coarse grain, medium grain and fine grain), the programming basis for the building block (MUX based or Lookup-table based). In addition to the node-in-an-array programmability that he describes, there are other structured ASIC like approaches that include VIA programmable techniques. One can clearly see that the number of these fabrics start growing rapidly as you start selecting one from each of the axis. If you look further into the details of what is required to make one of these fabrics successful, one of the primary components is the EDA tools available to program these fabrics. Ensuring that these EDA tools are customized to take advantage of each of these unique innovations is a critical success factor for these fabrics to survive.
If we look under the hood for what is exactly required to build a toolset for these fabrics, they will need HDL language parsers, elaborators, mappers, synthesis engines, module generators, placement engines and routers, and netlist translators. An off-the-shelf solution by its very definition will not work, because it is not tailored to the fabric. Each fabric has its own nuances, and needs a specific set of targeted library elements or pre-built components.
No front line EDA vendor is stepping up to provide a customized toolset for these fabric providers.
However, it is possible to engineer a solution with Front-End components (parser and elaborator) from a vendor such as Verific (www.verific.com), a synthesis engine and its associated customized module-generator and mapper from a vendor such as SoftJin (www.softjin.com), and possibly a placer and router that might need to be built for the fabric from scratch. VPR from the University of Toronto was the right idea for such a solution.
The elegance of this solution comes from the fact that you don't have to compromise quality of results to adopt such a solution. All it requires is that each component be individually tested and verified and the appropriate pieces customized as necessary.
Solutions have to be as individual as the customer itself
This approach introduces a new way to think about solutions that move away from a common off-the-shelf product model to a more customer-centric customized tool development model. The way to accomplish this is to pre-develop and license key re-usable EDA modules and then enhance or extend them for the specific requirements of the customer. The model allows for an EDA company to profitably develop specific features for a customer and at the same time spread the cost of common R&D involved in developing re-usable components over its customer base.
Is this what customers want? Why don't we ask them?
Kumar Venkatramani, Executive Consultant, has over 20 years of experience in the Electronic Design Automation (EDA) industry uniquely blending both hardware and software design disciplines. His career has included various senior technical and management roles in both engineering and services organizations at both large and startup EDA companies.
Currently, he is helping SoftJin pioneer innovative approaches both in technology and business models that could affect the way the EDA industry operates today. Prior to this, at Cadence, he was one of three technologists, looking into innovative business models and new services opportunities in the eMerging Business Unit.
Kumar has published several papers, presented technical seminars and has been awarded over 10 patents. He is an active participant in the industry standards activity both in VSIA and VCX and has co-authored one of the widely adopted standards in the area of IP reuse. Kumar received his MSEE from Columbia University, NY in 1983 and his BSEE from University of Madras, India with a specialization in Communications in 1981.
EDA Vendors: "Service your Customers"
Pre-developing and licensing key re-usable EDA modules provides a new way to think about solutions that move away from a common off-the-shelf product model to a more customer-centric customized tool development model.In the 25-year history that I have been developing EDA software tools, there is one message that I have constantly strived to listen to. It is the message: "Listen to your customers!" This is easier said than done – unfortunately, not all of my customers have actually known what they want, and even when they do, they often have not been able to express themselves well enough for me to know what to build. Having said this, my most successful products have always been rooted in doing what the customer asked for, nothing more, nothing less.In the early days of my EDA career, specification writing was always done by hardware designers. They knew what they were doing and all they wanted was to automate some fairly repetitive and time-consuming tasks. They knew the parameters within which they wanted to solve this problem and created fairly good bounds for the problem to solve.
Today's large commercial EDA tools are big, solve complex problems, and carry a lot of legacy. They support layers of bug fixes and support multiple platforms through a series of complex conditions. This raises the complexity of the code base, thereby making it difficult to manipulate and modify easily. If I look into the details of any one of the complex releases from EDA companies, there is probably a very good reason why they do what they do, but if you look into the details of how these tools are architected and built, they are all aimed at reducing the support burden or maximizing the use of a single code stream, an extremely important goal for the software developer but of marginal value to the end customer. I really can't fault the EDA companies for what they do; it is a way to make a business out of our complex industry.
Throwing the baby out along with the bath water?
However, in all this innovation, we seem to have left no room to solve the simplest of problems – namely, the ones the designer needs solved in his or her daily work life. Where does he or she turn to solve them? The smart algorithm developers are far removed from the end customer and are plagued by internal deadlines and processes that ensure that all their time is spent on the design, so that there is very little time to see or feel the pain of the end customer. The recognition they strive for and get is from their peers and managers.
The big design houses can afford a CAD engineering team that can at least try to resolve the issues that their engineers bring them with scripts or simple fixes or mostly by beating up on their EDA tools suppliers, but those that don't either have the clout or are not big enough, have no recourse but to live with this problem, or as we are hearing from the pundits – a lot of companies are turning to build tools or augment their in-house CAD groups as they did in the early days or electronic design automation.
We as an EDA industry can help this situation.
The engineering answer to solving a problem always starts with breaking it down into simpler problems. Internally, we all do that, but we don't publish the partials as the value at the end of the day is represented by who builds and owns the complete solution. This is counter to what the end-customer wants. If we were to publish all the simpler tasks and provide a "tool-box" of solutions, then the customer himself (or a paid service provider) can integrate these pieces into elegant solutions.
Does it really work?
Ask any hardware design engineering manager about what they like most about their EDA vendor, and it invariably is the AE that comes with the tool. Why? Because it is this individual who can work wonders with the tools their company develops – but even more than that, they can often tailor the tool to solve the problem. Let's call this the customization engineer.
Now what does this customization engineer use for his toolbox? It turns out that it is not just skill, but the toolkits they share amongst their colleagues, and tools they get from their tool developers. These goodies are invaluable for keeping customers happy. These tools never see the light of day in a price book, but without this effort (which it turns out is usually trivial for a tool developer), a large number of deals would collapse. These tools are toolkits that embody core algorithms, but are used in ways that often were not originally thought to be the mainstream use of the tool.
If you look at the software industry, the process, of breaking a solution into its internal components, has been proven to work over and over again. Whether it is in the Web world of today (Java components, Java Beans et al) or in the C++ world (class libraries and toolkits), this is known as component-based design.
Closer to home, the IP industry has blossomed with the exact same idea. Building IP to solve specific but simpler problems and integrating it into a SoC has finally taken hold after a few initial hiccups. We can surely learn from those mistakes and build a solid foundation for this type of activity.
A specific example
Here is a specific example of how something like this would work. In the context of the emerging market of programmable fabrics, or the plethora of semiconductor fabrics with both FPGA like and ASIC like qualities, Clive Maxfield has done an admirable job of classifying these in his book The Design Warrior's Guide to FPGAs
In this book, Maxfield classifies programmable architectures based on three different axis, namely, their technology basis (SRAM, Antifuse, Flash), the granularity of the basic building block (coarse grain, medium grain and fine grain), the programming basis for the building block (MUX based or Lookup-table based). In addition to the node-in-an-array programmability that he describes, there are other structured ASIC like approaches that include VIA programmable techniques. One can clearly see that the number of these fabrics start growing rapidly as you start selecting one from each of the axis. If you look further into the details of what is required to make one of these fabrics successful, one of the primary components is the EDA tools available to program these fabrics. Ensuring that these EDA tools are customized to take advantage of each of these unique innovations is a critical success factor for these fabrics to survive.
If we look under the hood for what is exactly required to build a toolset for these fabrics, they will need HDL language parsers, elaborators, mappers, synthesis engines, module generators, placement engines and routers, and netlist translators. An off-the-shelf solution by its very definition will not work, because it is not tailored to the fabric. Each fabric has its own nuances, and needs a specific set of targeted library elements or pre-built components.
No front line EDA vendor is stepping up to provide a customized toolset for these fabric providers.
However, it is possible to engineer a solution with Front-End components (parser and elaborator) from a vendor such as Verific (www.verific.com), a synthesis engine and its associated customized module-generator and mapper from a vendor such as SoftJin (www.softjin.com), and possibly a placer and router that might need to be built for the fabric from scratch. VPR from the University of Toronto was the right idea for such a solution.
The elegance of this solution comes from the fact that you don't have to compromise quality of results to adopt such a solution. All it requires is that each component be individually tested and verified and the appropriate pieces customized as necessary.
Solutions have to be as individual as the customer itself
This approach introduces a new way to think about solutions that move away from a common off-the-shelf product model to a more customer-centric customized tool development model. The way to accomplish this is to pre-develop and license key re-usable EDA modules and then enhance or extend them for the specific requirements of the customer. The model allows for an EDA company to profitably develop specific features for a customer and at the same time spread the cost of common R&D involved in developing re-usable components over its customer base.
Is this what customers want? Why don't we ask them?
Currently, he is helping SoftJin pioneer innovative approaches both in technology and business models that could affect the way the EDA industry operates today. Prior to this, at Cadence, he was one of three technologists, looking into innovative business models and new services opportunities in the eMerging Business Unit.
Kumar has published several papers, presented technical seminars and has been awarded over 10 patents. He is an active participant in the industry standards activity both in VSIA and VCX and has co-authored one of the widely adopted standards in the area of IP reuse. Kumar received his MSEE from Columbia University, NY in 1983 and his BSEE from University of Madras, India with a specialization in Communications in 1981.
......................................................................
