Author here (Paul Campbell) - AMA
Do you dance? :)
https://youtu.be/nlu0foF3WBk?t=182
I know, I'm leaning hard on that second "A" there. :D
VRoom A high end RISC-V implementation
51–60 of 135 posts
Re: VRoom A high end RISC-V implementation
#52Author here (Paul Campbell) - AMA
As a language VM implementor, I would really love to have a conditional call instruction, like arm32. AFAICT this would be a relatively simple instruction to implement in the CPU. Is that accurate?
8080 had it too, 8086 dropped it due to disuse. In a modern context it's just a performance hack, an alternative to macro-op fusion, but for high-performance RISC-V (or i386, or amd64, or aarch64) you need macro-op fusion anyway.
Re: VRoom A high end RISC-V implementation
#53The presentation was interesting; but I would like to write an idea that is tangentially related to this CPU. I noticed that modern CPUs are optimized for legacy monolith OS kernels like Linux or Windows. But having a large, multimegabyte kernel is a bad idea from a security standpoint. A single mistake or intentional error in some rarely used component (like a temperature sensor driver) can get attacker full access…
Segment registers are precisely how NT does context switching. I think it may be restricted to just switching from user- to kernel- threads. I can't remember if there's thread-to-thread switching using segment registers — I feel like this was a thing, or it was just a thing we did when we tried to boot NT on Larrabee. (Blech.)
Re: VRoom A high end RISC-V implementation
#54For a few years I worked with the guy behind this project, Paul Campbell. He is a fearless coder, and moves between hardware and software design with equal ease. An example of his crazy coding chops, he was frustrated by the lack of verilog licenses at the place he worked back in the early 90s. His solution was to whip up a compliant verilog simulator, then wrote a screen saver that would pick up verification tasks f…
Synthesizable verilog is a very small language compared to system verilog — especially in the 90s. Off the top of my head I know of six "just real quick" verilog simulators that I've worked with (one of which I wrote). I'm not sure how I feel about them. On one hand, I hate dealing with licenses; on the other hand, now you've got to worry that your custom simulation matches behavior with the synthesis tools. A lot of the "nonstandard" interpretation for synthesizable verilog from the bigs comes from practical understanding of the behavior for a given node. Most of that is captured in ABC files ... but not all of it.
Re: VRoom A high end RISC-V implementation
#55Any recommendations for resources on learning to makes things like this in general?
Computer Architecture: A Quantitative Approach[1] is the textbook that gets recommended the most on the topic, I believe.
Re: VRoom A high end RISC-V implementation
#56For a few years I worked with the guy behind this project, Paul Campbell. He is a fearless coder, and moves between hardware and software design with equal ease. An example of his crazy coding chops, he was frustrated by the lack of verilog licenses at the place he worked back in the early 90s. His solution was to whip up a compliant verilog simulator, then wrote a screen saver that would pick up verification tasks f…
Synthesizable verilog is a very small language compared to system verilog — especially in the 90s. Off the top of my head I know of six "just real quick" verilog simulators that I've worked with (one of which I wrote). I'm not sure how I feel about them. On one hand, I hate dealing with licenses; on the other hand, now you've got to worry that your custom simulation matches behavior with the synthesis tools. A lot of…
It was more than simple synthesisable verilog, but not a lot - it was also a compiler rather than an interpreter - at the time VCS was just starting to be a thing, verilog as a language was not at all well defined (lots of assumptions about event ordering that no-one should have been making)
I was designing Mac graphics accelerators I'd built it on a some similar infrastructure I'd built to capture trace from people's machines to try and figure out where QuickDraw was really spending it's time - we ended up with a minimilistic graphics accelerator that beat the pants off of everyone else
Re: VRoom A high end RISC-V implementation
#57What does GPL mean for a chip design? I understand how it applies to the HDL, but I doubt that it obligates you have to open your code to users of physical chips.
It means "pay me to remove the GPL". It's fake GPL like MySQL and MongoDB.
https://www.fsf.org/blogs/rms/selling-exceptions
RMS wrote "I've considered selling exceptions acceptable since the 1990s, and on occasion I've suggested it to companies. Sometimes this approach has made it possible for important programs to become free software."
Re: VRoom A high end RISC-V implementation
#58Author here (Paul Campbell) - AMA
Do you dance? :) https://youtu.be/nlu0foF3WBk?t=182 I know, I'm leaning hard on that second "A" there. :D
heh! - I'm a Kiwi who lived and worked in Silicon Valley for 20 years, moved back when the kids started high school, but mostly still work there - while I was there I started a company using "Taniwha" ... great for a logo, but a mistake because of course no one in the US knows how to pronounce it (pro-tip the "wh" is most close to an english "f")
Re: VRoom A high end RISC-V implementation
#59Author here (Paul Campbell) - AMA
From what little I know about microarchitecture, this seems extremely impressive. Hopefully these aren't dumb questions: Are there GPL'd designs for PCIe, USB, etc, that could be used to incorporate this into a SoC design? If not, how much work is that compared to this? Also, what other kind of technical considerations would be involved to make this into a "real" chip on something like 28nm?
Not Paul Campbell, but I'll share what I know on the matter.
So GPL'd IO blocks - This is a great question, and something I have definitely been asking myself! One thing to keep in mind is that IO interfaces like PCIe, USB, and whatnot have a Physical interface ("Phy" for short.) Those contain quite a bit of analog circuitry, which is tied to the transistor architecture that's used for the design.
That being said, A lot of interfaces that aren't DRAM protocols use what's known as a SerDes Phy (short for Serializer De-serializer Physical interface.) More or less, they have an analog front end and a digital back end, and that digital back end that connects to everything else is somewhat standardized way. So it wouldn't be unreasonable to try to build something like an open PCIe controller that only has the Transaction Layer and Data Link Layer. While there are various timing concerns/constraints when not including a Phy layer (lowest layer,) I don't think it's impossible.
The other big challenge is that anyone wanting to use an open source design will definitely want the test benches and test cases included in the repo (you can think of them like unit tests.) Unfortunately, most of the software to actually compile and run those simulations is cost prohibitive for an individual, because it's licensed software. Also, the companies that develop this software make a ton of money selling things like USB and PCIe controllers, so I'll let you draw your own conclusions about the incentives of that industry.
Even if you were able to get your hands on the software, the simulations are very computationally intensive, and contribution by individuals would be challenging ...though not impossible!
Despite those barriers, it's a direction that I desperately want to see the industry move towards, and I think it's becoming more and more inevitable as companies like Google get involved with hardware, and try to make the ecosystem more open. Chiplet architectures are also all the rage these days, so it would be less of a risk for a company to attempt to use an open source design.
I'd really be curious to hear Paul Campbell's take on this question though. He definitely knows a lot more than I do!
Re: VRoom A high end RISC-V implementation
#60Earlier quoted context omitted.
It's likely too big for those programs - I am (just now) starting a build with the Open Lane/Sky tools not with the intent of actually taping out but more to squeeze the architectural timing (above the slow FPGA I've been using for bringing up Linux) so I can find the places where I'm being stupidly unreasonable about timing (working on my own I can't afford a Synopsys license)
Gotcha. Did you run into any issues with yosys given that it has limited system verilog support? Ibex needed to add a pass with sv2v https://github.com/lowRISC/ibex/tree/master/syn
I'm just starting this week, I've recently switched to some use of SV interfaces and it does not like arrays of them - sv2v seems the way to go - but even without that yosys goes bang! somethings too big Vivado compiles the same stuff - I rearchitected the bit that might obviously be doing this but no luck so far.