I think the SoC Builder project should happen. From discussions so far
(that I've seen), here's what I think should be done:

First, I'll work on the generic netlist format, generic Synopsys
library, and associated code. It's not super interesting work, but it's
the only way I can think of to allow SoC builder to run legally on the
OpenCores server.

Second, it would be great if one of you web-guys out there (which I am
not) would sign up for doing some initial web pages for us. Just some
simple selection widgets and a way to spit out a text file of choices
would be a good start. Of course, once you start, I suspect that we'll
be asking for a lot more...

For the first version of the SoC Builder, someone (possibly me) could
just write some very simple scripts to glue together the structural netlist.

Finally, there's the task of converting the generic SoC structural
netlist to a specific target. I think this is the hardest part. My
old OpenLPM project would be OK for doing this, but if we can get
another language-neutral open-source module generation tool, I'd be for it.

To improve performance for mapping to specific targets, I'll create an
option for including target-specific gate-level netlists rather than the
generic netlist. However, I want to be sure to have the generic version
of each component as well so that the resulting designs can be re-targetted.

Bill

I can do simple web design. I know html and Java. I can't do any php,perl,python or anything like that. I would suggest starting this project on both the opencores website and sourceforge (linking with freshmeat wouldn't hurt either). I also suggest searching for what other people are doing now for a few weeks to see what work has already been done. Maybe a componentized aproach would be good. One module for the GUI, serveral modules for different types of SOC builders (confluence, Perilog, netlist generator...), and modules for different automatic test bench generators. Automatic test generation is very important. I know how to do great C testbenches with verilog and Icarus verilog simulator. I don't do VHDL though. I think you are going to find many people who are very picky about their HDL language, so a component approach would be better. That way, if they don't like your HDL choice, they can reuse your GUI and just build a different SOC builder module. It would be great if we can find a GUI that would work good for us. The eclipse tools look nice and would be a good standard, but a lot of work. There are some better ones out there, I'm sure. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 4178 bytes Desc: not available Url : http://www.opencores.org/forums.cgi/cores/attachments/20040131/6d70e3af/attachment.bin

This would work great as a GUI: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/gef-home/overview.html?cvsroot=Tools_Project It is eclipse based and there is a lot of momentum behind eclipse. -Brian -----Original Message----- From: Brian Korsedal on behalf of Brian Korsedal Sent: Sat 1/31/2004 10:05 AM To: Discussion list about free open source IP cores Cc: Subject: RE: [oc] SoC Builder I can do simple web design. I know html and Java. I can't do any php,perl,python or anything like that. I would suggest starting this project on both the opencores website and sourceforge (linking with freshmeat wouldn't hurt either). I also suggest searching for what other people are doing now for a few weeks to see what work has already been done. Maybe a componentized aproach would be good. One module for the GUI, serveral modules for different types of SOC builders (confluence, Perilog, netlist generator...), and modules for different automatic test bench generators. Automatic test generation is very important. I know how to do great C testbenches with verilog and Icarus verilog simulator. I don't do VHDL though. I think you are going to find many people who are very picky about their HDL language, so a component approach would be better. That way, if they don't like your HDL choice, they can reuse your GUI and just build a different SOC builder module. It would be great if we can find a GUI that would work good for us. The eclipse tools look nice and would be a good standard, but a lot of work. There are some better ones out there, I'm sure. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 5186 bytes Desc: not available Url : http://www.opencores.org/forums.cgi/cores/attachments/20040131/8e894662/attachment.bin

Brian Korsedal wrote:


Great!


Ok. I just filed for an "SoC Builder" project on Source Forge. I'll
also try to start an "SoC Builder" project on OpenCores as well in the
"Other" category, like the SoC Interconnection project.


I agree. Discussions about the component architecture should start as
soon as a mail list can be created.


Testbench generation seems like a tough nut to crack in a language
neutral way. I agree that being component based makes sense, and
plugging in new components should be easy. I think we should generate
some C code that the on-chip processor can run to check out it's
peripherals (and itself). This could be a simple script to combine C
test routines, but the C code for each module would need to be written.
This would work for any component attached to the CPU, whether Verilog,
VHDL, or schematic based.

I envision an SoC Builder system that can be used by non-RTL designers
to customize parts. For example, I could choose a PIC or OpenRisc CPU,
configure some SRAM and ROM, and get a gate-level netlist that could be
sent to the fab. The web site could let me download an FPGA based
emulation of my SoC which I could run on a custom emulator designed to
act like the SoC.

