Forum Discussion

pnp's avatar
pnp
Icon for New Contributor rankNew Contributor
4 years ago
Solved

GPIO DDRIO IP output swapped: datainhi/datainlo inverts forwarded clock

I have a source-synchronous interface for which I am forwarding a clock with a DDRIO register as recommended in AN433 pp6-7 to minimize skew between the clock and data waveform:

I created a GPIO IP in Quartus Prime Pro 21.1 to forward the clock:

and instantiate as follows:

module ddriotest
(
    input logic  clk,
    output logic clk_fwd,
    output logic [7:0] data
);
    // forward clock
    ddr_output i_ddr
    (
        .ck(clk), .din(2'b10),
        .pad_out(clk_fwd)
    );

    // generate example source synchronous output data
    logic [7:0] count = '0;
    always @(posedge clk) count <= count + 1'b1;
    always @(posedge clk) data <= count;
endmodule

When I look at the post-fitter technology map netlist, I see DATAINHI = 1'b1 and DATAINLO = 1'b0 on the DDIO_OUT primitive, which matches the connections shown in AN433 to forward the clock (see pic above for comparison):

But when I simulate this project, I see:

Notice that clk and clk_fwd are inverted with respect to one another! I believe they should be in-phase aside from Tco delay and clock delay, and both of those delays wouldn't be present in this functional sim. I have to swap din[0] and din[1]to get desired behavior. I have good reason to believe this is happening with the actual hardware as well, so it isn't just a sim issue. I've followed the connection all the way to the cyclone10gx_ver.cyclone10gx_ddio_out primitive, which is encrypted so I can't look any further.

Why is this inversion taking place?

I'm using Quartus Prime Pro 21.1 and GPIO IP 20.0 with Questa Intel Starter Edition-64 21.1 (beta) for a Cyclone 10 GX device. Full example project and sim attached.

Thanks,

Paul

9 Replies

  • pnp's avatar
    pnp
    Icon for New Contributor rankNew Contributor

    Looking at the very bottom of ug_altera_gpio.pdf there is this note:

    I feel like this is a clue, though this paragraph is as clear as mud to me. In my case I did not migrate the IP, I am not using the legacy top-level port names, and the port meaning in that bullet list is what I expect the IP to do.

  • AminT_Intel's avatar
    AminT_Intel
    Icon for Regular Contributor rankRegular Contributor

    Hello,

    What do you mean by 'I have good reason to believe this is happening with the actual hardware as well, so it isn't just a sim issue'?

    Thanks

    • pnp's avatar
      pnp
      Icon for New Contributor rankNew Contributor

      The synthesized design behaves as the simulation shows: the signal on datainhi is output on the falling edge of the clock. For my source synchronous interface, this was sneaking in a 180-degree phase shift on the output clock. The timing analyzer assumes pos-unate edges so data transitions occur in the wrong place relative to the active edge of the clock, which breaks my interface. If I swap datainhi and datainlo, my design works as expected.