Related
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 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.
I am trying to find if an inout port is used as an input port or as an output port during simulation from my PLI based C-code. How can it be done?
Before you go down this path, note that most tools have capabilities to give you this information with Extended VCD files or in other formats usually associated with power estimation tools.
Doing this withe the VPI requires extensive knowledge of the §38 VPI routines and §36 VPI object model diagrams in the 1800-2012 LRM. I can give you an outline of what needs to be done:
For each inout port
Register a cbValueChange callback using vpi_register_cb
Build a list of drivers using the diagram §37.16 Nets
Classify each driver as being outside the module (HiConn) or inside (local or LoConn)
The callback routine needs to scan the list of drivers for the port that changed value
If the active driver is outside the module, the port is in input mode.
If the active driver is inside the module, the port is in output mode.
In many UNIX TCP implementations, a socket option TCP_CORK is provided which allows the caller to bypass Nagle's algorithm and explicitly specify when to send a physical packet. Is there an equivalent feature in Windows (Winsock)?
TCP_CORK (since Linux 2.2)
If set, don't send out partial frames. All queued partial frames are sent when the option is cleared again. This is useful for prepending headers before calling sendfile(2), or for throughput optimization. As currently implemented, there is a 200 millisecond ceiling on the time for which output is corked by TCP_CORK. If this ceiling is reached, then queued data is automatically transmitted. This option can be combined with TCP_NODELAY only since Linux 2.5.71. This option should not be used in code intended to be portable.
(I'm aware of TCP_NODELAY, but this isn't what I need; I still want multiple writes to be accumulated in the send buffer, and then trigger the TCP stack when I'm ready for it to send a physical packet.)
FWIW I successfully use TCP_NODELAY to get TCP_CORK-style behavior. I do it like this:
unset the TCP_NODELAY flag on the socket
Call send() zero or more times to add your outgoing data into the Nagle-queue
set the TCP_NODELAY flag on the socket
call send() with the number-of-bytes argument set to zero, to force an immediate send of the Nagle-queued data
That works fine for me under Windows, MacOS/X, and Linux. (Note that under Linux the final zero-byte send() isn't necessary)
There is no equivalent. The best you can do is gather your data pieces into your own buffer first, and then send the completed buffer to the socket when ready, and let Nagle handle the packets normally.
I just read this in "Operating System Concepts" from Silberschatz, p. 18:
A bit, called the mode bit, is added to the hardware of the computer
to indicate the current mode: kernel(0) or user(1). With the mode bit,
we are able to distinguish between a task that is executed on behalf
of the operating system and one that is executed on behalf of the
user.
Where is the mode bit stored?
(Is it a register in the CPU? Can you read the mode bit? As far as I understand it, the CPU has to be able to read the mode bit. How does it know which program gets mode bit 0? Do programs with a special adress get mode bit 0? Who does set the mode bit / how is it set?)
Please note that your question depends highly on the CPU itselt; though it's uncommon you might come across certain processors where this concept of user-level/kernel-level does not even exist.
The cs register has another important function: it includes a 2-bit
field that specifies the Current Privilege Level (CPL) of the CPU. The
value 0 denotes the highest privilege level, while the value 3 denotes
the lowest one. Linux uses only levels 0 and 3, which are respectively
called Kernel Mode and User Mode.
(Taken from "Understanding the Linux Kernel 3e", section 2.2.1)
Also note, this depends on the CPU as you can clearly see and it'll change from one to another but the concept, generally, holds.
Who sets it? Typically, the kernel/cpu and a user-process cannot change it but let me explain something here.
**This is an over-simplification, do not take it as it is**
Let's assume that the kernel is loaded and the first application has just started(the first shell), the kernel loads everything for this application to start, sets the bit in the cs register(if you are running x86) and then jumps to the code of the Shell process.
The shell will continue to execute all of its instructions in this context, if the process contains some privileged instruction, the cpu will fetch it and won't execute it; it'll give an exception(hardware exception) that tells the kernel someone tried to execute a privileged instruction and here the kernel code handles the job(CPU sets the cs to kernel mode and jumps to some known-location to handle this type of errors(maybe terminating the process, maybe something else).
So how can a process do something privileged? Talking to a certain device for instance?
Here comes the System Calls; the kernel will do this job for you.
What happens is the following:
You set what you want in a certain place(For instance you set that you want to access a file, the file location is x, you are accessing for reading etc) in some registers(the kernel documentation will let you know about this) and then(on x86) you will call int0x80 instruction.
This interrupts the CPU, stops your work, sets the mode to kernel mode, jumps the IP register to some known-location that has the code which serves file-IO requests and moves from there.
Once your data is ready, the kernel will set this data in a place you can access(memory location, register; it depends on the CPU/Kernel/what you requested), sets the cs flag to user-mode and jumps back to your instruction next to the it int 0x80 instruction.
Finally, this happens whenever a switch happens, the kernel gets notified something happened so the CPU terminates your current instruction, changes the CPU status and jumps to where the code that handles this thing; the process explained above, roughly speaking, applies to how a switch between kernel mode and user-mode happens.
It's a CPU register. It's only accessible if you're already in kernel mode.
The details of how it gets set depend on the CPU design. In most common hardware, it gets set automatically when executing a special opcode that's used to perform system calls. However, there are other architectures where certain memory pages may have a flag set that indicates that they are "gateways" to the kernel -- calling a function on these pages sets the kernel mode bit.
These days it's given other names such as Supervisor Mode or a protection ring.