[libre-riscv-dev] maybe adding OmniXtend support

[Jacob Lifshay]

On Wed, Dec 19, 2018, 10:05 Luke Kenneth Casson Leighton <lkcl at lkcl.net
wrote:

> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
> On Wed, Dec 19, 2018 at 10:49 AM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
> >
> > Western Digital is working on creating OmniXtend, which is basically
> > TileLink with modifications over ethernet:
> >
> https://github.com/westerndigitalcorporation/omnixtend/blob/master/README.md
> >
> > https://youtu.be/qQnpF8pbuAU starting at 16:05
> >
> > I think implementing support for it in the Libre SoC is a good idea
> > (assuming that we are going to have ethernet anyway) as it makes for a
> easy
> > way to connect to external parts using a cache-coherent protocol and it
> > shouldn't take that much additional area or power.
> >
> > One of the most important parts is that it can leverage already existing
> > ethernet PHYs and switches, so those won't have to be reimplemented.
> >
> > From what I read in the spec, TileLink is about as simple as you can get
> > for a extendible cache-coherent protocol with fast at-memory atomic rmw
> > operations.
> >
> > I think supporting OmniXtend will make our SoC really useful for
> > implementing large low-cost shared-memory systems and will be really
> useful
> > for things like low-cost many-core servers (4 cores per chip at $4 per
> chip
> > + ram + ethernet switch chips + power + PCB; I have not done any
> research,
> > but it sounds really inexpensive) and for crypto-miners.
> >
> > One other benefit is that we don't need additional i/o pins to support
> it.
> > I haven't checked, but we may also be able to run tcp/ip over the same
> port
> > simultaneously without worrying about security since the protocol number
> > would be different than IP.
>
>  if it drops over ethernet frames just like IPX/SPX was a completely
> different protocol for example, such that effectively raw packets can
> be thrown at the RGMII PHY then that's absolutely fine.


>  if done at the hardware level it would be necessary to do a partial
> decode of the ethernet frames and extract them from the stream as
> opposed to passing them directly on to the software layer.
>
It would definitely need to be handled in hw as sw would be way too slow.
Assuming we have TileLink internally, the only additional parts needed are
the state machine to generate the ethernet framing and crcs.

I checked and the current version of the spec is incompatible with the
ethernet mac layer, so we could share the phy between the mac layer and
OmniXtend and switch which one is active.

Since we can run memory-mapped devices through OmniXtend, we could have
external ethernet hw for when we need both standard ethernet and OmniXtend.

We can just switch the phy to connect to the mac layer to get standard
ethernet when we aren't using OmniXtend.

We could also have things like an OmniXtend to PCIe bridge, which would be
really handy.

>
>  here's the RGMII GbE interface i found by alex forenchich:
>  https://libre-riscv.org/shakti/m_class/RGMII/

I checked and it looks pretty simple to modify to allow adding OmniXtend
support.

>
>
>  it's the one used by lowrisc v0.6
>
> l.
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>