English
Planning, adopting and implementing adaptive reuse
By Camille Kokozaki, IDT
edadesignline.com (November 18, 2008)
It has been mentioned that during the rough-and-tumble days of 1950s Chicago politics, a ward boss asked an Adlai Stevenson volunteer who sent him to help in the campaign and when the response was nobody, he quickly replied: "We don't want nobody nobody sent." It is the same with reuse in that nobody wants reuse no one reuses. If you have to question the reuse benefit, then you should not spend resources making anything reusable. Similarly, no convincing is necessary when reuse becomes a practice weaved into the design process such that when it is built, it gets used with cool efficiency.
Many dogmatic arguments have been waged about the advisability of planning for reuse when project schedules can suffer due to added design delays or increased burdens on documentation. The originator of the reusable element or methodology usually dreads subsequent demands for support by any future user of the reused element. To be sure, many misguided reuse attempts did not achieve the intended benefits of reuse, which should be modularity, efficiency, repeatability, productivity, interoperability, consistency and development cost savings. The desirability of reuse can significantly change depending on the time horizons that a return on investment (ROI) analysis chooses and on the various reuse scenarios that marketing envisions. Reuse of IP in a different context, which would turn one perfectly functioning chip into an inoperable one, has caused many to be cautious when it comes to whole-heartedly embracing reuse. It is undeniable, though, that a methodology including reuse as common practice will garner many benefits in quality and productivity even when no reuse is intended or planned. This is because the reuse discipline tends to sharpen awareness of interoperability and interdependencies while being an excellent communication vehicle among temporally or geographically distant authors or beneficiaries of reuse. Streamlining, breaking the problem into manageable pieces and reducing degrees of interaction complexities are benefits that come to mind when reuse intent and practice are at work.
The reuse imperative (where the developer and implementer are two separate entities) has potentially two separate goals, depending on whether the point of view is from the reuse content developer or the reuse content consumer. The developer perspective considers implementing the most universal and versatile solution to maximize dissemination and sale, while the reuse consumer wants the solution that provides the most differentiation with unique features not easily reproducible and may be willing to give up reuse to maintain the value-add that is hard to reproduce. One way to reconcile those two conflicting necessities is to develop adaptive, reconfigurable approaches that allow single development with multiple, user-modifiable uses. A memory compiler is a perfect example of a design-once, retarget-multiply-without-compromising differentiation. With this in mind, creating environments that lend themselves to reuse and retargeting can provide the optimal solution for reuse and value maintenance while helping productivity. To complete the picture, one has to be aware as to whether the reuse is applied pre-silicon or if the reuse is intended for post-silicon reconfiguring. Field programmable gate array (FPGA) and tunable/register or software programmable options are examples of post-silicon reuse.
edadesignline.com (November 18, 2008)
It has been mentioned that during the rough-and-tumble days of 1950s Chicago politics, a ward boss asked an Adlai Stevenson volunteer who sent him to help in the campaign and when the response was nobody, he quickly replied: "We don't want nobody nobody sent." It is the same with reuse in that nobody wants reuse no one reuses. If you have to question the reuse benefit, then you should not spend resources making anything reusable. Similarly, no convincing is necessary when reuse becomes a practice weaved into the design process such that when it is built, it gets used with cool efficiency.
Many dogmatic arguments have been waged about the advisability of planning for reuse when project schedules can suffer due to added design delays or increased burdens on documentation. The originator of the reusable element or methodology usually dreads subsequent demands for support by any future user of the reused element. To be sure, many misguided reuse attempts did not achieve the intended benefits of reuse, which should be modularity, efficiency, repeatability, productivity, interoperability, consistency and development cost savings. The desirability of reuse can significantly change depending on the time horizons that a return on investment (ROI) analysis chooses and on the various reuse scenarios that marketing envisions. Reuse of IP in a different context, which would turn one perfectly functioning chip into an inoperable one, has caused many to be cautious when it comes to whole-heartedly embracing reuse. It is undeniable, though, that a methodology including reuse as common practice will garner many benefits in quality and productivity even when no reuse is intended or planned. This is because the reuse discipline tends to sharpen awareness of interoperability and interdependencies while being an excellent communication vehicle among temporally or geographically distant authors or beneficiaries of reuse. Streamlining, breaking the problem into manageable pieces and reducing degrees of interaction complexities are benefits that come to mind when reuse intent and practice are at work.
The reuse imperative (where the developer and implementer are two separate entities) has potentially two separate goals, depending on whether the point of view is from the reuse content developer or the reuse content consumer. The developer perspective considers implementing the most universal and versatile solution to maximize dissemination and sale, while the reuse consumer wants the solution that provides the most differentiation with unique features not easily reproducible and may be willing to give up reuse to maintain the value-add that is hard to reproduce. One way to reconcile those two conflicting necessities is to develop adaptive, reconfigurable approaches that allow single development with multiple, user-modifiable uses. A memory compiler is a perfect example of a design-once, retarget-multiply-without-compromising differentiation. With this in mind, creating environments that lend themselves to reuse and retargeting can provide the optimal solution for reuse and value maintenance while helping productivity. To complete the picture, one has to be aware as to whether the reuse is applied pre-silicon or if the reuse is intended for post-silicon reconfiguring. Field programmable gate array (FPGA) and tunable/register or software programmable options are examples of post-silicon reuse.
|
E-mail This Article | 
|
|
Printer-Friendly Page |
