5 ms·

The Amaranth hardware description language

83 points by pabs3 1y ago

MutedEstate45 1y ago
[flagged]
- mabster 1y ago
  It's been a while since I've done this stuff, but VHDL seemed like this to me: that generally if it compiles, it synthesises. I really battled with Verilog!
- wd776g5 1y ago
  But what is it for? It would be impressive if they used this to develop their gravitons but I find that hard to believe. What's the use case?
  - duskwuff 1y ago
    https://glasgow-embedded.org/ https://glasgow-embedded.org/ Which uses a single Python codebase to implement both the gateware (as Amaranth) and the software which interacts with it.
  - mkj 1y ago
    https://greatscottgadgets.com/cynthion/ https://greatscottgadgets.com/cynthion/ is another in-production user of it, a USB protocol analyzer and tool.
- supriyo-biswas 1y ago
  It appears that your entire profile is simply LLM generated comments, including this comment right here. Please do not do this on HN.
  - scrubs 1y ago
    Appears? How so?
    - astrange 1y ago
      > If you've ever been burned by Verilog's "works in sim, breaks in synthesis" gotchas This is LLM phrasing. It's trying to be witty and relatable about an experience basically no person has ever had - or at least, those people being hardware engineers, they usually don't try to be witty and relatable in forum comments. I don't know though, the comment as a whole doesn't feel AI-generated, but maybe AI-assisted.
      - HelloNurse 1y ago
        Apart from the telltale direct paraphrasing of the Amaranth home page, the discourse about "works in sim, breaks in synthesis" can be regurgitated from any mildly disappointed essay about Verilog and feels plausibly AI-generated to me.
    - xarope 1y ago
      "The result: a design that passes simulation is far more likely to synthesize identically, averting costly back-end surprises" This is the sort of phrasing that either a committee of marketing people wrote up, or an LLM.
  - throwaway48476 1y ago
    The parent comment absolutely has the LLM stench.
- dark-star 1y ago
  Amaranth is basically SystemC but in Python (and it's much easier to use and works better)
bsder 1y ago
The biggest issue is simply: an HDL is not a programming language. As such, making an HDL look like a programming language doesn't increase my expressiveness or productivity all that much. (Side note: this assumes VHDL or SystemVerilog--old-school Verilog is terribly anemic in ways that SystemVerilog mostly fixed) Now, my testbench, on the other hand, is dramatically helped by being in a real programming language with the appropriate constructs. However, we already have cocotb (in Python!) which fits the bill there and interfaces directly with my simulators without a translation step.
- deleted 1y ago
  [deleted]
- danhor 1y ago
  That is the point of Amaranth (and migen). It's not HLS, it doesn't try to generate logic from normal python code. It's an HDL implemented in python, not trying to look like python code. In my opinion, it's even more of an HDL than SV or VHDL: It has native concepts of Clock Domains, reset handling and e.g. blockram, it describes the hardware. There is no missmatch with two different, weird assignment types. It's occupied with with accurately covering available/commonly used hardware constructs with commonly used features, not introducing useless abstractions that don't help in practice (trivial example: Your clock signals are not just another signal that mess up timing everywhere if you try to use them that way). But on the other hand, there is no weird, half-useless metaprogramming/simulation layer with almost the same syntax but tricky rules that differ. That part is proper python. Thus it's easy to write code that is flexible over different interface types (i.e. one async fifo that can be used for almost all data or an width adapter that mostly works automatically), generate memory-mapped registers that are correctly hooked up, generate wide e.g. CRC operations that are optimized in python code before making HDL out of it as Vivado barfs on them (which I've also seen done with python code that generates systemverilog using string concatenation). I think my point is just that SystemVerilog isn't a good HDL. It makes it hard to (correctly) describe hardware and makes reuse often harder than it needs to be. Regarding the intermediate translation step: Amaranth has it's own native simulator and for system-level simulation interfaces directly with yosys for cxxrtl or synthesis for parts directly supported by yosys, bypassing the need for a yosys-> verilog conversion. It's "only" needed for most commercial tools, that can only process SV and VHDL.

