Port pins missing in Debug net list

[notooth]

I have this module with a 256 bit width port, but I see only 1 bit port in the Debug net list. Can anyone help?

Code: [Select]

module test (
     input              aclk
    ,output reg [255:0] responce_tdata = 0
    );
       
always @(posedge aclk) begin
    responce_tdata <= 256'h1111111111111111111111111111111111111111111111111111111111111111; 
end
     
endmodule

[Someone]

Read the synthesis report (assuming you are adding debug pre-implementation) it will explain why the signal has changed.

[ejeffrey]

Because all 256 bits are the same value (either all 0 or all 1) they have been deduplicated down to a single net.

[BrianHG]

Which Debug net list?
Did you compile in something like Modelsim?  The entire net should be visible.

[ejeffrey]

Ah, I misread that but it doesn't matter.  The zero bits are constant and can be eliminated entirely, only the bits that toggle need to exist at all, and they are all equal.

[notooth]

Read the synthesis report (assuming you are adding debug pre-implementation) it will explain why the signal has changed.

I do not see any info about the signal has changed.

[notooth]

Because all 256 bits are the same value (either all 0 or all 1) they have been deduplicated down to a single net.

Changing the value to 256'hfedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210 did not fix the issue.

[notooth]

Which Debug net list?
Did you compile in something like Modelsim?  The entire net should be visible.

It is Vivado Debug Netlist.

[notooth]

It's probably the =0 at the end of the declaration.

output reg [255:0] responce_tdata = 0
should be
output reg [255:0] responce_tdata

It does not fix the issue.

[ejeffrey]

Because all 256 bits are the same value (either all 0 or all 1) they have been deduplicated down to a single net.

Changing the value to 256'hfedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210 did not fix the issue.

Doesn't matter.  All the bits initialized to zero and then set to zero will be eliminated entirely, all the bits initialized to zero but assigned to one will be combined into a single signal during synthesis. 

Try making a counter.

[ejeffrey]

It's probably the =0 at the end of the declaration.

output reg [255:0] responce_tdata = 0
should be
output reg [255:0] responce_tdata

It does not fix the issue.

To be clear I don't think there is an issue except for your expectation.  The circuit you described only has one bit of unique information and the synthesizer has noted that and produced an equivalent netlist.

[hamster_nz]

Have a look at addint the KEEP and DONT_TOUCH synthesis attributes.

They can ensure that things don't get optimized out.

[notooth]

I used DONT_TOUCH to keep all 256 bits of the port:

Code: [Select]

module test (
     input              aclk
    ,(* dont_touch = "yes" *) output reg [255:0] responce_tdata = 0
    );
       
always @(posedge aclk) begin
    responce_tdata <= 256'h1111111111111111111111111111111111111111111111111111111111111111;
end
     
endmodule
I can see the value 256'h1111111111111111111111111111111111111111111111111111111111111111 in the ILA window, but I got a different value when reading the XDMA c2h port which connected to it.

[hamster_nz]

Sounds like you have a new problem, one where us here have been given zero details.

[Someone]

Sounds like you have a new problem, one where us here have been given zero details.

This huge complex system will work if you spoon feed me the fix for this tiny problem....  wishful thinking.

[ejeffrey]

Sounds like you have a new problem, one where us here have been given zero details.

Or the original problem remains and the optimized out signals were a red herring.  Either way there is no information.