Forum Discussion

zayjanos's avatar
zayjanos
Icon for New Contributor rankNew Contributor
3 years ago
Solved

Struct type multi-bit port optimized to 1-bit port during mapping

Hello,

I am using Quartus Lite 18.1.

My RTL includes packed struct type ports, e.g.:

input dll_steer_payld_t rx_rts_steer_info;

The type definition for dll_steer_payld_t:

typedef struct packed {
logic [1:0] order;
logic [1:0] prio;
logic [2:0] port_id;
} dll_steer_payld_t;

The port is changed to 1 (or 0?)-bit port as noted in the map report:

; rx_rts_steer_info ; Input ; Warning ; Input port expression (0 bits) is smaller than the input port (7 bits) it drives. Extra input bit(s) "rx_rts_steer_info[0..6]" will be connected to GND. ;

' Extra input bit(s) "rx_rts_steer_info[0..6]" ' is a bit ambiguous. If the port is changed to 1-bit, then there will be 7-1=6 extra bits instead of 7.


Please let me know if it is possible to preserve all bits in the port.

Thanks,
János

  • ShengN_altera's avatar
    ShengN_altera
    3 years ago

    Hi,

    The code is fine. It's just this feature only supported in pro version without warning (check image):

    Same warnings also appear in standard version (check image):

    The synthesis engine of pro version is different compared with standard/lite synthesis engine.

    Thanks,

    Best regards,

    Sheng

    p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 4/5 survey.

6 Replies

  • sstrell's avatar
    sstrell
    Icon for Super Contributor rankSuper Contributor
    3 years ago

    It depends on how you have the signal connected in your design. Can you show what this input is being connected to and confirm that bits aren’t getting optimized away?

    • zayjanos's avatar
      zayjanos
      Icon for New Contributor rankNew Contributor
      3 years ago

      These signals should not be optimized. I am afraid the tool cannot handle struct type ports.

      Please find a simple example attached. You can load the .qpf file in Quartus and run "Compile Design".

      Also attached the map.rpt file that includes the mentioned warnings:

      ; din ; Input ; Warning ; Input port expression (0 bits) is smaller than the input port (2 bits) it drives. Extra input bit(s) "din[1..0]" will be connected to GND. ;
      ; dout ; Output ; Warning ; Output or bidir port (2 bits) is wider than the port expression (0 bits) it drives; bit(s) "dout[1..0]" have no fanouts ;

  • ShengN_altera's avatar
    ShengN_altera
    Icon for Super Contributor rankSuper Contributor
    3 years ago

    Hi,

    The code is fine. It's just this feature only supported in pro version without warning (check image):

    Same warnings also appear in standard version (check image):

    The synthesis engine of pro version is different compared with standard/lite synthesis engine.

    Thanks,

    Best regards,

    Sheng

    p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 4/5 survey.

    • zayjanos's avatar
      zayjanos
      Icon for New Contributor rankNew Contributor
      3 years ago

      Hi Sheng,

      can you please confirm that the netlist created by Quartus Lite/Standard will not be logically equivalent with RTL because of this limitation of the synthesis engine?
      This is just a warning in the map report, but it could be a critical warning or error because the functionality of the circuit is modified by connecting the struct type ports to GND.
      My understanding is that I need to remove struct type ports from the RTL or switch to Quartus Pro to have logically equivalent netlist.

      Thanks,
      János

  • FvM's avatar
    FvM
    Icon for Super Contributor rankSuper Contributor
    3 years ago

    For the posted code example, I see only an inappropriate warning in the mapper report. As the technology map viewer clarifies, the pins are connected correctly. I don't see the claimed relation to synthesis engine capabilities. Besides unsubstantiated warnings, do you see any problems in actual design mapping, may be for a less trivial design?

    I also don't understand the relation to Quartus Pro. There's effectively no choice between Quartus Standard versus Quartus Pro. Some devices need Quartus Pro, for others Quartus Pro isn't provided, e.g. Cyclone V used by the OP, even if you have the license. I know that Quartus Pro has more support for some new VHDL and SV features.