There are some standards that are designed to make IP Integration esier, such as IP-XACT (IEEE-1685). It's hardly perfect (in fact is it undergoing some significant enhancements), but IP-XACT does enable the capture of all the register information, modes, interfaces, etc. to enable IP to be "packaged" for integration. Tool such as those from Duolog (full disclosure - I work there) can use IP-XACT data to integrate the IP automatically, e.g. construct the full chip memory map or stitch together subsystems and systems.
Some of the larger IP companies have embraced IP-XACT, but the smaller ones seem to lag behind. I think it's mostly a manpower issue for them, but it could be solved quite easily with some automated tools.
It's a great question at the right time, Brian. So much more could be accomplished if progress was made here. I like what Synopsys is doing, but it's a point solution. Still, with so much innovation happening at the IP level and so many divergent needs. i have a hard time seeing any real standards evolving any time soon.
Do you really want to test and verify the IP you add to your system? Is there a way to define/partition IP in such a way that it is 'correct by construction' when added to a system?
Maybe we can create IP using a standard interface, a standard protocol and 'higher level' operations that dramatically simplify the 'integration' process. Perhaps simplify it so much we don't really need to worry about 'integration' any more? Then we have a real solution...
Is this a possibility? Any work going on along these lines anywhere out there anywhere?
When you integrate IP into an SOC, one of the things you will need is test vectors for ensuring that the block you added is performing as expected. Happily, there is a standard now out that might help. It's the new JTAG IEEE 1149.1-2013. This is an extension of the boundary scan architecture defined for board test long ago, intended to simplify internal IC test. As I understand it, it allows IP developers to define JTAG testing for the boundary of their block, and have the test vectors they develop able to be dropped unchanged into a larger test program. This should simplify creating the necessary test patterns for SOCs.
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 ...