On Fri, Nov 7, 2014 at 8:10 PM, Ouabache Designworks <[email protected]> wrote: > 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. > 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 > 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. > 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. > 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. > > > 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 _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
