Why ASIC designers should not fear merging or conflicts
April 11, 2016 Leave a comment
ASIC designers have a very strong sense of ownership towards their code, and although they collaborate at interfaces, they seldom let another designer edit their code. I finally understood using an analogy.
ASIC designers are like civil engineers. Let’s look at what each type of engineer builds:
|Civil Engineer||ASIC Designer||Verification Engineer|
|City blocks||ASIC blocks||Data Generators|
|Highways, Roads||Buses, Signals||Transaction data|
|Intersections, Traffic Control Devices||Muxes, Arbiters||Functions and methods|
|Buildings||Memories||Abstract data types, lists, databases|
The things ASIC designers (and civil engineers) build are static in nature, they don’t flow, they don’t live: they exist to hold stuff and do things to stuff. Their creations are instantiated statically, and while they can serve more than one need, they are the place you go to for a service. The file that describes the “road” or the “building” is strongly tied to the engineer who designed it. And so designers see nothing limiting in operating a versioning control system that locks files while they are being edited. And when two people edit the same file, panic sets in: how can a file be edited by two people at the same time? How is this not breaking the file (and ruining my design)?
The verification engineer on the other hand builds the living things that flows through the services provided by the statically instantiated hardware. Those living things travel on buses, flow from block to block, get stored and are read back to be stored in another place. They are processed by multiple hardware instances. They are transformed along the way. They don’t have a sense of ownership over the data they throw at the design.
The problem of merging and conflict resolution has been solved a long time ago. Have no fear. But I guess it depends on the tools you are using.
This post was originally written in 2008, but has been published in 2016!