[libre-riscv-dev] maybe adding OmniXtend support

Luke Kenneth Casson Leighton lkcl at lkcl.net
Wed Dec 19 18:05:01 GMT 2018


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

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

 it's the one used by lowrisc v0.6

l.



More information about the libre-riscv-dev mailing list