Thomson
Full Member level 3
As known, the software reuse techniques such as OOP or other associated leverage the designer’s current perception level about the software programming. Although some software programming process or management promotes the reusability as well, the knowledge of the person is the major point in the design reuse arena. Among all the reusing methods mentioned by current software development teams, the design patterns are a big step towards the road of reusing the codes previous written or maybe prepared for the future purpose.
However, after elaborate thinking, that the hardware scope can utilize such methodologies to such a big degree that everyone cannot help adopting these ideas put up by the software designers or others.
In fact, the reuse in the hardware has experienced such a big similar procedure as that of software, but in a higher-level about module IPs which contains such a full functionality more than that of software. Here some little-level reusability techniques are put up and summarized by the Dragon implementing experience and maybe helpful for the other developers.
Some similar notations are directly borrowed from the software such as design patters and virtual interface/class and objects. However some ambiguities may still exist and remains to be rectified.
<1> Adapter: which connects the two different interfaces. Of course these two different interfaces must be industrial standard such that the adapter can be reused by the design team. For example, the adapter between the AHB and Wishbone bus is just the case. Sometimes this is also called Bridge in the hardware nomenclature.
<2> virtual interface: sometimes only one interface shall be adjusted to the new version or new standard interface. For example, the PCI express shall substitute for the PCI bus, at which condition, only the interface can be replaced while the implementation of the Adapter can be unaltered. This is a smaller-level than the above design patter. This is rather analogous to that the virtual interface concept in the C++ about class’s interface that defers its implementation.
<3>Configurator: this pattern contains a lot of hardware modules such as FIFO which can be parameterized, Adders synthesized automatically by the DC and other similar ones, as well as specific hardware circuits including Card Sense Logic/ Timer/ Power-On-Reset logics.
These above all I've experienced in my development process, and if anyone have some add-ons, please just include them!
Thomson
However, after elaborate thinking, that the hardware scope can utilize such methodologies to such a big degree that everyone cannot help adopting these ideas put up by the software designers or others.
In fact, the reuse in the hardware has experienced such a big similar procedure as that of software, but in a higher-level about module IPs which contains such a full functionality more than that of software. Here some little-level reusability techniques are put up and summarized by the Dragon implementing experience and maybe helpful for the other developers.
Some similar notations are directly borrowed from the software such as design patters and virtual interface/class and objects. However some ambiguities may still exist and remains to be rectified.
<1> Adapter: which connects the two different interfaces. Of course these two different interfaces must be industrial standard such that the adapter can be reused by the design team. For example, the adapter between the AHB and Wishbone bus is just the case. Sometimes this is also called Bridge in the hardware nomenclature.
<2> virtual interface: sometimes only one interface shall be adjusted to the new version or new standard interface. For example, the PCI express shall substitute for the PCI bus, at which condition, only the interface can be replaced while the implementation of the Adapter can be unaltered. This is a smaller-level than the above design patter. This is rather analogous to that the virtual interface concept in the C++ about class’s interface that defers its implementation.
<3>Configurator: this pattern contains a lot of hardware modules such as FIFO which can be parameterized, Adders synthesized automatically by the DC and other similar ones, as well as specific hardware circuits including Card Sense Logic/ Timer/ Power-On-Reset logics.
These above all I've experienced in my development process, and if anyone have some add-ons, please just include them!
Thomson