Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An FPGA-friendly 32-bit RISC-V CPU implementation

github.com

Post reply on HN
Print view View original

11–20 of 44 posts

Re: An FPGA-friendly 32-bit RISC-V CPU implementation

#11

Post by monocasa »

ajross wrote: post #10
monocasa wrote: post #6

Earlier quoted context omitted.

Parts of DRAM, USB, and GPIO controllers at least are probably going to stay closed for the short term. The analog properties of their PHYs are per process hard blocks typically that the fabs are super into keeping locked up. I2C and SPI are pretty trivial though, I've written HDL for both of those. SPI is literally just a shift register and an chip enable signal.

USB has an actual PHY hardware spec for exactly that reason. And I'm not sure I buy your GPIO argument, not a hardware engineer but I've known several who all swear never to use fab-supplied GPIO blocks. It may well be that DRAM's analog requirements are fab-specific (though I'd be a little surprised if it were that bad: these are full swing classic bus signals), but nonetheless most of the complexity in these contro…

> USB has an actual PHY hardware spec for exactly that reason. And I'm not sure I buy your GPIO argument, not a hardware engineer but I've known several who all swear never to use fab-supplied GPIO blocks.

It's not "what does the the external spec require", it's "how do we achieve that at a given fab process". Ie. how do you achieve specific slew rate etc. on a given process?

> It may well be that DRAM's analog requirements are fab-specific (though I'd be a little surprised if it were that bad: these are full swing classic bus signals), but nonetheless most of the complexity in these controllers is in the logic side: clocking, refresh, bank mapping, ECC, etc... That's all stuff we could (and should) be writing in open source HDL.

There's plenty of open source implementations for the digital side of things. On this very github project:

https://github.com/SpinalHDL/VexRiscv/blob/master/src/main/s...

Re: An FPGA-friendly 32-bit RISC-V CPU implementation

#12

Post by baobrien »

quigonjinn wrote: post #8

Kinda off-topic. SpinalHDL is the second HDL, that I come across, being implemented in Scala. It seems that every popular programming language has at least one HDL implemented in it these days. Any obvious reasons for this trend?

I'm not sure about the trend in general, but it looks like SpinalHDL is a fork of Chisel, the 'other' Scala-based HDL.

Re: An FPGA-friendly 32-bit RISC-V CPU implementation

#13

Post by rvense »

quigonjinn wrote: post #8

Kinda off-topic. SpinalHDL is the second HDL, that I come across, being implemented in Scala. It seems that every popular programming language has at least one HDL implemented in it these days. Any obvious reasons for this trend?

Everybody wants a new HDL but there's no standard yet. Embedding it in your favourite language is the obvious solution, and hence there will be at least one per language.

Re: An FPGA-friendly 32-bit RISC-V CPU implementation

#14

Post by ajross »

monocasa wrote: post #11
ajross wrote: post #10

Earlier quoted context omitted.

USB has an actual PHY hardware spec for exactly that reason. And I'm not sure I buy your GPIO argument, not a hardware engineer but I've known several who all swear never to use fab-supplied GPIO blocks. It may well be that DRAM's analog requirements are fab-specific (though I'd be a little surprised if it were that bad: these are full swing classic bus signals), but nonetheless most of the complexity in these contro…

> USB has an actual PHY hardware spec for exactly that reason. And I'm not sure I buy your GPIO argument, not a hardware engineer but I've known several who all swear never to use fab-supplied GPIO blocks. It's not "what does the the external spec require", it's "how do we achieve that at a given fab process". Ie. how do you achieve specific slew rate etc. on a given process? > It may well be that DRAM's analog requi…

You're overselling the complexity here. Yes: mating analog specifications to line drivers/receivers requires per-process design. And at the very top end of achievable technology (USB 3.1, PCIe 4, DDR4...) these designs are likely to be NDA-level IP you have to get from the fab or its partners. But come on, "slew rate" matching is a matter of looking up some capacitance and I/D curves and plugging them into a SPICE model. Literally everyone does this in school.

But that's not remotely where we are with RISC-V designs in the market, where we'd be very happy to get a LPDDR2 controller and a USB Hi-Speed link with an open interface that doesn't require junky proprietary drivers or crazy workarounds for undocumented hardware bugs.

(Also FWIW: I can't find a DRAM controller implementation in that VexRisc tree. That line you point to looks maybe like an abstraction layer for plugging one in that's already on the FPGA?)

Re: An FPGA-friendly 32-bit RISC-V CPU implementation

#15

Post by monocasa »

ajross wrote: post #14
monocasa wrote: post #11

Earlier quoted context omitted.

> USB has an actual PHY hardware spec for exactly that reason. And I'm not sure I buy your GPIO argument, not a hardware engineer but I've known several who all swear never to use fab-supplied GPIO blocks. It's not "what does the the external spec require", it's "how do we achieve that at a given fab process". Ie. how do you achieve specific slew rate etc. on a given process? > It may well be that DRAM's analog requi…

You're overselling the complexity here. Yes: mating analog specifications to line drivers/receivers requires per-process design. And at the very top end of achievable technology (USB 3.1, PCIe 4, DDR4...) these designs are likely to be NDA-level IP you have to get from the fab or its partners. But come on, "slew rate" matching is a matter of looking up some capacitance and I/D curves and plugging them into a SPICE mo…

> You're overselling the complexity here. Yes: mating analog specifications to line drivers/receivers requires per-process design. And at the very top end of achievable technology (USB 3.1, PCIe 4, DDR4...) these designs are likely to be NDA-level IP you have to get from the fab or its partners. But come on, "slew rate" matching is a matter of looking up some capacitance and I/D curves and plugging them into a SPICE model. Literally everyone does this in school.