Hopefully, any new components that an RTL designer wants to add to his
SoC should be easily added to our system. In that case, he's
responsible for his own testbenches, and also for the C-code to check
out his component.

Such a product could compete in the microcontroller and DPS markets
where users never see Verilog or VHDL. Such users would need support,
custom emulators, compilers, etc. There may be room for small start-up
companies here.


You clearly know a lot more about this end of the project than me. If
there's no objections, I think you should make those decisions.

To get started, I'd recommend doing something simple. I think each
component should be able to have it's own web interface to customize it,
which could start out as an html page with radio buttons, numeric
fields, and check boxes to set values for the component. Selecting
components could be a bit like a shopping cart, where each configured
component shows up in a list that the user can edit. Of course, to a
non-web programmer like me, this sounds simple, but I don't know the
truth of it.

We can also assume that each component is either directly connected to
the CPU (memory, ROM, cache), or is on a bus (wishbone to start with).
There should be C-code to exercise each from the CPU.

Bill

I'll work on the GUI, but don't get your hopes up. I am really busy at work and I can sometimes be flakey. I've started a lot of projects before that have gone nowhere, but I know Java well and I've used eclipse. I think I can base the GUI on some eclipse code. I want my user interface to be similar to Simulink or Kivio (Visio). However, instead of running things on the mathlab engine, the code will be run directly on a free simulator. This will be very slow, but cycle/bit accurate. In the distant future, I would like to work in a simple and fast way to simulate the design... in the distant future. I think there should be a set of cores that are designed for testbenches. Things such as random data generators for DSP. File players just read in a golden file and read out the results somewhere and compare it against another file. FFT's (fftw C/C++ based, not HDL) to see the spectrum of what your DSP code is putting out. Maybe in the distant future, generic transmitters and recievers for protocols (DVB-T, 802.11a/b/g etc.). I know how to do the simple ones in a mix of verilog and C code. Also, it would be great if the simulators would be started in a different thread and be able to run independent of the GUI. This way, you can start several simulations and come back the next day to see the results. Maybe there will be a browser window (like a file browser) for simulation threads where you can pause, analyze, halt and clean them up (their dump files). At first I will stick to what I know and do everything just for Verilog code. I will make it flexible and modular. Each core that my GUI can use will need a small text file to tell the GUI what the core is and what it can do. Hopefully, this file would be a script. My GUI would provide generic commands and the script would translate them into exactly what needs to be done. These files should be small and easy to edit, less than a page. This way, each core can be whatever language it want's to be and my GUI will have a common interface to configure them. However, simulation will be difficult. Maybe we will have to convert everything to a netlist before we link them together for simulation? I don't know. It would be great to have a way to simulate mixed cores. I think there will be five major HDL's for cores, Verilog, VHDL, netlist, confluence and SystemC. We will probably need someone who will work on the simulator because my GUI will just be eye candy unless it has one. I probably won't get started on this right away, we are putting in 50 hour work weeks in my company trying to get our thingamagiger out the door. Probably in the beginning of March. -Brian -----Original Message----- From: cores-bounces at opencores.org on behalf of Bill Cox Sent: Sun 2/1/2004 3:41 AM To: Discussion list about free open source IP cores Cc: Subject: Re: [oc] SoC Builder Brian Korsedal wrote: >I can do simple web design. I know html and Java. I can't do any php,perl,python or anything like that. > Great! >I would suggest starting this project on both the opencores website and sourceforge (linking with freshmeat wouldn't hurt either). > > Ok. I just filed for an "SoC Builder" project on Source Forge. I'll also try to start an "SoC Builder" project on OpenCores as well in the "Other" category, like the SoC Interconnection project. >I also suggest searching for what other people are doing now for a few weeks to see what work has already been done. Maybe a componentized aproach would be good. One module for the GUI, serveral modules for different types of SOC builders (confluence, Perilog, netlist generator...), and modules for different automatic test bench generators. > > I agree. Discussions about the component architecture should start as soon as a mail list can be created. >Automatic test generation is very important. I know how to do great C testbenches with verilog and Icarus verilog simulator. I don't do VHDL though. I think you are going to find many people who are very picky about their HDL language, so a component approach would be better. That way, if they don't like your HDL choice, they can reuse your GUI and just build a different SOC builder module. > > Testbench generation seems like a tough nut to crack in a language neutral way. I agree that being component based makes sense, and plugging in new components should be easy. I think we should generate some C code that the on-chip processor can run to check out it's peripherals (and itself). This could be a simple script to combine C test routines, but the C code for each module would need to be written. This would work for any component attached to the CPU, whether Verilog, VHDL, or schematic based. I envision an SoC Builder system that can be used by non-RTL designers to customize parts. For example, I could choose a PIC or OpenRisc CPU, configure some SRAM and ROM, and get a gate-level netlist that could be sent to the fab. The web site could let me download an FPGA based emulation of my SoC which I could run on a custom emulator designed to act like the SoC. Hopefully, any new components that an RTL designer wants to add to his SoC should be easily added to our system. In that case, he's responsible for his own testbenches, and also for the C-code to check out his component. Such a product could compete in the microcontroller and DPS markets where users never see Verilog or VHDL. Such users would need support, custom emulators, compilers, etc. There may be room for small start-up companies here. >It would be great if we can find a GUI that would work good for us. The eclipse tools look nice and would be a good standard, but a lot of work. There are some better ones out there, I'm sure. > You clearly know a lot more about this end of the project than me. If there's no objections, I think you should make those decisions. To get started, I'd recommend doing something simple. I think each component should be able to have it's own web interface to customize it, which could start out as an html page with radio buttons, numeric fields, and check boxes to set values for the component. Selecting components could be a bit like a shopping cart, where each configured component shows up in a list that the user can edit. Of course, to a non-web programmer like me, this sounds simple, but I don't know the truth of it. We can also assume that each component is either directly connected to the CPU (memory, ROM, cache), or is on a bus (wishbone to start with). There should be C-code to exercise each from the CPU. Bill _______________________________________________ http://www.opencores.org/mailman/listinfo/cores -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 9182 bytes Desc: not available Url : http://www.opencores.org/forums.cgi/cores/attachments/20040201/b65070e0/attachment.bin

About a business model: SoC Builder could do well along the lines of
viasic's method of single mask additions to a sea of cells that can make logic cores.

SoC Builder (including icarus verilog and bus functional test models in icarus verilog) +
viasic's and competitors's mask programmable logic could be a money maker if Bill's quest
for the order flow to get the price right succeeds. The ante for first article needs to be below $15K
for the kinds of customers I see as a freelance engineer. They are wanting something to sell fast, too.
After doing some 5 or so work for hires like that, one garage shop engineer might spring for
ownership of a mask programmable production
Another way to make money might be custom logic and analog + cores that is reduced
to solve only the problem at hand, for small volumes, in old processes
on silicon, but I see most old process fabbing is way off in China...except for MEMS.
Aligning with MEMS 10 micron processing ($120 mylar mask making!), is likely a
way to make money, and that means analog, not just logic. It could soon
mean non-silicon organic semiconductor processing also. That means testbenches that
exist would work fine as is for clock referred tests, but all absolute time tests would need rewriting.
For the "retarded" 10 micron silicon and the large feature size "but advanced..." and
medium voltage, (15- 45V), organic transistor logic RTL code may be less valuable than
a pared down wordwidth or handmade logic design that is well minimized. For these new developments
multiple processors with special purposes and minimal/partial instructions and memory needs
will be best. It will be a creative free-for-all if we make tools to do it. I think MEMS and organics
will allow for "garage shop virtual chip companies" more than programmable logic alone, but
programmable logic will be the bread and butter income generator to get anything started with.

John Griessen

Below is a review of parts of recent discussions I think are critical to this idea.
==========================
To improve performance for mapping to specific targets, I'll create an
option for including target-specific gate-level netlists
[jg]Target specific HDL blocks and testbench blocks may be needed for truly weird
processes -- If we keep the framework for generating these open, we will
be able to deal with that at a source level, otherwise hand edited
HDL blocks and testbench blocks will model the real (and slow), function of a short bus made from
45 volt organic semiconductors.
=========================
trial version of SOPC-builder from an Alteras webpage --- shows
that an SoC Builder can be done and has some merit.
=========================
The market for these "virtual chip" companies (as I call them) could be
huge. The major missing pieces 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
[jg]See MEMS/organics missing piece described above
=================
-- 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
-- This tool then spits out gate level Verilog/VHDL
On Wed, 2004-01-28 at 10:34, bporcella wrote:

[jg]Yes, the only hugely impactful productivity change would come from
using modules pretested in a certain process to really check timing constraints
so your additional parts on that bus would get timing checks.
For a garage shop "virtual chip designer", his customer will fire him if
he says "It's blown, lady... ya's Gonna' need a new engine...."
=========================
A step in this direction is opencores coding guidelines manual and hopefully
soon to follow a linter tool that will automatically enforce guidelines.
regards, Damjan
=======================
What's the business model? This is important, because without
the prospect of money, progress on such a large project will be
slooooooow. Stuart
[jg]So true.
--
John Griessen Cibolo Design Austin Texas
EE good at IR systems, power supplies, logic design, A2D D2A, digital amps,
mechatronics, SiGe and CMOS layout, MEMS/mech/electronic/photonic
modeling, charge pump PV/battery/fuel cell power converters, linux counter #249315

Hi, John. I see that you're one of those out-of-the-box thinkers. I agree that minimum chip orders need to be pushed down below $15K. I haven't been thinking of MEMs or organics in particular, but these are interesting ideas I'll have to keep in mind. Some of the other ideas you posted I strongly agree with. I think that an equation that could change the world is SoC Builder + OpenCores + advanced ASICs for https://lists.sourceforge.net/lists/listinfo/socbuilder-discussion This will let me take most of the SoC Builder related stuff off this list, which is probably already annoying some people. If SoC Builder is aproved on the OpenCores site, I'll ask to have the discussion list hosted there. Bill John Griessen wrote:

Bill it takes about 5 minutes to register a new project and about 24 hrs to set up a mailing list. I think SoC Builder would be an excellent way of taking OpenCores idea to the next level and OpenCores would be happy to host the SoC Builder project. :-) In fact in Flextronics Semiconductor we have built a technology that does the low level integration of IP Cores. It is similar to the idea of Perlilog (which also started within Flextronics Semiconductor) and I'm talking to the management to consider opening this technology and offer it as the low level of the SoC Builder. This technology has already proved as several ASIC projects within Flextronics Semiconductor were done using it. This lower layer will integrate the IP cores together, generate a traffic cop (used with WISHBONE type of IP Cores) and generate top level. It will instantiate pads etc. There was also a project started to build the GUI in Java (Marko do you have a screenshot to publish?). I have attached a manual, a script that creates an example SoC (OR1200, Ethernet MAC, PCI, UART, GPIO and Memory Controller) and I'd like to hear your comments. regards, Damjan -------------- next part -------------- A non-text attachment was scrubbed... Name: Flint Toolkit Reference.rtf Type: application/msword Size: 517492 bytes Desc: not available Url : http://www.opencores.org/forums.cgi/cores/attachments/20040206/8f70caa6/FlintToolkitReference.wiz -------------- next part -------------- A non-text attachment was scrubbed... Name: marvin.fl Type: application/octet-stream Size: 26714 bytes Desc: not available Url : http://www.opencores.org/forums.cgi/cores/attachments/20040206/8f70caa6/marvin.obj

