Bug 778

Summary: strategy for connecting eth_mac suitable for ASIC deployment
Product: Libre-SOC's second ASIC Reporter: Luke Kenneth Casson Leighton <lkcl>
Component: source codeAssignee: Luke Kenneth Casson Leighton <lkcl>
Status: RESOLVED WONTFIX    
Severity: enhancement CC: libre-soc-bugs
Priority: ---    
Version: unspecified   
Hardware: Other   
OS: Linux   
See Also: https://bugs.libre-soc.org/show_bug.cgi?id=850
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:
Bug Depends on:    
Bug Blocks: 690    

Description Luke Kenneth Casson Leighton 2022-02-24 20:56:28 GMT
https://github.com/freecores/ethmac

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.