4 ms·

Silice: A language for hardcoding Algorithms into FPGA hardware

98 points by mleonhard 5y ago

DoingIsLearning 5y ago
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 5y ago
  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 5y ago
    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 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.
    - kingosticks 5y ago
      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 5y ago
        >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?
        kingosticks 5y ago
        > 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.
        zsmi 5y ago
        > 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-vhdl.html https://vhdlguru.blogspot.com/2010/04/recursive-functions-in...
        anon_tor_12345 5y ago
bobnamob 5y ago
See also: https://clash-lang.org/ https://clash-lang.org/
- rectang 5y ago
  Very different licensing! Clash is BSD-2, while Silice is AGPL.
  - sylefeb 5y ago
    Hi, Silice author here -- about the license see also discussion here https://news.ycombinator.com/item?id=27575174 https://news.ycombinator.com/item?id=27575174 and github issue https://github.com/sylefeb/Silice/issues/106 https://github.com/sylefeb/Silice/issues/106
    - rectang 5y ago
      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.
sehugg 5y ago
You can play around with Silice in 8bitworkshop: https://8bitworkshop.com/v3.7.2/?platform=verilog&file=copperbars.ice https://8bitworkshop.com/v3.7.2/?platform=verilog&file=coppe...
vmchale 5y ago
Is the name a pun on 'cilice?' :p
gfiorav 5y ago
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.
- vinsci 5y ago
  Reference?

98 points by mleonhard 5y ago

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 5y ago
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 5y ago
  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 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.
  - kingosticks 5y ago
    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 5y ago
      >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?
      - kingosticks 5y ago
        > 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.
      - zsmi 5y ago
        > 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-vhdl.html https://vhdlguru.blogspot.com/2010/04/recursive-functions-in...
        anon_tor_12345 5y ago

bobnamob 5y ago

See also: https://clash-lang.org/ https://clash-lang.org/

rectang 5y ago
Very different licensing! Clash is BSD-2, while Silice is AGPL.
- sylefeb 5y ago
  Hi, Silice author here -- about the license see also discussion here https://news.ycombinator.com/item?id=27575174 https://news.ycombinator.com/item?id=27575174 and github issue https://github.com/sylefeb/Silice/issues/106 https://github.com/sylefeb/Silice/issues/106
  - rectang 5y ago
    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.

sehugg 5y ago

You can play around with Silice in 8bitworkshop: https://8bitworkshop.com/v3.7.2/?platform=verilog&file=copperbars.ice https://8bitworkshop.com/v3.7.2/?platform=verilog&file=coppe...

vmchale 5y ago

Is the name a pun on 'cilice?' :p

gfiorav 5y ago

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.

vinsci 5y ago
Reference?