FuseSoC doesn't generate any code. Perhaps the most asked feature is
top-level generation to hook up components. In my opinion those things are
best handled by other mechanisms.
As a fictive example:
1. Each core contain their own IP-XACT files which are specified in the
core description file
2. FuseSoC finds all dependencies and notes that some of them have files
that need to be generated on the fly (using generators)
3.The top-level core asks FuseSoC to call an external tool (using
generators) to build the structural parts, memory maps, device trees etc
from the supplied IP-XACT files or other configuration files
On Thu, Nov 23, 2017 at 1:08 PM, Dr Jonathan Kimmitt <jrrk2(a)cam.ac.uk>
Yes I think I heard a presentation about FuseSoC at the last-but-one
ORConf. The really interesting stuff for me is not how the package manager
resolves the dependency versions, though this is important and a
well-investigated problem, but how to make the HDL code compositional, i.e.
valid when you make an arbitrary composition of different ingredients. Can
your tool generate AXI bus converters and regenerate the memory map when
you add or remove components? Can it generate a device tree for Linux? Can
it select and run unit tests? Can it ensure a computer system is bootable?
As you know the System-Verilog language is not friendly to arbitrary
composition because of the need to pass bundles of signals all over the
place. Perhaps with a suitable naming convention and much use of .* this
could be worked around.
On 23/11/17 11:58, Olof Kindgren wrote:
Glad to hear that you find it interesting. I could probably spend the rest
of the week talking about FuseSoC (just ask anyone who has been to ORConf
:)), but I'll try to answer your questions short and informative. Please
let me know where I can fill in details.
Regarding modularity, it is supposed to be quite easy to add new tool
backends and providers (methods for getting cores from remote sources). I'm
currently working on adding support for a new core description format (a
side effect of that is that it will be easier to plug in other core
description formats as well) and generators, which is a facility to run
external preprocessing functions, such as Chisel/Migen/MyHDL/IP-XACT->verilog
generation or similar.
One of the main goals of FuseSoC is battling the bad practices of
dependency management which are prevelent among RTL designers. The most
common ways are either to just dump code together will all dependencies in
a big repo, or use submodules, but those are both quite clunky mechanisms.
Especially when you're starting to have many cores that depend on some
common functionality. FuseSoC resolves dependencies just as your normal
software package manager would do, with version ranges (e.g. at least
verison 2.5, exactly version 4.1 or anything but version 2.4)
For information, I packaged version 1 of the complete Pulpino ecosystem
already almost three years ago, and I have version 2.1 mostly packaged last
year, but never found time to clean up and upload. The ambition in the
LowRISC context is of course to package all of LowRISC to be used with
FuseSoC and thereby reusing the packaging work already done on Pulpino. My
hope is that once package management becomes more common in the open source
silicon world, people will stop writing so much new code and just reuse
Much more to say, but I'll leave it here :)
On Thu, Nov 23, 2017 at 12:22 PM, Ahmed Khalaf <me(a)ahmedkhalaf.com> wrote:
> Dear Olof,
> I checked the FuseSOC intro, it seems really interesting. Especially its
> extendable and can help building on different tool-chains and FPGA flows.
> The task of porting a SoC design to a different device is not an easy
> task, so in what aspects can FuseSOC help?
> Also, how modular is "modular"? this is in particular is interesting
> because of the increasing importance of updates and dependency tracking in
> a growing community.
> We had an interesting discussion earlier this month that could be
> relevant to this:
> Thank you
> Ahmed Khalaf
> On Thu, Nov 23, 2017 at 12:57 PM, Dr Jonathan Kimmitt <jrrk2(a)cam.ac.uk>
>> Dear Olof,
>> Our simulator of choice is verilator. We only use XSim when VHDL
>> components are instantiated (such as for DDR controller simulation).
>> All our memories take advantage of the Xilinx feature of being
>> preloadable and writable. We would have to change this when we reach ASIC
>> ready stability. Verilator does not support true dual-port RAM easily
>> because of the way it schedules changes. So the situation when
>> ADD_MINION_SD is enabled is not simulatable in Verilator. We will be
>> looking for a different solution in our next release. The purpose in this
>> case is to provide two way communication through dual-port RAM between
>> Rocket and Minion processors.
>> Ok, so you are looking at creating a tool-agnostic RAM with initial
>>> contents, with byte enable, configurable width and depth which can also be
>>> used by vendor tools for post-implementation initialization?
>>> The good part is that I spent quite some time doing something very
>>> similar a few years ago. The bad part is that I found it was in practice
>>> impossible to do this in a tool-agnostic way. Either, the byte enable
>>> signals were ignored, or it didn't map efficiently to RAM resources in
>>> Quartus or Vivado. My conclusion was that it is actually better to do this
>>> as a tech-agnostic frontend with selectable backends using available FPGA
>>> primitives and a fallback to pure HDL for simulation. (In a wider scope
>>> this is one situation where my dream of HDL standard libraries would be
>>> very beneficial :) http://olofkindgren.blogspot.c
>>> Right now I also see that there are explicit instantiations of Xilinx
>>> primitives when ADD_MINION_SD is defined which means that it's not
>>> tech-agnostic anyway.
>>> I would like to rewrite this part as a stand-alone component instead.
>>> Can't promise to find the time, but if I do, could you tell me a bit
>>> about the details of this implementation. I sense that there is some extra
>>> trickery going on here that I haven't fully grasped yet. Are you trying
>>> append two memories to a larger one when ADD_MINION_SD is defined? Do you
>>> need ISim support (the simulator in ISE) or is it really XSim (the
>>> simulator in Vviado) support you refer to with the comments? Do you want it
>>> as a RAM or would a ROM be good enough?