3 ms·

i'll hop on the dismissive bandwagon but not for the same reason as everyone else: not a single one of these HDLs ever (ever) amount to more than perl scripts.

i'll hop on the dismissive bandwagon but not for the same reason as everyone else: not a single one of these HDLs ever (ever) amount to more than perl scripts. why? how? how could that possibly be? this one is written in rust...? because not a single one of them, ever (ever) emits a netlist. they all emit verilog (or vhdl). hence: overengineered perl scripts (which actual employed RTL engineers use heavily...).

zem 3y ago
for a software analogy, a lot of programming languages compile to C; that doesn't make them perl scripts!
- fpgamlirfanboy 3y ago
  > that doesn't make them perl scripts! but it doesn't make them compilers either :shrug:
  - zem 3y ago
    of course it does! what else would you call something like chicken scheme [https://call-cc.org/ https://call-cc.org/], ats [https://ats-lang.sourceforge.net/ https://ats-lang.sourceforge.net/], or ghc [https://www.haskell.org/ghc/ https://www.haskell.org/ghc/]? they are not "scripts", they are full-blown compilers that happen to use C as their compilation target, and then leverage C compilers to generate code for a variety of architecures. it's a very sensible way to do things.
    - fpgamlirfanboy 3y ago
      ghc doesn't target C since 7.0. the other two i couldn't be bothered to care even less about. when you can point to a production grade """compiler""" that targets C (instead of emitting ir or asm directly) then i'll be happy to discuss the merits/virtues of source to source translation instead of compilation.
    - treflop 3y ago
      Umm, everyone calls them transpilers?
      - zem 3y ago
        transpilers are a subset of compilers though. they span the gamut from things like coffeescript that do fairly simple syntax transformations, to full fledged languages whose compilation target happens to be a high level language like C or javascript, but which otherwise implement most of what you would expect in a "compiler".
vrinsd 3y ago
That's because in order to turn your "design" into an ASIC or an FPGA, you need to go from whatever high-level language (insert new-HDL-du-jour) into a netlist compatible with your physical part. The only scalable/vendor/device-neutral way to do that is to back-end your "new" HDL with Verilog/SystemVerilog/VHDL, especially if you want to simulate your design. A long time ago people used to design chips and CPLDs/FPGAs in schematic-capture (which actually does have its place) which is basically one-step removed from being a netlist. Among other challenges if you wanted to change to a new device (say a bigger part) or a part from a different vendor, there wasn't really "neutral" way to do this until HDLs came around. To really change the status quo, you'd have to own EVERYTHING from the point of design entry to the physical device and all steps between. Even with both "major" FPGA vendors now with their own synthesis and sometimes simulation capability they can barely and/or reliably make that minimum bar work.
- fpgamlirfanboy 3y ago
  > The only scalable/vendor/device-neutral way to do that is to back-end your "new" HDL with Verilog/SystemVerilog/VHDL i mean like the guy below says, but in the opposite tone, that's like saying building a C emitter is the same as building a compiler. like i just don't agree (for C, because C isn't some abstract device model and isn't (easily) optimizable) because you are forever yoked to the assumptions/affordances of the target language (which is ultimately a language and not an IR/netlist/whatever). > The only scalable/vendor/device-neutral way blif is a thing, eblif, xml, etc. are there points of ingress in vivado or intel's thing for any of these? i don't remember but regardless i agree they're probably not well-supported. > To really change the status quo, you'd have to own EVERYTHING from the point of design entry to the physical device and all steps between. nah that's not true. LLVM/GCC/etc. FOSS compilers that grew up in the last ~20-30 years prove you don't need to own the last mile to change the status quo. if you build it, device manufacturers will come. the truth is simply that performant logic synthesis, tech mapping, place and route, etc are just all much harder to implement than XYZ compiler pass. but it could be done given maybe 20*5 highly competent engineer years? i dunno pulling it out of my ass but i know i could write some of that stuff and i'm not that smart. maybe i'm underestimating by 2x (40*5) but that's still less than most "exciting" startups that raise series A today. it just takes diligence and "hard" technical skills (familiarity with the relevant optimization literature). > Even with both "major" FPGA vendors now with their own synthesis and sometimes simulation capability they can barely and/or reliably make that minimum bar work. not sure what's the minimum bar you're referring to but sure i agree - i work at one of em (the one that didn't file divorce papers recently...) and i still readily admit the toolchain is trash. which is why i wish some consortium would get together and replace it (because i would love to be able to program/design on our own parts using a modern tool suite). and no circt/yosys/vtr whatever aren't there probably won't ever be (yosys in particular is terribly disappointing for all the waves/claims it makes).
fayalalebrun 3y ago
Chisel does emit FIRRTL. Which can be made into a bitstream directly by Yosys.

zem 3y ago

for a software analogy, a lot of programming languages compile to C; that doesn't make them perl scripts!

fpgamlirfanboy 3y ago
> that doesn't make them perl scripts! but it doesn't make them compilers either :shrug:
- zem 3y ago
  of course it does! what else would you call something like chicken scheme [https://call-cc.org/ https://call-cc.org/], ats [https://ats-lang.sourceforge.net/ https://ats-lang.sourceforge.net/], or ghc [https://www.haskell.org/ghc/ https://www.haskell.org/ghc/]? they are not "scripts", they are full-blown compilers that happen to use C as their compilation target, and then leverage C compilers to generate code for a variety of architecures. it's a very sensible way to do things.
  - fpgamlirfanboy 3y ago
    ghc doesn't target C since 7.0. the other two i couldn't be bothered to care even less about. when you can point to a production grade """compiler""" that targets C (instead of emitting ir or asm directly) then i'll be happy to discuss the merits/virtues of source to source translation instead of compilation.
  - treflop 3y ago
    Umm, everyone calls them transpilers?
    - zem 3y ago
      transpilers are a subset of compilers though. they span the gamut from things like coffeescript that do fairly simple syntax transformations, to full fledged languages whose compilation target happens to be a high level language like C or javascript, but which otherwise implement most of what you would expect in a "compiler".

vrinsd 3y ago

That's because in order to turn your "design" into an ASIC or an FPGA, you need to go from whatever high-level language (insert new-HDL-du-jour) into a netlist compatible with your physical part. The only scalable/vendor/device-neutral way to do that is to back-end your "new" HDL with Verilog/SystemVerilog/VHDL, especially if you want to simulate your design. A long time ago people used to design chips and CPLDs/FPGAs in schematic-capture (which actually does have its place) which is basically one-step removed from being a netlist. Among other challenges if you wanted to change to a new device (say a bigger part) or a part from a different vendor, there wasn't really "neutral" way to do this until HDLs came around. To really change the status quo, you'd have to own EVERYTHING from the point of design entry to the physical device and all steps between. Even with both "major" FPGA vendors now with their own synthesis and sometimes simulation capability they can barely and/or reliably make that minimum bar work.

fpgamlirfanboy 3y ago
> The only scalable/vendor/device-neutral way to do that is to back-end your "new" HDL with Verilog/SystemVerilog/VHDL i mean like the guy below says, but in the opposite tone, that's like saying building a C emitter is the same as building a compiler. like i just don't agree (for C, because C isn't some abstract device model and isn't (easily) optimizable) because you are forever yoked to the assumptions/affordances of the target language (which is ultimately a language and not an IR/netlist/whatever). > The only scalable/vendor/device-neutral way blif is a thing, eblif, xml, etc. are there points of ingress in vivado or intel's thing for any of these? i don't remember but regardless i agree they're probably not well-supported. > To really change the status quo, you'd have to own EVERYTHING from the point of design entry to the physical device and all steps between. nah that's not true. LLVM/GCC/etc. FOSS compilers that grew up in the last ~20-30 years prove you don't need to own the last mile to change the status quo. if you build it, device manufacturers will come. the truth is simply that performant logic synthesis, tech mapping, place and route, etc are just all much harder to implement than XYZ compiler pass. but it could be done given maybe 20*5 highly competent engineer years? i dunno pulling it out of my ass but i know i could write some of that stuff and i'm not that smart. maybe i'm underestimating by 2x (40*5) but that's still less than most "exciting" startups that raise series A today. it just takes diligence and "hard" technical skills (familiarity with the relevant optimization literature). > Even with both "major" FPGA vendors now with their own synthesis and sometimes simulation capability they can barely and/or reliably make that minimum bar work. not sure what's the minimum bar you're referring to but sure i agree - i work at one of em (the one that didn't file divorce papers recently...) and i still readily admit the toolchain is trash. which is why i wish some consortium would get together and replace it (because i would love to be able to program/design on our own parts using a modern tool suite). and no circt/yosys/vtr whatever aren't there probably won't ever be (yosys in particular is terribly disappointing for all the waves/claims it makes).

fayalalebrun 3y ago

Chisel does emit FIRRTL. Which can be made into a bitstream directly by Yosys.