I'm trying to automate compiling my Aldec block designs using the VSimSA shell instead of using the Aldec GUI. Currently, I am able to get the following command to work in the GUI console with the desired results (producing a converting a .bde file to a .vhd file in the compile directory as well as using the VHDL compiler on the .vhd file).
'''
acom -w -O3 -e 100 -work gen8_ieee -2008 -d <path to compile directory> -s <path to library.cfg> -j <path to projlib.cfg> <BDE file path>
'''
When issuing the same command in the VSimSA shell, I receive the following error. This error occurs for multiple lines in the bde file. If I run the same command in VSimSA on a .vhd file, it compiles with no issues.
*Error: COMP96_0010: <BDE file path> : (12, 36) : Invalid literal.*
Line 12 in the BDE file :
#DEFAULT_RANGE0="<range<index=\"0\"><name=\"bist_cctrl\"><left=\"bcw-1\"><direction=\"downto\"><right=\"0\"><initial_value=\"\"><delay=\"\">>"
Is there another command that needs to be issued first to convert the BDE file to a VHDL file prior to running the 'acom' command? The help documentation states the 'acom' command works with BDE files.
Related
erlc -I <abspath-to-include-dir> <module>.erl on the command line correctly compiles <module>
But in the Erlang shell (erl), the following produces errors with "cannot find include file":
c(<module>, [{i, <abspath-to-include-dir>}]).
Why? Shouldn't the behavior of these two ways of compiling files be the same?
Try writing the path as a list of directories, as in {i, [".../here/", ".../there/"]}, even if it's just a single directory.
Hi I am using gcov (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51)
When I run gcov I am getting errors like "cannot open graph file". (My gcno and gcda file are created with name as abc.pic.gcda and abc.pic.gcno). But when I rename these files by removing "pic" (abc.gcda and abc.gcno) gcov is working fine. My question is: how to make gcov to read the files which are named like abc.pic.gcda and abc.pic.gcno?
Looks like you have file like abc.pic.cpp
and when you compile it
$ g++ --coverage abc.pic.cpp
$ ls
abc.pic.cpp abc.pic.gcno a.out
File abc.pic.gcno is created as you see. Next run binary
$ ./a.out
$ ls
abc.pic.cpp abc.pic.gcda abc.pic.gcno a.out
And run gcov:
$ gcov abc.pic
abc.gcno:cannot open graph file
$ gcov abc
abc.gcno:cannot open graph file
As you can see there is an error. To make it working you should provide full filename like
$ gcov abc.pic.cpp
File 'abc.pic.cpp'
Lines executed:100.00% of 6
abc.pic.cpp:creating 'abc.pic.cpp.gcov'
At first I take the message sample.gcda:stamp mismatch with graph file
the order of compilation and running is observed
hexdump -e '"%x\n"' -s8 -n4 sample.gcno -> aaa1aaaa
hexdump -e '"%x\n"' -s8 -n4 sample.gcda -> bbb2bbbb
stamp mismatch with graph file
Means that graph file has been compiled again after binaries built.
If the compilation order is correct, you could try to check if there is a compilation of the sample.cpp twice somewhere in building rules.
For example we have something like that:
g++ ... sample.cpp -o sample
g++ ... -shared sample.cpp -o sample2.o
So one file is compiled twice. It will cause that gcno file will be updated by new timestamp that will not match to gcda file anymore.
If you performed your product or application testing thoroughly and manually and spent lot of effort on it. If your objective is to get code coverage report using lcov and gcov but by mistake deleted gcno files. You can regenerate gcno files by recompiling the code but it will be generated with new timestamp and gcov reports error saying "stamp mismatch with graph file" and no code coverage report will be generated. This will result in all your testing effort getting wasted.
There is a shortcut to still generate the code coverage report. This is just a workaround and should not be relied upon all the time. Its recommended to preserve *.gcno files till your testing completes.
Note down your gcc version(gcc -v) and download its source code from one of the mirror sites
Eg - ftp://gd.tuwien.ac.at/gnu/sourceware/gcc/releases/gcc-4.4.6/gcc-4.4.6.tar.bz2
After extracting downloaded file, gcc the folder structure will be as follows
gcc-4.4.6
gcc-4.4.6/gcc
If you directly go inside gcc-4.4.6/gcc and try to do ./configure and compile(make) from there then you will encounter below problem
build/genmodes -h > tmp-modes.h
/bin/sh: build/genmodes: No such file or directory
Solution is do ./configure and make from gcc-4.4.6 and no errors will be shown related to genmodes. This will compile all modules including gcc. You may have to install mpfr and gmp modules which are needed by gcc if any error shown by ./configure
goto gcc-4.4.6/gcc/gcov.c and comment below lines and then recompile with above command
/* if (tag != bbg_stamp)
{
fnotice (stderr, "%s:stamp mismatch with graph file\n", da_file_name);
goto cleanup;
}*/
Example path of new gcov binary after compilation is gcc-4.4.6/host-x86_64-unknown-linux-gnu/gcc/gcov
Place this binary in /usr/bin and regenerate code coverage report with command as shown in below example
lcov --capture --directory ./ --output-file coverage.info ; genhtml coverage.info --output-directory /var/www/html/coverage
Now you should not get "stamp mismatch with graph file" error and you will get code coverage report properly
I downloaded and installed win32 yaws-1.98 installer for my win7 and tried to start it from windows command prompt with: yaws -i. the result I got is just as right below. where I have placed # was a simicolon.
Failed to create the process entirely.
Tried to invoke: erl.exe -pa "C:/Program Files/Yaws-1.98/ebin" -conf "C:\Program Files\Yaws-1.98\yaws.conf" -run yaws -yaws id default #
Make sure you have erl in your environment PATH
after some research, I placed the following paths in the O.S environment variables list separated by semicolon, first under the name ERL_LIBS and then PATH all with no change :
C:\Program Files\erl5.10.3\erts-5.10.3\bin
C:\Program Files\erl5.10.3\bin
what could I be missing
...s.b help.
After reading article found at https://www.dartlang.org/articles/web-ui/tools.html, I tried to compile my application by following it.
My application stored in web/app.html can be successfully compiled to Javascript under DartEditor by using "Run as Javascript" command.
When I try to use following command lines to perform a compilation for deploying in production, I encounter an issue on uncopied package part file.
$ dart --package-root=packages/ packages/web_ui/dwc.dart --out /tmp/dart/ --no-rewrite-urls web/app.html
$ ls lib/app/
model_browser.dart model_server.dart
$ ls lib/app/src/model/
model_browser.dart model_server.dart model_shared.dart
$ cd /tmp/dart
$ dart2js -v app.html_bootstrap.dart --package-root=packages/ -oapp.html_bootstrap.dart.js
...
info: scanning library file:///private/tmp/dart/_from_packages/bm/model_browser.dart
_from_packages/app/model_browser.dart:12:1: Error: Cannot read "_from_packages/app/src/model/model_shared.dart" (OS Error: No such file or directory, errno = 2).
part 'src/model/model_shared.dart';
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
info: Error: compiler cancelled: Error: Cannot read "_from_packages/app/src/model/model_shared.dart" (OS Error: No such file or directory, errno = 2).
...
$ ls _from_packages/app/
model_browser.dart model_browser.dart.map
$ ls _from_packages/app/src/model/
model_browser.dart model_browser.dart.map
In fact, "model_shared.dart" file isn't copied into /tmp/dart/_from_packages/app/src/model/model_shared.dart.
The content of model_browser.dart is following
library model;
import 'dart:json' as json;
import 'package:bm/i18n.dart' as i18n;
import 'package:logging/logging.dart';
import 'package:web_ui/web_ui.dart';
part 'src/model/model_shared.dart';
part 'src/model/model_browser.dart';
DartEditor can launch my application as Javascript. What is the right command line for launching dart2js in order to take into account the "part" statements of my "model" library ?
The issue is linked to "--no-rewrite-urls" option and the absolute path in --out option.
If I remove the "--no-rewrite-urls" option and put a relative path in --out option, the dart2js compilation is successfully done.