An idea just hit me that potentially could have a huge impact on the
electronic design world. I haven't thought about it enough to describe
it clearly, or name it, so I'll just do a brain-dump of the components
involved:

-- Users post pre-synthesized cores to OpenCores (as well as RTL
source), in a generic netlist format (this is something I know how to do).
-- We write open-source tools that can combine those cores
automatically, taking core-specific options, and running the author's
customization scripts.
-- This tool then spits out gate level Verilog/VHDL to the desired
target (Xilinx, Altera, LSI, etc).

As an example, an interactive (as well as batch) version of the tool
takes inputs from the user, such as what CPU he wants, what peripherals,
etc. It then generates from generic gate-level source files a target
specific netlist combining all the elements the user asked for, using
wishbone, and any other good ideas we come up with.

I think we can automate design reuse, and make if flexible enough to
work with any combination of front-end and back-end tools. The EDA
industry wont do this (there are good reasons for this).

The impact on design productivity is potentially huge.

Any interest in discussing the idea?

Bill

On Wed, 2004-01-28 at 19:41, Bill Cox wrote:


We have actually talked about this way a while back !
We got stuck trying to determine how legal that would be
specially with tools like design compiler and may be even
Magma.



This sounds very interesting and probably also somewhat
difficult to implement. Perhaps we should provide a
environment for SoC building. One as a 'top end' with the
OpenRisc (32 bit) system, and one as a 'low end' with any
of the available 8 bit Micros.

Perhaps this can be done with a perl script ?!



Yes, I would definitely shoot for a source code instead of
a netlist generation.




I'm definitely interested.

My first input would be:

1) The authors of all the CPUs, must write a Wishbone
Interface wrapper for their CPU. Or perhaps some other
volunteer.
2) The authors of peripheral IP must provide a Wishbone
wrapper for their peripheral/device IP.
3) I would volunteer to take it all and put it together in
to one huge (low end) SoC. Perhaps someone from Damjans
group could provide a 'high end' version ?!

Cheers, rudi ======================================================== ASICS.ws ::: Solutions for your ASIC/FPGA needs ::: ..............::: FPGAs * Full Custom ICs * IP Cores ::: FREE IP Cores -> http://www.asics.ws/

Well how about having a web interface where you simply select the cores, set their addresses and interrupts (assuming this is a SoC with an embedded procsssor) and it gives you out the RTL of the SoC? This is something that will eventually (hoping for sooner than later) show up on opencores ;-) regards, Damjan ----- Original Message ----- From: "Rudolf Usselmann" rudi at asics.ws> To: "Discussion list about free open source IP cores" cores at opencores.org> Sent: Wednesday, January 28, 2004 3:10 PM Subject: Re: [oc] Potentially awesome open-source idea

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 28 January 2004 22:23, Damjan Lampret wrote:


Taking a page out of software development... and idea like this would require
a lot of standardization.. especially interfacing... using WB itself is not
sufficient.. for example, we would need the signals to be marked out clearly
and specifically for interfacing.. even licensing would need to be
standardized to avoid mix licenses used in an SoC..

it's an interesting idea.. but implementing it would require everyone's
cooperation.. it would require OC to change it's role from a repository role
(like SF, where anyone can dump anything) to something a little more like an
organization that is charged with standardizing things, exporting API and
maintaining a little more control over the things that get through (something
more akin to KDE)..

But it would be great to see something like that... maybe a software similar
to VB or Delphi, where we can drag and drop components onto a top level, link
a few things together and click GENERATE and it'll dump out the final code..
then, we'll just need to do some optimizations.. and we've got ourself a
complete SoC.. I wonder what would be the ramifications of that..



- --
with metta,
Shawn Tan.

+=======================+
| ICQ : 1802628 |
| Keyserver: F9BA3B9A |
| Linux # : 297959 |
+=======================+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAF95s9KUEj/m6O5oRAuxeAJ9a74B/C4sQvYufHaFehwvxJC3guwCcDU5p
BCrsrTrowpDeetWNJN+H5cs=
=FEXo
-----END PGP SIGNATURE-----

require

not

clearly


A step in this direction is opencores coding guidelines manual and hopefully
soon to follow a linter tool that will automatically enforce guidelines.


role

an

