irun, ncverilog does not determine header file - verilog

irun does not determine define.h file. When I use irun like this
irun -f xxx.f
I've got a error message like this.
irun: E.FMUK the type of the file m_def.h could not be determined.
Above file is consist of all 'define xxxx. How can I solve this problem?

You can use irun commnad line option - vlog_ext to add new file extensions to irun.
Add extensions to the list of built-in, predefined extensions by using a plus sign ( + ) before the list of extensions to add. For example, the following option adds .rtl and .vh.
-vlog_ext +.rtl,.vh

Rename m_def.h to m_def.vh (or m_def.v).
The .h file extension is for C/C++ header files. Verilog header files more often use the .vh extension; if not then .v. SystemVerilog header files should use .svh extension.
Many Verilog/SystemVerilog simulators allow overriding/extending the accepted file extension type. Refer to the manual for the specific simulator. Note that some simulator except C/C++, Verilog, SystemVerilog, VHDL, and others. It is recommended not to add the file extension to one language that is already being used by another.
In this case .h is already used with C/C++, so don't add .h to the allowed Verilog/SystemVerilog file extension. If .vh is not supported by default, you may add it to the allowed Verilog file extension list.

Related

How to get plain text files in Doxygen documentation?

I cannot include any text file in my Doxygen documentation. The only exception is a README.md file that I set as the main page.
In particular, I would like to see the Changelog.txt file in the documentation. I tried to add it explicitly in the INPUT field and in the FILE_PATTERNS field, without success. In the generated HTML documentation, I cannot find anything neither in the file list nor making a search.
The only trace is in Doxygen's log file:
Preprocessing C:/Source/Changelog.txt...
Parsing file C:/Source/Changelog.txt...
...
Parsing code for file Changelog.txt...
If I change the extension of the file from txt to md, the file is added to the documentation.
You need EXTENSION_MAPPING=txt=md otherwise the .txt file is handled as a C / C++ source file and it is missing comment signs, resulting in no output.
From the documentation:
EXTENSION_MAPPING Doxygen selects the parser to use depending on the
extension of the files it parses. With this tag you can assign which
parser to use for a given extension. Doxygen has a built-in mapping,
but you can override or extend it using this tag. The format is
ext=language, where ext is a file extension, and language is one of
the parsers supported by doxygen: IDL, Java, Javascript, C#, C, C++,
D, PHP, Objective-C, Python, Fortran (fixed format Fortran:
FortranFixed, free formatted Fortran: FortranFree, unknown formatted
Fortran: Fortran. In the later case the parser tries to guess whether
the code is fixed or free formatted code, this is the default for
Fortran type files), VHDL. For instance to make doxygen treat .inc
files as Fortran files (default is PHP), and .f files as C (default is
Fortran), use: inc=Fortran f=C. Note: For files without extension you
can use no_extension as a placeholder. Note that for custom extensions
you also need to set FILE_PATTERNS otherwise the files are not read by
doxygen.

Why there are verilog verification files not in the form of module?

Why are there Verilog verification files not in the form of a module?
The files I see start with just initial begin, and some file names use the .inc extension.
It is common to include files of arbitrary content into Verilog modules. This is done using the `include compiler directive, as described in IEEE Std 1800-2012, section "22.4 `include":
The file inclusion (include) compiler directive is used to insert the
entire contents of a source file in another file during compilation.
The result is as though the contents of the included source file
appear in place of the `include compiler directive.
It can be useful for sharing common code between different modules: parameters, define macros, tasks, functions, etc.
In general, the .inc file extension is not special. It may be a convention used by certain simulation tools.

Finding the default project settings file

I'm trying to write a plugin for 3ds max, I went through the entire sdk installation process to the letter as described in the help files.
The problem I'm facing though is intellisence complaining about an invalid macro definition
"IntelliSense: command-line error: invalid macro definition:_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES_COUNT =1"
I found the definition in project settigs -> c/c++ -> preprocessor definitions as inherited from parent or project default.
I tried disabling the inherited definitions and re-entered them, this time without the space between the name and the = and all works fine so I'm guessing its a typo on their part?
Anyway, I want to change the default project or whatever to not repeat it every time i start a new project. The project is created with a wizard which required me to copy over some files to appear and after which I had to enter the sdk path.
The files I copied are plain text with some fancy extensions and not much in them so I'm guessing the defaults are described in the sdk directory.. somewhere. Does anybody know what kind of a file I'm looking for?
EDIT: I found a file called root.vcxproj_template and it has a section for preprocessor definitions but all it contains is
<PreprocessorDefinitions>_USRDLL;%(PreprocessorDefinitions)</PreprocessorDefinitions>
and no mention of the broken one
EDIT2: in another part of the file there was a path to a property sheet (maxsdk\ProjectSettings\propertySheets\3dsmax.common.tools.settings) which included the faulty definition. I fixed it an no more complaints from VS.
_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES_COUNT = 1 means that compiler should replace all old C run-time routines such as sprintf, strcpy, strtok with new versions such as strprintf_s, strcpy_s, strtok_s and similar. It goes in pair with following definition _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES = 1.
More you can find here: (MSDN) https://msdn.microsoft.com/en-us/library/ms175759.aspx. However I tried to use this but without success. It says that you can use this only for statically allocated buffers like char buffer[32], but compilers was still complaining bout unsecure strcpy.

When are `include directives not needed in Verilog and SystemVerilog?

