svmodule
svmodule copied to clipboard
cclienti
-o, --paste-as-logic not implemented?
It looks like this options is not implemented? Nothing comes out of it when I parse a module like so:
module bin2therm #(
parameter REG_OUTPUT = 0, // Registered output data enable
parameter DIN_WIDTH = 2, // Binary data input width
parameter DOUT_WIDTH = (1<<DIN_WIDTH)-1 // Thermomether data out width
)
(
input clk, // Input clock, only needed if REG_OUTPUTS = 1
input reset_n, // Active low reset, only needed if REG_OUTPUTS = 1
output other_out,
input [DIN_WIDTH-1:0] binin, // Binary data in
output [DOUT_WIDTH-1:0] thermout // Thermomether data out
);
I do
svmodp -c bin2therm.v then svmdop -o, and I get a blank output
I think that was the idea, but it would be awesome to have an output like so:
logic clk;
logic reset_n;
logic other_out;
logic [DIN_WIDTH-1:0] binin;
logic [DOUT_WIDTH-1:0] thermout;
You need to specify the type for the I/O in your module. The parser cannot guess if you want wire/reg/logic ...
module bin2therm #(
parameter REG_OUTPUT = 0, // Registered output data enable
parameter DIN_WIDTH = 2, // Binary data input width
parameter DOUT_WIDTH = (1<<DIN_WIDTH)-1 // Thermomether data out width
)
(
input wire clk, // Input clock, only needed if REG_OUTPUTS = 1
input wire reset_n, // Active low reset, only needed if REG_OUTPUTS = 1
output wire other_out,
input wire [DIN_WIDTH-1:0] binin, // Binary data in
output wire [DOUT_WIDTH-1:0] thermout // Thermomether data out
);
Then $ svmodp -c test.v && svmodp -o:
wire clk;
wire reset_n;
wire other_out;
wire [DIN_WIDTH-1:0] binin;
wire [DOUT_WIDTH-1:0] thermout;
I see, thanks!
It would be nice if the parser could see they are wires, as this is what the ports are when not explicitely defined, as per verilog standard
It is more complex than that. The default type relies on the one declared with the `default_nettype directive.
I personally consider that relying on the default net type is a bad habit. The default_nettype can be changed somewhere in a header included in your design with some strange results some times, especially in verilog with the difference between wire and regs that many people does not understand very well.
The past-as-signal shoud be removed or merge with past-as-logic that does the same.
At the beginning past-as-signal was looking the IO direction to infer the net type (reg or wire). But such behaviour does not work if the user declared another default_nettype.
That is true. But I guess a missing `default_nettype directive equals to a `default_nettype wire? Personally I have never found an issue with relying on the default_nettype of wire. I check the warnings on sims and linting tools so I never had to bore with that directive.
Anyway, what I mean is, if I can simulate my module with these ports, and they are treated as wires, wouldn't it make sense for your parser to treat them as wires? If you do not like messing with the parser, maybe just make the printer to consider them as wires by default, unless told so?
My perspective on this is that I want to generate a long list of signals declarations to hook up the instances of my modules. I actually do not care too much if they are generated as wire or logic as long as it works without the need to add wire to each of the ports on my modules (which many times you can't modify as they are IP blocks...)
Looks like we answered pretty much at the same time!
Commenting on this now:
The past-as-signal shoud be removed or merge with past-as-logic that does the same.
Yes, I agree. Maybe you could add an extra argument so the ports can be declared as wires or logic. (plain verilog vs SV)? Something like -o wire or -o logic ?
Thanks!