OPENCORES.ORG

The test benches would have to be dealt with. When implementing the

Bill Cox wrote.
> 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.
>

Very interesting that you should mention this.   I am working (as we speak)
on some
ideas along these lines.

The problem Open Cores has ( from what I have seen ) is :
a lot of good ideas  --  but a lot of independent people  --- and not enough
resources
to pull everyone together.

To the senior guys that are working on Open Cores --- 

It would sure be nice if the "wishlist" page were cleaned up and
prioritized.
I'm probably not the only one trying to figure out how to help.

Its hard to figure what anyone really wants done.
(Some of the "wishlist" projects seem to come from grad students - they need
to be doing their own work).

bj Porcella

----- Original Message ----- 
From: "Bill Cox" <bill@v...>
To: "Discussion list about free open source IP cores" <cores@o...>
Sent: Wednesday, January 28, 2004 11:32 AM
Subject: Re: [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
>
>
> _______________________________________________
> http://www.opencores.org/mailman/listinfo/cores