Suppose I have a top level file that I pass to my compiler that has:
`include "my_defines.sv"
`include "my_component.sv"
Inside "my_component.sv" file, I am using some defines from "my_defines.sv", like this:
my_variable = `CONSTANT_FROM_MY_DEFINES;
The question is the following: do I need to have `include "my_defines.sv" inside "my_component.sv"? Perhaps this requirement is compiler-specific?
If your "my_defines.sv" has an "include" guard, then it is safe and better to include "my_defines.sv" in all your other files. The "include" guard at the top of "my_defines.sv" will look like this:
`ifndef MY_DEFINES_SV
`define MY_DEFINES_SV
// put your own defines here ...
`endif
include directives like that are like copying and pasting that file into the point where the include is. The compiler:
Reads the file you give it.
When it encounters an include, it reads that file.
When it's finished that file it continues the original file.
The result is that the compiler sees one big flat file.
In your example you can use stuff from my_defines in my_component because it appears earlier.
The problem with doing a lot of this is that eventually you'll end up with conflicts. Maybe two things reference each other (which include comes first), two things use the same name (clashing definitions), or multiple things have the same include statement (multiple definitions of the same thing).
Packages solve those problems. Once things start getting a little more complex, look into them.
It is dependent upon the order in which your source files are compiled. Because you are referring specifically todefine macros, which are global, it is required that the macro definitions are compiled before the macro is used. In your case, you do not need to include "my_defines.sv" inside "my_component.sv" since "my_defines.sv" was already compiled in your top file.
Macro definitions only persist across files but only to the end of the translation unit. Simulators must support two different methods of assigning source files to translation units and it's hard to get `include files full of `defines to compile correctly in both methods.
It is better use parameters or const variables for constants. Since parameters and constants follow normal scoping rules you can safely include them in every file/scope that needs them. Then it doesn't matter how the code is broken into translation units, it always compiles. I think it is easier to find the definitions when you're browsing the code because the `include is probably in the same file instead of off in some other unrelated file.
you have to include `include "my_defines.sv in my_component.sv...
best practice is add all include in one pkg and add that pkg to each of file.

Is there a way to tell whether code is now being compiled as part of a PCH?

I need to branch a certain statement in a precompiled-header .h file, based on whether the .h is now being used to create the PCH (i.e., included in a cpp compiled with /Yc), or now included just to use the PCH (i.e., included in a cpp compiled with /Yu).
In other words, I'm looking for something like -
#ifdef NOW_CREATING_THE_PCH
#import yadayada_with_option_a
#else
#import yadayada_with_option_b
#endif
...and can't find anything.
Any ideas would be appreciated!
Thanks,
-Ofek
[Edit:] The reason I need this is that I use Incredibuild, and have started getting this warning. Per the FAQ suggestion, I wish to #import with no_implementation during PCH creation, and with implementation_only during PCH usage.
You can specifically change the configuration (in Visual Studio) of stdafx.cpp (or whatever source file you have that gets compiled with /Yc) to define the symbol NOW_CREATING_THE_PCH, leaving the symbol undefined for the rest of the source files (which get compiled with /Yu).
That's not something you get out-of-the-box, but if you need to do it just for one project (or a few), it's not a problem.
While this is not a direct answer to your question, the simplest way of solving this problem is to use the #import statement with no_implementation in the header file which is used to generate the precompiled header (usually StdAfx.h) and re-#import the header file into the source file that is used to trigger the generation of the pch with the parameter implementation_only. That way the implementation of the wrapper functions are being defined, but only in one place.

Resources