How to add compile option for ModelSim using VUnit? - vhdl

Using ModelSim and VUnit I try to compile some UVVM, but this gives some warnings like:
** Warning: C:\work\Qtec\SVN_sim\Design\uvvm\uvvm_util\src\methods_pkg.vhd(1159): (vcom-1346) Default expression of interface object is not globally static.
So I would like to suppress these warnings, so I tried updating the VUnit "run.py" file with add_compile_option based on VUnit Python Interface:
uvvm_util = prj.add_library('uvvm_util')
uvvm_util.add_source_files(join(root, '../../uvvm/uvvm_util/src/*.vhd'))
uvvm_util.add_compile_option('modelsim.vcom_flags', ['-suppress 1346'])
But when compiling, I then get the error:
Compiling ....\uvvm\uvvm_util\src\types_pkg.vhd into uvvm_util ...
** Error (suppressible): (vcom-1902) Option "-suppress 1346" is either unknown, requires an argument, or was given with a bad argument.

You could edit the suppress entry in the modelsim.ini file. source
It could be a python/TCL error with spaces. See this link.
So the space between -suppress and 1346 is not properly forwarded.
The VUnit ui.py shows
modelsim.vcom_flags
Extra arguments passed to ModelSim vcom command.
Must be a list of strings.
I cannot test it, but this case the line should possibly be:
uvvm_util.add_compile_option('modelsim.vcom_flags', ['-suppress', '1346'])
edit: after some reading... To me the difference between add_compile_option and set_compile_option is not clear. Maybe you could try the other?

Related

Where should I start to debug when Make throws a particular error

My knowledge of Make is small. I have been told that everything you put after make (that does not contain "-") is a target.
Well a building process I have is failing.
First there is a line
make path/to/configuration_file
configuration_file is not a target. It is a autogenerated configuration file buried inside the directory structure ("path/to") that is of the form
#
# Boot Configuration
#
#
# DRAM Component
#
CONFIG_DRAM_TYPE_LPDDR4=y
# CONFIG_DRAM_TYPE_DDR4 is not set
CONFIG_DDR_SIZE=0x80000000
#
# Boot Device
#
# CONFIG_ENABLE_EMMC_BOOT is not set
# CONFIG_ENABLE_NAND_BOOT is not set
CONFIG_ENABLE_SPINAND_BOOT=y
# CONFIG_ENABLE_SPINOR_BOOT is not set
CONFIG_EMMC_ACCESS_8BIT=y
# CONFIG_EMMC_ACCESS_4BIT is not set
# CONFIG_EMMC_ACCESS_1BIT is not set
so I cannot understand how this is a target. For reference, when I run make there is a Makefile but this Makefile does not reference this file.
Still this line is going well.
The path where it fails says
make diags
and I have verified there is no "diags" target.
I will print here the error file that can give us more info of what is happening
GEN cortex_a/output/Makefile
Init diag test "orc_scheduler" ...
remoteconfig: Failed to generate configure in cortex_a/soc/visio/tests/orc_scheduler!
Makefile:11 recipe for target 'orc_scheduler-init' failed
make[10]: *** [orc_scheduler-init] Error 25
At least what I would like to know is how to interpret this error message. I don't know what the "11" or the "10" or the "25" refers to.
make is fundamentally a tool for automatically running commands in the right order so you don't have to type them in yourself. So all the commands make runs are commands that you could just type into your shell prompt. And all the errors that those commands generate are the same ones that you would see if you typed the command yourself. So, looking at make to try to understand those errors is looking in the wrong place: you have to look at the documentation for whatever command was invoked.
A "target" is just a file that make knows how to build. The fact that when you typed make <somefile> is didn't give you an error that it doesn't know how to build <somefile>, means that <somefile> is a target as far as your makefiles are concerned.
The error message Makefile:11: simply refers to the filename Makefile, line 11, which is where the command that make ran, that failed, can be found. But this likely won't help you solve the problem of why the command failed (unless the problem is you invoked it with the wrong arguments and you need to adjust the makefile to specify different arguments).
The command that failed generated the message:
remoteconfig: Failed to generate configure in cortex_a/soc/visio/tests/orc_scheduler!
I don't know what that means, but it's not related to make. You'll need to find out what this remoteconfig command is, what it does, and why it failed. It's unfortunate that it doesn't show any better error message as to why it failed to "generate configure", but again there's nothing make can do about that.
If you want to learn more about make you can look at the GNU make manual (note, GNU make is only one implementation of make; there are others and they are fundamentally the same but different in details).

