RISC-V In… Typescript?

We are accustomed to seeing RISC-V implementations in Verilog or VHDL, but [Low Level JavaScript] has one in TypeScript. Before you dismiss it as a mere emulator, know that the project relies on gateware-ts, a conversion between TypeScript and Verilog. From there, you can actually put the CPU on an FPGA. You can see the launch video below and there is one development video as well as, presumably, more to come.

We aren’t sure if many FPGA designers will be willing to switch to TypeScript. But if you are comfortable with it, it might open up FPGA development without having to learn as much of a new language.

Of course, the end product is Verilog which gets put through the vendor’s tools. The good news is that means it will work with nearly anything. The bad news is that it is another step and means things like error messages might not relate directly back to your code in a way that’s easy to understand.

There are plenty of alternatives to Verilog and VHDL, but it doesn’t seem like any of them get much traction. You might want to compare this implementation (as it develops) with a RISC-V done in SpinalHDL. Then again, maybe just learn Verilog.

8 thoughts on “RISC-V In… Typescript?

  1. have programmed in lots of different programming languages over the years (as in used them in commercial setting) and I don’t think there’s anything about Verilog that’s so scary that it warrants running back, with tail tucked between the legs, to the the familiar embrace of some conventional software programming language.

    Seriously, one isn’t going to escape from some of the different concepts going on by doing that – the reality of clock-driven digital circuitry that can execute in parallel will still be there. Only thing will get is something that has a bit more syntax familiarity. Syntax sugar is just not worth it in respect to introducing an indirection that doesn’t have tight correlation to what one has to finally deal with in the vendor Verilog tool, where the rubber is finally going to meet the road, so to speak. The simulation, the test – all the feedback will be centric to the Verilog code. Trying to stay removed from Verilog is just going to be self-inflicting a handicap.

    Ah, but glad to see another RISC-V implementation – am kind of shopping for one of those for FPGAs

    1. You are correct that when it comes to low level design, one has to describe the clock driver circuitry. However the advantages of these new HDL(s) comes with high level systems.

      This is how you define the RAM block on a RISC-V SoC in LiteX:

      self.add_sdram(“sdram”,
      phy = self.sdrphy,
      module = M12L16161A(sys_clk_freq, “1:2”),
      origin = self.mem_map[“main_ram”],
      size = 2*mB,
      l2_cache_size = 0x8000,
      l2_cache_min_data_width = 128,
      l2_cache_reverse = True
      )

      The equivalent in verilog takes more lines and has less flexibility – in this example the L2 cache configuration is optional and can be omited.

    2. Verilog on its own have very limited code generation abilities, besides the simple `for` and alike. Which makes it nearly mandatory to use higher level code generation / preprocessing tools (e.g., the emacs `verilog-mode`). It also makes sense to use a high level language to generate Verilog where you have a lot of repetition that cannot be handled by the Verilog own tools, and this is exactly what all those Chisel, MyHDL, gateware-ts and alike are for.

      They’re complimentary to Verilog, not a substitution.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.