[monocasa]

> 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...

[ajross]

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?)

[monocasa]

> 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...

[ajross]

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.

[microcolonel]

> 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".

Why don't you quit being an arrogant armchair architect prick on Hacker News, telling everyone what they should and should not be doing, and do it yourself.

This is not an open hardware project, this is a soft CPU core intended for final use in an FPGA: that is, not intended for manufacture. The best memory controllers and GPIO on your FPGA are the ones which are burned in at the fab. Why spend precious time developing a memory controller which will ultimately underperform the one you already have as part of your FPGA? To satisfy some dood on HN?

If it's so important and you're so disappointed with the quality of published peripheral controller HDL, then surely it's your job to show us all the right way.

[dang]

Yikes. Personal attacks aren't allowed here and we ban accounts that do that, so please don't do that again. Your comment would be just fine if it were just the middle paragraph.