P2-ES Ethernet Dev Board Add-on

Hello Parallax,

Is there any plan to make a ethernet dev board add-on for P2?

I think that if parallax selects and provides a common board, then it will speed up development.

Comments

  • I'd also greatly appreciate such a board.
  • Peter JakackiPeter Jakacki Posts: 9,211
    edited 2020-06-24 - 06:59:06
    I have box loads of my tiny IoT5500 modules, fitted to and the size of the magjack itself. I will send some with the P2D2 shipments to @Publison in a couple of week. I have TAQOZ code that runs with it that implements Telnet, and FTP and HTTP servers. I made these up a few years back just before I went through chemo and a double-dealing WIZnet distributor.
  • I suggest Parallax that they choose a MAC/PHY or PHY and design an add-on board for P2-Eval.

    The Wiznet 5000/5200/5500, ENC28J60/ENC624J600 or similar IC helper solutions are not optimal for many reasons

    Those Wiznet 5000/5200/5500, ENC28J60, etc... ICs are limited to they internal fixed architecture. They were born in the first place to help Low performance MCU to have Ethernet connectivity. Have limits on performance, number of TCP/IP sockets, etc ... It is not flexible.

    A MAC/PHY directly 'read/write' ethernet frames into the wire. It is completely flexible (able to develop any protocol). You are 'read/write' at top line wire speed (97 Mbps).

    With a MAC/PHY you can DEMO/SHOW that the P2 is able to fit the space between a high performance MCU and FPGA. And beat them both due to easy of programming, flexibility to develop any protocol, and top wire speed performance.

  • jmgjmg Posts: 14,372
    Ramon wrote: »
    I suggest Parallax that they choose a MAC/PHY or PHY and design an add-on board for P2-Eval.
    With a MAC/PHY you can DEMO/SHOW that the P2 is able to fit the space between a high performance MCU and FPGA. And beat them both due to easy of programming, flexibility to develop any protocol, and top wire speed performance.
    I agree that would be interesting to see, but I think that that also locks the P2 Sysclk, to 25MHz multiples.
    I see the W5500 data claims this
    "The W5500 SPI supports 80 MHz speed and the new efficient SPI protocol, so users can implement high speed network communication. "

    The W6100 data claims 70MHz SPI speeds.
  • jmg wrote: »
    I agree that would be interesting to see, but I think that that also locks the P2 Sysclk, to 25MHz multiples.
    Or for the discrete PHY only approaches, if you wanted more consistent clocking into the P2 with the same TX and RX clock (and less pins) you'd probably be best to use RMII which uses 50MHz as the REF_CLK signal. The P2 would need to run at some multiple of this clock rate. The differences between MII and RMII are provided here:

    https://en.wikipedia.org/wiki/Media-independent_interface

    Of course we can't actually clock the P2 off the 8 GPIO pins each module feeds directly to/from the P2-EVAL, that would need to be jumpered somehow to control the P2 clock which gets messy.

    I wonder what other common MAC interfaced buses use? QSPI could be handy for Fast Ethernet but wider parallel bus solutions will restrict their use once they exceed 16 pin capabilities of the double wide P2-EVAL modules.

    Also before these such Ethernet modules are usable on the P2 you'll need a low level MAC and/or PHY driver and very probably an IP stack too (depending on what you want to do with Ethernet).
  • MJBMJB Posts: 1,160
    I have box loads of my tiny IoT5500 modules, fitted to and the size of the magjack itself. I will send some with the P2D2 shipments to @Publison in a couple of week. I have TAQOZ code that runs with it that implements Telnet, and FTP and HTTP servers. I made these up a few years back just before I went through chemo and a double-dealing WIZnet distributor.

    Oh yes
    I am waiting for the P2D2 with development board or could use a spare IoT5500 to port the scriptable dynamic webserver I had for Spinneret under Tachyon 3.0 to Taqoz
    Or maybe first port it to Tachyon 5.x when I have a bit time in August
  • I want to clarify my original post to avoid having this thread derailed into (#1) products that are not ready yet (even if they will be shipped in two weeks; loop #1), or products that are just sitting in a box somewhere.

    The purpose of this thread is to know if Parallax is willing to choose a PHY, design a board, and sell that Ethernet Add-on Module as extra for P2-EVAL board ... to have some kind of reference design, and to avoid duplicating software efforts ... that will help Parallax to say 'look I can do all of this so simple with just one P2, a cheap common PHY, and some smartpins'.

    So I suggest to use directly a PHY IC. With Hyperram/Hyperflash it wasn't a big problem to choose specific which specific IC (there were just two manufacturers, and a few parts). But with ethernet PHY is more difficult as there are many options.

    About PHY interface. Probably there are just only two options out there:

    1) RMII

    System clock can be P2 or PHY
    Clock frequency : (50 MHz +/-50ppm) for both 10Mbps and 100Mbps
    Total number of pins required: 10 pins (8 for PHY + 2 for MDIO/MDC)

    2) RGMII

    There are two clocks : TX and RX clocks (and are dependent on speed)
    Clock frequency : 2.5 MHz, 25 MHz, 125 MHz (for 10 , 100 and 1000 Mbps modes)
    Total number of pins required : 14 pins (12 for PHY + 2 for MDIO/MDC)

    The board will need to be plugged into two 2x6 headers due to number of pins (just like hyperram board).

    The need to choose the PHY IC is because every PHY on the market needs to be configured via two pins (like I2C, but called MDIO/MDC) at startup and that code might be PHY dependent.

    But other that those two MDIO/MDC pins, the other pins (8 for RMII, or 12 for RGMII) follow a standard. So the software coded for this part is common for every PHY on the market (usually called MAC). And that is the reason that I think it would be better if parallax choose one IC component and make a board and everyone else develop a software on that board.

    Is it parallax here? @Ken @cgracey @VonSzarvas ? or do I need to send the question to support?
  • VonSzarvasVonSzarvas Posts: 1,987
    edited 2020-06-25 - 11:29:59
    Hi @Ramon - agree it could be a good idea.

    Will need to digest all the ideas in this thread and understand what would be the most useful configuration for most users.

    For example- if the 8 pins are the main requirement, and those extra 2 are only for 1-time configuration, then maybe this could be a single-header accessory and have a 2-pin jumper cable to another edge header for the occasional configuration need. OR maybe share 2 of the 8 pins and have a dip-switch or jumper to swap into configure mode, instead of a jumper cable... (that assumes all 8 I/O's are not needed during the configuration step).

    You mention RMII and RGMII ... which would you choose ?
  • Hi, thank you for your reply.

    Those two MDIO/MDC are always usually needed even if the application is simple because that is the only way you can check link status (up/down), set speed/duplex mode (10mbps-duplex, 100mbps-HalfDuplex, 1000mbps), check counters, and many other things (like reset) ... BY SOFTWARE.

    Usually the PHY can many extra pins to configure the speed mode, and duplex mode by (pullup or gnd connection). This is usually called hardware configuration. I don't think it is flexible for a development board so I suggest to have two dedicated MDIO/MDC pins. However there will be no problem to reserve some jumpers to allow hardware configuration IF there is board space.

    So a RMII 8 pins board with hardwired modes (user selectable) might be possible but if will require the user to change a jumper every time it wants to change from 10 to 100, or from half-duplex to full-duplex. And will mean no way to have statistics (number of packets, errors, etc ...).

    Between RMII or RGMII, I honestly don't know what will choose due to clocking. By the way, I miss that the P2 board doesn't have a socket for common 3.3v DIP oscillators (half-size DIP8). Also, RGMII use double data rate (DDR). I am not familiar enough with P2 to know if smart pins can handle it, and if they can handle external clocking for RX that has a different phase from the P2 clock TX clock (as RGMII has two clocks). RMII specification says that the clock can be dictated by either the P2 (the call it MAC) or the PHY (which will limit somewhat usefullnes to P2 board). Datasheet needs to be checked carefully. Other PHYs maybe can do clock recovery from its received TX (from P2) and synchronize the RX clock to that TX clock and use buffers fir RX data (from wire cable). I remember that TI 'phyter' said something related about this.

    So it requires some study and discussion to check what both PHY and P2 can do.

    In case of doubt, a call to some PHY manufacturer FAE saying that you want to ship a development board - worldwide - as reference design ... with their chip on it ... might help a lot in the design phase of the board.
  • Agree you'll want to keep the MDC & MDIO pins connected for PHY control.

    For Fast Ethernet support only I would think RMII is much easier to sort out the clocking. The Wiki page I linked above mentions this about RMII REF_CLK:

    "Reference clock may be an input on both devices from an external clock source, or may be driven from the MAC to the PHY"


    This means in theory the P2 could supply this clock from an IO pin.

    Supporting Gigabit Ethernet using common PHYs on a P2 with a 16 pin limit you'll need to use RGMII but it will be a challenge with the receive clocking from PHY->P2, clock variation with link speed, and the RX framing. From a streamer perspective it's probably looking somewhat like the HyperRAM with DDR, but the receive control signal timing may be tricky. It looks like you need to continually stream data in and later mark frame start points in memory because the data valid signal comes in with the data itself, you can't use it to trigger the streamer it's too late by then. RGMII also uses lower voltages and so would require level translation though that is probably a very simple issue to sort out.
  • The good news are that almost all PHYs out there share the same pins for RMII and RGMII. And that RMII or RGMII mode can be software selected either by the two wires MDIO/MDC or by hardware (pull-ups) at startup or reset on some specific pins (IC dependent).

    Check just DP83TC811R-Q1 as example, but almost all other PHYs are the same.

    So it is possible to have both interfaces as option (but not working at the same time) within a single board.
  • jmgjmg Posts: 14,372
    Ramon wrote: »
    ... By the way, I miss that the P2 board doesn't have a socket for common 3.3v DIP oscillators (half-size DIP8)...
    Surely DIP oscillators are not common*, but expensive and rare dinosaurs ? The Eval B board has solder pads on XI/XO, and P2D2 has Si5351 and TXCO options.

    *A quick check at lcsc finds these product lines
    SMD Oscillators(XO) (2235) DIP Oscillators(XO) (11)


  • jmgjmg Posts: 14,372
    VonSzarvas wrote: »
    Will need to digest all the ideas in this thread and understand what would be the most useful configuration for most users.
    P2 with Ethernet should also consider IEEE 1588 and maybe EtherCAT ? - What would be the most common use ?
    Maybe
    https://www.microchip.com/wwwproducts/en/LAN9252
    or
    https://www.ti.com/interface/ethernet/phys/products.html?pqs=paqs&familyid=1752#p2192=IEEE 1588 PTP;IEEE 1588 SOF


  • jmg- EtherCAT is a great suggestion. That Microchip is pretty cool.

Sign In or Register to comment.