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 existing stuff.
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
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:
On Thu, Nov 23, 2017 at 12:57 PM, Dr Jonathan Kimmitt
<jrrk2(a)cam.ac.uk <mailto:email@example.com>> wrote:
Our simulator of choice is verilator. We only use XSim when
VHDL components are instantiated (such as for DDR controller
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
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
ISE, 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 :)
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 really 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 more 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 to 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?