Use Edalize to interface EDA tools

[olofk]

Edalize is an abstraction library for interfacing EDA tools. Edalize uses language-agnostic yaml for configuration and support 20+ EDA tools.

To make use of Edalize, Silice would only need to generate an EDAM file to go with the generated HDL (+constraints and what else uou need) and pass it to Edalize

[sylefeb]

Hi Olofk, thanks! Definitely on my todo (I actually started looking a bit into Edalize already, looks great). I am hoping this will greatly simplify the frameworks/build scripts.

[sylefeb]

Hi - so I started to look into this and was able to run a few Edalize python scripts successfully. This is looking very promising.

Ideally, I would like to come up with a system where the user can launch a build script with a command looking like: silice-build.sh <file.ice> <framework>

The framework will typically select a target FPGA board as well as the specific EDA toolchain. The build script would then generate a python script setting up the EDAM structure and making the appropriate calls to edalize, and then run this python script. Would that seem the right approach?

[sylefeb]

Well, I might as well directly make the build script in python! Will give this approach a try.

[rob-ng15]

Looks like a good plan.

On Wed, 23 Sep 2020, 17:51 sylefeb, notifications@github.com wrote:

Well, I might as well directly make the build script in python! Will give this approach a try.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sylefeb/Silice/issues/59#issuecomment-697683259, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN4SYT3CFTYWQGZJMY7UUNTSHIRP3ANCNFSM4QRUUTPQ .

[olofk]

I think that would make sense as well.

[sylefeb]

Thanks! I started work on a new build system, basically a python script and a set of folders per boards with specifications in json files. For each board there will be different possible build systems (edalize and/or script). This is happening in draft branch.

Todo

• [done] script prototype
• [done] folder hierarchy
• [todo] edalize for all boards
• [todo] scripts for supported boards (in progress: ulx3s, orangecrab, icestick, icebreaker)
• [todo] revise demos according to (few) changes to pins
• [todo / brainstorm] expand the script to easily have it create new projects, filling the 'main' from the pin definitions => It would be great to be able to choose groups of pins instead of fixed sets as currently ; in particular for boards supporting pmods. This mechanism would complete (or replace?) board variants. However this information has to be stored / retrieved from the project during build to produce the proper Verilog framework header. Could be by generating a script with command line ; or perhaps (better) through use of defines? (Verilog defines applied from the project main file?)
• [todo / brainstorm] similarly facilitate creation of projects with multi-board support

[sylefeb]

Investigating how this could interact with (or be replaced by) fusesoc

[sylefeb]

I now see a much nicer plan, where the current silice-make tool (in draft) would be entirely replaced by fusesoc. A new tool (reusing the folder / json structure) would be used to create a new core, let us call it silice-new-core.

silice-new-core would create a new fusesoc core, and take as parameters a list of targets (e.g. ulx3s,de10nano) as well as a list of io pins layouts (e.g. sdram,hdmi). The pin layouts have to exist in the Silice frameworks definitions (the json files) for all selected target boards.

This would then produce a fusesoc core structure with all targets properly setup. Then fusesoc is used for building, and each of these projets could be then easily integrated as fusesoc libraries.

So for instance, in a current directory, calling silice-new-core my_cool_project --targets ulx3s,de10nano --io sdram,hdmi would create a fusesoc ready core 'my_cool_project'.

I'll be running a few tests in this direction!

[olofk]

This all sounds super interesting. I don't have much time to help out but I'm cheering from the sidelines. I would like to bring up one thing related to this that I have thought about for many years. It would be fantastic if all new HDLs (e.g. Silice, (n)migen, SpinalHDL etc) could collaborate on some kind of pinout/board definition format. Over the years I have seen everyone just reimplementing this time and time again and I believe their could already be hundreds of boards described in different formats. Perhaps we could host some discussion around this from FOSSi Foundation if there's interest in this. Same thing really goes with tools for loading FPGA binaries (OpenFPGALoader, openocd, impact, quartus_pgm, iceprog...etc) where I would love to see an abstraction library that everyone could use. That one could potentially go into Edalize, or be a stand-alone thing that Edalize uses.

