[J-core] Online talk on the 16th.

[Rob Landley]

Brian Bartholomew wrote:
>  > https://www.youtube.com/watch?v=dVD1Yws__v0&list=PLxde5XJWZRbTerLRlh0vp43scTA3cfKN8
> 
> I watched the talks, and the progress ie exciting; I didn't know DDR3
> and ethernet were already implemented.

100baseT ethernet and LPDDR2 controller have been implemented for a while.
Gigabit isn't too hard if you're ok talking to an off the shelf PHY chip. DDR3
controllers are available as a library in some FPGAs we're using, but we need to
do our own implementation that we can make an ASIC out of.

The problem with DDR3 and gigabit ethernet is is clocking the I/O fast enough.
We're trying to deploy stuff in cheap FPGAs you can get in bulk for under $50.
There are fast expensive FPGAs that cost 10 times that, and we have a few for
development, but it's too expensive to deploy anything in, where deploy means
"send to customers" or "expect a larger development community to use".)

In theory you can have I/O circuitry at the edge of the FPGA clocked way faster
than the processor the rest of it's implementing, but then there's clock routing
and domain crossing, and still timing closure, and the result's messy. We added
a clock domain crossing for the GPS correlators on spartan 6 (which isn't as
fast as kintex so going at the CPU speed it could only track 3 satellites at
once and we needed 5) and it took weeks to debug.

In the current SOC, 100baseT is 11 megabytes/second (benchmarked) and SD 1.0 is
12.5 megabytes/second (before packet overhead anyway, 4 data wires clocked at 25
mhz) and when things match up like that switching just _one_ part to be faster
leaves the fast bit spinning its wheels. There's a certain amount of needing to
upgrade multiple parts at once to reach a new balance.

> But where can I buy all that
> hardware you featured?
> 
> Brian  

In theory it's going up on crowdsupply. Mike Tokue (in Tokyo) is handling that.

Rob