On HLS in general, I was a skeptic too until I read this paper. [1] I am still more a verilog and verilog-mode [2] kinda guy but I can definitely see the benefits. For me, it's hard to look at figures 5,6,7 & 8 and not be impressed. I've actually started using Chisel [3] because of that paper.
That said, it's not all unicorns and rainbows. Unfortunately dealing with back end CAD is kinda an issue because they use verilog as an intermediate language and one basically ends up with the C++ name mangling issue. Chisel is not so bad about it, but it's not great either.
[1] https://people.eecs.berkeley.edu/~magyar/documents/firrtl-ic... [2] https://veripool.org/verilog-mode/help/ [3] https://github.com/schoeberl/chisel-book
I also try to build an environment around Silice so that one can easily get started and enjoy testing things, experimenting with relatively advanced projects that are also (for several) explained in details. (The build system relies upon many great projects: yosys, nextpnr, edalize, openfpgaloader, verilator, icarus, etc.)
But this is a very subjective thing ; I absolutely understand that others may not like it or feel it is not necessary, being already expert at other tools. Also, I would never argue that one should use Silice instead of X. Take a look at the repo, checkout a few projects (I recommend 'vga_demo', 'terrain', 'ice-v', 'pipeline_sort' and, for pushing beyond reasonable, 'doomchip'). If you see something you might like, perhaps try making a simple design, see if that is a good tool for you.
how do you generate recursive designs in vhdl? e.g. reduction trees?
>preprocessing/templating can't fix
so your tool (vhdl/verilog) requires using another tool (perl/tcl/python) to be productive and you think that's not a failing of the (first) tool?
>> preprocessing/templating
> so your tool (vhdl/verilog) requires using another tool (perl/tcl/python) to be productive and you think that's not a failing of the (first) tool?
In my opinion yes it does, and yes that is a failing. But what I was saying is, that alone is not worth the large cost of moving to something new. I was asking if Slice could offer anything more to justify that large cost.
I understand mapping a recursive algorithm to hardware, and VHDL can definitely do that [1]. (even if it is generally a bad idea) But what is a recursive hardware design? It sounds really interesting.
[1] https://vhdlguru.blogspot.com/2010/04/recursive-functions-in...
Just wondering if you are also planning to support FIRRTL in addition to Verilog? It is an intermediate representation for later versions of Chisel and previous discussions on HN [1].
In your Silice descriptions, you did mention about utilizing Lua, can you explain its relationship with Silice?
Lua is used as a pre-processor language. This is quite powerful, for instance to automatically generate code, read data into BRAMs (for init), for example RISCV compiled code or DooM wad data (!!). This is used in most projects, see for instance 'pipeline_sort', 'ice-v' or 'doomchip' (a bit extreme there). All lines starting with $$ are pre-processor code, and inserts such as $N$ concatenate the Lua generated N in the Silice code. You can for instance write a for loop with Lua that will duplicate Silice code to e.g. generate a sorting network.
Yes, exactly! Silice is only a thin abstraction layer over Verilog with a few syntax conveniences (fsms, pipelines, BRAMs, groups, interfaces, please see README ).
You can design in Silice in a way similar to Verilog ( with more comfort -- well I hope :) ) and choose to use some of its more advanced helpers such as building FSMs with explicit control flow constructs (while/break/subroutines).
Silice only does a few optimizations/transformations and they are very predictable (most rules are already documented), so you can still reason about your design directly in terms of flip-flops, states, multiplexers, etc. In this way it is much simpler compared to what I understand an HLS to be (these are capable of remarkable optimizations). I am trying to strike a balance between comfort of design and remaining very close to the hardware.
Silice generates Verilog, and I have to say it is not pretty -- I am not expecting anyone to directly edit the output. However Silice easily interops with Verilog: one can directly reuse existing modules and access vendor specific primitives -- also Silice generated Verilog could be easily integrated in Verilog projects, but I yet have to make this easier.
As I said in another thread (https://news.ycombinator.com/item?id=27575174) the spirit in which I am developing Silice is "I hope you'll find it useful" ; there are many options out there and I think it is great to have various tools for various problems and various styles.