100G E-tile error on Stratix 10 DX

I'm using 22.1. I have not been using 22.2 due to this issue: https://community.intel.com/t5/Intel-Quartus-Prime-Software/PCIe-HIP-clocking-regression-on-Stratix-10-MX-in-Quartus-Prime/m-p/1394323#M74234

The code that interfaces with the E-tile was developed from scratch based on the documentation for the Agilex F series part, and is used with minimal modification on the Stratix 10 DX. The core logic that does not interface with the E-tile was also written from scratch, but runs and builds correctly on many different FPGAs, including the Stratix 10 DX.

The problem is from the E-tile 100G Ethernet IP core.

I have not tried to build the example design, but I will give it a shot and see if I can replicate the issue. I suspect that maybe it has to do with some of the unused PTP signals being tied off, instead of being driven by registers.

Sure, the Stratix 10 DX and Agilex F are somewhat different, but the E-tile is ostensibly exactly the same on both. And the core logic already works fine on the Stratix 10 DX and 10G and 25G, only difference between 10G/25G/100G in terms of the core logic is clock frequency and datapath width. And the core logic runs correctly on many other FPGAs without any device-specific modifications (Xilinx Virtex 7, Xilinx UltraScale, Xilinx UltraScale+, Intel Stratix 10 MX, Intel Stratix 10 DX, Intel Agilex F).

So I did some digging around, and the problem seems to be with how i_ptp_fp was being driven. Apparently something about the soft logic wrapper around the E-Tile ends up requiring that all of the PTP-related input signals are driven by a "hyperflex-friendly register".

For reference, the error is associated with the wdata_reg input of

        alt_ehipc3_mlab #(
            .WIDTH      (TX_PTP_WIDTH),
            .ADDR_WIDTH (4),
            .SIM_EMULATE(0)
        ) ptp_tx_ff (
            .wclk       (int_tx_clk),
            .wdata_reg  (usr_tx_ptp_ff_in),
            .wena       (tx_ts_ff_write),
            .waddr_reg  (ptp_tx_ff_waddr),
            .raddr      (ptp_tx_ff_raddr),
            .rdata      (usr_tx_ptp_ff_out_wire)
        );

This is driven by

        assign usr_tx_ptp_ff_in = {i_ptp_ins_ets,       // 1-bit
                                   i_ptp_ins_cf,        // 1-bit
                                   i_ptp_zero_csum,     // 1-bit
                                   i_ptp_update_eb,     // 1-bit
                                   i_ptp_ts_format,     // 1-bit
                                   i_ptp_ts_offset,     // 16-bit
                                   i_ptp_cf_offset,     // 16-bit
                                   i_ptp_csum_offset,   // 16-bit
                                   i_ptp_eb_offset,     // 16-bit
                                   i_ptp_tx_its,        // 96-bit
                                   i_ptp_ts_req,        // 1-bit
                                   i_ptp_fp             // 8-bit
                                  };

Apparently whatever directly drives these signals must be a simple flip flop with no reset input. Not an MLAB, not an M20K, not even a flip flop with a reset, preset, etc. input.

Personally, I consider this to be a bug in the soft logic wrapper. If this MLAB instance needs to be driven by "hyperflex-friendly registers", then such registers should exist in the soft logic wrapper to isolate the upstream logic from the MLAB instances to avoid this kind of difficult-to-debug DRC error. It's unclear why this only seems to be a problem on Stratix 10 devices, but not on Agilex.

Anyway, what I ended up doing was adding a register slice across all of the input signals on the transmit side, both the AVST interface and i_ptp_fp. Presumably this will end up being a permanent workaround for this issue.