I have a question on `default_nettype directive of SystemVerilog.
By default, the following code is ok.
module m1 (
input logic i1,
output logic o1
);
logic l1;
assign l1 = i1;
assign o1 = l1;
endmodule
However, when I change the default net type to none:
`default_nettype none
only i1 causes an error:
ERROR: [VRFC 10-1103] net type must be explicitly specified for i1 when default_nettype is none ...
My question is why only input logic i1 causes an error and requires explicit wire, but output logic o1 and logic l1 does not.
Verilog has too many implicit rules to accommodate lazy programmers (i.e. people who were interested in designing hardware, not writing software)
This error is explained in section 23.2.2.3 Rules for determining port kind, data type, and direction
For the first port in an ANSI style port list:
If the port kind is omitted:
For input and inout ports, the port shall default to a net of default net type. The default net type can be changed using the
`default_nettype compiler directive
This implicit 'net' port rule is the opposite of what is used when declaring output ports, and all other declarations outside of ports. The reason behind this is that input ports are an overwhelmingly majority of ports used in a module, and keeping ports connections as wires allows for port collapsing, which is more efficient for simulation.
This is the confusing part of SystemVerilog. Your code works on my simulator, that outputs a warning instead of an error.
If you dive enough in help messages you get that the "type" of the identifier (as in net versus var, opposing to "datatype" which is logic or whatever else) is context sensitive, and specifically input ports are by default nets, while output ports are by default variables. This means that with "default_nettype none" all your input ports are effectively not fully described, because the compiler does not know the resolution function for the net (you might want a wand, for example). Your output ports, being variables, need no resolution function and so no error is thrown there.
Since you cannot really connect the same port to more than one signal unless you really try to this seems redundant to me, but it might be needed due to net coercion rules for elaboration if the input net is driven by more than one assign elsewhere in the design.
My understanding is that "default_nettype none" is mostly used to ensure you do not have undeclared identifiers (leading to width mismatch due to single bit inference) and a port is declared, so you might check if your tool has the option of inferring a wire for ports anyway (again, my simulator outputs a warning and does this by default, and the synthesizer does not complain either).
Other than that, the only workaround I see is going for "default_nettype none" first thing after the ANSI port declaration and "default_nettype wire" last thing before endmodule, in every module.
We cannot do that, as per 1800-2017 22.8:
The directive `default_nettype controls the net type created for implicit net declarations (see 6.10). It can be used only outside design elements.
The reference for implicit net declaration is section 6.10 in IEEE 1800-2017, although following the mentioned sections from there seems to point to non-ANSI declarations only... you might need a deeper dive to fully understand the matter.
Related
I know how to link modules but could someone explain the flow of calling the modules to be used when I want it to be used.
Like have a state machine and depending on the state I can call a module to activate, or like if I need to repeat a process how to go back to a module earlier in a state machine.
again I get the instantiating part like this
wire clk;
wire sig;
wire out;
A a(clk, sig, topout);
B b(clk, sig);
endmodule
but can someone explain how to call modules and how the control flow works in general for them?
(I am new to HDLs so I appreciate any help)
Verilog is a language specifically developed to simulate behavior of hardware. Hardware is a set of transistors and other elements which always statically presented and function in parallel. Functioning of such elements could be enabled or disabled, but the hardware is still present.
Verilog is similar to the hardware in the sense that all its elements are always present, intended for parallel functioning.
The basic functional elements of Verilog are gates, primitives and procedural blocks (i.e., always blocks). Those blocks are connected by wires.
All those elements are then grouped in modules. Modules are used to create logical partitioning of the hardware mode. They cannot be 'called'. They can be instantiated in a hierarchical manner to describe a logical structure of the model. They cannot be instantiated conditionally since they represent pieces of hardware. Different module instances are connected via wires to express hierarchical connectivity between lower-level elements.
There is one exception however, the contents of an always block is pure software. It describes an algorithmic behavior of it and as such, software flow constructs are allowed inside always block (specific considerations must be used to make it synthesizable).
As it comes to simulation, Verilog implements an event-driven simulation mode which is intended to mimic parallel execution of hardware. In other words, a Verilog low level primitive (gate or always block) is executed only if at least one of its inputs changes.
The only flow control which is usually used in such models is a sequence of input events and clocks. The latter are used to synchronize results of multiple parallel operations and to organize pipes or other sequential functions.
As I mentioned before, hardware elements can be enabled/disabled by different methods, so the only further control you can use by implementing such methods in your hardware description. For example, all hardware inside a particular module can be turned off by disabling clock signal which the module uses. There could be specific enable/disable signals on wires or in registers, and so on.
Now to your question: your code defines hierarchical instantiation of a couple of modules.
module top(out);
output wire out;
wire clk;
wire sig;
A a(clk, sig, out);
B b(clk, sig);
endmodule
Module 'top' (missing in your example) contains instances of two other modules, A and B. A and B are module definitions. They are instantiated as corresponding instances 'a' and 'b'. The instances are connected by signals 'clk', which is probably a clock signal, some signal 'sig' which is probably an output of one of the modules and input in another. 'out' is output of module top, which is probably connected to another module or an element in a higher level of hierarchy, not shown here.
The flow control in some sense is defined by the input/output relation between modules 'A' and 'B'. For example:
module A(input clk, input sig, output out);
assign out = sig;
...
endmodule
module B(input clk, output sig);
always#(posedge clk) sig <= some-new-value;
...
endmodule
However, in general it is defined by the input/output relation of the internal elements inside module (always blocks in the above example). input/output at the module port level is mostly used for semantic checking.
In the event-driven simulation it does not matter hardware of which module is executed first. However as soon as the value of the 'sig' changes in always#(posedge clk) of module 'B', simulation will cause hardware in module 'A' (the assign statement to be evaluated (or re-evaluated). This is the only way you can express a sequence in the flow at this level. Same as in hardware.
If you are like me you are looking at Verilog with the background of a software programmer. Confident in the idea that a program executes linearly. You think of ordered execution. Line 1 before line 2...
Verilog at its heart wants to execute all the lines simultaneously. All the time.
This is a very parallel way to program and until you get it, you will struggle to think the right way about it. It is not how normal software works. (I recall it took me weeks to get my head around it.)
You can prefix blocks of simultaneous execution with conditions, which are saying execute the lines in this block when the condition is true. All the time the condition is true. One class of such conditions is the rising edge of a clock: always #(posedge clk). Using this leads to a block of code that execute once every time the clk ticks (up).
Modules are not like subroutines. They are more like C macros - they effectively inline blocks of code where you place them. These blocks of code execute all the time any conditions that apply to them are true. Typically you conditionalize the internals of a module on the state of the module arguments (or internal register state). It is the connectivity of the modules through the shared arguments that ensures the logic of a system works together.
In the documentation it is indicated, that cardinality() function is deprecated and should no longer be used. However, it is still used in the libraries such as ThermoSysPro.
e.g.
if (cardinality(C) == 0) then
some code
end if;
where C is FluidInlet or FluidOutlet
Could anyone give a simple example of how it could be replaced?
The usual solution is to make the connector conditional, and if enabled you require that it is connected.
For physical connectors you can see how heatports and support is handled in:
Modelica.Electrical.Analog.Interfaces.ConditionalHeatPort
Modelica.Mechanics.Rotational.Interfaces.PartialElementaryOneFlangeAndSupport2
For control signals you can see how p_in, h_in etc are handled in
Modelica.Fluid.Sources.Boundary_pT
Modelica.Fluid.Sources.Boundary_ph
However, the connectors of ThermoSysPro belong in neither of those categories and that should ideally also be cleaned up.
The only thing I know, that could be used in this regard, is the connectorSizing annotation. It is described in the MLS chapter 18.7.
It is used a number of times in the Modelica Standard Library, e.g. in Modelica.Blocks.Math.MinMax via the parameter nu. When using it, the tool automatically sets the modifier for nu according to the number of connections to it.
parameter Integer nu(min=0) = 0 "Number of input connections"
annotation (Dialog(connectorSizing=true));
Modelica.Blocks.Interfaces.RealVectorInput u[nu];
In the example below, nu=2 is generated by Dymola automatically when creating a connection in the graphical layer. I have removed the graphical annotations, to make the code more readable.
model ExCS
Modelica.Blocks.Math.MinMax minMax(nu=2);
Modelica.Blocks.Sources.Sine sine(freqHz=6.28);
Modelica.Blocks.Sources.Constant const(k=0.5);
equation
connect(sine.y, minMax.u[1]);
connect(const.y, minMax.u[2]);
end ExCS;
The cardinality() operator is used in Modelica.Fluid.Sources.BaseClasses.PartialSource, and in a similar way in other fluid libraries (IBSPA, AixLib, Buildings, BuildingSystems and IDEAS), in the form
// Only one connection allowed to a port to avoid unwanted ideal mixing
for i in 1:nPorts loop
assert(cardinality(ports[i]) <= 1,"
each ports[i] of boundary shall at most be connected to one component.
If two or more connections are present, ideal mixing takes
place with these connections, which is usually not the intention
of the modeller. Increase nPorts to add an additional port.
");
end for;
I occasionally had models from users who somehow ended up with more than one connection to a ports[i]. How this happened was not clear, but I find the use of cardinality() useful to catch such situations, which otherwise can yield to mixing in the fluid port which the user did not intent and which are hard to detect.
I have a testbench declared as
module test_circuit
logic a,b,c;
logic y;
circuit UUT (.*); //what does this line mean?
initial begin
//something here
end
endmodule
I haven't found any tutorials which tell me what it means. I have looked at the language reference manual and it says it is a 'wildcard pattern', but doesn't go into enough detail.
Otherwise... it is difficult to search special character in any search engine, and results which I found seem to only be related to other languages.
It is actually described pretty extensively in the SystemVerilog LRM. Take a look at Section 23.3.2.4 Connecting module instances using wildcard named port connections (.*). Quoting the first part of this section:
SystemVerilog can implicitly instantiate ports using a .* wildcard syntax for all ports where the instance port name matches the connecting port name and their data types are equivalent. This eliminates the requirement to list any port where the name and type of the connecting declaration match the name and equivalent type of the instance port.
To reflect this onto your example: assume the module circuit has the ports a, b, y, and d.
You could connect them fully explicit as described in Section 23.3.2.2 in the LRM. This is necessary if the names or widths do not match:
circuit UUT
(.a (a),
.b (b),
.c (c),
.y (y));
You could also use implicit named port connections (Section 23.3.2.3 of the LRM):
circuit UUT
(.a,
.b,
.c,
.y);
However, the quickest way if you do not want to type out all ports is to make sure the names and types of the signals match through the hierarchy. Then, you can simply use wildcard named port connections:
circuit UUT
(.*);
Please keep in mind that this last method may make it hard to debug your RTL, since it becomes harder trace signals at a high level.
Bonus: In addition to the LRM, take a look at Sutherland & Mills paper Synthesizing SystemVerilog - Busting the Myth that SystemVerilog is only for Verification. Section 7 gives a great summary on the different types of port connections and on the advantages of dot-name and dot-star connections.
In addition to Silicon1602's answer, you can also do this, which means that variable aa is connected to port a and every other port is connected to variables of the same name:
circuit UUT
(.a(aa),
.*);
I have a module that is instantiated many times in other modules. Two of the inputs to this module are used very rarely, and to avoid code bloat I don't want to have to connect them in every instantiation. Is there a way to mark these two ports to the compiler to indicate they can be left unconnected?
eg.
module mymod(input logic foo, unused1, unused2, output logic out);
//...
endmodule
module top(...);
//...
mymod(.foo(1'b0));
endmodule
will not compile due to port mismatch errors. How can I change the code so unused1 and unused2 don't need to be connected?
Yes, you can specify a default value for a unconnected port (See 23.2.2.4 Default port values in the 1800-2017 LRM)
module mymod(input logic foo, unused1='0, unused2='0, output logic out);
//...
endmodule
Another option is to explicitly leave these ports unconnected when instantiating.
mymod(.foo(1'b0), .unused1(), .unused2() );
But in either case, your tool may have specific requirements with unconnected ports that you will have to deal with as they ask you to do.
I defined an interface in system verilog and use bind statement to bind to internal RTL signals. I want to be able to force internal RTL signals through the interface. However, this is causing the RTL signal to go to 'x' if I don't force these signals explicitly, it seems bind to interface is having driving capability. I don't want RTL signal to change to 'x' when nothing is forcing it in this case, not sure what I am doing wrong here?
my code looks like this with DUT being the design:
interface myInf(
inout RTL_a,
inout RTL_b
);
bind DUT myInf myInf_inst(
.RTL_a(DUT.a),
.RTL_b(DUT.b)
);
bind DUT myDrv(myInf_inst);
where myDrv is a module which drives the ports on myInf.
In this case, DUT.a and DUT.b are internal RTL signals, they have their driver from design, but I want to be able to force them if needed. however, these signals becoming 'x' when I am just binding them to myInf without actually driving them.
The inout signals might be a non-net type. It is better to be explicit in the the declaration and define them as inout wire. Inside the interface, assign the nets to a logic and initialize the logics to z. A non-z value will apply a driver while a z will allow signals to drive. Example:
interface myInf(
inout wire RTL_a,
inout wire RTL_b
);
logic drv_a, drv_b;
initial {drv_a,drv_b} = 'z; // z means not driving
assign RTL_a = drv_a;
assign RTL_b = drv_b;
endinterface
There might be conflicting drivers, such as the normal drivers from the design. In this case you will need to override the driver. Assuming the signal being overrode is a net type, this is done by changing the assign statements to assign (supply1,suppl0) RTL_a = drv_a;. This is utilizing the Verilog concept of drive strength. Assigning to z will still all other drivers. Most nets are driven with a strength of strong1,strong0 which is weaker then supply1,supply0. Drive strength will not work for non-net types (e.g. logic & reg). These register/variable-types use a last-assignment-wins approach. Fore more on drive strength read IEEE Std 1800-2012 sections 28.11 through 28.15
Your sample code has some bugs. The pin connections for myInf_inst should use hierarchical references relative to its target scope. Unless there is an instance called DUT inside module DUT, then the DUT. should be omitted (See IEEE Std 1800-2012 ยง 23.11 Binding auxiliary code to scopes or instances). The bind statement for myDrv is missing an instance name. The code should be:
bind DUT myInf myInf_inst(
.RTL_a(a), // no DUT.
.RTL_b(b) // no DUT.
);
bind DUT myDrv myDrv_inst(myInf_inst);
sample code: http://www.edaplayground.com/x/2NG