Forum Discussion

FvM's avatar
FvM
Icon for Super Contributor rankSuper Contributor
1 month ago

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

Hello,
I'm trying to build a basic SE to DE converter on Agilex 5

module SEtoDE (
	input 			SE,
	output         DE
);
assign DE = SE;
endmodule

I assign respective IO standards and use locations chosen by Quartus

Resulting in this .qsf assignments

set_global_assignment -name DEVICE A5EC008BM16AE6S
set_location_assignment PIN_AJ24 -to SE -comment IOBANK_5A
set_location_assignment PIN_D13 -to DE -comment IOBANK_3A_B
set_location_assignment PIN_C12 -to "DE(n)" -comment IOBANK_3A_B
set_instance_assignment -name IO_STANDARD "3.3-V LVCMOS" -to SE -entity SEtoDE
set_instance_assignment -name IO_STANDARD "1.3-V TRUE DIFFERENTIAL SIGNALING" -to DE -entity SEtoDE

Compilation on Quartus 25.3.1 however doesn't produce a programming file due to below listed warnings

Critical Warning(25207): A programming file will not be generated because the assembler identified some pins have missing I/O Standard assignments. 
Refer to the I/O Assignment Warnings table in the fitter report for details. 

Critical Warning(15714): Some pins are missing I/O Standard assignments. Refer to the I/O Assignment Warnings report for details. 
+----------------------------------------------------------------------------------------------------------+
; I/O Assignment Warnings                                                                                  ;
+----------+-----------------------------------------------------------------------------------------------+
; Pin Name ; Reason                                                                                        ;
+----------+-----------------------------------------------------------------------------------------------+
; DE       ; Missing termination setting                                                                   ;
; DE(n)    ; Incomplete set of assignments. Missing I/O standard, drive strength and slew rate assignments ;
+----------+-----------------------------------------------------------------------------------------------+

There are essentially two kinds of warnings, both unexpected and only occuring with Agilex 5 (and also Agilex 3). With Agilex 7 or Cyclone 10 GX, the design compiles flawlessly.
1. Warnings for negative pin: Missing I/O standard etc.
2. Missing termination setting

It turns out, that the problem can be fixed by adding an explicit I/O standard for the negative pin, although it shouldn't be required according to Quartus User Manual.

Then the warning level reduces and programming files are generated

Warning(25315): Some pins are missing drive strength (current strength) and/or slew rate assignments. Refer to the I/O Assignment Warnings report for details. 
+----------------------------------------+
; I/O Assignment Warnings                ;
+----------+-----------------------------+
; Pin Name ; Reason                      ;
+----------+-----------------------------+
; DE       ; Missing termination setting ;
; DE(n)    ; Missing termination setting ;
+----------+-----------------------------+

To remove this warning, we also need to assign dummy termination settings to the TDS outputs

set_global_assignment -name DEVICE A5EC008BM16AE6S
set_location_assignment PIN_AJ24 -to SE -comment IOBANK_5A
set_location_assignment PIN_D13 -to DE -comment IOBANK_3A_B
set_location_assignment PIN_C12 -to "DE(n)" -comment IOBANK_3A_B
set_instance_assignment -name IO_STANDARD "3.3-V LVCMOS" -to SE -entity SEtoDE
set_instance_assignment -name IO_STANDARD "1.3-V TRUE DIFFERENTIAL SIGNALING" -to DE -entity SEtoDE
set_instance_assignment -name IO_STANDARD "1.3-V TRUE DIFFERENTIAL SIGNALING" -to "DE(n)" -entity SEtoDE
set_instance_assignment -name OUTPUT_TERMINATION OFF -to "DE(n)" -entity SEtoDE
set_instance_assignment -name OUTPUT_TERMINATION OFF -to DE -entity SEtoDE

Presume this should never happen

Regards
Frank

6 Replies

  • ShengN_altera's avatar
    ShengN_altera
    Icon for Super Contributor rankSuper Contributor

    Hi FvM,

    The current workaround is to add the IOSTD QSF assignment for the DE(n) pin. Will aim to fix it in 26.1.1.

  • FvM's avatar
    FvM
    Icon for Super Contributor rankSuper Contributor

    Hi Sheng,
    I think, the behaviour is almost clear. There's a bug in Agilex 3/5 specific fitter code that causes partial failure of automatic negative node assignment. As a workaround you can assign TDS IO-standard to negative pin explicitely in Assignment Editor or .qsf. Changing your design to Agilex 7 and back to Agilex 5 apparently also adds this assignment, I didn't try.

    However seeing TDS IO-standard in Pin Planner doesn't mean it's actually assigned, must be also present in .qsf, as described in first post.

    I presume the bug can be easily fixed in Quartus.

    Regards

    Frank

    • ShengN_altera's avatar
      ShengN_altera
      Icon for Super Contributor rankSuper Contributor

      Hi Frank,

      I add the I/O standard of negative node pin in .qsf and successfully generate programming file without critical warning.

      I had reflected that to engineering team as well. Will get back to you once any further feedback from them

  • ShengN_altera's avatar
    ShengN_altera
    Icon for Super Contributor rankSuper Contributor

    Hi FvM,

    Previously the inconsistent behaviour observed from my side due to design file corrupt. After new testing, I'm getting constant behaviour.

    Will get back to you once any update on why Agilex 7 don't have critical warning while Agilex 5 got critical warning.

  • ShengN_altera's avatar
    ShengN_altera
    Icon for Super Contributor rankSuper Contributor

    I got the same result as yours.

    I see another weird thing. In the same design, at first Agilex 5 got assembler critical warning. Then in same design, I change to device Agilex 7 and change pin there's no assembler critical warning. After that in same design, I change back to Agilex 5 and change back the pin and clean project, there's no assembler critical warning after compilation.

    Not sure if you see the same thing as mine?

    If yes, I think it's a potential bug