IO_OBUF polarity not matching RTL

Hi,

Tri-state buffer can be either active high or active low. There are many types of it you can refer here. What I can guess is that IO_OBUF is most likely an active low tri-state buffer.

Moreover, --OE is active high-- you highlighted in manual don't very related to IO_OBUF mentioned above. That is for Data Interface Signals of gpio ip.

Best regards,
Sheng

p/s: If any answer from the community or Intel support are helpful, please feel free to give Kudos.

That doesn't change the fact that when I implement an active-high tri-state buffer (either with RTL or instantiating a GPIO IP block), the tools put in the IO_OBUF and the polarity of the OE is active-low, but that doesn't seem to be compensated for.

The behavior of my hardware is the opposite of what I have coded for the design and when I drive 0 instead of hi-Z in the "disabled" state the polarity is now correct. I have never actually instantiated an IO_OBUF, that is just what the tools used during synthesis but it seems like they are not compensating for the active-low OE of that primitive.

So...

assign TRIG[0] = (lb_enable_dd) ? clk_fast : 1'bz;

lb_enable_dd = 0, TRIG[0] = clk_fast (observed on the HW, which is wrong, it should be hi-Z)

lb_enable_dd = 1, TRIG[0] = hi-Z (observed on the HW, which is wrong, it should be clk_fast)

assign TRIG[0] = (lb_enable_dd) ? clk_fast : 1'b0;

lb_enable_dd = 0, TRIG[0] = 0 (observed on the HW, which is correct)

lb_enable_dd = 1, TRIG[0] = clk_fast (observed on the HW, which is correct)

Thanks

Rob

Yes, I understand driving 0 will instantiate a different buffer. I am using that "version" to show that my logic is sound.

Let me put it more simply. If my RTL contains this line in the top level, and TRIG[0] is defined as an output pin on the top-level design.

assign TRIG[0] = (lb_enable_dd) ? clk_fast : 1'bz;

And lb_enable_dd is "1", what would you expect on the output pin TRIG[0]? I think it should be "clk_fast".

And if lb_enable_dd is "0", I would expect Hi-Z? Does that sound correct?

If so, there is a problem in the way Quartus is synthesizing this statement.

I believe you that IO_OBUF has an active low OE input, I see that in the tech view. However, why is there no inverter instantiated by the tools before the OE# input to match the logic defined in the RTL. This is the issue. What I am coding is not what I am getting, and I have confirmed this on the hardware as well.

Hi Rob,

I further think about the problem you mentioned and found out should be no problem with both IO_OBUF primitive and RTL.

IO_OBUF primitive is designed to be active low OE means you have to use '0' instead of '1' to enable output in order to enable the clock.

So when using assign TRIG[0] = (lb_enable_dd) ? clk_fast : 1'bz;, an inverter is automatically added to make the RTL matches the IO_OBUF primitive design setting. If change to assign TRIG[0] = (lb_enable_dd) ? 1'bz : clk_fast;, I guess the inverter will most likely disappear. The problem is IO_OBUF OE part there will change based on which RTL you are using to make sure '0' is used to enable output at last.

If you still insist to use '1' for triggering the clock, I think you have to additionally add a not gate or inverter in front of active low OE manually by yourself. O_OBUF primitive setting will not do that for you.

Thanks.

Best regards,
Sheng

"So when using assign TRIG[0] = (lb_enable_dd) ? clk_fast : 1'bz;, an inverter is automatically added to make the RTL matches the IO_OBUF primitive"

You seem to be missing the point. The tools ARE NOT automatically adding this inverter, that is my whole issue!!!!!

Hi Rob,

Do you have any further update or Should I consider that case to be closed?

Thanks,

Best regards,
Sheng

The problem still persists. The Quartus synthesis is failing to add the required inverter in front of the IO_OBUF to match the logic in my RTL.

Inverting it on my end changes my intended logic (and would still likely be wrong on my end).

The issue appears to be in the tools, not my RTL, so I can't see a way that I can fix this on my end.

Sure. However, can you please be more specific as to which file(s) you want to look at? I want to make sure I provide adequate information to look at.

Or do you mean create a very small project that demonstrates the error? I can do that too, will just take a bit more time.

I made a very simple new project. The same device (AGFB014R24B2E3V). This is the RTL.

module tri_test (

input logic clk1,
input logic clk2,

input logic en1,
input logic en2,

output logic out1,
output logic out2
);

assign out1 = (en1) ? clk1 : 1'bz;
assign out2 = (en2) ? clk2 : 1'b0;

endmodule

You can see that out1 "should" be clk1 if en1 is high, and Hi-Z if en1 is low. You can also see the post-fit Technology Map Viewer shows the polarity implemented is wrong (there is no inverter added to compensate for the active-low OE on the IO_OBUF primitive).

The out2 circuit is the same logic, but without the tri-state (it just outputs 0 if en2 is low).

The whole project folder is now attached.

I am hesitant to simply invert the control to "work around" this bug since all it will take is a newer version of the tools (with the fix in place) and suddenly the polarity of the control signal will be wrong again (at a system level).

If I am the one working on this new version that would be fine, but if it is someone else, they won't necessarily have the historical information to know what is happening.

At this point, I would just like to be kept in the loop on the fixes being made, and what release of the tools will contain the fix. Also, if there is a pre-release patch that becomes available I would like to know about it.

Is there a way to get on a notification list or something?