Support 10GBase-R Simulation.

[nightseas]

Hi Alex,

Do you have any plan to support BaseRSerdesSource & BaseRSerdesSink in the cocotbext-eth?
And maybe add eth_phy_10g simulation with cocotb in verilog-eth?

Thanks & BR.

[alexforencich]

Yes. However, I have no timeline on that at the moment. Basically the current sticking point is I want to build a nice abstraction for the serializers and associated components, something that could potentially scale up to support things like 40G and 100G Ethernet that use multiple lanes bonded together. So there would be modules for, say, a 64b/66b encoder, 8b/10b encoder, m:n gearbox, serializer, etc. The idea would be to create, say, cocotbext-serdes for the core components, and then implement the Ethernet-specific stuff here. But I don't currently have a nice, clean way to string such modules together. If you can help me think of something that would work well for that, then that could expedite things.

[nightseas]

Well I think it's a good idea to support serdes interface towards all possible standards.
The 66b interfaces for 10G/25GBase-R ares connecting to real transceiver IP and can be verified in FPGA beside simulation. Not sure if it's meaningful to include the components such as serializer which should be black box implementations inside the hard IP like GTY or E-Tile.
And will there be customized 40G/100G PCS/PMA IP implemented in verilog-eth or Corundum repo in the future? If yes, then it's necessary to create test end point for them from the beginning. Otherwise it perhaps should be low priority.
Frankly speaking I'm quite new to the PHY design and simulation. Let me see what I can do for this.

[alexforencich]

The idea is to make something modular that can be used to test designs that have a variety of interfaces. For example, if we restrict ourselves to 10G Ethernet on a GTY transceiver, you can do 128 bit raw, 64 bit raw, 32 bit raw, 16 bit raw (pushing the spec), 64 bit 64/66 bit async gearbox, 64-bit 66 bit sync gearbox, 32-bit 64/66 async gearbox, and 32-bit 64/66 sync gearbox. That's 8 different options for one protocol on one platform, and it makes no sense to write 8 different modules that do the same thing but have slightly different interfaces. So I'm thinking that there needs to be some way to make standard blocks and chain them together. For instance, a base-R block that exposes an interface on one side like the XGMII source and sink modules in this repo, and then on the other side can be connected to various serdes components. For instance, a gearbox that converts 66 bits to 64 bits or 32 bits or something else. Then I would have transceiver interface modules that could be connected to one of these modules on one side, and then drive signals into a verilog design just as the device transceiver would.

The trick is I'm not sure how best to connect these modules together. My initial thought was python generators, where the data generator "yields" output data to the next module in the chain. But it's not clear at the moment how you would cleanly compose those into a chain, especially if you want to do an N:1 mux or 1:N demux (say, for striping or lane bonding). The sticking point right now is mainly how to build this interface in a nice, clean, usable way in python. If I can sort that out, then making all of these modules shouldn't be particularly complex. Last time I looked in to this and asked on the cocotb gitter, there were a few ideas that came up including some ideas from uvm-python. But I don't really want to pull in uvm-python as a dependency. I suppose I can borrow some of the ideas and see what I can do with that.

Eventually I might have some 40G and/or 100G stuff. We shall see. It's much more complex than 10G, and I don't really see much point to 40G if there is also 25G and 100G, and we're seeing a lot of hard IP at 100G (Xilinx CMAC, Intel E-tile, etc). But, being able to drive a top-level integration test could be a useful capability, so even if I don't write any verilog implementations of 40G and 100G, having the capability to generate and receive 40G and 100G "wire" data could still be useful. This could also be useful for the PCIe side, along with implementing PIPE.

[alexforencich]

I went ahead and ported the BASE-R specific myhdl simulation model over to cocotb: https://github.com/alexforencich/verilog-ethernet/blob/master/tb/baser.py . That will probably suffice until I cook up a more extensible way of doing things. Unfortunately, I have not had much time to work on this.