Bug 974

Summary: Implementation of the ethmac block
Product: Libre-SOC's second ASIC Reporter: Jean-Paul Chaput <Jean-Paul.Chaput>
Component: source codeAssignee: Jean-Paul Chaput <Jean-Paul.Chaput>
Status: CONFIRMED ---    
Severity: enhancement CC: libre-soc-bugs, lkcl
Priority: ---    
Version: unspecified   
Hardware: PC   
OS: Linux   
NLnet milestone: NGI.POINTER.Gigabit.ASIC total budget (EUR) for completion of task and all subtasks: 3000
budget (EUR) for this task, excluding subtasks' budget: 3000 parent task for budget allocation: 889
child tasks for budget allocation: The table of payments (in EUR) for this task; TOML format:
jean-paul=3000
Attachments: Plot of the ethmac block.

Description Jean-Paul Chaput 2022-10-30 10:29:57 GMT

    
Comment 1 Jean-Paul Chaput 2022-10-30 10:37:24 GMT
Created attachment 187 [details]
Plot of the ethmac block.

Plot of the ethmac block. With the standard cell based SRAM (left side) and a clock tree (right side).
Comment 2 Jean-Paul Chaput 2022-10-30 10:38:09 GMT
Generator of ``ethmac`` sub-block
=================================

General outline of the block

1. The I/O pads are supposed to be facing the east side of the block,
   there are 21 of them. The height of the block have been adjusted
   match it. As we do not know the the size of the I/O pads for
   Skywater we made an educated guess.

2. The connection to the core of the circuit, that is the two wishbone
   interfaces are on the right side of the chip.

3. When the SRAM is present, it is put on the left side of the chip.

Possible options

1. With or without the standard cell based SRAM generator.
2. With or without clock tree on PHY supplied RX/TX clocks.

Experimental results
~~~~~~~~~~~~~~~~~~~~

+----------------+--------------------+----------------+-------------------+
|      Tech      |     Options        |   Wire Length  |         Area      |
+================+====================+================+===================+
| SkyWater 130nm | No SRAM  No H-Tree | 3047615 -      | 1900*2100  -      |
|                +--------------------+----------------+-------------------+
|                | No SRAM     H-Tree | 3070051 -      | 2000*2100  -      |
|                +--------------------+----------------+-------------------+
|                |    SRAM  No H-Tree | 2523052 (-17%) | 2482*1360  (-15%) |
|                +--------------------+----------------+-------------------+
|                |    SRAM     H-Tree | 2544690 (-17%) | 2508*1360  (-19%) |
+----------------+--------------------+----------------+-------------------+
| TSMC 180nm     | No SRAM  No H-Tree | 4050593 -      | 3510*1898  -      |
|                +--------------------+----------------+-------------------+
|                | No SRAM     H-Tree | 4076011 -      | 3510*1898  -      |
|                +--------------------+----------------+-------------------+
|                |    SRAM  No H-Tree | 3377114 (-17%) | 3398*1768  (-10%) |
|                +--------------------+----------------+-------------------+
|                |    SRAM     H-Tree | 3387077 (-17%) | 3431*1768  (-9%)  |
+----------------+--------------------+----------------+-------------------+

Conclusions:

1. Even with a standard cell generated SRAM we win both in term of
   wirelength and area.

2. Using the SRAM allow us to restrict the placement area so the trees
   for the RX/TX clocks coming from the I/O pads (``mrx_clk_pad_i`` and
   ``mtx_clk_pad_i``) are much more compacts.