[OpenRISC] Using fusesoc in an asic tool flow

[Ouabache Designworks]

I have thought about how you could use fusesoc when doing an asic design.
Fusesoc provides
the ideal way for a project manager to create a custom orpsoc-cores that
could be
sent to the entire team to download all repositories and keep the entire
team in sync.

However there are some current shortcomings in fusesoc that would cause
problems. You should
consider these issues if you want to see fusesoc used anywhere other than
for small fpga designs.


1) Local tool install option: Installing fusesoc in the system is quick
and easy but a lot of IC
designers do not have superuser on the machines where their chips are built
and verified. In some cases they do not even have access. Some other group
will download, rebuild and simulate the entire chip on a nightly basis.

2) Sandboxing: You will have more than one design active at any time in
numerous different design environments. You MUST ensure that no IP can leak
out of one design environent and into another. Using $HOME/.cache
$HOME/.config and $HOME/.local/share is fine for most applications but
never use them for IC design.

3) File system: There is far to much IP in the world to try and fit it into
a flat file system. Try doing fusesoc list-coresand seeing 3,497 entries.
Good luck with that. You will need to switch over to a hierarchial file
system for tracking IP and the sooner the better.

4) Tools and Software: Besides IP we also need to fetch tools and software
drivers. These will also need to be stored along side the IP in a
hierarchial system. Fusesoc should be quite capable of handling these as
well.



I would like to start a discussion about these issues and any others that
would help.


John Eaton

[Olof Kindgren]

Post by Ouabache Designworks
I have thought about how you could use fusesoc when doing an asic design.
Fusesoc provides
the ideal way for a project manager to create a custom orpsoc-cores that
could be
sent to the entire team to download all repositories and keep the entire
team in sync.
However there are some current shortcomings in fusesoc that would cause
problems. You should
consider these issues if you want to see fusesoc used anywhere other than
for small fpga designs.

Hi John,

Thanks for the comments, and yes, we have talked about using it for
ASIC flows as well. Aside from the things you list below, FuseSoC only
needs support to launch the ASIC tools. The two things holding this
back now is lack of time and lack of tools. Lots of other
(FuseSoC/OpenRISC-related) work to do, and I'm currently not in an
environment where I can get easy access to ASIC tools. More in-depth
answers to your suggestions below.

Post by Ouabache Designworks
1) Local tool install option: Installing fusesoc in the system is quick and
easy but a lot of IC
designers do not have superuser on the machines where their chips are built
and verified. In some cases they do not even have access. Some other group
will download, rebuild and simulate the entire chip on a nightly basis.

FuseSoC can be installed in the users home directory without problems.
I usually do "./configure --prefix=$HOME/local && make && make
install" when I want to do that. Python >=2.7 will be required as
well. I'm explicitly mentioning this as I have come across company
with build servers that still runs ancient python versions (2.5, 2.6)
in 2014

Post by Ouabache Designworks
2) Sandboxing: You will have more than one design active at any time in
numerous different design environments. You MUST ensure that no IP can leak
out of one design environent and into another. Using $HOME/.cache
$HOME/.config and $HOME/.local/share is fine for most applications but never
use them for IC design.

These are all overridable in different ways, except for the cache dir,
which should be fixed.
The file (fusesoc.conf) in $HOME/.config/fusesoc is only used if there
is no fusesoc.conf in the current working directory. fusesoc.conf will
in turn point out the paths to the core libraries, so even if
orpsoc-cores by default installed in $HOME/.local/share, it won't be
used if it doesn't have an entry in fusesoc.conf.

So in essence, a designer running several projects will use different
build directories (or workspaces as I tend to call them), each with a
different fusesoc.conf pointing out different core libraries to use.

Post by Ouabache Designworks
3) File system: There is far to much IP in the world to try and fit it into
a flat file system. Try doing fusesoc list-coresand seeing 3,497 entries.
Good luck with that. You will need to switch over to a hierarchial file
system for tracking IP and the sooner the better.

I have loosened the restrictions on the hierarcy inside a fusesoc core
library, so that users are free to implement whatever hierarchcal
scheme that fits them the best. Currently the only division is between
systems and cores in orpsoc-cores, but we are free to rearrange those
when we feel the need to do so.

This doesn't address your other concern about a huge flat list, but
for that my idea for a solution instead is free text search for names
and descriptions together with tags in the .core files, so that you
can search for "wishbone", "ethernet" "sdram" or whatever you are
looking for.

Post by Ouabache Designworks
4) Tools and Software: Besides IP we also need to fetch tools and software
drivers. These will also need to be stored along side the IP in a
hierarchial system. Fusesoc should be quite capable of handling these as
well.

Yes. This will probably require a bit more ad-hoc solutions, since
these things are rarely standardized, but as a first effort we should
at least make sure to ship drivers with the cores that we have
drivefrs for, as well as device trees for complete systems.

Post by Ouabache Designworks
I would like to start a discussion about these issues and any others that
would help.
John Eaton

I'm happy to discuss this in more detail. Thanks again for the
suggestions and comments

Regards,
Olof