Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
15461 Discussions

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

pnp
Novice
654 Views

I have a legacy BDF that I need to use in a current design. Using Quartus Prime Pro v20.4 or v21.2, I see the bus indexes reversed on the port connections when the BDF diagram is instantiated from within a SystemVerilog module. This same practice in Quartus II worked without the unexpected index reversal.

Here's a toy example that illustrates the problem. I've attached the full project below.

BDF:

bdf2.png

Top-level:

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

bdftest bdf_i
(
  .clk(clk),
  .x_in({x, 4'b0}), // Indexes [3:0] should be 0
  .y_out(y)
);
endmodule

The RTL netlist viewer shows:

pnp_0-1630003879157.png

Looking at the properties for bdf_i:

pnp_1-1630003956922.png

The connections are reversed!  This worked as expected in Quartus II v9.1. While not a big issue in this toy example, it is a problem for my module when MSBs and LSBs are reversed.

Any ideas how to fix this behavior rather than manually bit reversing all the inputs and outputs?

 

Thanks,

Paul

0 Kudos
1 Solution
sstrell
Honored Contributor III
505 Views

Yeah, I'd just convert to HDL and use that if you have more complex designs causing this issue.  Just save yourself the time and effort trying to fix the schematics.

View solution in original post

10 Replies
sstrell
Honored Contributor III
612 Views

Weird.  Have you tried explicitly specifying [3:0] in the instantiation or creating a wire to perform the concatenation outside of the instantiation?

pnp
Novice
610 Views

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

 

pnp_0-1630083883694.png

 

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

pnp_3-1630084700863.png

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

pnp_4-1630085063267.png

 

sstrell
Honored Contributor III
556 Views

Wow, that is really weird!  On the off off chance this is SystemVerilog related, can you try a plain .v file instead of .sv?

 

This is why I don't use schematics anymore!

pnp
Novice
554 Views

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

pnp_1-1630343840808.png

The results were the same:

pnp_0-1630343776564.png

This is indeed strange!

sstrell
Honored Contributor III
545 Views

Because this was driving me crazy, I finally downloaded your design and opened it in Standard so I could generate an HDL file from the .bdf (a feature that for some reason is not available in Pro).  I think the issue is that VCC above the register is connected to the preset  and reset inputs of the register.  If you have both preset and clear pulled up to Vcc, synthesis has to account for both control inputs.  Obviously, there is no way for either input to go low, but synthesis is trying to account for that possibility so the tool synthesizes an 8-bit bus wire and sets its value to 1 (instead of 0xff strangely).  This bus wire also is little endian instead of big endian and this explains the strangeness you are seeing.  Normally you would just leave these inputs unconnected if you were not using them.

I'm not sure if this is a bug or what, but I'm attaching the HDL code from your schematic and also the code when I disconnected VCC from the PRN input but left it connected to the CLRN input, which is almost as strange.

pnp
Novice
540 Views

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:

pnp_0-1630358199867.png

The synthesized result still has connections reversed:

pnp_1-1630358544809.png

pnp_2-1630358582097.png

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

sstrell
Honored Contributor III
532 Views

When I disconnected from both PRN and CLRN, the code for the register was correct.  See attached.  Maybe something else is going on for you.  Check to make sure there aren't any little wire segments hidden behind the register in the schematic.  Any little connection can cause an issue.  It's why I'm not a fan of the schematic editor.  Or maybe that's not the standard DFF primitive which would just throw everything out of whack (though you say this happens even without a register).  I'm not sure what's going on then.

pnp
Novice
512 Views

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:

pnp_0-1630425781022.png

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!

sstrell
Honored Contributor III
506 Views

Yeah, I'd just convert to HDL and use that if you have more complex designs causing this issue.  Just save yourself the time and effort trying to fix the schematics.

pnp
Novice
497 Views

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

Reply