Amnon Parnass
New member
Design reuse is a booming trend in the chip design industry, the IP market is constantly growing and many select to purchase an IP over spending the effort and facing the risk of designing the required functionality. This approach works well for large design pieces where detailed specific knowledge is required and the complexity of design is high. But what about low level design reuse?
The common practice for low level “Bite size” design reuse is “code scavenging”, which is a clean phrase for the actual practice most of us logic designers use in our day-to-day design tasks. If you know there is some component that you can use again, even if it requires some slight modification, then you will do so as long as you trust the person who wrote the code and you can understand it well enough to do the required modifications.
Code scavenging is probably the most frequently used and least complex way of re-using code and has been in practice for many years. Actually, logic design is quite difficult to teach and most designers learn by reading pre-designed code and using it as the starting point for designing their own logical blocks. So effectively, they "scavenge" the good parts and modify them for their design intent.
The problem with the “code scavenging” approach is the lack of methodology, resulting in lost effort and increased risk. Acknowledging that scavenging actually exists and is a part of every logic design engineer’s daily design tasks reveals the potential benefits of employing this common practice in a methodical ways.
One such method would be to use a library of pre-designed and pre-verified code components, this library would be clearly cataloged and well documented, reducing the time it takes to search and evaluate code for “scavenging” style re-use.The components on the library would be any nontrivial, nearly independent, and replaceable part of a design that performs a clear function within a well-defined architectural requirement. The design component would be parameterized, allowing multiple uses in different design contexts without modifications.
Defining low level components with clear interface and specific functionality would make them easy to verify and document for future use. Adding verification assertions to those components would enable encapsulation of the design intent and assumptions on the components interfaces. The components are actually turned into “verification agents” within the block, serving to check the surrounding logic correctness.
Actual chip design experience, using a component library, reveals additional benefits of this method. Design micro-architects started using the available library components to define the design intent, reducing misunderstanding between designer and architect. The result was a common “language” for definition of block functionality where everybody understands what a “Weighted round robin arbiter” or an ”Asynchronous FIFO”, means. The process of defining and reviewing the micro-architecture of a block was significantly reduced.
Further productivity improvements came from the design team itself where designers started by first instantiating pre-defined generic components from the library and only then, added the block specific functionality. Typical blocks went from micro-architecture stage to first test in half the time, and were ready for integration much earlier.
The conclusion is that having a component library can streamline the code scavenging design practice and harness it for the purpose of improved chip design flow productivity.
<script src="//platform.linkedin.com/in.js" type="text/javascript"></script>
<script type="IN/Share" data-counter="right"></script>
The common practice for low level “Bite size” design reuse is “code scavenging”, which is a clean phrase for the actual practice most of us logic designers use in our day-to-day design tasks. If you know there is some component that you can use again, even if it requires some slight modification, then you will do so as long as you trust the person who wrote the code and you can understand it well enough to do the required modifications.
Code scavenging is probably the most frequently used and least complex way of re-using code and has been in practice for many years. Actually, logic design is quite difficult to teach and most designers learn by reading pre-designed code and using it as the starting point for designing their own logical blocks. So effectively, they "scavenge" the good parts and modify them for their design intent.
The problem with the “code scavenging” approach is the lack of methodology, resulting in lost effort and increased risk. Acknowledging that scavenging actually exists and is a part of every logic design engineer’s daily design tasks reveals the potential benefits of employing this common practice in a methodical ways.
One such method would be to use a library of pre-designed and pre-verified code components, this library would be clearly cataloged and well documented, reducing the time it takes to search and evaluate code for “scavenging” style re-use.The components on the library would be any nontrivial, nearly independent, and replaceable part of a design that performs a clear function within a well-defined architectural requirement. The design component would be parameterized, allowing multiple uses in different design contexts without modifications.
Defining low level components with clear interface and specific functionality would make them easy to verify and document for future use. Adding verification assertions to those components would enable encapsulation of the design intent and assumptions on the components interfaces. The components are actually turned into “verification agents” within the block, serving to check the surrounding logic correctness.
Actual chip design experience, using a component library, reveals additional benefits of this method. Design micro-architects started using the available library components to define the design intent, reducing misunderstanding between designer and architect. The result was a common “language” for definition of block functionality where everybody understands what a “Weighted round robin arbiter” or an ”Asynchronous FIFO”, means. The process of defining and reviewing the micro-architecture of a block was significantly reduced.
Further productivity improvements came from the design team itself where designers started by first instantiating pre-defined generic components from the library and only then, added the block specific functionality. Typical blocks went from micro-architecture stage to first test in half the time, and were ready for integration much earlier.
The conclusion is that having a component library can streamline the code scavenging design practice and harness it for the purpose of improved chip design flow productivity.
<script src="//platform.linkedin.com/in.js" type="text/javascript"></script>
<script type="IN/Share" data-counter="right"></script>
Last edited by a moderator:
