3 ms·

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

by 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).
- vrinsd 3y ago
  LLVM/GCC target fixed ISA devices. Even GPUs can be represented in this paradigm of having a core set of instructions and registers for SIMD/SMT. What FPGA or random ASIC could LLVM front-end? How do you go from LLVM-IR to something that can live in an FPGA? You can either do what most "high-level" or "new HDL" tools do which is emit some form of "RTL" (Verilog/VHDL) or you can stick a place-holder design in the FPGA and then your LLVM-IR is basically emitting instructions for an "overlay" type of design. And if we are being pedantic you can use Verilog or VHDL to write a purely STRUCTURAL netlist which includes hard instantiating "basic building block" primatives. i.e. have your RTL instantiate an ISERDES or OSERDES block (which I suspect will mean something to you). But even with a "netlist" based design in RTL you still have to technology map that into building blocks of your hardware and that whole process becomes so complex people have just migrated to writing "behavorial" RTL (or translating to it from some other language, i.e. Vivado HLS). Lastly, Vivado does support EDIF netlists as do most FPGA tools (whether they advertise it or not) but if you don't have a way to do a technology mapping stage from your high-level RTL into building blocks (which is effectively part of the "synthesis" steps), then what did you accomplish?
  - fpgamlirfanboy 3y ago
    > LLVM/GCC target fixed ISA devices. Even GPUs can be represented in this paradigm of having a core set of instructions and registers for SIMD/SMT. What FPGA or random ASIC could LLVM front-end? How do you go from LLVM-IR to something that can live in an FPGA? You completely missed my point, which was not that RTL and an ISA are comparable in any way but that many of the target codegen backends for both those compilers were contributed by the owners of the ISAs themselves. I said that in response to your claim that you need to own the whole stack to "change the status quo". You don't, you just (mighty big just) need to present a compelling enough value proposition in your stack for the device manufacturers to contribute the remainder of the stack.

by vrinsd 3y ago

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).

vrinsd 3y ago
LLVM/GCC target fixed ISA devices. Even GPUs can be represented in this paradigm of having a core set of instructions and registers for SIMD/SMT. What FPGA or random ASIC could LLVM front-end? How do you go from LLVM-IR to something that can live in an FPGA? You can either do what most "high-level" or "new HDL" tools do which is emit some form of "RTL" (Verilog/VHDL) or you can stick a place-holder design in the FPGA and then your LLVM-IR is basically emitting instructions for an "overlay" type of design. And if we are being pedantic you can use Verilog or VHDL to write a purely STRUCTURAL netlist which includes hard instantiating "basic building block" primatives. i.e. have your RTL instantiate an ISERDES or OSERDES block (which I suspect will mean something to you). But even with a "netlist" based design in RTL you still have to technology map that into building blocks of your hardware and that whole process becomes so complex people have just migrated to writing "behavorial" RTL (or translating to it from some other language, i.e. Vivado HLS). Lastly, Vivado does support EDIF netlists as do most FPGA tools (whether they advertise it or not) but if you don't have a way to do a technology mapping stage from your high-level RTL into building blocks (which is effectively part of the "synthesis" steps), then what did you accomplish?
- fpgamlirfanboy 3y ago
  > LLVM/GCC target fixed ISA devices. Even GPUs can be represented in this paradigm of having a core set of instructions and registers for SIMD/SMT. What FPGA or random ASIC could LLVM front-end? How do you go from LLVM-IR to something that can live in an FPGA? You completely missed my point, which was not that RTL and an ISA are comparable in any way but that many of the target codegen backends for both those compilers were contributed by the owners of the ISAs themselves. I said that in response to your claim that you need to own the whole stack to "change the status quo". You don't, you just (mighty big just) need to present a compelling enough value proposition in your stack for the device manufacturers to contribute the remainder of the stack.