[libre-riscv-dev] [Bug 70] evaluate Bus Architectures

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=70

--- Comment #7 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #6)
> when multiple reference implementatiobs are available it will save us a huge
> amount of time and help us to ensure interoperability.

Ok, sounds good.

> 
> until then, unfortunately, the cost is i feel too high.  it's a brilliant
> idea, not to be ruled out entirely: we may even need to span across multiple
> FPGAs and ethernet is one of the easiest ways to do that.

>From reading the spec, tilelink seems to be a relatively simple (20-30 states)
state machine along with a 64-bit Add/CompareEq/Min/Max/MinU/MaxU/And/Or/Xor
ALU for handling AMOs. I would be surprised if TileLink needed more than 2-3k
gates.

If all the upstream interfaces handled AMOs themselves, the ALU wouldn't be
needed, however, I think it's a good idea to have the ALU even if we don't end
up using TileLink at all.

The tilelink state machine:
https://github.com/chipsalliance/omnixtend/blob/master/OmniXtend-1.0.3/spec/StateTransitionTables-1.8.0.pdf

To implement OmniXtend, you'll need receive and retransmit buffers, both
buffers need to be at least 1 ethernet frame, but making them larger will
increase maximum throughput. The retransmit buffer can be single ported, but
the receive buffer should have a separate read and write port.

So, for a 1Gbps link with 30us round-trip-time, you would need about 4kB for
each buffer to fully saturate the link. That is about the same size of buffers
needed to implement a CPU-controlled ethernet interface anyway, so it doesn't
seem too expensive, especially considering that it would only need to run at
less than 20MHz if it has a 64-bit datapath.

-- 
You are receiving this mail because:
You are on the CC list for the bug.