83 points by pabs3 1y ago

MutedEstate45 1y ago

[flagged]

mabster 1y ago
It's been a while since I've done this stuff, but VHDL seemed like this to me: that generally if it compiles, it synthesises. I really battled with Verilog!
wd776g5 1y ago
But what is it for? It would be impressive if they used this to develop their gravitons but I find that hard to believe. What's the use case?
- duskwuff 1y ago
  https://glasgow-embedded.org/ https://glasgow-embedded.org/ Which uses a single Python codebase to implement both the gateware (as Amaranth) and the software which interacts with it.
- mkj 1y ago
  https://greatscottgadgets.com/cynthion/ https://greatscottgadgets.com/cynthion/ is another in-production user of it, a USB protocol analyzer and tool.
supriyo-biswas 1y ago
It appears that your entire profile is simply LLM generated comments, including this comment right here. Please do not do this on HN.
- scrubs 1y ago
  Appears? How so?
  - astrange 1y ago
    > If you've ever been burned by Verilog's "works in sim, breaks in synthesis" gotchas This is LLM phrasing. It's trying to be witty and relatable about an experience basically no person has ever had - or at least, those people being hardware engineers, they usually don't try to be witty and relatable in forum comments. I don't know though, the comment as a whole doesn't feel AI-generated, but maybe AI-assisted.
    - HelloNurse 1y ago
      Apart from the telltale direct paraphrasing of the Amaranth home page, the discourse about "works in sim, breaks in synthesis" can be regurgitated from any mildly disappointed essay about Verilog and feels plausibly AI-generated to me.
  - xarope 1y ago
    "The result: a design that passes simulation is far more likely to synthesize identically, averting costly back-end surprises" This is the sort of phrasing that either a committee of marketing people wrote up, or an LLM.
- throwaway48476 1y ago
  The parent comment absolutely has the LLM stench.
dark-star 1y ago
Amaranth is basically SystemC but in Python (and it's much easier to use and works better)

bsder 1y ago

The biggest issue is simply: an HDL is not a programming language. As such, making an HDL look like a programming language doesn't increase my expressiveness or productivity all that much. (Side note: this assumes VHDL or SystemVerilog--old-school Verilog is terribly anemic in ways that SystemVerilog mostly fixed) Now, my testbench, on the other hand, is dramatically helped by being in a real programming language with the appropriate constructs. However, we already have cocotb (in Python!) which fits the bill there and interfaces directly with my simulators without a translation step.

deleted 1y ago
[deleted]
danhor 1y ago
That is the point of Amaranth (and migen). It's not HLS, it doesn't try to generate logic from normal python code. It's an HDL implemented in python, not trying to look like python code. In my opinion, it's even more of an HDL than SV or VHDL: It has native concepts of Clock Domains, reset handling and e.g. blockram, it describes the hardware. There is no missmatch with two different, weird assignment types. It's occupied with with accurately covering available/commonly used hardware constructs with commonly used features, not introducing useless abstractions that don't help in practice (trivial example: Your clock signals are not just another signal that mess up timing everywhere if you try to use them that way). But on the other hand, there is no weird, half-useless metaprogramming/simulation layer with almost the same syntax but tricky rules that differ. That part is proper python. Thus it's easy to write code that is flexible over different interface types (i.e. one async fifo that can be used for almost all data or an width adapter that mostly works automatically), generate memory-mapped registers that are correctly hooked up, generate wide e.g. CRC operations that are optimized in python code before making HDL out of it as Vivado barfs on them (which I've also seen done with python code that generates systemverilog using string concatenation). I think my point is just that SystemVerilog isn't a good HDL. It makes it hard to (correctly) describe hardware and makes reuse often harder than it needs to be. Regarding the intermediate translation step: Amaranth has it's own native simulator and for system-level simulation interfaces directly with yosys for cxxrtl or synthesis for parts directly supported by yosys, bypassing the need for a yosys-> verilog conversion. It's "only" needed for most commercial tools, that can only process SV and VHDL.