I am working on a design using an Agilex F-series part (AGFB014R24B2E3V) and am having issues with tri-stated outputs. The RTL in question is: assign TRIG[0] = (lb_enable_dd) ? clk_fast : 1'bz; When I test my board, I found it to be inverted. If I set lb_enable_dd high, it was hi-z, low gave me clk_fast on my TRIG[0] output. When I opened the Technology Map View (post-fit) I noticed the IO_OBUF primitive had a inverter on the OE input that didn't seem to be compensated for in compile. Things I have tried: - Tested both 21.2 and 21.3 versions of the tools. - Switching to a non-tristating output. This works as expected, no polarity issues. assign TRIG[0] = (lb_enable_dd) ? clk_fast : 1'b0; - Tried generating the buffer using the GPIO Intel FPGA IP core from the library. trig_out trig_out ( .din ({lb_rxclk_det[0], clk_fast, lb_enable_dd, clk_fast}), .oe ({4{lb_enable_dd}}), .pad_out (TRIG[3:0]) ); Same inverter present on the IO_OBUF. Even when I open the datasheet for that IP core it says OE should be active high. Thoughts?

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,Shengp/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

Hi Rob, In order to be in tri-state mode, you have to drive "hi-Z" instead of "0". Otherwise, it will be switched to a non-tristating output as you say before if you drive "0". Thus, driving "hi-Z" or "0" will result in two different modes. In tri-state mode, IO_OBUF primitive comes originally with active-low OE internal settings. That is the primary internal logic function of IO_OBUF primitive which you cannot simply change it. Btw, you can refer to here https://en.wikipedia.org/wiki/Three-state_logic as well for Three-state logic. (Many devices are controlled by an active-low input called OE (Output Enable) which dictates whether the outputs should be held in a high-impedance state or drive their respective loads (to either 0- or 1-level).) Thanks. Best regards, Sheng

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, Can you provide a sample project with the problem for better viewing? Thanks. Best regards,Sheng

IO_OBUF polarity not matching RTL | Altera Community

24 Replies

ShengN_altera
Super Contributor
3 years ago
Hi Rob,

The internal team feedback is the problem will be planned in version 22.3. You may keep tracking the progress from here https://hsdes.intel.com/appstore/article/#/15010826170

Thanks,
Best regards,
Sheng
nkolme
New Contributor
7 months ago
Hi Sheng,
Can you tell me what the progress is on this issue? The link you provided is no longer valid. As per your last email, the fix was planned for Q22.3 but I can still see incorrect behavior in 22.4.0 Pro Edition. If there is a workaround or a patch, that would be great as I am avoiding upgrading Quartus versions due to other unrelated support issues.
Thanks,
Nadine
- ShengN_altera
  Super Contributor
  6 months ago
  Hi,
  
  Sorry for delay reply,
  
  Engineering had confirmed that the behaviour is correct check below:
  The bubble is to indicate the inversion to compensate for the active low oe port of the obuf. So, what you see in the tech map view is actually correct.
  
  I see the RPI is not set for out1 to invert the core signal to OE. However, we use RBC to set the programmable invert for the OE inside fm_gpio to compensate for OE being active low. So, it should work fine.
  And we also have BCM simulation of a design similar to the sample test design and it is working fine.
  
  set up running BCM simulation for design tri_test.zip.
  Looking at the result, the behaviour of the OE is expected.
  The RTL is:
  assign out1 = (en1) ? clk1 : 1'bz;
  The simulation waveform is:
  You can see when en1 is low, out1 is Z regardless of clk1.
  You can also see when en1 is high, out1 follows clk1.
FvM
Super Contributor
7 months ago
Hi,

in initial post of this thread, it's stated that Quartus is implementing wrong en signal polarity for tri-stated outputs. In following discussion, actual device behaviour is never mentioned, instead only wrong technology map is shown.

I see now that all Quartus versions (Std and Pro), up to most recent have wrong polarity of en port in technology map viewer, as seen below for Quartus Std. 24.1

module tri_test0 ( input logic in1, input logic en1, output logic out1 ); assign out1 = (en1) ? in1 : 1'bz; endmodule
RTL Viewer

Technology Map Viewer

Implemented hardware is however behaving according to RTL description, the fault is only in technology map viewer.

Inverting en1 in code flips all polarities, RTL map and hardware behaviour are still correct, technology map is wrong.
module tri_test0 ( input logic in1, input logic n_en1, output logic out1 ); assign out1 = (!n_en1) ? in1 : 1'bz; endmodule

I have no Agilex 7 board at hand to check if it shows wrong hardware behaviour as claimed in post #1, either with previous or recent Quartus Pro versions.

I feel that Intel should clarify if there actually has been wrong hardware behaviour of tri-state output with Agilex 7 or other devices in any Quartus version. And also if obviously wrong polarity display in technology map viewer is planned to be fixed.

Regards
Frank
- ShengN_altera
  Super Contributor
  6 months ago
  Hi,
  
  Sorry for delay reply,
  
  Engineering had confirmed that the behaviour is correct check below:
  The bubble is to indicate the inversion to compensate for the active low oe port of the obuf. So, what you see in the tech map view is actually correct.
  
  I see the RPI is not set for out1 to invert the core signal to OE. However, we use RBC to set the programmable invert for the OE inside fm_gpio to compensate for OE being active low. So, it should work fine.
  And we also have BCM simulation of a design similar to the sample test design and it is working fine.
  
  set up running BCM simulation for design tri_test.zip.
  Looking at the result, the behaviour of the OE is expected.
  The RTL is:
  assign out1 = (en1) ? clk1 : 1'bz;
  The simulation waveform is:
  
  You can see when en1 is low, out1 is Z regardless of clk1.
  You can also see when en1 is high, out1 follows clk1.
  - FvM
    Super Contributor
    6 months ago
    @ShengN_Intel
    "The bubble is to indicate the inversion to compensate for the active low oe port of the obuf. So, what you see in the tech map view is actually correct."
    Active low port unfortunately isn't indicated in the symbol, otherwise it would be designated nOE, OE# or similar. I see what you mean, but technology map schematic doesn't comply with commonly understood logic symbol presentation, although it's used "since ever" in Quartus. It's prone to misunderstanding as shown by this thread.
    Best regards
    Frank

Forum Discussion

IO_OBUF polarity not matching RTL

24 Replies

Recent Discussions

Timing analysis - long combinational path

QuartusPro 25.3 Crashed after using the Signal Tap Logic Analyzer

Duplicate_hierarchy_depth / duplicate_register

Automatically added negative node for TDS output doesn't work with Agilex 5

Quartus 20.1std compilation fails for Quartus map - Device 10AS057K2F40I1SG