Bus index reversal when SystemVerilog module instantiates a BDF in Quartus Prime Pro 21.2

Thanks! Yes, I tried all of those combinations that you suggested. Using a wire and concatenating results in the same reversed connections:

module top
(
   input logic clk,
   input logic [3:0] x,
   output logic [7:0] y
);

wire [7:0] x_in;
assign x_in = {x, 4'b0};

bdftest bdf_i
(
   .clk(clk),
   .x_in(x_in),
   .y_out(y)
);

endmodule

As does using a register:

module top
(
   input logic clk,
   input logic [3:0] x,
   output logic [7:0] y
);

logic [7:0] x_in;
always @(posedge clk)
   x_in <= {x, 4'b0};

bdftest bdf_i
(
   .clk(clk),
   .x_in(x_in),
   .y_out(y)
);
endmodule

As well as a register with explicit indexes in the assignment and instantiation:

module top
(
   input logic clk,
   input logic [3:0] x,
   output logic [7:0] y
);
logic [7:0] x_in;
always @(posedge clk)
begin
   x_in[7:4] <= x;
   x_in[3:0] <= 4'b0;
end

bdftest bdf_i
(
   .clk(clk),
   .x_in(x_in[7:0]),
   .y_out(y)
);
endmodule

And finally, same results with a wire and explicit assignment/instantiation:

module top
(
   input logic clk,
   input logic [3:0] x,
   output logic [7:0] y
);

wire [7:0] x_in;
assign x_in[7:4] = x;
assign x_in[3:0] = 4'b0;

bdftest bdf_i
(
   .clk(clk),
   .x_in(x_in[7:0]),
   .y_out(y)
);
endmodule

Thanks. Yeah, I inherited these old schematics and we have been steadily converting the simpler ones to SystemVerilog. The remaining one is big and thoroughly tested, so it hasn't been migrated yet...

I gave your suggestion a try and converted the module to straight Verilog (top.v):

module top
(
    input wire clk,
    input wire [3:0] x,
    output wire [7:0] y
);
wire [7:0] x_in;
assign x_in[7:4] = x;
assign x_in[3:0] = 4'b0;

bdftest bdf_i
(
    .clk(clk),
    .x_in(x_in[7:0]),
    .y_out(y)
);
endmodule

The results were the same:

This is indeed strange!

Sorry to drag you into this insanity as well : -)

Hmm. That little-endian vector sure may be a clue to what's going on. Also interesting with the generated RTL that you posted is that y_out is assigned x_in inputs in the correct order there: y_out[7] <= x_in[7].

I disconnected the CLRN and PRN signals from the flip-flop:

The synthesized result still has connections reversed:

Also, the schematic from my actual design has a number of inputs and outputs that aren't being fed to simple registers and those connections are reversed, too.

I appreciate your taking a look at this!

Paul

I agree with your sentiment about these schematics, and I can't wait to be completely rid of them. I don't think there are any extra wire bits in the .bdf. I opened it in Quartus II 9.1 SP2--that's all I have installed that can generate BDF->HDL--and generated a Verilog HDL file for it. Quartus 9.1 created a compact, correct representation for it:

// PROGRAM		"Quartus II"
// VERSION		"Version 9.1 Build 350 03/24/2010 Service Pack 2 SJ Full Version"
// CREATED		"Tue Aug 31 08:30:37 2021"

module bdftest(
    clk,
    x_in,
    y_out
);

input	clk;
input	[7:0] x_in;
output	[7:0] y_out;
reg	[7:0] y_out;

always@(posedge clk)
begin
    begin
    y_out[7:0] = x_in[7:0];
    end
end

endmodule

If I instantiate that in my Quartus Prime Pro 21.2 project instead of the .bdf, I get a correct instantiation:

If I instantiate that same .bdf rather than the generated verilog file in my v21.2 project, I get reversed connections. One gotcha I ran into was that regardless of the files listed in the project, the generated HDL file would get picked up for synthesis rather than the BDF if it was left in the project directory.

Are you suggesting that as the workaround: generate the HDL for the .bdf from an old version of Quartus and use that in the project? I can give that a try.

Thanks,

Paul

Edit: attached the .bdf. Had to add a .txt extension to get the forum software to allow me to attach. This is further proof these schematic files are antiquated: you can't even post them to the forum as-is!

Thanks. We opted to create a Verilog wrapper that bit-reverses all inputs and outputs to the schematic module, which should get us by for now.

I appreciate all of your help. It would be great if Intel would acknowledge this is a bug in the software and maybe even fix it...

Regards,

Paul