|
Message
From: Bill Cox<bill@v...>
Date: Wed Jan 28 20:32:24 CET 2004
Subject: [oc] Potentially awesome open-source idea
bporcella wrote:>I don't have any basic problem with the idea - it seems relatively
>straightforward to implement.
>but don't see how impact on productivity could be potentially huge (or even
>significant) -- unless of course the tool
>also puts together the composite testbench and writes the total verification
>suite.
>
The test benches would have to be dealt with. When implementing the
cores in an ASIC, I'd also like to see testing addressed. I'm not sure
how this happens, but I know that there have been reasonable solutions
in the past. At HP, we had an advanced testing scheme where each part
of our chip had it's own test-bench, and the overall testbench was
somewhat automatically created from them. I don't recall the details of
the system, but I think the designers told the tool how to get data to
and from their core, and the tool did the rest.
I think that what OpenCores is already doing will have a huge impact on
productivity. Having a rich set of proven reusable cores is big. When
they're open-source, we have added benifits of not having to negotiate
contracts with each core's owner, and we can take them to different fabs
with little effort.
Since OpenCores isn't a big EDA or silicon company, I think there's a
real chance we can get beyond the issues that traditionally stop
progress towards simple integration of cores. Efforts like LPM and
virtual-socket-interface get spoiled when companies like Synopsys and
Cadence start using their influence to gain competitive advantages.
For example, we could put together a set of post-synthesized verilog and
VHDL cores in a generic high-level netlist format. The big EDA and
silicon companies out there aren't willing to support such an effort for
various reasons (thus, the poor showing of LPM). Then we could glue
them together automatically with tools like
Perlilog/Confluence/OpenLPM/JavaHDL.
Having the intermeadiate format could eliminate a lot of pain. For
example, one core might have been designed with Design Compiler, and
another with Synplify. How do you use them together today when there
are portability issues? A generic target format would allow cores to be
synthesized by the designer of the core, and then reused by people who
don't own the same front-end tools. It also allows us to get around the
VHDL vs Verilog problem, since the intermeadiate netlist format could be
available in both.
Bill
|
 |
Browse