The spice model is closed and behind NDA. Seriously, can you point me to spice models of even ancient process nodes that are still manufactured? Let's say TSMC 0.13umG just to pick one out of the blue.

> But that's not remotely where we are with RISC-V designs in the market, where we'd be very happy to get a LPDDR2 controller and a USB Hi-Speed link with an open interface that doesn't require junky proprietary drivers or crazy workarounds for undocumented hardware bugs.

Here's a USB2 controller that's existed for more than 15 years on opencores:

https://opencores.org/project,usb

> (Also FWIW: I can't find a DRAM controller implementation in that VexRisc tree. That line you point to looks maybe like an abstraction layer for plugging one in that's already on the FPGA?)

It's imported from the spinal standard library. It's underlying implementation is here:

https://github.com/SpinalHDL/SpinalHDL/tree/master/lib/src/m...

Re: An FPGA-friendly 32-bit RISC-V CPU implementation

#16

Post by duskwuff »

Dolu wrote: post #5
ajross wrote: post #2

Too many people jumping into the "I wanna design a CPU too!" pool. Not nearly enough designing the needed microcontroller peripherals to have a working open hardware ecosystem. The JTAG debugging hooks are a nice touch for a FPGA product though. Do the existing RISC-V silicon implementations not provide this?

Yes, silicon implementation provide the JTAG, but it's very likely their implementation will not be reusable for FPGA project (including JTAG debug things) because of their over complicated (but powerfull) solutions which would consume way to much area and restrict the FMax. Then this specific VexRiscv ecosystem also provide a basic SoC with an multi master AXI4 inteconnect, SDRAM controller, embedded ram, APB3 inter…

For an FPGA implementation, it's often useful to hook the soft core into the FPGA's own JTAG controller, so that it's possible to program the FPGA and debug the core over a single connection. This is often not portable even between FPGAs, and certainly isn't portable to ASIC, but it makes development a lot easier, so...

Re: An FPGA-friendly 32-bit RISC-V CPU implementation

#17

Post by ajross »

monocasa wrote: post #15
ajross wrote: post #14

Earlier quoted context omitted.

You're overselling the complexity here. Yes: mating analog specifications to line drivers/receivers requires per-process design. And at the very top end of achievable technology (USB 3.1, PCIe 4, DDR4...) these designs are likely to be NDA-level IP you have to get from the fab or its partners. But come on, "slew rate" matching is a matter of looking up some capacitance and I/D curves and plugging them into a SPICE mo…

> You're overselling the complexity here. Yes: mating analog specifications to line drivers/receivers requires per-process design. And at the very top end of achievable technology (USB 3.1, PCIe 4, DDR4...) these designs are likely to be NDA-level IP you have to get from the fab or its partners. But come on, "slew rate" matching is a matter of looking up some capacitance and I/D curves and plugging them into a SPICE…

You've lost me on what you're arguing. I'm saying "we want to spend more time integrating open hardware designs into RISC-V devices and less time making new CPU cores in our fun new HDLs".

And you're saying "we can't" because... why? I know that junk is there on OpenCores too. I've looked at it. I've synthesized some of it. No one uses it on silicon. That's the part we need to fix. And it's not because of SPICE parameters being behind an NDA.

There's no reason you can't plug a USB state machine into a per-process line driver, that's the way it works everywhere (even on FPGAs). Synopsys et. al. ship their verilog with the logic carefully isolated from the semiconductor process dependency (for obvious reasons). Don't tell me that open hardware device vendors can't do the same thing. They just haven't, largely because existing open source people are spending their time making CPU cores instead of integrating a SoC (and software stack) made up of open designs that can be plugged into fab-supplied analog blocks in an obvious way.

Re: An FPGA-friendly 32-bit RISC-V CPU implementation

#18

Post by zokier »

Dolu wrote: post #5
ajross wrote: post #2

Too many people jumping into the "I wanna design a CPU too!" pool. Not nearly enough designing the needed microcontroller peripherals to have a working open hardware ecosystem. The JTAG debugging hooks are a nice touch for a FPGA product though. Do the existing RISC-V silicon implementations not provide this?

Yes, silicon implementation provide the JTAG, but it's very likely their implementation will not be reusable for FPGA project (including JTAG debug things) because of their over complicated (but powerfull) solutions which would consume way to much area and restrict the FMax. Then this specific VexRiscv ecosystem also provide a basic SoC with an multi master AXI4 inteconnect, SDRAM controller, embedded ram, APB3 inter…

Is either AXI4 or APB3 usable as external bus (like PCI(/e)), or are they intended for on-die communication?

Re: An FPGA-friendly 32-bit RISC-V CPU implementation

#19

Post by finfet1 »

monocasa wrote: post #9
finfet1 wrote: post #7

Earlier quoted context omitted.

Perhaps a solution would be if the verilog cpu project provided a few specific model numbers for each part (obviously, choosing ones that are commonly available and lesser cost), so that public contributors can work towards a common implementation for said part.

I mean, the issue is that you're not going to find the specifications for the PHY stuff anywhere. There's no model numbers to clone. It's literally things like how do you etch out capacitors in the fab's process? What's the electrical properties of their different dopants? There's not really any models to clone without cloning the whole fab. Our best option IMO is to wait until Moore's law hits more of a standstill,…

We're not talking about achieving on-die chip speeds at the picosecond range here. We're talking about interface specifications between the CPU and the DRAM, USB, etc -- these things can be designed for based on specs, and you don't need a trise/tfall equal to 10% of your FO4 inverter delay to achieve this. These are board level specifications which can be achieved with medium tier off the shelf components. And if they can't be achieved at the latest DDRX specs, then just design for one generation behind to at least get something going in the community.
Post reply on HN