tag:blogger.com,1999:blog-17864065.post-72373003359273112242008-07-27T12:51:00.009-04:002008-07-27T14:02:07.142-04:00I wanted to share a perspective I heard while in the Bay Area last week. We've made some of these points, but I liked the way it was wrapped.<br /><br />The context was in discussing issues with hardware design. The engineer's viewpoint was that a fundamental issue was design reuse, or the adequate lack thereof in hardware design.<br /><br />He made a comparison to the software space, where most software applications are largely built on top of pre-existing libraries. In the software space you stand on the shoulders of those before you. These software libraries aren't application specific, but are general libraries of all sorts of useful building blocks and capabilities. It wouldn't be atypical for a GUI software program to consist of only a fraction of new code, with the bulk built using libraries. And, in the software space, as libraries grow, reuse grows commensurately.<br /><br />In contrast, reuse in the hardware space consists of large, application specific blocks, e.g. PCIe, processor, etc. You just don't see a lot of general purpose libraries that can be easily used in different situations to build your designs. And, when you do, typically they're very brittle -- it's difficult to interface to them, to change them and to leverage them for specific needs.<br /><br />I think there are two fundamental reasons for this:<br /><br />1. There are no standard interface conventions (analogous to calling conventions in the software space) -- this means that it's very hard to use hardware IP blocks. Each instantiation requires a custom, manually-intensive, situation-dependent implementation.<br /><br />2. Shared resource conflicts must be manually handled. Hardware is parallel -- and the biggest complication is avoiding (scheduling around) race conditions where two operations might try to access the same resource (such as a register or an interface, such as enqueue and dequeue on a FIFO).<br /><br />These two items prevent IP from being reused as a black box. The semantics of RTL (I include SystemC, SystemVerilog, Verilog, VHDL) prevent this from ever happening -- just like assembly language prevents the type of libraries that you see at a higher level in languages like C/Java/...<br /><br />Atomic transactions address both these problems -- and enable general purpose hardware libraries, including those that look very much like what you might expect to only see in the hardware space.George Harperhttp://www.blogger.com/profile/12782319843580094075noreply@blogger.com2