Use of IP in an SoC is analogous to OOP, so much can be taken from OOP software development. The EDA tools today do nothing to assist the designer in the early stages, but rather seem to assume that the design is complete at day one. So synthesis optimization is part of the first compile when the design is not complete so it will throw away anything that is not totally connected then only says "sy6nthesized away these nodes". On the other hand an OOP compiler gives meaningful error messages. Another thing the OOP source editor provides selectable information for classes and methods at entry time. HDL source editors offer absolutely no help. Real chips are made up of and/or/invert, not if/else/case/always. The IP should be defined as a class so it can be compiled/instantiated along with the software in the system design. Then the function should be mapped onto the chip. Since the IP class would have been derived from the hardware design, it would be a matter of instantiating the IP modules.
Food for thought.
Your point about risk introduced by having at least two distinct teams (software at one end and silicon implementation at the other) is an important one. I agree that the hard boundaries drawn between the 'hardware' team and the 'software' team make it easy for cracks to open up - cracks which unrecorded architectural requirements or assumptions get lost in.
A breed of SoC engineer that understands the big architectural picture, the tools and techniques used at each stage and the methodologies for keeping the implementation in line with the system-level models would be of great value. Until there is a critical mass of such engineers, I wonder if the best tools in the world can be readily adopted...?
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...