Bug 778 - strategy for connecting eth_mac suitable for ASIC deployment
Summary: strategy for connecting eth_mac suitable for ASIC deployment
Alias: None
Product: Libre-SOC's second ASIC
Classification: Unclassified
Component: source code (show other bugs)
Version: unspecified
Hardware: Other Linux
: --- enhancement
Assignee: Luke Kenneth Casson Leighton
Depends on:
Blocks: 690
  Show dependency treegraph
Reported: 2022-02-24 20:56 GMT by Luke Kenneth Casson Leighton
Modified: 2022-08-29 23:12 BST (History)
1 user (show)

See Also:
NLnet milestone: ---
total budget (EUR) for completion of task and all subtasks: 0
budget (EUR) for this task, excluding subtasks' budget: 0
parent task for budget allocation:
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:


Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kenneth Casson Leighton 2022-02-24 20:56:28 GMT

the above 10/100 ethernet MAC (RMII) is designed to be deployed for an ASIC:
there is a FIFO which has AsyncFF Synchronisers in front of it which bridge
between the RxMac and TxMac clocks, and the main SYS clock at which the
wishbone master runs.

the problem to overcome with the FIFO is that it is not designed for ASICs,
and so has to be done with FFs. that means in turn that it cannot be too
large, and that in turn risks starvation if the wishbone master requests
are not served fast enough.

a very aimple workaround is to provide a local SRAM with a wishbone slave
in front of it, and a local arbiter that allows the eth_mac highest priority
to read and write to it.

the local SRAM can be large enough to compensate for a smaller FIFO, large
enough to hold an entire frame, but not so large it eats area.

the second port on the arbiter will map through to the main memory bus, at a
lower priority.  in this way the main processor can also read and write but
without interrupting the eth_mac core.