4 ms·

I've always been a bit wary of higher-level languages to replace lower-level RTL (e.g. in Verilog or VHDL). From my experience whilst SystemVerilog isn't a nice

I've always been a bit wary of higher-level languages to replace lower-level RTL (e.g. in Verilog or VHDL). From my experience whilst SystemVerilog isn't a nice language it doesn't really get in the way of the actual hard problems, just causes a nuisance for easier things. In processor micro-architecture the hard problems come when you're trying to hit a frequency, power or area target. You may need to do some interesting things that can be quite circuit specific and have complex tradeoffs (e.g. perhaps you choose to handle some corner case that produces a large timing path with some kind of stall or replay when it occurs, is the corner case sufficiently infrequent that overall you get a performance increase?). Having some high level way to sweep through the design space here would be incredibly useful, but the problem is building each point of the design space can be its own complex task. Having a high level description you can easily fiddle with in order to try different kinds of complex instructions, easily play around with structure sizing and the like sounds great. The problem is if it doesn't produce a design that's as optimal as the hand-coded RTL could be you might get the best design for your application that the tool can make but it gets outperformed by a more standard design that's normal hand-coded RTL. It's tempting to compare to software, where high-level code is often preferred even if it's not the most efficient due to the other benefits it brings but chips have certain fixed manufacturing costs that just aren't present in software. Due to these costs it's often better to put more into the design, by more detailed low-level work, in order to get a more optimal design. Though that said I really need to spend some more time with these higher-level tools. I'm sure there's some great stuff to be done with them.

brucehoult 5y ago
It's just like the compiler vs assembly language arguments back in the 1970s to mid 80s. Yes, you can get better results with hand-coding the RTL, and indeed with hand-placing the resulting transistors and even making them different sizes depending on the fan-out required etc. The question is: can you AFFORD to? SiFive use Chisel to design all their CPUs. Their original 32 bit FE310 back in late 2016 ran at 320 MHz on a 180nm process -- absolutely killing the frequencies ARM Cortex M3/M4 were available in at the time (or now .. 180 MHz is still the fastest I'm aware of) SiFive's FU540 with quad core U54 64 bit cores ran at 1.5 GHz on a 28nm process in early 2018, as do the quad dual-issue U74 cores in their FU740 this year. Sure, you can do better with hand design, but it costs $billions. Only Intel, AMD, and Apple have that kind of money to spend.
klelatti 5y ago
That’s really interesting - could you say anything about real world design process for a modern state of the art CPU? Is that all done in lower-level RTL?
- gchadwick 5y ago
  Well I can't speak for all CPUs but yes, at arm at least, lower-level RTL is used for the CPU design. Combined with that will be modeling at various levels. C++ models can be used for performance exploration for instance. Cycle accurate (or close to cycle accurate) models for the CPU are useful but also hard to work with. You may well be developing the accurate model in combination with the CPU itself. In early design work you'll hack features into an older model just to see how they might work in isolation or even just stare at some spreadsheets with performance counters and make an educated guess as to how some new feature or structure will effect them and use that to calculate potential performance increases.
  - klelatti 5y ago
    Thanks - much appreciated. Sounds quite challenging given the complexity of modern CPUs!
rowanG077 5y ago
Honestly I very much welcome different RTL based languages. VHDL and Verilog are just so bad. But HLS seems to just be the wrong way forward.
- FPGAhacker 5y ago
  Curious, what do you find so bad about them?
  - rowanG077 5y ago
    Little to no IDE support. Arcane or no type systems. Shitty module systems. Inconsistent semantics. High verbosity. Extremely bad tooling. etc etc
    - FPGAhacker 5y ago
      I can agree with verbosity. But VHDL has an extremely strong type system, which comes from its ADA heritage. It’s semantics are also very consistent per my recollection, but it’s been a while. Verilog definitely has looser numeric typing. It tripped up a friend of mine yesterday. I’ve been doing this stuff forever so I don’t think about it much, and I’m grateful for the simplified math it affords. Disagree on IDE support because vscode support for SV at least is pretty nice. And sigasi is still doing well. But I’m old school I guess and prefer vim/nvim. I actually do a hybrid thing where I’ll use nvim in the vscode terminal to do some quick edits for something not In the workspace every now and then. SystemVerilog smoothed over some of the ugliness of verilog, but then bolted on at least three other languages into one with the semantic inconsistencies you mention. Particularly No idea what the rational was there, if any. But I never found it to be a significant barrier to learning. I’ve done experiments with writing an HDL in Clojure that would compile to SV, and it was fun, but it just created a new set of problems. Much better to work in a standardized language warts and all.
Lramseyer 5y ago
I would agree with you in the case of a mass market design where you're competing with a major CPU player. And while that gets the most attention in the tech media, it's actually a somewhat small portion of the market. it's important to keep in mind that a large portion of the semiconductor (VLSI, digital design) market is chips that perform auxiliary tasks. Things like networking equipment controllers, Storage device controllers, and connectivity device controllers like Bluetooth, USB, and whatnot. Those designs all have CPUs in them, but performance is not as critical as something like a Ryzen CPU or an i7. Unit volumes can be lower for these chips as well, and there is definitely a lot of value to be gained by a lowered development costs, which this aims to do. While I'm not claiming that this is a perfect implementation, the VLSI design world is definitely ripe for newer, higher level, and more open source design languages and tools. There will always be performance critical designs that lower level languages will be useful for, similarly how there will always be performance critical code that will be written in C/C++ and assembly. And yes, I'm aware of most of the alternative HDLs, and open source EDA tools out there, and I have varying opinions about them. I understand the limitations of building hardware and why we do things the way we do. But I think it's incredibly naive to think that we can't apply more mindsets from software engineering to hardware engineering. We just happen to be in a market where good hardware engineers can get paid more as a software engineer. I call this out because I get the push back from so many people in my industry, and they sound like (what I would imagine) Autodesk developers sound like when Blender gets brought up in a conversation.
lizknope 5y ago
Have you looked at Chisel? It isn't really high level synthesis but the Chisel is converted to Verilog and then that is synthesized like normal. It makes connecting things and configuration a lot easier. https://en.wikipedia.org/wiki/Chisel_(programming_language) https://en.wikipedia.org/wiki/Chisel_(programming_language) https://www.chisel-lang.org/ https://www.chisel-lang.org/

