1. RTL semantics cannot ensure proper connectivity, both in terms of port hookup and in terms of interface protocol — this means that designers have to lean on written specifications to understand the protocol and caveats around a piece of IP. It also means that a lot of control logic has to be written for every instantiation of a piece of IP. We use FIFO as the classic example — for every instantiation:
* You have to ensure that you don’t enqueue when full; don’t dequeue when empty; and don’t simultaneously enqueue and dequeue when you are not supposed to (each FIFO is different) — this is a fair amount of control logic
* If there are more than one user of the IP, you need to correctly coordinate this control logic and mux/arbitration logic with others — even more complicated

2. Inevitably, and especially for in-house IP, you need to change something — this is where you break things because it’s hard to read other people’s RTL and because control logic is highly complex.

I like the idea of reporting quality in public forum — but without a better semantic model for hardware, you’ll never solve the above two issues.

If you release your product under an opensource license then I will be glad to report all the bugs I find as well as checking in the bug fixes along with documentation and a test suite. I’m that kind of guy.

But if you are selling your product then my responsibility ends when my check clears. I expect that you will pay for the QA and bug fixes and if I’m doing your QA testing then I want to see a check from you.

Let’s start a movement. If IP vendors had to pay the going rate for all the QA testing that users perform then maybe they would do a better job before they release.

John Eaton

Thanks, Kwam. Now I can’t get the picture of naked IP providers out of my head

Seriously, I think this sort of transparency works under certain circumstances:

1) There is a single portal (or a few portals). For books, there is Amazon and B&N and that’s 95% or the online market, so there is critical mass where you can go and find the reviews. A counterexample is hotel or other product reviews, where I can find many places to get these and not critical mass in one place. For IP, there are a few portals such and Design & Reuse and Chip Estimate (now Cadence) that have most IP, so its possible that this might work. (In fact, I’ve been scratching my head about why Cadence bought ChipEstimate and all I can come up with is this portal idea).

2) The rating is independent and fair. Sites like the one mentioned above don’t want to alienate the IP providers or they will lose the advertising revenue on which they survive. Can you trust a PCIExpress rating if the IP provider is one of the advertising clients? If the site only passes on user ratings (like Amazon), then at least that bias is gone.

3) The rating is dynamic. IP is dynamic and can improve over time, so it’s important that old ratings and reviews that don’t apply can be flushed out. This is I think the biggest difference between IP and books, which are static. Still, by tracking the dates of the reviews and ratings, one could come up with a trend line that would indicate quality over time.

In addition to the rating, I think there needs to be specific detailed data to the IP provider on what is broken (see the baggage example). It’s not always the IP provider’s fault. The IP can work in one release of the tools and not in the next. The goal is not to punish IP providers, but to give them the tools to to make their IP better. I’d even give them our test suite so they can get it right out-of-the-gate.

Just a thought..

Kwam

>anybody with me?

Absolutely!!!!

Here’s my take on what we need to do to get there. I think it’s a logical extension of your idea.

Provide INDEPENDENT OPEN_SOURCE Verification IP. Let the cores companies charge for the IP, but let’s see if we can get them to be tested on some standard verification IP.

Take Care,
Mike

JL

At DVCON this year, I think they were talking about teams of 100-150 designers doing the most complex chips, so the team size you gave seems right in that range.

There are a only handful of bus specs that are standards and common enough to have catalyzed a significant quantity of IP. For internal busses, AHB and AXI come to mind most readily. Externally, the PCI family and USB families. In all these cases, the spec is well documented and there is some golden validation, e.g. plugfest for hardware and VIP conformance tests for RTL. If I want to buy any of these IP, at least I can know if they passed these industry standard tests.

For other IP, there are no standard tests. The only “benchmark” for quality for these IP is the QIP metric that VSIA developed and is now managed by IEEE. But that is all self-graded and I don’t see that used much, so it’s not that helpful.

When you do something like that with designers creating cards that will plug into a mainframe then you usually have enough sense to publish a bus spec
to tell everybody what signals that they will need to create and what they can expect from the mainframe.

Has anyone seen such a spec for digital components? I have seen a lot of
guidelines but nobody has ever published them together in one place.

We need a single document that tells designers what they can and cannot do in their designs as well as rtl checkers that will catch any deviations.

When you get a new piece of code you need to have an incoming inspection
tool that can expose anything strange as soon as possible.

John Eaton