I am trying to use STD_LOGIC in my VHDL code. It will not compile because the STD_LOGIC I am trying to use in the port(.....) section is not working. I know the problem is because I did not import the IEEE library. I tried to import it but I was not successful.
How to import the IEEE library properly to a VHDL program in ModelSim?
To import the package that defines the std_logic type to a VHDL design, add the following two lines to the top of your VHDL file:
library ieee;
use ieee.std_logic_1164.all;
Related
I could declare a package or import a package in Modelica models, but I am not sure if there is any difference between them, I tried the following code, both of them work fine.
My question is :
Is there anything I should pay attention to when using these two methods?
partial model A
package SI1=Modelica.SIunits;
import SI2=Modelica.SIunits;
SI1.Voltage u1;
SI2.Voltage u2;
end A;
You are doing two fundamentally different things here, which both work for this case:
package SI1=Modelica.SIunits; is called a short class definition.
You create a new package named SI1, which inherits everything from Modelica.SIunits.
Short class definitions are basically the same as writing
package SI1
extends Modelica.SIunits;
end SI1;
See chapter 4.5.1 Short Class Definitions in the Modelica spec for details.
import SI2=Modelica.SIunits on the other hand simply influences where the Modelica tool looks for class definitions - so no new class is defined here. The chapter 13.2.1.1 Lookup of Imported Names explains that in the Modelica spec.
If you just want to use the package, import it. That's what import was designed for. Declaring a new package only makes sense if you want to add functionality or change anything (which is very limited though, if you are using the short class definition).
Only the import clause seems to trigger the lookup on a package that is not already loaded. Using for example the Modelica_LinearSystems2 library:
import: it checks, and Modelica_LinearSystems2 is loaded
partial model A
import ls2=Modelica_LinearSystems2;
end A;
package: it checks, but Modelica_LinearSystems2 is not loaded
partial model B
package ls=Modelica_LinearSystems2;
end B;
I guess that can break your models if not all of their dependencies are loaded when trying to simulate.
It is nevertheless interesting to see how Dymola (or even Modelica, since pedantic check doesn't throw any error) does not seem to care much about the use of package instead of import, when it comes to packages already loaded. I wasn't expecting the following model to work:
model C
package SI1=Modelica.SIunits;
SI1.Voltage u1;
parameter SI1.Current R=1;
equation
u1=2*R;
end C;
It turns out that even auto-completion (Ctrl+Space) works:
this is a question for lrm experts. I am trying to find an lrm saying about parsing of v2k lib contents and finding some bits and pieces which contradicts each other. So, here is a schematic example:
library lib1 pkg1.sv, top1.sv, mod1.sv;
library lib2 pkg2.sv, top2.sv, mod2.sv;
pkg1.sv and pkg2.sv
package pkg;
...
endpackage
top1.sv and top2.sv:
module top()
import pkg::*;
mod mod(...);
...
endmodule
mod1.sv and mod2.sv
module mod(...);
...
endmodule
sometop.sv
module sometop();
mod mod1(...);
mod mod2(...);
...
endmodule
config v1;
...
mod1 use lib1.mod;
mod2 use lib2.mod;
endconfig
In the example above same module names and same package names are in multiple libraries. It has been proven that vcs parses the all packages and hierarchies from lib1 for mod1 and from lib2 if for mod2. This is an expected behavior from the consumer point of view.
However,
33.4 A configuration may change the binding of a module, primitive, interface, or program instance, but shall not change the binding of a package.
33.2.1 A library is a named collection of cells. A cell is a design element (see 3.2), such as a module, primitive,interface, program, package, or configuration.
The standards talks a lot of binding cells to the libraries, but I could not find any clause that would dictate that the compiler has to chose hierarchies or packages from the same library.
Can someone explain this behavior from LRM point of view?
There is no contradiction here. Packages must be compiled before they can be imported and they are bound at that time (IEEE 1800-2017 26.3). When you compile lib1 you are binding lib1.pkg with lib2.mod and lib2.pkg with lib1.mod.
The config clause is changing the binding of sometop with lib1.mod or lib2.mod. The packages that these modules were bound to remain unchanged.
After I setup the rocket-chip, it generated example top level Verilog. Can I synthesize the testharness.v module? I manually import the code into vivado, but got syntax error in SimDTM.v
(import "DPI-C" function int debug_tick)
vivado doesn't know what to do with DPI-C
Did I miss some package?
I'm a bit late, but you can't synthesize the testharness. It's used for testing in simulation only. DPI is a simulation-only construct.
I have a tool that produces .sv RAL files for use in a UVM testbench. The problem is that this file creates the register block as a package. My issue is that for my testbench, I want to import multiple .sv RAL files (representing different reg blocks).
To do this, I want to create a single package all_my_regs_pkg.sv and `include the other packages into this package. I get a compilation error and looking into it, it looks like there isn't support for nested packages in SystemVerilog.
So do I need to manually import each of the reg block packages when I want to use them? I suppose I could create a file with the imports and just `include it, but is this the only way?
SystemVerilog does not allow nesting of package declarations. The best thing for you do do is to define a file that is a list of package import statements and have users `include that file where needed.
The is another SV feature that allows you to chain package imports, but you have to explicitly export a symbol that you import into a package to be imported by the next package. See Section 26.6 Exporting imported names from packages in the 1800-2012 LRM
I come with the background in languages like Java or Python where modular programming is enabled by packaging system and import directive (aka namespace aliasing). Historically MATLAB's approach to resolve problems like naming conflicts boils down to setting/playing with MATLABPATH, renaming/extending identifiers with prefixes, etc. So far I have been successfully playing with native MATLAB packaging by prepending plus sign "+" before the folder name (MATLAB notation for package also see here). Obviously they are very long to type ;-) Basically I am back to the similar problem as discussed here with no solution. So let me paraphrased for my particular angle:
Assume I have folder +mypackage defined containing file myfun.m with the function code of the same name.
How to achieve aliasing for MATLAB function inside the user (non-java) package as illustrated by the following python code:
from mypackage import myfun
?
[EDIT] Please note that AFAIK import keyword works only for java classes (with jvm attached to MATLAB process). No, import is working perfectly fine for both functions and aliases for objects and function of both Java and MATLAB origin.
Possibly related but not the same.
[EDIT2]
python's
from mypackage import myfun as anotherfun
is equivalent to MATLAB's
anotherfun = #mypackage.myfun
Doesn't
import mypackage.myfun
work?
link to documentation