Bill Cox Wrote


Don't forget there's services like Mosys or Europractice (www.europractice.imec.be) that allow you to get prototypes and small volumes for reduced prices.

Steven

Hi, Damjan.

Damjan Lampret wrote:



Bill it takes about 5 minutes to register a new project and about 24 hrs to
set up a mailing list. I think SoC Builder would be an excellent way of
taking OpenCores idea to the next level and OpenCores would be happy to host
the SoC Builder project. :-)

Hi!

I've attached the screenshot, but it is really not something big, since we engineers rather write the text code ;) The code that way is much more reusable and configurable. We now have tons of code in flint languge, able to generate cop, pads, BSDL files, etc. Although Damjan sent you very bad example (but other ones are probably all confidential), I hope you will find the code readable enough. I've also attached added vi syntax highlighting file. best regards, Marko -------------- next part -------------- " Vim syntax file " Language: Flint " Maintainer: Marko Mlinar, markom at flextronics.si " Last Update: Wed Feb 19 10:05:54 CET 2003 " For version 5.x: Clear all syntax items " For version 6.x: Quit when a syntax file was already loaded if version = 600 setlocal iskeyword=@,48-57,_,192-255,+,-,? else set iskeyword=@,48-57,_,192-255,+,-,? endif " A bunch of useful Verilog keywords syn keyword flintStatement include recursive exclude path syn keyword flintStatement print function syn keyword flintStatement return syn keyword flintStatement catch foreach in if else syn keyword flintStatement unconnected multidrive input output inout signal syn match flintStatement ">>\?" "old ones syn keyword flintStatement project shell import toplevel abstract property pairwise add sub module syn keyword flintTodo contained TODO syn match flintOperator display contained "[&|~!)(*%@+/=?:;}{,.\^\-\[\]]" syn match flintSpecial "\\[1-9]" syn region flintRegex start=++ contains=flintRegexSpecial syn match flintRegexCat "#" syn match flintRegexRange "[0-9]\+[\t\n ]*[:][\t\n ]*[0-9]\+" syn match flintRegexSpecial display contained "\\[1-9]" syn region flintComment start="/\*" end="\*/" contains=flintTodo syn match flintComment "//.*" oneline contains=flintTodo syn match flintGlobal "$[a-zA-Z0-9_]\+\>" syn match flintGlobal "${[^}]*}" " syn match flintConstant "\" syn match flintConstant "\" syn match flintConstant "FLIN\-[0-9]\+" " syn match flintNumber "\" syn region flintString start="\"" skip=+\\\\\|\\"+ end="\"" contains=flintEscape,flintEscapeError syn match flintEscape display contained "\\[nt\"\\]" syn match flintEscapeError display contained "\\[^\"\\nt]" syn cluster flintParenGroup contains=flintParen,flintBracket,flintParenError "Modify the following as needed. The trade-off is performance versus "functionality. syn sync lines=50 " Define the default highlighting. " For version 5.7 and earlier: only when not done already " For version 5.8 and later: only when an item doesn't have highlighting yet if version >= 508 || !exists("did_flint_syn_inits") if version else command -nargs=+ HiLink hi def link endif " The default highlighting. HiLink flintCharacter Character HiLink flintString String HiLink flintTodo Todo HiLink flintComment Comment HiLink flintConstant Constant " HiLink flintNumber Number HiLink flintOperator Operator HiLink flintEscape Special HiLink flintEscapeError flintError HiLink flintSpecial Special HiLink flintStatement Statement HiLink flintGlobal Define HiLink flintRegex Type HiLink flintRegexCat Type HiLink flintRegexRange Type HiLink flintType Type HiLink flintError Error delcommand HiLink endif let b:current_syntax = "flint" " vim: ts=8 -------------- next part -------------- A non-text attachment was scrubbed... Name: flint_gui.png Type: image/png Size: 19412 bytes Desc: not available Url : http://www.opencores.org/forums.cgi/cores/attachments/20040206/11ca6b0c/flint_gui.png

