[HN Gopher] High-Level Synthesis for RISC-V
___________________________________________________________________
High-Level Synthesis for RISC-V
Author : PaulHoule
Score : 37 points
Date : 2021-10-28 17:29 UTC (5 hours ago)
(HTM) web link (semiengineering.com)
(TXT) w3m dump (semiengineering.com)
| gchadwick wrote:
| 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.
| Lramseyer wrote:
| 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.
| klelatti wrote:
| 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 wrote:
| 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 wrote:
| Thanks - much appreciated. Sounds quite challenging given
| the complexity of modern CPUs!
| rowanG077 wrote:
| 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.
| lizknope wrote:
| 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://www.chisel-lang.org/
| Decabytes wrote:
| Curious to see what cool and interesting things come out when the
| BeagleV finally comes out. Hopefully it will make Risc-V more
| accessible to the masses
| gchadwick wrote:
| https://forum.beagleboard.org/t/the-future-of-beaglev-commun...
| Sadly their current prototype is not becoming a production
| model though they are working on other board designs.
___________________________________________________________________
(page generated 2021-10-28 23:01 UTC)