Is there a tool that expands verilog modules as much as it can?
For example:
module and_gate(...);
/* module description ... */
endmodule
module test(...);
and_gate and1(...);
endmodule
In that example I would like the and_gate instance and1 in the test module to expand to the module description with the necessary modifications so that the module would compile (maybe prefix every element with the name of the instance, etc.).
I am not aware of any tool that can do that, because:
The synthesis process already does that: when a module is "called" from within another, that module is actually instantiated. That is, its contents (and the contents of any module that this module "calls" to) are included in the upper module
For simulation, you want meagninful names for your nets and modules so your wave traces are easy to read and your possible mistakes easy to spot. Any tool that mangles net names so nets in simulations don't match nets in your design will give you a lot of headaches
Anyway, I recall that Verilog functions and tasks behave mostly the way you ask. So do modules, but you won't get an updated source code with the expansion performed.
Related
I compiled an old software, where several "system" modules are used all starting with D (DLIB, DWIN, DWINTY, ...). I noticed that on the oneline oneApi manual similar modules starting with the "I" instead of the "D" are illustrated. At first sight it doesn't seem to be much different (the software compiles with DWIN or IWIN). Is a D module the debug version of the respective I module?
A module in the DF* and MSF* series of names is the same as the corresponding module in the IF* series. These names series provide for migrations between the compilers from the different corporate entities.
The source code for those compiler provided modules is provided with your compiler installation (e.g. search the installation tree for IFWINTY.f90). If you inspect the source for the IFWINTY module (just as an example) you will find that it has source for lots of type and constant declarations. DFWINTY and MSFWINTY, on the other hand, just consist of USE IFWINTY (and lots of licence boilerplate).
I come from Java backgrounds and the problem of packaging is as follows then:
I can have many files under the same package, say com.parobay.io. I can then distribute this as a library, and the users will use it like this:
import com.parobay.io.Input;
import com.parobay.io.Output;
or
import com.parobay.io.*; // to import everything
So I can have a single "module (com.parobay.io) and classes defined in multiple files.
So how to I achieve the same in D? Do I have to create a directory com\parobay\io and there place two files called Input.d and Output.d or is there a smarter way?
In Java the rules are very strict, so it's hard to get it wrong. In D there are many possibilities. So are there any conventions, like one class per file, or file name equal to the name of class?
You can choose to do it basically the same as Java, though remember these items:
import foo.* doesn't work in D, but you CAN make a file called package.d in the directory which manually lists public import foo.Input; public import foo.Output; etc. which allows you to import the whole package.
ALWAYS put a module com.parobay.io.Input; or whatever line at the top of any file that is imported. Don't expect it to just work based on directory structure and filename. The directory structure actually isn't strictly necessary, it is just a convention to easily find the file. The module line at the top with the name is the authoritative thing the compiler checks.
D modules often have all lowercase names, but you can use uppercase ones if you like. I think it is nice to use a lowercase name like the class name, so you might call the module io.input and the class Input. The reason for this convention is sometimes filename case gets lost when transferring from system to system. But developers are pretty aware of case so in practice either way should work.
One class per file will work fine or you can put two tightly coupled classes together in the same file (they'll have access to each other's private members if they are in the same file).
See this page for more info: http://dlang.org/module especially search for the heading "Package Module"
Don't use two separate files for your Input and Output classes. Instead, put both classes in a single file, parobay/io.d (corresponding to the module parobay.io).
It's definitely not the convention to limit yourself to just one class per file. D modules are for grouping together code of related functionality. When someone does import parobay.io;, they expect to get all of parobay.io - classes, utility functions and whatever else is relevant. It's similar to Java's import com.parobay.io.*;.
If someone really wants to import specific parts of your module, they can use selective imports:
import parobay.io: Input; // Just the Input class of the parobay.io module.
import parobay.io: Output; // Just the Output class.
import parobay.io: Input, Output; // Just the Input and Output classes.
There are a few additional things to note about this.
Package and module names are conventionally all-lowercase.
It makes everyone's lives easier if the path to the file matches up exactly with its full module name. For example, module foo.bar.baz should be in the file foo/bar/baz.d.
In my experience, it's rare for a D module to be named after a domain name. You can prefix your module names with com or org or net if you really want to, but it's not expected like it is in Java.
Adam D. Ruppe's answer has some great points about explicit module declarations and class member visibility. It's also well worth reading the module and style pages on the official D website.
D community has three widely accepted alternatives.
Write a module named all.d which includes all modules from your package. (Literally '*' --> 'all'). After that you simply do import com.paroboy.io.all;
I see more and more that D developers use _ for this. So they write a module called _.d for this purpose. Similarly to #1, you do import com.paroboy.io._;
Relatively new addition to the D programming language is the package.d module, which can be used to import the package. More about this at the following DIP: http://wiki.dlang.org/DIP37 . If I remember well, DMD supports it since v2.064 . (Documentation: http://dlang.org/module#PackageModule)
I myself use the #1 approach because it is obvious what is going on. While #2 and #3 may be confusing to people reading D source file, especially the third one. A valid question someone may ask: "What the heck am I importing, package?? But import is only for modules!??"
Allthough nothing stops you from having separate module per-class, I would not recommend it. D is truly modular language, so take advantage of that. Group all your types in a single D module. That is my advice, and that is the "D way".
NOTE:
There is a (big) semantic difference between Java "module" and a D module, as you have probably already noticed. I am primarily a Java programmer, so I know how confusing this may be to Java programmers who are playing with D. Java classes in the same package quite often take advantage of the package-level access. However, classes within the same module behave like "friends" in C++.
Speaking about Java modules, they were supposed to come with Java 8 (true modules!), but were posponed and will hopefully be included in Java 9.
UPDATE: We reached conclusion, after a chat on FreeNode (IRC) with some members of the D-Programming-Language, that it is indeed safe now to use the package attribute. It behaves as the specification says.
in two directories I have two different, independent Fortran 90 programs, and I want them to share certain routines that use some variables defined in modules. In other words, I have a directory dirA with program prgA.f90 and a couple of routines in an extra file sub.f90, and these routines use some stuff from a module in the file modA; all of them reside in dirA. In another directory, dirB, I have the independent code prgB.f90 that is supposed to use routines from sub.f90 and hence needs modules that define the stuff needed by it. For technical reasons, I cannot use the modules from modA in dirA directly, but write a variant of it, modB, with the same module name and containing the variables of interest with the same names as in modA as well as other variables only used by prgB. Will the routines from sub.f90 work with modA in the executable of prgA and with modB in the executable of prgB?
I have partly tried to adapt my codes to this, and the compiler seems to accept it somehow, but I'm not sure if it will really work and not produce garbage results in spite of compiling seemingly ok.
Basically the question is this: Can I share functions USEing certain modules between different programs if I ensure that the modules have the same name and have a subset of variables in common, or do the modules USEd by the functions have to be exactly the same for both programs?
Thomas
If I understand correctly then what you are doing is just fine.
When you build progA the compiler encounters, on tackling sub.f90, a statement such as use globals. At that point the compiler will look for a file called globals.mod which it should, by that point, have created by compiling the module source. Of course, that module source need not be in a file called globals.f90 but that's neither here nor there. The module source might, for example, be in a file called globals_for_a.f90.
When you build progB the compiler encounters, on tackling sub.f90, a statement such as use globals. At that point the compiler will look for a file called globals.mod which it should, by that point, have created by compiling the module source. Of course, that module source need not be in a file called globals.f90 but that's neither here nor there. The module source might, for example, be in a file called globals_for_b.f90.
So long as the compilation for each program finds the right source for globals.mod everything should compile as you wish. You've chosen to divide your source files across a number of directories but that's not strictly necessary; a make file with suitably defined targets could build either program or both however you organise the source files and directories.
Note that almost all of this is outside the concern of the Fortran standards, it's more a question of how compilers and compilation work.
I am trying to implement a custom IPCore for the Zedboard. In my User_Logic I am including a component (My_Module) from the VHDL module (My_Module.vhd) which I wrote as part of the ISE project. But when I come to generate the bitstream for my design in PlanAhead it asks for the My_Module.ngc as if it is treating it as a blackbox. I though the NGC was only required when using CoreGen IPCores, but it seems it also wants it for any VHDL module included as I guess this is a 'black box'.
The issue is how do I create a NGC file from the VHDL for this module, which is part of an ISE project. As I can't find any function in ISE that allows you to just generate the netlist for one VHDL module. Or can I export this module out into a separate ISE project and then synthesise it to get the .ngc?
Many thanks
Sam
Are you sure you've typed the module name in exactly the same way both in your module .vhd file, and in the file using the module as a component?
Under normal circumstances, if your project includes the module as a .vhd file, it'll just be synthesized along with the rest of your sources - I did a quick test and renamed a component in one of my own projects, and got a complaint about a possibly missing .ngc file (this was in ISE, and not in PlanAhead though).
So the answer is to generate the NGC files by making the modules you want "the top module" you can then run the synthesis to generate the individual NGC. Then proceed as normal when adding IP to a PCore. So adding these NGC files to the netlist folder and modifying the BBD file and all that!
As a note for completion to get the module working you need to set the synthesis setting "Xilinx Specefic" -> and disable "add io buffers"
Are you including My_Module.vhd as a source file in your ISE Project? If you are, check to see that the ISE project doesn't have a yellow question mark next to the My_Module component. If it does, then it needs more information about that component. You should see a little icon with the letters VHD in it in your ISE Implementation Hierarchy View.
I mean this module : Option
I can't find it, open Option gives me Error: Unbound module Option and there is no 'option.cma' file
Is it in the standard library ? Is it named 'option.cma' ?
This is not part of the OCaml standard library, no. It looks like it might be part of a former library named Extlib. Extlib, in turn, seems to have become part of OCaml Batteries Included. The Option module is now named BatOption.
If you want this module, you should get OCaml Batteries Included. Then you need to tell the OCaml compiler how to find the library. It will be explained in the installation instructions for Batteries.