Merge pull request #79 from ed-xmos/feature/timing_stress_test

Test RMII in a MIPS constrained environment

CHANGELOG.rst

@@ -4,14 +4,14 @@ lib_ethernet change log
 4.0.0
 -----
 
-  * REMOVED: Slicekit based examples because hardware is obsolete
-  * REMOVED: Support for waf build system
-  * ADDED: Support for XCommon CMake build system
-  * REMOVED: Support for XS1 devices
-  * RESOLVED: Build warnings even when compile successful
   * ADDED: Support for running MII sim tests for XS3 architecture
   * ADDED: RMII Ethernet MAC support for XCORE-AI
   * ADDED: Extended sim tests for testing RMII applications
+  * ADDED: Support for XCommon CMake build system
+  * RESOLVED: Build warnings even when compile successful
+  * REMOVED: Slicekit based examples because hardware is obsolete
+  * REMOVED: Support for waf build system
+  * REMOVED: Support for XS1 devices
 
   * Changes to dependencies:
 

doc/rst/lib_ethernet.rst

@@ -33,7 +33,7 @@ Various MAC blocks are available depending on the XMOS architecture selected, de
    - Supported
  * - XS3 (xcore.ai)
    - Supported
-   - Contact XMOS
+   - Supported
    - Contact XMOS
    - N/A
 
@@ -67,11 +67,11 @@ The amount required depends on the feature set of the MAC. The table below summa
    - 2
    - ~23 k
    - 4
- * - 10/100 Mb/s Real-Time MII
+ * - 10/100 Mb/s Real-Time RMII
    - 7
    - 3 (1-bit), 2 (4-bit) or 4 (1-bit)
    - 2
-   - ~TBD k
+   - ~25 k
    - 4
  * - 10/100/1000Mb/s RGMII
    - 12
@@ -196,6 +196,9 @@ have their port type set independently and can be mixed. Unused pins on a 4-bit
     the PHY to be configured so that the receive data strobe is set to RX_DV mode. Please check your chosen PHY supports this.
 
 
+The RMII MAC requires a minimum thread speed of 75 MHz which allows all 8 hardware threads to be used on a 600 MHz xcore.ai device.
+
+
 Table 1 below describes the RMII signals:
 
 .. list-table:: RMII signals
@@ -471,18 +474,24 @@ Similarly the RMII real-time MAC may be instantiated::
       streaming chan c_rx_hp;
       streaming chan c_tx_hp;
       par {
-        rmii_ethernet_rt_mac(i_cfg, 1, i_rx_lp, 1, i_tx_lp, 1,
-                            c_rx_hp, c_tx_hp,
-                            p_eth_clk,
-                            &p_eth_rxd, p_eth_rxdv,
-                            p_eth_txen, &p_eth_txd,
-                            eth_rxclk, eth_txclk,
-                            4000, 4000, ETHERNET_ENABLE_SHAPER);
+        unsafe{rmii_ethernet_rt_mac(i_cfg, 1, i_rx_lp, 1, i_tx_lp, 1,
+                                    c_rx_hp, c_tx_hp,
+                                    p_eth_clk,
+                                    &p_eth_rxd, p_eth_rxdv,
+                                    p_eth_txen, &p_eth_txd,
+                                    eth_rxclk, eth_txclk,
+                                    4000, 4000, ETHERNET_ENABLE_SHAPER);}
        application(i_cfg[0], i_rx_lp[0], i_tx_lp[0], c_rx_hp, c_tx_hp);
       }
     }
 
 
+.. note::
+    The call to rmii_ethernet_rt_mac() needs to be wrapped in  ``unsafe{}`` because the rmii_data_port_t types are sent as references which translate to unsafe (array bounds unchecked) pointers.
+
+
+
+
 The application can use the other end of the streaming channels to send and receive high-priority traffic e.g.::
 
   void application(client ethernet_cfg_if i_cfg,