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.
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)!
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.
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.
> 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.
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.
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!
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?
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.
Something missing from those discussions is perception of legal risk around the licenses.
If you fail to comply with any FOSS license, the enforcement mechanism is the same: since you didn't uphold the terms of the license, you have NO license and thus can be penalized for copyright infringement.
However, FOSS license violations rarely result in the most draconian copyright infringement penalties. Generally, what FOSS authors want is adherence to the license going forward, rather than to sue you for money and maximize damages.
In the case of permissive licenses, coming into compliance just means adding credit somewhere. Nobody finds that painful. So infringement suits basically don't happen — infringeers just add credits in new releases, the past is forgotten, end of story.
In the case of copyleft, coming into compliance typically requires more work: most infringers remove the copyleft dependency and either replace it with something else or write new code. Theoretically the infringer could also release previously proprietary source code under the copyleft license but AFAIK in practice nobody chooses this option. Because copyleft compliance is more work, copyleft enforcement is a bigger deal, and copyleft authors sometimes go to court.
The consequence is that copyleft licenses are perceived as entailing greater legal risk, especially GPL and AGPL.
This copyleft-vs.-permissive bifurcation isn't perfect because e.g. the Eclipse License is a copyleft license but is perceived as low risk. Really the perception of risk around a licnse has to do with the community around the license and its traditions. GPL and AGPL, among all FOSS licenses, are perhaps the most likely to result in enforcement actions.
So... by choosing AGPL, you associate your project with a comparatively litigious FOSS community, even if the enforcement mechanism being leveraged isn't any different from what's available to permissive license communities. And so, users who wish to minimize what they perceive as increased legal risk may stay away from your project.
Kind of random, but this remindied me of how in the Telco industry (think Cisco), researchers order batches of their improved algos to be printed on boards to comply with the european requirments to be "patentable".
Then they get kickbacks every time the algo is used in router software. Pretty incredible.
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.