FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6228 Discussions

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

pnp
Novice
1,244 Views

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:

pnp_2-1631059285291.png

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

pnp_1-1631059148072.png

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):

pnp_4-1631060805766.png

But when I simulate this project, I see:

pnp_5-1631061537234.png

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

0 Kudos
1 Solution
AminT_Intel
Employee
1,115 Views

Hello Paul,

 

We have checked the design. We think it may be because of your coding design. We switched your 10 to 01 and got this result. Is this what you are expecting?

 

 
 

AminT_Intel_2-1632219938309.png

Image 1: Waveform

 

AminT_Intel_3-1632219974898.png

Image 2: Design

 

 

AminT_Intel_5-1632220058752.png

Image 3: Reference from https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_altera_gpio.pdf

 

Thank you.

 

 

View solution in original post

0 Kudos
9 Replies
pnp
Novice
1,199 Views

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

pnp_0-1631143408870.png

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.

0 Kudos
AminT_Intel
Employee
1,158 Views

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

0 Kudos
pnp
Novice
1,151 Views

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.

0 Kudos
AminT_Intel
Employee
1,116 Views

Hello Paul,

 

We have checked the design. We think it may be because of your coding design. We switched your 10 to 01 and got this result. Is this what you are expecting?

 

 
 

AminT_Intel_2-1632219938309.png

Image 1: Waveform

 

AminT_Intel_3-1632219974898.png

Image 2: Design

 

 

AminT_Intel_5-1632220058752.png

Image 3: Reference from https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_altera_gpio.pdf

 

Thank you.

 

 

0 Kudos
pnp
Novice
1,104 Views

Amin,

 

Thank you for looking into this issue! That is exactly where I ended up: I swapped the din values as you did. I see the waveform you posted from the documentation, but that is for half-rate conversion. We are not doing half-rate conversion in this case.

 

My issue is that the behavior contradicts the documentation:

pnp_0-1632243632125.png

 

from https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_altera_gpio.pdf

In this case, datain_width is 1. So

 

datain_h = din[(2 * 1 - 1):1] = din[1:1] and

datain_l = din[(1 - 1):0] = din[0:0]

 

which matches what I see in the technology mapped netlist (see my initial post in this issue). The comment at the end of the document states:

pnp_0-1632244262890.png

 

which is what I expect to happen, however swapping values in din is required to get the expected behavior.

 

Thanks,

Paul

0 Kudos
AminT_Intel
Employee
1,055 Views

Hello,

 

The last screenshot you've given is on Guideline: Swap datain_h and datain_l Ports in Migrated IP which is for migration for your GPIO IP from previous devices to the GPIO IP core. This only applies only for the migration.

 

AminT_Intel_0-1632816235285.png

 

0 Kudos
pnp
Novice
1,047 Views

Amin,

 

I am grateful for your assistance in resolving this issue: all of our cyclone10gx_ddio_out  instances are working properly now in our FPGA design. I accept that I have misunderstood the documentation and that the GPIO IP is working as Altera designed. I'd suggest, though, that it would be helpful if someone added a full-rate scenario timing diagram to the docs, because the IP does behave differently than the legacy altddio_out megafunction with nearly identical port names.  At the very least, this thread will be here if anyone else is snagged.

 

Best regards,

Paul

0 Kudos
AminT_Intel
Employee
981 Views

Hello Paul,

 

I'm glad that it helps! Thank you for the suggestion we will take note of that.

 

Thanks

0 Kudos
AminT_Intel
Employee
981 Views

 I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.

0 Kudos
Reply