	SoC Builder Home Page
		Home

SoC Builder Home Page

SoC Builder is a new project in its infancy. Discussions about SoC Builder are currently taking place on the SoC Builder discussion list. Any comments should be directed to the mail list. Active discussion topics can be seen at this mail archive.

Anyone who wants to take part in this project should send me an email at bill@viasic.com

For more information, check out this discussion summary.

Also, check out Rudi's preliminary spec at soc_gen.pdf.

A summary of what I have in mind for the SoC Builder follows.

What Is It?
How It Works
SoC Architecture
SoC Builder Architecture

1. What Is It?

Building SoCs, or at least a good starting point, is the latest thing in IC design automation. Think of it as Power Point templates. You select a basic layout, customize colors, add your logo, and presto, you have an empty presentation that looks pretty good, even if the only text you've added is "Hmmmm". Perhaps I should have used it to build this web page...

More specifically, an SoC builder is a tool that combines proven IP cores automatically into a complete RTL description. Our goal is to automate integration of IP cores from OpenCores. We assume that you are familiar with OpenCores in the rest of this document.

2. How It Works

Well... it doesn't, at least not yet. Perhaps you would like to help change that? Consider being a developer and contribute code, web pages (which we obviously need), or RTL! If you'd rather give money, save it for charity. My financial problems are way to big for you to fix (unless you're Bill Gates, but I hear he's not a fan of open-source).

In theory, our SoC Builder will take input through the web, where users can select a CPU (OpenRISC 1000, 8051, PIC, ...), some on-chip busses (Wishbone), some RAM, ROM, and peripherals such as USB, SPI, UART, PWM/timers/counters, etc. Each core will have a configuration page to customize it. When you've made your selections, press the RUN button and pray. Of course, a completely bug-free and timing-correct synthesized netlist will pop right out! Yeah, right. Well, that's the idea at least.

3. SoC Architecture

To start with, we'll try to support at least two CPUs (OpenRISC, and a small microcontroller). The Wishbone bus allows peripherals to be added in a fairly simple manner. We'll add Wishbone compatible cores over time. We'll also provide a Wishbone interface to your custom core(s). Talking to the SoC could be done in different ways, and hasn't been discussed yet. In particular, there's JTAG, and a debug core. If this description sounds weak or poorly thought out, well fix it! This baby needs some really good RTL guys (I'm more of a coder) to put some real thought into it.

4. SoC Builder Architecture

SoC builders already exist. Altera has one. I litterally was given a demo of another one two days ago. For only a few hundred thousand dollars, I could fill out a form, press the run button, and get a gate level description of a chip. I don't want to knock the product. It looks very good. It's just a bit too expensive for a typical project that might need a few thousand chips. Oh, if you select the ARM core, you need to pay a bit more. You really don't want to know how much. Even Bill Gates would cringe.

Basically, the architecture hasn't been nailed down either. The basic idea is to do something simple, but try to weasle out of getting nailed down into specifics until we're pretty comfortable with them.

That said, there are at least two aproaches that can be taken, and which one is still up in the air.

First, we could do it the traditional way. Basically, we'd just write a bunch of Perl scripts to munge the SoC together at the RTL level. With this aproach, we could probably leverage Perlilog, but someone would have to write an equivalent for VHDL. This aproach has a lot of advantages. The generated RTL code could be simulated at the RTL level. The synthesis tools would have a chance to optimize the whole system globally. Independent synthesis vendor Synplicity sells more synthesis tools, and I make money on their stock.

Second, we could do it through intermediate generic netlists. With this flow, each core would be synthesized once into a generic high-level netlist format similar to LPM, but based on Verilog and VHDL. The SoC Builder would read these netlists into a real netlist database and glue the cores together there. Then, each of the high-level components that had not yet been reduced to gates, such as counters, multipliers, etc, would be passed to a module generator and rendered to gates specific to a particular back-end technology, such as Xilinx or a structured ASIC. There are advantages to aproach. First, no commercial tools are required in the loop to complete a gate-level netlist ready for place and route on the technology of choice. Second, we avoid the headache of trying to get all the RTL to play together. Third, there's a better chance that the resulting netlist will actually work.