- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
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:
Looking at the properties for bdf_i:
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Weird. Have you tried explicitly specifying [3:0] in the instantiation or creating a wire to perform the concatenation outside of the instantiation?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page