链接已复制
yes, I used this struct:
typedef struct packed {
logic clk;
logic rst;
logic de;
logic hsync;
logic vsync;
} hdmi_if_s;
here are the declared signals:
hdmi_if_s hdmi_rx_if;
hdmi_if_s hdmi_tx0_if;
hdmi_if_s hdmi_tx1_if;
here are the signal assignments:
assign hdmi_rx_if.rst = reset;
assign hdmi_rx_if.clk = hdmi_rx_vid_clk;
assign hdmi_rx_if.de = hdmi_rx_de;
assign hdmi_rx_if.hsync = hdmi_rx_hsync;
assign hdmi_rx_if.vsync = hdmi_rx_vsync;
assign hdmi_tx0_if.rst = reset;
assign hdmi_tx0_if.clk = hdmi_tx0_vid_clk;
assign hdmi_tx0_if.de = hdmi_tx0_de;
assign hdmi_tx0_if.hsync = hdmi_tx0_hsync;
assign hdmi_tx0_if.vsync = hdmi_tx0_vsync;
assign hdmi_tx1_if.rst = reset;
assign hdmi_tx1_if.clk = hdmi_tx_vid_clk;
assign hdmi_tx1_if.de = hdmi_tx_de;
assign hdmi_tx1_if.hsync = hdmi_tx_hsync;
assign hdmi_tx1_if.vsync = hdmi_tx_vsync;
In SignalTap, I searched for the signals with the "SignalTap: pre-synthesis" option, but they did not appear there ...
yes, I searched for "*hdmi*" and yes I performed the Analysis & Elaboration stage previously
Do you able to get the result you wanted by following sstrell's suggestion in tapping the right hand side signals?
Best Regards,
Richard Tan
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.
yes, the right-hand signals could be tapped... but the struct itself cann't ...
no, the issue is still open... The signals, which have been declared as structs, could not be seen by SignalTap ...
I don't understand. You can tap the exact signals that are in your struct, so why is it still an issue that you can't tap the struct itself? The signals are physical. The struct is for organizing in the code with no specific relation to the hardware.
If you go into the Technology Map Viewer, I will bet you will not see the struct names there either, further confirming they are not physical. Signal Tap can only tap actual signals.
"why is it still an issue that you can't tap the struct itself" - I don't know why... this is why I'm asking
Here is a simple example - the struct named 'ab' could not be seen/tapped in the 'top' hierarchy by SignalTap (only signals i0 and i1 could be tapped/seen):
////////////////////////////////////////////////////////////////////////////////////////////////////
package pkg;
typedef struct packed {
logic a;
logic b;
} ab_s;
endpackage
////////////////////////////////////////////////////////////////////////////////////////////////////
module top
import pkg::*;
(
input i0,
input i1
);
ab_s ab;
assign ab.a = i0;
assign ab.b = i1;
sub sub_i (
.ab (ab),
.out()
);
endmodule
////////////////////////////////////////////////////////////////////////////////////////////////////
module sub
import pkg::*;
(
input ab_s ab,
output logic out
);
assign out = ab.a^ab.b;
endmodule
But inside of the 'sub' hierarchy, the signals ab.a and ab.b could be tapped/seen by the SignalTap.
Based on your example, I can only guess that physical signal names normally take priority (i0 and i1 are identical to ab.a and ab.b, respectively), but across a hierarchical boundary, if there is no physical signal name, the tool uses the struct because it has no choice. Try adding wires and assign statements inside sub to test this theory.
