4 ms·

VHDL and Verilog are virtually no different from eachother. It's basically equivalent to ARM assembly vs MIPS assembly -- they are both machine-level assembly

by pdq 9y ago

VHDL and Verilog are virtually no different from eachother. It's basically equivalent to ARM assembly vs MIPS assembly -- they are both machine-level assembly languages. If you want something more interesting, see High Level Synthesis (aka C to RTL, SystemC, etc) [1]. But this is still very beta (and has been for over a decade), so it's almost unused in the industry on designs. The majority of hardware design time is now dominated in the hardware verification space, aka SystemVerilog. [1] https://en.wikipedia.org/wiki/High-level_synthesis https://en.wikipedia.org/wiki/High-level_synthesis

chclau 9y ago
On the last releases of Vivado, Xilins is making a big push for HLS. Personally I have not still had the chance to learn and try it.
beagle3 9y ago
I last did either VHDL or Verilog in 1997, which is 20 years ago (and reminds me I'm getting old), but if things are remotely similar, the apt comparison is not ARM assembly vs. MIPS assembly, but rather Verilog=~C vs VHDL=~Ada
- chclau 9y ago
  I don't know ADA, I have always thought that Verilog is like old C and VHDL like C++. Not that VHDL is object oriented, but is a strong-typed language.
  - beagle3 9y ago
    VHDL's syntax was borrowed from Ada (and much more closely resembles it than Verilog, which was inspired by C but not adapted from it) Example Ada: http://perso.telecom-paristech.fr/~pautet/Ada95/e_c16_p5.ada http://perso.telecom-paristech.fr/~pautet/Ada95/e_c16_p5.ada
  - ajdlinux 9y ago
    VHDL's syntax and type system are quite Ada-ish, from what I gather.
  - oelang 9y ago
    VHDL is an old version of ADA combined with a build-in discrete event simulator. The syntax, type system, general semantics are all copied from ADA. This is actually a good thing, Verilog (and even more SystemVerilog) is designed by people who don't have a clue about language design resulting in an incredible mess of a language.
microcolonel 9y ago
I think there is room for something in-between. High-level synthesis is probably never going to meet the needs of most ASIC designers, especially as progress on manufacturing processes has effectively stopped. The more promising avenue to me is structured synthesis: using straightforward abstraction but keeping the HDL model. Chisel (based in Scala) seems to be the biggest open source one; bluespec is a more established run at the same concept which is based in Haskell, and interestingly they seem to be throwing all of their marketing weight behind RISC-V solutions. So in a way, high-level functional HDL is dominated by RISC-V today.
- codebook 9y ago
  I have doubt that RISC-V will take visible portion of mobile/embedded core any time soon. It was announced 6 years ago as far as I know but still only few commercial products have it inside. Chiesel itself would be sunken together since it uses RISC-V as a ad.
  - microcolonel 9y ago
    At least embedded seems to be embracing RISC-V like it's a race. Microsemi markets RISC-V tooling, Lattice semiconductor markets it, and basically all of Bluespec's marketing material is around their RISC-V development tools (for formal and differential verification of new RISC-V cores). NVIDIA is already embedding RISC-V deeply into every one of their chipsets (all Tegras, all mobile discrete GPUs, all desktop discrete GPUs). I don't see how somebody with any knowledge of the embedded industry could conclude that RISC-V will fail to penetrate that market. As for consumer mobile devices, such as smartphones and tablets, you could make the argument that ARM has a lot of traction. However, the cost and flexibility benefits of RISC-V are not moot. For platforms like the Chromebook, you have a lot more flexibility in terms of the hardware platform. There's no practical reason why RISC-V would fail in Chromebooks. Workstations, desktops, and general purpose (usually windows) laptops are a lot tougher. There is a lot of consumer value in the dominance of x86 in these markets so I probably wouldn't expect much to budge there in a short amount of time. As for servers, however, there is no strict reason why any new ISA would fail. The biggest handicaps would be lack of out-of-the box distro support, platform inconsistency (huge problem for ARM, where you can't generally share images between boards), and low quality of compilers and language runtimes. If there is a good JVM port, a good v8 port, a good GCC port, and a good LLVM port, and maybe a few other VMs (like BEAM), there is no reason why RISC-V would be doomed to fail on servers. In fact, I see huge reasons why RISC-V would win the server market. Imagine an SoC which has the ethernet MAC, the remote management system/iKVM (with low-level access to the platform serial console) and a big wide superscalar OoO for running your server application on it. Imagine that the clean separation of ABI, SBI, HBI, and MBI drives up the quality, isolation guarantees, and performance of virtual machines. Imagine that you could have a TPU on the same die as the application processor, with a low-latency preemptible interconnect and unified memory. I see RISC-V's technical decisions as almost uniquely suitable for the server market, and I think the server market is probably the most amenable to new ISA penetration.
