[J-core] Happy new year.

Rob Landley rob at landley.net
Sun Jan 10 21:05:42 UTC 2021


On 1/10/21 2:12 PM, emanuel stiebler wrote:
> On 2021-01-01 23:21, Rob Landley wrote:
>> We can probably get j-core running on that, AND it should work with the fully
>> open toolchain.
> 
> What is also interesting, the open source tool chains also support DDR3
> by now, sticking with DDR1/DDR2 is not necessary anymore ...

That's like saying "the current C compilers now support 80211.N wireless device
drivers, you don't need to stick with 80211.B wifi drivers anymore". That's...
not how it works? It was never a toolchain issue?

we weren't ddr2, we were lpddr2. The lp stands for "low power". I believe it's a
separate spec from "ddr2"?

  https://en.wikipedia.org/wiki/LPDDR

One big advantage is it's got a variable bus size so we can use fewer FPGA pins.
(Number of available FPGA pins is a limiting factor for us, at least in this
FPGA generation.)

If you mean libraries, there's been a DDR3 dram controller library in spartan 6
FPGA all along:

  https://www.xilinx.com/support/documentation/user_guides/ug388.pdf

But we implemented our own in FPGA fabric because we're making an ASIC, not JUST
living in FPGA forever. We could have licensed somebody else's all along but
we're not doing that for any of the other components. (We'll happily use
compatibly licensed open source implementations, it turns out a lot of the open
source software licenses are inappropriate for producing hardware. And several
of the components we've temporarily glued on were in verilog, and we wrote
proper vhdl two process versions eventually anyway.)

That said, we've looked at other memory controller implementations and they
didn't meet our design needs, but Jeff is the guy to go into details. (He had a
half hour call with me last year explaining how the one the skylake guys were
planning to use didn't have various features we needed, something about burst
mode and back to back transfers and...)

I believe there's memory controller work in the engineering queue of the J32
branch, but switching sdcard from spi/mmc mode to 6-wire sd 1.0 @25 mhz is a
more immediate performance increase for current designs. (And of course getting
it all up on github with kernel support pushed into Linus's tree, that's been
properly tasked and staffed since new year's I think? Working on it...)

Rob


More information about the J-core mailing list