There have been several ideas posted so far to the socbuilder-discussion list. This is a crude attempt to capture them so we can begin to converge on the architecture for the SoC and the SoC Builder.
SoC Architecture
There seems to be consensus that the SoC should be built around bus interfaces, starting with wishbone. It sounds like we should plan to be bus neutral, but get wishbone right first.
On the bus(es) there should be master and slave cores. There has been discussion about peer-to-peer testbenches where a testbench for a slave knows there is a master, but not what type (is this right?). The details are fuzzy to me (feel free to edit this page and fix it).
There has also been discussion about having a standard test interface in the cores.
To get started, it has been suggested that we work with only two CPUs (probably wise). The OR1K is a no-brainer. For a second CPU, the 8051 has been suggested.
Richard states that the ideal SoC Builder would be similar to Sonic's silicon backplane SoC-builder. Anyone got any public domain info on this?
SoC Builder Architecture
Some tasks we need to do include checking out existing tools. This includes:
Perlilog
Rudi's CONMAX IP core
Flint manual
There seems to be consensus that synthesizable RTL should be the primary output of the SoC Builder. Perlilog could perhaps be used to generate this, but we'd also like to see VHDL support. Lower priority has been placed on supporting integration of post-synthesized netlists. Generic netlist support probably requires a module generator tool, such as Confluence, or possibly my old OpenLPM tool.
If someone could take a close look at the CONMAX core and summarize what it does, that would be great!
SoC Interface
There have been two interface styles suggested: web based selection and configuration, or Java based graphical assembly. The simple web based interface would be somewhat form based, where users select and configure cores. A graphical version could show the cores connections to buses, and possibly allow editing at a bus connection level. There doesn't seem to be a lot of concern here, since people seem confident we can write the interface. The SoC Builder itself will be text-based.
SoC Builder Output
There have been several things suggested that SoC Builder should do:
Generate synthesizable RTL for the SoC
Pad insertion
Design Compiler scripts (and others?)
Licensing summary
Address/interrupt maps
C code for self-test
Testing
There has been some discussion about testbench generation, as well as testing devices.
Testing the actual devices is done by the fab, usually in a fab-dependent manner. However, we could help somewhat generate some C code to run on the processor that could act like a self-test. Beyond that, we probably can't do much.
Testbench integration is a more interesting problem. There has been talk of C testbenches that integrate through the Verilog API to tools like Icarus Verilog. However, testbenches for VHDL is still a problem. There seems to be some consensus on testbenches:
It's hard to do
Peer-to-peer (master/slave) and component-based seem promising
Existing testbenches are spotty, and difficult to integrate
We may need to go forward without initially having great testbench support, although there is strong agreement that it's a critical issue. However, we can probably pick a methodology to support, and start getting cores to conform to it. One approach was documented at http://pages.sbcglobal.net/bporcella/ This approach looks cool, and it may apply for both testbenches and BIST of actual devices. However there is concern that we may be taking on too much by trying to standardize on such an approach. The peer-to-peer approach is Richard Herveille's concept, and sounds very promising. More documentation on it would be great.
Approaches have been characterized in two categories:
Component based testbench/core with some automated integration. This probably includes peer-to-peer.
Standard API based. This would include Verilog PLI testbenches, and probably Bj's BIST approach.
Licensing
There was much discussion about licensing, and so far as I know, none of us are lawyers. However, this seems to be the consensus:
Lesser GPL and BSD licensed cores are OK
Full GPL cores will generate warnings, since resulting designs can be freely copied by competitors
SoC Builder source code will be released under GPL.
All generated output of SoC builder that is not directly derived from a license core will be the property of the person(s) running the SoC Builder tool.
This should keep any commercial company from reselling the SoC Builder, and simultaneously make the generated designs as useful as possible, and acceptable for general commercial use.
There is some uneasiness about the vagueness of the Lesser GPL. There seems to be consensus that we interpret layouts and bitstreams to have the same status as compiled executable code, and that chips are like CDs in that they are used for distribution. It would be helpful if we generally agree that should any licensing issues come up that we haven't foreseen, that we will work together to resolve them so that our original intent is followed.
bjp I was here 2/11/2004 1 day late -- a few
dollars short -- but who is counting its Miller Time this CVS-SSH thing
has really been nasty---and its still not 100% configured correctly