odmkSeijin 9y ago
I programmed FPGAs using both VHDL and Verilog for many years. Recently I have started at a start-up where we predominantly program using C++ HLS. I never want to go back to full-time HDL again. We have found it is possible to get the same performance as carefully written RTL, but you still have to write with the underlying device architecture in mind. There are advantages with HLS, simulation is vastly faster, and C++ templates can be used. This makes it easy to try many iterations and find clever optimizations. If you try to do the same with HDL it would be a nightmare with a large design. More people should move to HLS and push for the tools to improve. the world would be a better place.
- orbifold 9y ago
  What tool do you use for this? Also, are you targeting ASICS or FPGAs? I think for ASICs there are probably a ton of custom non-public tools that use C++, one is for example described in http://scale.eecs.berkeley.edu/papers/krashinsky-phd.pdf http://scale.eecs.berkeley.edu/papers/krashinsky-phd.pdf, the Mill Architecture people seem to plan the same, but I haven't seen any in the open so far.
- oelang 9y ago
  Be honest though, HLS works well for DSP-like applications, not for anything else. Not every digital design is image processing and if it works well you're still sacrificing ~20% of your LUTs.
  - odmkSeijin 9y ago
    I don't agree with this, but I think I see what you are trying to say. I think typically a full design would include some interface portion with maybe DMA or PCIe or whatever that would be done in HDL, and maybe a processor or not. HLS works for the processing that is done inside the FPGA. If this is what you mean by DSP-like, then sure, but it does not have to be image processing, it could be anything done in fabric. It is possible to write a specific truth-table, and similar basic elements in C++, so why would you be forced to do any specific type of application? Where did you get %20 percent number? At least for Xilinx HLS, I don't think that has anything to do with anything (maybe for some other compiler??). If you take some generic C or C++ code and try to put it in an FPGA, the number will be more like 80%. The results will be horrible. On the other hand, if you write code in a way that naturally maps to the hardware you are using then the results can be every bit as good RTL. But this is not necessarily easy to do. I think that this has more to do with the quality of the current compilers, not some inherent limitation with the concept. I like HDL, but I would much much rather program in C++. It is a more sophisticated language. I think Intel/Altera is supposed to release some HLS tool, and I know there are others that I haven't tried. What I am saying is that it would be nice if enough effort was put into these tools to not have to worry about whether there are limitations. Even more so since I think the newer C++ standards are moving towards multi-threading/concurrency.

by pdq 9y ago

chclau 9y ago

On the last releases of Vivado, Xilins is making a big push for HLS. Personally I have not still had the chance to learn and try it.

beagle3 9y ago