(something


Very true. I think opencores.org role is evolving. At the beginning it had
to be a repository because there were no open source IP cores. Today there
are some already, more on the way. So the role should change. I'm working on
this already. I think everybody will really like the new opencores.org site
when it becomes operational in end of february.


similar

link

code..


Why not just a web interface. Select what you want and it will integrate al
lthe stuff on the web server and you just download the complete SoC package?

regards,
Damjan

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.

bj

Hi, Damjan and Rudi.

BTW, Damjan, the OpenRISC effort is quite impressive. I've got two or
three silicon guys checking it out, and considering using it instead of ARM.

Damjan Lampret wrote:


A web interface will be straight-forward once a back-end system is in
place. I'd recommend using a text based back-end that takes data from
the web interface in batch mode.


There insn't any problem with posting post-synthesized code that you
have legally synthesized. You own it. Also, several tools are generic
enough to fool into synthesizing into a generic library (like Design
Compiler, and Synplify ASIC). With generic netlists, we wont need any
commercial tool in the loop to generate the combined netlists. Even
Magma takes output from Design Compiler, so we should even work well
with them.


I agree that it's going to be a big project. I've got two systems I can
donate that might help: gnetman and OpenLPM. I might also be able to
donate Verilog and VHDL readers and writers. Gnetman is a modern
netlist database that is good for manipulating netlists. OpenLPM is a
bit like Confluence. It's a module generation language. I don't know
if these pieces are the right ones, but we probably wont have to start
from scratch.


I agree. A good place to start is with OpenRISC, and a low-end CPU
(MiniRISC? and 8051?). Wishbone is a natural as well.
I think a lot of thought would need to be put into how the system works,
what it does, etc.

How about if we talk a bit about what the system would do?

One idea here is that the user simply selects components, rather than
writes RTL. At a mimum, the input would simply be a set of components.
This works if the components are all going to talk through wishbone.
I'm a fan of keeping things simple to start with, so what if we just
implement a wishbone specific system to start with (with two CPUs as
Rudi suggested)?

Another idea is that the author of a core should be able to offer users
configuration options, and then have the core customized. For example,
did you want a 32 bit MAC, or a 16 bit MAC (probably a poor example).
If we have a module-generation capability that's easy to work with, I
think we can pull this kind of flexibility off.

I think I can see at least three software projects here:

- A Web based GUI
- A tool to glue cores together, initially using wishbone
- A module generation system (Confluence and/or OpenLPM and/or JavaHDL)

The module generation system serves two purposes: First, it run scripts
to custimize cores. Second, it does more mundane tasks like converting
a 32-bit adder into actual gates. This allows us to have reasonable
performance using generic netlists.

Is this any clearer?

Bill

At we think about co-design.

One of the opinion was to have a "tools" (software or/and langage) that
could permit to write "executive spec" BUT reusing soon written IPs.

The idea is to explore architecture as quickly as possible and reuse
validated core (mainly peripherals).

So IP modele could speed up simulation but model are never perfect or even
exist.

I don't know any tools that work that way. (a bunch of shell script, perl
script, tcl script to control modelsim, + gcc compiler for the cpu model,
+ some asm to boot the cpu aren't consider as a tools :)

At we think about co-design.

One of the opinion was to have a "tools" (software or/and langage) that
could permit to write "executive spec" BUT reusing soon written IPs.

The idea is to explore architecture as quickly as possible and reuse
validated core (mainly peripherals).

So IP modele could speed up simulation but model are never perfect or even
exist.

I don't know any tools that work that way. (a bunch of shell script, perl
script, tcl script to control modelsim, + gcc compiler for the cpu model,
+ some asm to boot the cpu aren't consider as a tools :)

Hi Bill & gang --


[. . .Major discussion about a big open-source SoC builder . . .]


I've played around with gnetman a little bit. Currently, it generates
SPICE netlists from schematics drawn using gEDA's gschem, which is
cool. I think it could use some closer integration with gschem, but
that is on the way (slowly). (It's up to gschem to accomodate
gnetlist, BTW.) Also, it would be nice to see gnetman
support other output netlists. It is certainly powerful enough to
generate them; it's only a matter of writing the code for it.

My reaction to the SoC builder this is: It sounds very interesting!
But it's also a big project. How will people be motivated to work on
it, besides doing it for fun? That is, how will it make money for the
software engineers working on the project, or the companies who employ
them? What's the business model? This is important, because without
the prospect of money, progress on such a large project will be
slooooooow.

Stuart

Have you looked at the Perlilog project on OPENCORES? I have just
glanced at it, but it sounds similar to what you are describing.

Regards,

John McCaskill

bporcella 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.

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

Stuart Brorson wrote:


There are a couple possible ways to make money here.

First, here's mine. I own a lot of ViASIC stock. ViASIC will do much
better if people can be productive using our one-mask structured ASIC
fabric. We specialize in producing structured ASICs with very low NRE,
but that's only useful if the design cost to produce an ASIC is also low
(and I'm not a fan of sending all our jobs to India). OpenCores already
helps in this area a lot, which is why I'm a fan. Taking it further by
reducing the required design effort will also be good for ViASIC.

Here's a possible motivation for a smart ASIC designer that would like
to go into business for himself. These customizable cores may require a
ton of work. For example, let's think about the 8-bit microcontroller
market. An expert in this field will be able to configure our scripts
and web interface to customize a microcontroller using a wishbone bus
and several cores available on OpenCores. More importantly, he can
provide support to users, emulators, links to compilers and debuggers,
etc. In effect, the ASIC designer could set-up shop as a virtual chip
company. People would go to his web site, configure their
microcontroller, download an FPGA emulation bitstream, pay a few
thousand dollars to the ASIC guy, and send a chip order to someone like
ViASIC or one of our partners (again, more motivation for me). A few
weeks later, a UPS truck drops off a few thousand parts to the customer.

The market for these "virtaul chip" companies (as I call them) could be
huge. The major missing peices are 1) advanced cheap silicon in low
volume, and 2) easy configuration/selection of cores. OpenCores seems
like a natural place to work on the second problem. I'm personally
working hard on the first problem, and I'm going to nail it if I can get
the resources to do it.

Bill

Bill Cox wrote.
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 at viasic.com> To: "Discussion list about free open source IP cores" cores at opencores.org> Sent: Wednesday, January 28, 2004 11:32 AM Subject: Re: [oc] Potentially awesome open-source idea

On Wednesday 28 January 2004 10:49 am, Bill Cox wrote:

[large snip]



A while back I offered up Confluence to the OpenCores community for
this very concept: flexible IP and web-based netlist generation. The
offer still stands.

On a similar note, a Confluence user recently ported OR1200 to the
language. (Ken, are you going to post ORCF anytime soon?)

Bill, it's a great idea. If there's anything I can do to assist, let
me know.

Regards,
Tom

-- Tom Hawkins Launchbird Design Systems, Inc. 952-200-3790 http://www.launchbird.com/