FYI: Adapted to Digilent Nexys4 with

[cube1us]

Thanks for doing the work on this very versatile core!

I thought I would report on some work I have done getting this core to seemingly work (yay!) on a Digilent Nexys4 development board, for use with a project of mine ( https://www.computercollection.net/index.php/ibm-1410-fpga-implementation/ ) where I had exceeded the capacity of a USB based serial port to support it. The board is similar to the Arty7 example, except that the PHY is a LAN8720a -- RMII 10/100 Mbit Ethernet - so it didn't look like I could directly employ any of the examples -- and of course LEDs, Switches, etc. are different.

Unfortunately, I found cocotb to be problematic on my Windows 10 Pro machine with cygwin installed. After a few hours of effort, I waved the white flag on that. Not a problem at all, just an FYI. It does look like the test bench code will be helpful in understanding how to send and receive packets (test_udp_ip_rx., test_udp_ip_tx. and test_udp.* in particular).

I was first able to test using a simpler project on github, https://github.com/chasep255/Nexys-4-DDR-Ethernet-Mac , to test my understanding clocking, initialization and how to talk to the PHY layer and got that working. After that, I brought that knowledge, along with the (non longer supported, but freely available, including source) MII to RMII v2.0 LogiCore IP layer from Xilinx/AMD. Once I got my clock and reset logic in place and tested using a simple test bench done in VHDL to eventually match the rest of my own project (The PHY has a 100ns reset after the pll clock feeding it is in place, and it wasn't obvious to me how to accomplish that in the UDP core), this core just worked, using an echo test originating on my PC.

But, I have some questions that someone may be able provide some help / advice / or even criticism:

• I am using what was intended to be the 1Gb core for 100Mbit, via the MII to RMII adapter. Any concerns/caveats/gotchas?
• I usually run a 100MHz clock, and I changed the 125 MHz clock to 100Mhz. It seems to be working OK that way. Any concerns?
• For now, I am actually running two clock buffers fed from a common source, which I should probably combine, but I was wanting to change your core as little as possible at first. (and it looks like Vivado is already recognizing them and is combining / is prepared to combine them.)
• The PHY requires that its 50MHz clock (and for this development board, that has to be fed to it, rather than the PHY generating it) be 45 degrees out of phase with the clock of the component driving the PHY signals. But, curiously, to get that, I have to specify CLKOUT1_PHASE(22.5) -- if I use 45, I get a clock that is 90 degrees out of phase. Anybody have any ideas about that? Is that perhaps a result of the divide by 20? (The Nexys4 core I started with just uses 100Mhz, and just divides by 2 to get 50 Mhz).

So, I have:

MMCME2_BASE #(
.BANDWIDTH("OPTIMIZED"),
.CLKOUT0_DIVIDE_F(10), // Was 8 -- 10 for 100MHz
.CLKOUT0_DUTY_CYCLE(0.5),
.CLKOUT0_PHASE(0),
.CLKOUT1_DIVIDE(20), // My PHY needs 50 MHz
.CLKOUT1_DUTY_CYCLE(0.5),
.CLKOUT1_PHASE(22.5), // PHY needs 45 degree phase shift as well
.CLKOUT2_DIVIDE(1),
.CLKOUT2_DUTY_CYCLE(0.5),
.CLKOUT2_PHASE(0),
.CLKOUT3_DIVIDE(1),
.CLKOUT3_DUTY_CYCLE(0.5),
.CLKOUT3_PHASE(0),
.CLKOUT4_DIVIDE(1),
.CLKOUT4_DUTY_CYCLE(0.5),
.CLKOUT4_PHASE(0),
.CLKOUT5_DIVIDE(1),
.CLKOUT5_DUTY_CYCLE(0.5),
.CLKOUT5_PHASE(0),
.CLKOUT6_DIVIDE(1),
.CLKOUT6_DUTY_CYCLE(0.5),
.CLKOUT6_PHASE(0),
.CLKFBOUT_MULT_F(10), // Wondering if this shouldn't just be 1 for 100MHz.
.CLKFBOUT_PHASE(0),
.DIVCLK_DIVIDE(1),
.REF_JITTER1(0.010),
.CLKIN1_PERIOD(10.0),
.STARTUP_WAIT("FALSE"),
.CLKOUT4_CASCADE("FALSE")
)
clk_mmcm_inst (
.CLKIN1(clk_ibufg),
.CLKFBIN(mmcm_clkfb),
.RST(mmcm_rst),
.PWRDWN(1'b0),
.CLKOUT0(clk_mmcm_out),
.CLKOUT0B(),
.CLKOUT1(clk_50mhz_mmcm_out),
.CLKOUT1B(),
.CLKOUT2(),
.CLKOUT2B(),
.CLKOUT3(),
.CLKOUT3B(),
.CLKOUT4(),
.CLKOUT5(),
.CLKOUT6(),
.CLKFBOUT(mmcm_clkfb),
.CLKFBOUTB(),
.LOCKED(mmcm_locked)
);

Thanks for any input / comments / advice / etc.

JRJ