Slightly off-topic. Sorry for that. Will stop ranting now :)

[sylefeb]

Hi Olofk, thanks for the encouragements! The build system is shaping up nicely. With the help of @trabucayre we have a first Edalize integration. Very impressed with Edalize and Fusesoc ; once the build system is stabilized the next step will be to make it easy to turn a Silice project into a fusesoc library.

I fully agree on the need for a shared pinout/board definition. I don't feel I have enough experience to propose one but I'd be happy to contribute and make sure Silice would integrate such a system. It seems there are many shared things between vendors for pin configurations, but of course there will likely be specific options to expose. Btw, Icestudio has an interesting tool to generate json files from existing pcf / lpf 's pin definition.

A common tool for loading binaries would be fantastic as well. This is an area I have little knowledge about, but I think @trabucayre is the author of OpenFPGALoader?

[sylefeb]

Tons of progress on this. For a usage example see https://github.com/sylefeb/Silice/tree/draft/projects/blinky A simple makefile, type in make de10nano or make ulx3s or make orangecrab and boom, blinky runs on your board :-)

Makes full use of Edalize (default) and then possibly a user script. Edalize works like a charm, and is a huge progress when dealing with e.g. Quartus.

I am in the process of standardizing as much as possible the sets of pins (leds, vga, sdram, oled, etc.) so that designs can share the same 'main' signature across many boards. Of course some boards may have unique options. It will take time to update all designs, but that's well worth it I think.

Some missing features / points to address:

• Let a user extend an existing board (or specify a new one) without having to modify the Silice repo (e.g. from json files in her/his project directory). A good inspiration may be mods for games, where a user can reproduce the directory structure of the game in a custom folder, and whatever file is there overrides the game file. This way a user could easily override board.json, or pinout files, or anything else, starting from the Silice one a hacking changes in there.
• How to deal with setup? Python needs some packages (edalize, termcolor). Also the PATH better be set to access all tools (silice, yosys, nextpnr, quartus_*, everything) ; would be helpful to check that tools are there, and warn users if not.
• work on Makefiles ; for instance how to pass compile-time defines to Silice/Verilog? how to better deal with having multiple designs in a same folder? (e.g. project vga_demo has multiple makefiles, not great).
• provide a tool (silice-new-project.py) to create the basic Makefile and 'project.ice' with main algorithm, given the user chosen target boards and pin sets (and in case of name/width mismatch auto-generate Silice pre-processor directives)

(probably forgetting a few more!)

[sylefeb]

• Let a user extend an existing board

Well, while a fancy system is possible, for now I simply added an option to silice-make.py (--root or -r for short) to specify a different 'frameworks' directory, that will be used in place of the standard one.

• How deal with setup

The silice compilation script will install python dependencies ; also I'll update the documentation accordingly.

[sylefeb]

Encountered one (minor) difficulty with Edalize: some ulx3s designs with tight timing benefit from using the following yosys command line: scratchpad -copy abc9.script.flow3 abc9.script; synth_ecp5 -abc9 -json build.json. I could not find a way to add the scratchpad part before the synth_ecp5 command. Did I miss something? (for these designs the Makefile can simply resort on the shell script, -t shell option to silice-make.py)

[olofk]

There is supposed to be a way to do this, but I checked the code and noticed it wasn't implemented in the yosys backend. I pushed a branch with a fixed version.

With this, you can create a TCL file, add it to the EDAM with file_type : tclSource and it will be source by yosys before synthesis. This is how most of the other (vivado, ise, quartus, modelsim...etc) backends work. I think that should work for your use case, but let me know if I have missed something

[olofk]

FYI, I pushed it to the main branch now, so it should be available if you just pull latest edalize

[sylefeb]

Great thanks! I'll look into it asap.