Autoconf: check struct member type

I am new to autoconf so I would ask you how could I check if a struct member is declared with a particular type.
For example I should check if struct posix_acl.a_refcount is declared as refcount_t and not atomic_t.
I know AC functions as ac_fn_c_check_decl and ac_fn_c_check_member, but none that accomplish this task.
Thank you!
Disclaimer: As there are no other answers at the time this answer is being written, this represents my best attempt to provide a solution, but you may need to adjust things to make it work for you. Caveat emptor.
You would need to use the AC_COMPILE_IFELSE macro with code that uses atomic_t, and if the compilation succeeds, then you're using atomic_t. As future-proofing, you might also add a test for refcount_t if the atomic_t test fails.
Example:
# _POSIX_ACL_REFCOUNT_T(type-to-check)
# ------------------------------------
# Checks whether the Linux kernel's `struct posix_acl'
# type uses `type-to-check' for its `a_refcount' member.
# Sets the shell variable `posix_acl_refcount_type' to
# `type-to-check' if that type is used, else the shell
# variable remains unset.
m4_define([_POSIX_ACL_REFCOUNT_T], [
AC_REQUIRE([AC_PROG_CC])
AC_MSG_CHECKING([whether struct posix_acl uses $1 for refcounts])
AC_COMPILE_IFELSE(
[AC_LANG_SOURCE(
[#include <uapi/../linux/posix_acl.h>
struct posix_acl acl;
$1 v = acl.a_refcount;]
)],
[AC_MSG_RESULT([yes])
AS_VAR_SET([posix_acl_refcount_type], [$1])],
[AC_MSG_RESULT([no])
)
])
_POSIX_ACL_REFCOUNT_T([atomic_t])
# If posix_acl_refcount_type isn't set, see if it works with refcount_t.
AS_VAR_SET_IF([posix_acl_refcount_type],
[],
[_POSIX_ACL_REFCOUNT_T([refcount_t])]
)
dnl
dnl Add future AS_VAR_SET_IF tests as shown above for the refcount type
dnl before the AS_VAR_SET_IF below, if necessary.
dnl
AS_VAR_SET_IF([posix_acl_refcount_type],
[],
[AC_MSG_FAILURE([struct posix_acl uses an unrecognized type for refcounts])]
)
AC_DEFINE([POSIX_ACL_REFCOUNT_T], [$posix_acl_refcount_type],
[The type used for the a_refcount member of the Linux kernel's posix_acl struct.])
The tests assume that you already have a variable containing the kernel source directory, and the kernel source's include directory is specified in CPPFLAGS or CFLAGS prior to attempting the tests. You can add more tests at the position indicated, and if the resulting posix_acl_refcount_type shell variable is still not defined after all those tests, then the final AS_VAR_SET_IF invocation will invoke AC_MSG_FAILURE to stop configure with the specified error message.
Note that I used <uapi/../linux/posix_acl.h> to specifically target the kernel's linux/posix_acl.h header rather than the userspace API uapi/linux/posix_acl.h header installed in a system's include directory with the uapi/ stripped off, which may result in the compile tests above failing due to the missing struct posix_acl in the userspace API. This may not work the way I'd expect and may need modification.

Trying to compile with make on Windows gives error 127

this is the very first time that I try to compile anything in Windows and it already gives me the creeps (not because of Windows that is).
I downloaded a dictionary from here:
https://www.j3e.de/ispell/igerman98/dict/igerman98-20161207.tar.bz2
When I extract the folder then there is a Makefile, so I think that I have to compile the progrmam first. I tried that with two methods: first Cygwin, second MinGW. Both programs are in my PATH.
I use the terminal of both programs to navigate to D:/igerman98 and there I enter
make
The first message I get is:
$ make
A default make target doesn't exist. You might want to use one of those:
make hunspell/de_DE.dic hunspell/de_DE.aff (or de_AT or de_CH)
make myspell/de_DE.dic myspell/de_DE.aff (or de_AT or de_CH)
make ispell/de_DE.aff ispell/de_DE.hash (or de_AT, de_CH ...)
make aspell/de_DE.rws (or de_AT, de_CH ...)
make ligature/rmligs
make isowordlist-de_DE (or de_AT, de_CH ...)
Did I forget an important one ?-)
So I enter again the following:
make hunspell/de_DE.dic hunspell/de_DE.aff
But then I get the following error:
$ make hunspell/de_DE.dic hunspell/de_DE.aff
test -e all.words.placebo.tmp || echo a > all.words.placebo.tmp
buildhash all.words.placebo.tmp ispell/de_DE_null.aff ispell/de_DE_null.hash
make: buildhash: Command not found
make: *** [ispell/de_DE_null.hash] Error 127
What am I doing wrong here? I just want de_DE.dic and de_DE.aff files to be created so I can use them with the spelling module in Textadept...
Under Linux, the program buildhash comes with the ispell-package. Under Windows, you can use: ISPELL for Windwos

Usage of build:haddock-arguments option of stack.yaml

How do you pass options to stack haddock from stack.yaml? I cannot find any clue to correct syntax neither in documentation nor in stack source code.
Documentation describes the following:
build:
haddock-arguments: ""
Naive haddock-arguments: "--odir=./docs" fails with type error:
…failed to parse field 'haddock-arguments': expected HaddockOptsMonoid, encountered String
I figured out that it expects it to be like:
build:
haddock-arguments:
odir: "./docs"
However it fails with error Unrecognized field in HaddockOptsMonoid: odir.
What is correct syntax of passing arguments from haddock manual to stack via stack.yaml? In my specific case, I want specify custom output directory.
After looking at the source I figured out that the syntax is
build:
haddock-arguments:
haddock-args:
- "--odir=./docs"
In a sample project this has the following result (notice the location of the docs directory deep down in .stack-work):
$ ls .stack-work/install/x86_64-linux/lts-6.3/7.10.3/doc/docs/ | cat
doc-index.html
frames.html
haddock-util.js
hslogo-16.png
index-frames.html
index.html
minus.gif
ocean.css
plus.gif
synopsis.png
The links in index.html are broken, so I'm slightly pessimistic that you can achieve what you want by passing arguments to haddock in this way.

CMake - what does this OPTION command do?

I'm getting into CMake and have some trouble with the syntax of it. I was wondering if any of you could tell me what the following command does exactly:
OPTION(USE_OPENGL "Use OpenGL" FOUND_OPENGL)
As far as I can tell, it will Default OPENGL to ON if it is found. Is that correct?
This command provides an option to the user to change a specific aspect of your build system. The syntax is explained in the documentation:
option(<option_variable> "help string describing option"
[initial value])
In your specific case, it will create an option called USE_OPENGL which should have the default value from the FOUND_OPENGL variable. So the default will probably be the same as the result of an automatic check whether opengl is available. However, the syntax is actually wrong in the example you give. It should be:
OPTION(USE_OPENGL "Use OpenGL" ${FOUND_OPENGL})
Options are specifically available through the ccmake command or the cmake gui. Here, the given documentation string will be available to the user. After the user has decided on the option, you can use the the variable given as the first argument like any other boolean variable in CMake. E.g.:
IF(USE_OPENGL)
MESSAGE(STATUS "Will us OpenGL")
ENDIF()

Resources