I last did either VHDL or Verilog in 1997, which is 20 years ago (and reminds me I'm getting old), but if things are remotely similar, the apt comparison is not ARM assembly vs. MIPS assembly, but rather Verilog=~C vs VHDL=~Ada

chclau 9y ago
I don't know ADA, I have always thought that Verilog is like old C and VHDL like C++. Not that VHDL is object oriented, but is a strong-typed language.
- beagle3 9y ago
  VHDL's syntax was borrowed from Ada (and much more closely resembles it than Verilog, which was inspired by C but not adapted from it) Example Ada: http://perso.telecom-paristech.fr/~pautet/Ada95/e_c16_p5.ada http://perso.telecom-paristech.fr/~pautet/Ada95/e_c16_p5.ada
- ajdlinux 9y ago
  VHDL's syntax and type system are quite Ada-ish, from what I gather.
- oelang 9y ago
  VHDL is an old version of ADA combined with a build-in discrete event simulator. The syntax, type system, general semantics are all copied from ADA. This is actually a good thing, Verilog (and even more SystemVerilog) is designed by people who don't have a clue about language design resulting in an incredible mess of a language.

microcolonel 9y ago

I think there is room for something in-between. High-level synthesis is probably never going to meet the needs of most ASIC designers, especially as progress on manufacturing processes has effectively stopped. The more promising avenue to me is structured synthesis: using straightforward abstraction but keeping the HDL model. Chisel (based in Scala) seems to be the biggest open source one; bluespec is a more established run at the same concept which is based in Haskell, and interestingly they seem to be throwing all of their marketing weight behind RISC-V solutions. So in a way, high-level functional HDL is dominated by RISC-V today.

codebook 9y ago
I have doubt that RISC-V will take visible portion of mobile/embedded core any time soon. It was announced 6 years ago as far as I know but still only few commercial products have it inside. Chiesel itself would be sunken together since it uses RISC-V as a ad.
- microcolonel 9y ago
  At least embedded seems to be embracing RISC-V like it's a race. Microsemi markets RISC-V tooling, Lattice semiconductor markets it, and basically all of Bluespec's marketing material is around their RISC-V development tools (for formal and differential verification of new RISC-V cores). NVIDIA is already embedding RISC-V deeply into every one of their chipsets (all Tegras, all mobile discrete GPUs, all desktop discrete GPUs). I don't see how somebody with any knowledge of the embedded industry could conclude that RISC-V will fail to penetrate that market. As for consumer mobile devices, such as smartphones and tablets, you could make the argument that ARM has a lot of traction. However, the cost and flexibility benefits of RISC-V are not moot. For platforms like the Chromebook, you have a lot more flexibility in terms of the hardware platform. There's no practical reason why RISC-V would fail in Chromebooks. Workstations, desktops, and general purpose (usually windows) laptops are a lot tougher. There is a lot of consumer value in the dominance of x86 in these markets so I probably wouldn't expect much to budge there in a short amount of time. As for servers, however, there is no strict reason why any new ISA would fail. The biggest handicaps would be lack of out-of-the box distro support, platform inconsistency (huge problem for ARM, where you can't generally share images between boards), and low quality of compilers and language runtimes. If there is a good JVM port, a good v8 port, a good GCC port, and a good LLVM port, and maybe a few other VMs (like BEAM), there is no reason why RISC-V would be doomed to fail on servers. In fact, I see huge reasons why RISC-V would win the server market. Imagine an SoC which has the ethernet MAC, the remote management system/iKVM (with low-level access to the platform serial console) and a big wide superscalar OoO for running your server application on it. Imagine that the clean separation of ABI, SBI, HBI, and MBI drives up the quality, isolation guarantees, and performance of virtual machines. Imagine that you could have a TPU on the same die as the application processor, with a low-latency preemptible interconnect and unified memory. I see RISC-V's technical decisions as almost uniquely suitable for the server market, and I think the server market is probably the most amenable to new ISA penetration.

odmkSeijin 9y ago

I programmed FPGAs using both VHDL and Verilog for many years. Recently I have started at a start-up where we predominantly program using C++ HLS. I never want to go back to full-time HDL again. We have found it is possible to get the same performance as carefully written RTL, but you still have to write with the underlying device architecture in mind. There are advantages with HLS, simulation is vastly faster, and C++ templates can be used. This makes it easy to try many iterations and find clever optimizations. If you try to do the same with HDL it would be a nightmare with a large design. More people should move to HLS and push for the tools to improve. the world would be a better place.

orbifold 9y ago
What tool do you use for this? Also, are you targeting ASICS or FPGAs? I think for ASICs there are probably a ton of custom non-public tools that use C++, one is for example described in http://scale.eecs.berkeley.edu/papers/krashinsky-phd.pdf http://scale.eecs.berkeley.edu/papers/krashinsky-phd.pdf, the Mill Architecture people seem to plan the same, but I haven't seen any in the open so far.
oelang 9y ago
Be honest though, HLS works well for DSP-like applications, not for anything else. Not every digital design is image processing and if it works well you're still sacrificing ~20% of your LUTs.
- odmkSeijin 9y ago
  I don't agree with this, but I think I see what you are trying to say. I think typically a full design would include some interface portion with maybe DMA or PCIe or whatever that would be done in HDL, and maybe a processor or not. HLS works for the processing that is done inside the FPGA. If this is what you mean by DSP-like, then sure, but it does not have to be image processing, it could be anything done in fabric. It is possible to write a specific truth-table, and similar basic elements in C++, so why would you be forced to do any specific type of application? Where did you get %20 percent number? At least for Xilinx HLS, I don't think that has anything to do with anything (maybe for some other compiler??). If you take some generic C or C++ code and try to put it in an FPGA, the number will be more like 80%. The results will be horrible. On the other hand, if you write code in a way that naturally maps to the hardware you are using then the results can be every bit as good RTL. But this is not necessarily easy to do. I think that this has more to do with the quality of the current compilers, not some inherent limitation with the concept. I like HDL, but I would much much rather program in C++. It is a more sophisticated language. I think Intel/Altera is supposed to release some HLS tool, and I know there are others that I haven't tried. What I am saying is that it would be nice if enough effort was put into these tools to not have to worry about whether there are limitations. Even more so since I think the newer C++ standards are moving towards multi-threading/concurrency.