Hi, Steven.

Redant Steven wrote:


These services are wonderful. The chip they make are great for
prototypes, but too expensive for production. I checked the published
prices on the Mosis web site, and for their most advanced silicon, it
comes out to over $1,000 US dollars per part, and the part is untested.
I think for the average guy out there who just whats to make a million
dollars, ASICs are no longer affordable. I want to change that.

Bill

Dear Bill,



That depends on how many chips you want. You can go for small volumes (definition being: any volume the foundry doesn't want to give to you) too.
This can be up to a million pieces of a rather small chip e.g.

Hence there are some extra questions:
What technology have you calculated with? How many parts? Only a protoype run that gives you a very limited amount of parts?

Well, that depends. It's not necessary to use the most advanced technologies to make an application that will make you a million bucks. If you stay in the 'bigger' technologies ASICS are very affordable still. If you want to use e.g. .13 it's another story. Testing setup (SW/HW) cost is also amortized over the amount of chips you want to make. I would be very pleased to hear about novel ideas to get the cost of ASICs down for smaller volumes! Steven _______________________________________________ http://www.opencores.org/mailman/listinfo/cores

Your project was approved.. Just log in to opencores web and check your
personal page..

regards,
Miha

On Friday 06 February 2004 12:41 pm, Bill Cox wrote:

Did you managed to have it registered? Did you get a mailing list? Let me
know if you have any problems.



True. Flextronics is one of the major FPGA to ASIC conversion vendors and
for conversion open source means easy to handle. However Flextronics also
does SOCs (RTL-to-GDS flow). In this case the situation gets a little
different. However Flextronics is very open minded and believes you need to
be on the bleeding edge of changes or you will be run over by competition. I
think open source has an excellent future also in hardware (to be more
specific in cores and SoCs). IBM is now embracing Linux after many decades
of pushing proprietary software. I think IBM in ten years will be doign the
same with hardware intellectual property (cores and SoCs).

I have attached a more apropriate version. FLINT as a whole is still proprietary, but copy of the manual you can read it and if majority thinks this could be good underlaying technology for the SoC Builder, then I will talk to Flex management. regards, Damjan -------------- next part -------------- A non-text attachment was scrubbed... Name: Flint Toolkit Reference.rtf Type: application/msword Size: 503688 bytes Desc: not available Url : http://www.opencores.org/forums.cgi/cores/attachments/20040207/9908bd08/FlintToolkitReference.wiz