Silice: A language for hardcoding Algorithms into FPGA hardware | Hacker News Reader

Silice: A language for hardcoding Algorithms into FPGA hardware

github.com

98 pointsmleonhard20 comments

Very neat!

The first thing I thought of was this is a yosys compatible open-source HLS. Then the readme clarifies it is not an HLS.

> Silice does not aim to be a high level synthesis language: it remains close to the hardware and lets you fully exploit FPGA architectures, with a fine grain control on how your design maps to the hardware: You remain in control of what happens at each and every clock cycle, with predictable rules for flow control, how and when execution states appear, how flip-flops map to variables, and what gets registered or not. In fact, if you chose so you can design in a way that is very similar to Verilog, while still benefiting from the "quality of life" improvements of Silice syntax.

Would be interesting if the author could explain the motivation and rationale of how it is not an HLS? Is it in the sense that the auto-generated logic is more edit-friendly for future optimization? Just because the output is not an auto-generated mess doesn't make it less of an HLS I would have thought.

I'm not aware of any definitive definition of HLS, but generally the term is used to describe something like Xilinx Vitis HLS, which is a set of tools to transform C or Cpp (-ish) programs into something that can be "run" on an fpga.

Silice ( to the extent I understand it ) and projects like Chisel and migen are tools to compensate for some of the shortcomings of verilog and vhdl mostly in areas concerning software engineering practices: modularity, code-reuse, strong typing, testability.

Hi, Silice author here -

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.

I've looked before at these high-level things generating Verilog and I don't see what they bring that's so much better than what I can do with well-established VHDL. VHDL is rather verbose but that's nothing a bit of preprocessing/templating can't fix. Does slice offer something more here? I've looked at the readme but nothng jumps out. And I'm not even talking about vhdl-2019, which looks awesome (I can't wait to use in 2039 when it becomes supported in my tools)!

>what they bring that's so much better

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?

> how do you generate recursive designs in vhdl? e.g. reduction trees?

>> 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.

> how do you generate recursive designs in vhdl?

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...

actually this is exactly what i was talking about i.e. (as far as i understand it) this is essentially a reduction tree. i called it a recursive hardware design because it synthesizes to indeed i was unaware that you recursively call functions in vhdl. thanks!

I looked over the Silice readme yesterday, and as a seasoned HDL engineer, I didn't see anything for me but I could see it's merit as a learning tool.

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

Hi (author) - for me Silice brings comfort while designing, simplicity of reuse (groups+interfaces making it easy to assemble components), a syntax that is more to my taste (obviously ;) ) and ease of prototyping with the 'control-flow' FSM style and pipeline constructs. Plus the Lua pre-processor that I enjoy using. All this while staying close to Verilog and being able to inter-operate easily.

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.

Really nice tool to code FPGA, and hopefully by introducing more powerful tools will encourage and enable more people to utilize FPGA in their products and solutions design.

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?

[1]https://news.ycombinator.com/item?id=21340009

Hi (author) - Thanks! I would like to support FIRRTL very much, I have looked into it a bit in the past and that all looks feasible. It is a rather big feature though, so it will take some time.

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.