|
Message
From: Bill Cox<bill@v...>
Date: Wed Jan 28 17:49:01 CET 2004
Subject: [oc] Potentially awesome open-source idea
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:
>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 ;-)
>
>
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.
>>On Wed, 2004-01-28 at 19:41, Bill Cox wrote:
>>
>>
>>>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).
>>>
>>>
>>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.
>>
>>
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.
>>
>>
>>>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.
>>>
>>>
>>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 ?!
>>
>>
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 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).
>>>
>>>
>>Yes, I would definitely shoot for a source code instead of
>>a netlist generation.
>>
>>
>>
>>>The impact on design productivity is potentially huge.
>>>
>>>Any interest in discussing the idea?
>>>
>>>
>>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 ?!
>>
>>
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
|
 |
Browse
