[HN Gopher] Silice: A language for hardcoding Algorithms into FP...
___________________________________________________________________
Silice: A language for hardcoding Algorithms into FPGA hardware
Author : mleonhard
Score : 87 points
Date : 2021-06-22 08:28 UTC (14 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| gfiorav wrote:
| 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.
| sehugg wrote:
| You can play around with Silice in 8bitworkshop:
| https://8bitworkshop.com/v3.7.2/?platform=verilog&file=coppe...
| DoingIsLearning wrote:
| 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.
| a2800276 wrote:
| 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.
| sylefeb wrote:
| 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.
| teleforce wrote:
| 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
| sylefeb wrote:
| 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.
| kingosticks wrote:
| 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)!
| anon_tor_12345 wrote:
| >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?
| zsmi wrote:
| > 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...
| anon_tor_12345 wrote:
| 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!
| kingosticks wrote:
| > 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.
| sylefeb wrote:
| 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.
| zsmi wrote:
| 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/fi
| rrtl-ic... [2] https://veripool.org/verilog-mode/help/
| [3] https://github.com/schoeberl/chisel-book
| bobnamob wrote:
| See also: https://clash-lang.org/
| rectang wrote:
| Very different licensing! Clash is BSD-2, while Silice is AGPL.
| sylefeb wrote:
| Hi, Silice author here -- about the license see also
| discussion here https://news.ycombinator.com/item?id=27575174
| and github issue https://github.com/sylefeb/Silice/issues/106
| vmchale wrote:
| Is the name a pun on 'cilice?' :p
___________________________________________________________________
(page generated 2021-06-22 23:02 UTC)