brucehoult 5y ago

It's just like the compiler vs assembly language arguments back in the 1970s to mid 80s. Yes, you can get better results with hand-coding the RTL, and indeed with hand-placing the resulting transistors and even making them different sizes depending on the fan-out required etc. The question is: can you AFFORD to? SiFive use Chisel to design all their CPUs. Their original 32 bit FE310 back in late 2016 ran at 320 MHz on a 180nm process -- absolutely killing the frequencies ARM Cortex M3/M4 were available in at the time (or now .. 180 MHz is still the fastest I'm aware of) SiFive's FU540 with quad core U54 64 bit cores ran at 1.5 GHz on a 28nm process in early 2018, as do the quad dual-issue U74 cores in their FU740 this year. Sure, you can do better with hand design, but it costs $billions. Only Intel, AMD, and Apple have that kind of money to spend.

klelatti 5y ago

That’s really interesting - could you say anything about real world design process for a modern state of the art CPU? Is that all done in lower-level RTL?

gchadwick 5y ago
Well I can't speak for all CPUs but yes, at arm at least, lower-level RTL is used for the CPU design. Combined with that will be modeling at various levels. C++ models can be used for performance exploration for instance. Cycle accurate (or close to cycle accurate) models for the CPU are useful but also hard to work with. You may well be developing the accurate model in combination with the CPU itself. In early design work you'll hack features into an older model just to see how they might work in isolation or even just stare at some spreadsheets with performance counters and make an educated guess as to how some new feature or structure will effect them and use that to calculate potential performance increases.
- klelatti 5y ago
  Thanks - much appreciated. Sounds quite challenging given the complexity of modern CPUs!

rowanG077 5y ago

Honestly I very much welcome different RTL based languages. VHDL and Verilog are just so bad. But HLS seems to just be the wrong way forward.

FPGAhacker 5y ago
Curious, what do you find so bad about them?
- rowanG077 5y ago
  Little to no IDE support. Arcane or no type systems. Shitty module systems. Inconsistent semantics. High verbosity. Extremely bad tooling. etc etc
  - FPGAhacker 5y ago
    I can agree with verbosity. But VHDL has an extremely strong type system, which comes from its ADA heritage. It’s semantics are also very consistent per my recollection, but it’s been a while. Verilog definitely has looser numeric typing. It tripped up a friend of mine yesterday. I’ve been doing this stuff forever so I don’t think about it much, and I’m grateful for the simplified math it affords. Disagree on IDE support because vscode support for SV at least is pretty nice. And sigasi is still doing well. But I’m old school I guess and prefer vim/nvim. I actually do a hybrid thing where I’ll use nvim in the vscode terminal to do some quick edits for something not In the workspace every now and then. SystemVerilog smoothed over some of the ugliness of verilog, but then bolted on at least three other languages into one with the semantic inconsistencies you mention. Particularly No idea what the rational was there, if any. But I never found it to be a significant barrier to learning. I’ve done experiments with writing an HDL in Clojure that would compile to SV, and it was fun, but it just created a new set of problems. Much better to work in a standardized language warts and all.

Lramseyer 5y ago

I would agree with you in the case of a mass market design where you're competing with a major CPU player. And while that gets the most attention in the tech media, it's actually a somewhat small portion of the market. it's important to keep in mind that a large portion of the semiconductor (VLSI, digital design) market is chips that perform auxiliary tasks. Things like networking equipment controllers, Storage device controllers, and connectivity device controllers like Bluetooth, USB, and whatnot. Those designs all have CPUs in them, but performance is not as critical as something like a Ryzen CPU or an i7. Unit volumes can be lower for these chips as well, and there is definitely a lot of value to be gained by a lowered development costs, which this aims to do. While I'm not claiming that this is a perfect implementation, the VLSI design world is definitely ripe for newer, higher level, and more open source design languages and tools. There will always be performance critical designs that lower level languages will be useful for, similarly how there will always be performance critical code that will be written in C/C++ and assembly. And yes, I'm aware of most of the alternative HDLs, and open source EDA tools out there, and I have varying opinions about them. I understand the limitations of building hardware and why we do things the way we do. But I think it's incredibly naive to think that we can't apply more mindsets from software engineering to hardware engineering. We just happen to be in a market where good hardware engineers can get paid more as a software engineer. I call this out because I get the push back from so many people in my industry, and they sound like (what I would imagine) Autodesk developers sound like when Blender gets brought up in a conversation.

lizknope 5y ago

Have you looked at Chisel? It isn't really high level synthesis but the Chisel is converted to Verilog and then that is synthesized like normal. It makes connecting things and configuration a lot easier. https://en.wikipedia.org/wiki/Chisel_(programming_language) https://en.wikipedia.org/wiki/Chisel_(programming_language) https://www.chisel-lang.org/ https://www.chisel-lang.org/