Dear OpenCores users,

about half a year ago, I started the development of the System-on-Chip (SOC) Maker and I tagged the first alpha release today: https://github.com/feddischson/soc_maker/tree/v0.1.0-alpha

I want to use this state to make this project more public and also to enthuse other hardware and IP-core designer for this work. Another reason for this post is to catch your opinions, questions, doubts, hints, feature-requests or other constructive thoughts or even your willingness for some contribution.


The basic idea was to create a software, which allows an assembly of IP-cores to a System-on-Chip, to parameterize the SoC and it's cores, and to extend the SoC.
The software itself is written in Ruby (https://www.ruby-lang.org) and the output is VHDL (Verilog output is planed). A YAML based syntax is used to describe the cores and their interfaces. These YAML files are managed in a library and they form the basis for creating SoCs.
At the moment, no GUI exist and everything is done on scripting-level, but a GUI also planed in the future (when the core and the API is more stable).

With the current state, I was able to create a "Hello-World" SoC, which is synthesizable and which I tested on my Spartan-3an starter kit. The SoC consists of only five components:
- or1k
- wb-bus
- uart16550
- ram
- adv_debug_sys
but can be extended easily.

Please have a look here: https://github.com/feddischson/soc_maker/blob/v0.1.0-alpha/examples/or1200_test/or1200_test.rb to get a feeling how the system is composed.



The project with more description can be found here:
- http://opencores.org/project,soc_maker
- https://github.com/feddischson/soc_maker


I'm looking forward to reading your response :)

Ok,

So you see that we have a problem and you determine that by adding some additional data files to each component that you can create a tool that will solve the problem.

Congratulations, You have commited the classic error that plagues most designers. You forgot the step where you research to see if anyone else has tried to solve that problem to see what they are doing.


Had you done so then you would have discoverd that there is actually a IEEE 1685 standard for your data files and if you used it then it would solve problems that you don't even realize that you have such as working in a huge chip database with 27 different components all named "ram".




John Eaton

This looks to be something in between migen and fusesoc.
But you don't have many cores and no installation guide.

Yes, at the moment there is no user guide and there are not enough cores, but the tool is still in a development phase. But the the first stable version will include a guide and also more cores.

Regarding my forgotten step: I've had a deeper look at minsoc and fusesoc and I've also had a short e-mail conversation with Wojciech Koszek. But I haven't had a look on Migen/Misoc and neither on the IEEE 1685 standard, thanks for this info.

Migen/Misoc looks pretty interesting, I will compare it with my goals.
Using a XML based configuration like in the IP-XACT standard as primary format was never a goal for me, but it might be supported in futre (I need to have a deeper look).