I am compiling the below system verilog code in Active-HDL9.1 simulator. When compile i get this error
Error: VCP2000 tb_hutil.sv : (35, 15): Syntax error. Unexpected token: integer[_INTEGER]. Expected tokens: 'constraint'.
package hutil_pkg;
`define DATE "June_2012"
`ifdef TBID
`else
`define TBID "rapidio2_testbench"
`endif
`ifdef AUTHOR
`else
`define AUTHOR "ALTERA"
`endif
`define INFO 32'h00000001
`define DEBUG 32'h00000002
`define WARNING 32'h00000004
`define FAILURE 32'h00000008
static integer err_cnt; //Line no.35 //error on this line
I don't understand this error and no idea whether the problem is with system verilog syntax or tool issues.
In the posted example an endpackage is missing. Also you could use `ifndef for you if not defined statments.
Example below compiles on EDA Playground:
package hutil_pkg;
`define DATE "June_2012"
`ifndef TBID
`define TBID "rapidio2_testbench"
`endif
`ifndef AUTHOR
`define AUTHOR "ALTERA"
`endif
`define INFO 32'h00000001
`define DEBUG 32'h00000002
`define WARNING 32'h00000004
`define FAILURE 32'h00000008
static integer err_cnt;
endpackage
Related
I wrote c-shared library using go.
package main
import "C"
import "log"
//export RunLib
func RunLib() {
log.Println("Call RunLib")
}
func init() {
log.Println("Call init")
}
func main() {
log.Println("Call main")
}
I created the library using this command:
go build -buildmode=c-shared -o lib.so lib.go
To use the library, I wrote this golang code.
package main
/*
#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>
static void callFromLib() {
void (*fn)();
void *h = dlopen("lib.so", RTLD_LAZY);
if (!h) {
fprintf(stderr, "Error: %s\n", dlerror());
return;
}
*(void**)(&fn) = dlsym(h, "RunLib");
if (!fn) {
fprintf(stderr, "Error: %s\n", dlerror());
dlclose(h);
return;
}
fn();
dlclose(h);
}
*/
import "C"
func main() {
C.callFromLib()
}
If I run the last code it throws this error (go run call.go):
fatal error: bad sweepgen in refill
goroutine 1 [running, locked to thread]:
runtime.throw({0xb990782, 0xc000042a38})
/usr/local/go/src/runtime/panic.go:1198 +0x71 fp=0xc000042a18 sp=0xc0000429e8 pc=0xb930691
runtime.(*mcache).refill(0x41215b8, 0x2)
/usr/local/go/src/runtime/mcache.go:156 +0x24e fp=0xc000042a68 sp=0xc000042a18 pc=0xb91434e
runtime.(*mcache).nextFree(0x41215b8, 0x2)
/usr/local/go/src/runtime/malloc.go:880 +0x85 fp=0xc000042ab0 sp=0xc000042a68 pc=0xb90ba85
runtime.mallocgc(0x8, 0xb9ba300, 0x1)
/usr/local/go/src/runtime/malloc.go:1071 +0x4e8 fp=0xc000042b30 sp=0xc000042ab0 pc=0xb90c108
runtime.growslice(0xb9ba300, {0x0, 0x41a1910, 0x2}, 0xc00009c000)
/usr/local/go/src/runtime/slice.go:267 +0x4ea fp=0xc000042b98 sp=0xc000042b30 pc=0xb94586a
sync.(*Pool).pinSlow(0xba394e0)
/usr/local/go/src/sync/pool.go:223 +0x105 fp=0xc000042c30 sp=0xc000042b98 pc=0xb960ec5
sync.(*Pool).pin(0xba394e0)
/usr/local/go/src/sync/pool.go:206 +0x4e fp=0xc000042c48 sp=0xc000042c30 pc=0xb960d8e
sync.(*Pool).Get(0xba394e0)
/usr/local/go/src/sync/pool.go:128 +0x25 fp=0xc000042c80 sp=0xc000042c48 pc=0xb960ac5
fmt.newPrinter()
/usr/local/go/src/fmt/print.go:137 +0x25 fp=0xc000042ca8 sp=0xc000042c80 pc=0xb985d45
fmt.Sprintln({0xc000042d38, 0x1, 0x1})
/usr/local/go/src/fmt/print.go:280 +0x28 fp=0xc000042cf0 sp=0xc000042ca8 pc=0xb986008
log.Println({0xc000042d38, 0x24, 0x0})
/usr/local/go/src/log/log.go:329 +0x1e fp=0xc000042d20 sp=0xc000042cf0 pc=0xb98cd5e
main.RunLib(...)
/Users/.../demo/lib.go:8
_cgoexp_6b951f94a90e_RunLib(0xc000042d90)
_cgo_gotypes.go:36 +0x45 fp=0xc000042d58 sp=0xc000042d20 pc=0xb98cf85
runtime.cgocallbackg1(0xb98cf40, 0xc000042e60, 0x0)
/usr/local/go/src/runtime/cgocall.go:306 +0x29a fp=0xc000042e28 sp=0xc000042d58 pc=0xb903d1a
runtime.cgocallbackg(0xc0000001a0, 0x300000002, 0xc0000001a0)
/usr/local/go/src/runtime/cgocall.go:232 +0x109 fp=0xc000042eb8 sp=0xc000042e28 pc=0xb9039e9
runtime.cgocallbackg(0xb98cf40, 0x7ffeefbff737, 0x0)
<autogenerated>:1 +0x2f fp=0xc000042ee0 sp=0xc000042eb8 pc=0xb95e32f
runtime: unexpected return pc for runtime.cgocallback called from 0x4053e00
stack: frame={sp:0xc000042ee0, fp:0xc000042f08} stack=[0xc000042000,0xc000043000)
0x000000c000042de0: 0x000000c000042d9d 0x000000c000042e18
0x000000c000042df0: 0x000000000b95843b <runtime.exitsyscall+0x00000000000000fb> 0x000000c0000001a0
0x000000c000042e00: 0x000000c000042dd8 0x0000000000000000
0x000000c000042e10: 0x000000000b9c3dc0 0x000000c000042ea8
0x000000c000042e20: 0x000000000b9039e9 <runtime.cgocallbackg+0x0000000000000109> 0x000000000b98cf40 <_cgoexp_6b951f94a90e_RunLib+0x0000000000000000>
...
<_cgoexp_6b951f94a90e_RunLib+0x0000000000000000>
0x000000c000042ea0: 0x00007ffeefbff737 0x000000c000042ed0
0x000000c000042eb0: 0x000000000b95e32f <runtime.cgocallbackg+0x000000000000002f> 0x000000c0000001a0
...
<runtime.cgocallback+0x00000000000000b4>
0x000000c000042ee0: <0x000000000b98cf40 <_cgoexp_6b951f94a90e_RunLib+0x0000000000000000> 0x00007ffeefbff737
...
runtime.cgocallback(0x4004165, 0x4058340, 0xc000042f70)
/usr/local/go/src/runtime/asm_amd64.s:915 +0xb4 fp=0xc000042f08 sp=0xc000042ee0 pc=0xb95c134
goroutine 1 [runnable, locked to thread]:
unicode.init()
/usr/local/go/src/unicode/tables.go:9 +0x79
exit status 2
But if I use python everything works correctly!
>>> import ctypes
>>> lib = ctypes.cdll.LoadLibrary("lib.so")
>>> 2022/03/02 01:08:17 Call init
>>> lib.RunLib()
2022/03/02 01:08:22 Call RunLib
0
>>>
Informations
OS: macOs Big Sur 11.6.3 (20G415)
>>> clang --version
Apple clang version 13.0.0 (clang-1300.0.29.30)
>>> nm lib.so| grep RunLib
000000000008cfa0 T _RunLib
000000000008cf40 t __cgoexp_6b951f94a90e_RunLib
00000000000c4200 s __cgoexp_6b951f94a90e_RunLib.stkobj
>>> go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="~/Library/Caches/go-build"
GOENV="~/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="~/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="~/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.17"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="~/projects/go/.../go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/wl/9rtfdx8x7jvgyn6t8hpq7yh00000gn/T/go-build401121298=/tmp/go-build -gno-record-gcc-switches -fno-common"
I googled and found this article. But there is no golang in the article.
https://medium.com/learning-the-go-programming-language/calling-go-functions-from-other-languages-4c7d8bcc69bf
The problem described by the original poster looks weird. I could not reproduce it on Linux.
My setup: Ubuntu 18, Go 1.19.2, gcc 7.5.0
I made only one change: added pragma #cgo LDFLAGS: -ldl to the C snippet. It is required by GCC to enable dlopen & Co.
package main
/*
#cgo LDFLAGS: -ldl
#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>
static void callFromLib() {
void (*fn)();
void *h = dlopen("lib.so", RTLD_LAZY);
if (!h) {
fprintf(stderr, "Error: %s\n", dlerror());
return;
}
*(void**)(&fn) = dlsym(h, "RunLib");
if (!fn) {
fprintf(stderr, "Error: %s\n", dlerror());
dlclose(h);
return;
}
fn();
dlclose(h);
}
*/
import "C"
func main() {
C.callFromLib()
}
Launched as:
LD_LIBRARY_PATH=/home/user/tmp/try-go/ go run call.go
LD_LIBRARY_PATH variable points to the directory with lib.so
Output:
2022/10/26 09:39:10 Call init
2022/10/26 09:39:10 Call RunLib
As expected, no errors.
The original error bad sweepgen in refill is raised by the garbage collector. The cache of objects became incoherent. I suspect the issue is that there are two runtimes and two garbage collectors in the program - one comes from the calling program and the other is from the loaded lib.so. It looks like two garbage collectors clashed while running over the same heap.
Anyway, in go 1.19 the code works. Still I wouldn't load Go shared object through C dlopen - who knows how two Go runtimes could interact, especially if they are from different compilers versions.
A Go contributor writes that it is not possible to have two Go runtimes in one image. The comment refers to Windows, but seems to apply to macOS as well, since I can reliably reproduce the crash mentioned by the OP:
If I am understanding correctly, you are using a Go program to open a C++ DLL and the C++ DLL opens a Go DLL. I'm sorry, this won't work on Windows. There can only be one copy of the Go runtime in the program image on Windows, but you are trying to have two.
see https://github.com/golang/go/issues/50304#issuecomment-999302888
However since the OP uses macOS there is an alternative: the use of plugins, see https://pkg.go.dev/plugin:
Package plugin implements loading and symbol resolution of Go plugins.
The command to create the library would change as follows:
go build -buildmode=plugin -o lib.so lib.go
Accordingly, your call to the function defined in your library would then look something like this in Go:
package main
import (
"plugin"
)
func main() {
plug, err := plugin.Open("lib.so")
if err != nil {
panic(err)
}
runLib, err := plug.Lookup("RunLib")
if err != nil {
panic(err)
}
runLib.(func())()
}
A test with this program generates the following logging outputs:
stephan#mac golang-c-lib-in-go % go run call.go
2022/10/29 23:23:01 Call init
2022/10/29 23:23:01 Call RunLib
If the library is also to be used for calling from C and/or Python, then one possibility is to create the library in two variants: one that is called from C and/or Python, as shown in the question, and one in the plugin variant that can then be used by Go programs.
In your example, you don't need to make any changes in lib.go, the only difference is the command line to create the library.
Finally, an important note from the documentation:
Currently plugins are only supported on Linux, FreeBSD, and macOS.
I suggest this blog which discusses linking go programs with c libraries in detail.
Your code in the go program seems to be missing the compiler and linker instructions:
#cgo CFLAGS: -I./src
#cgo LDFLAGS: -L./lib -lmylib -Wl,-rpath=./lib
My ultimate goal is to set the version(that shows in properties->details) of an executable being compiled with MinGW gcc-g++. But for now I would like to compile a resource file with windres to be able to link it later manually. But I got following error, when I use this command: windres resource.rc -o resource.res:
windres: resource.rc:2: syntax error
The process tried to write to a nonexistent pipe.
...
The process tried to write to a nonexistent pipe.
resource.rc:4:0: fatal error: when writing output to : Invalid argument
VS_VERSION_INFO VERSIONINFO
compilation terminated.
windres: preprocessing failed.
My resource.rc looks like this:
#include "winver.h"
#include "../include/resource.h"
VS_VERSION_INFO VERSIONINFO
FILEVERSION 0,0,0,2
PRODUCTVERSION 0,0,0,2
FILEFLAGSMASK 0x3fL
#ifdef _DEBUG
FILEFLAGS 0x1L
#else
FILEFLAGS 0x0L
#endif
FILEOS 0x4L
FILETYPE 0x1L
FILESUBTYPE 0x0L
{
BLOCK "StringFileInfo"
{
BLOCK "040904b0"
{
VALUE "Comments", "comment\0"
VALUE "CompanyName", "comment\0"
VALUE "FileDescription", "base file\0"
VALUE "FileVersion", "0.0.0.2 TP\0"
VALUE "InternalName", "testTP\0"
VALUE "LegalCopyright", "none\0"
VALUE "OriginalFilename", "test.exe\0"
VALUE "ProductName", "test\0"
VALUE "ProductVersion", "0.0.0.2 TP\0"
}
}
BLOCK "VarFileInfo"
{
VALUE "Translation", 0x409, 1200
}
}
and my resource.h is just empty, maybe that is the problem? It amazes me how complicated it is to simply set the version number in the property tab in an exe. I've been reading a lot of other SO answers but none of them worked for me. For e.g. this one seems too ambiguous on how to exactly proceed after having this resource.rc file.
As a resource compiler windres does not know the constants found in your file so you need to provide those, which is commonly done via the includes.
The easiest thing is to adjust the header of your file to the following:
#include <windows.h>
VS_VERSION_INFO VERSIONINFO
FILEVERSION 0,0,0,2
PRODUCTVERSION 0,0,0,2
FILEFLAGSMASK 0x3fL
#ifdef _DEBUG
FILEFLAGS 0x1L
#else
FILEFLAGS 0x0L
#endif
/* rest follows */
As you want to compile/link with gcc you want windres to output an object file, otherwise you won't be able to link it later.
To fix that change the compile command to windres resource.rc -o resource.o.
GCC's C and C++ compilers have several useful warning options, such as
-Wsuggest-attribute=pure
-Wsuggest-attribute=const
-Wsuggest-attribute=format
and so on. When I try to compile my code with these options, the compiler also issues warnings on the code in the (header-only) libraries that I use. Is there a way to apply the warnings only on my code, e.g. by listing the directories that include relevant files or by some other means?
You might want to look into GCC's Diagnostic pragmas -- these are supported in the following form since gcc-4.5.
After the #include of all library-headers you do not care about, add:
#pragma GCC diagnostic warning "-Wsuggest-attribute=format"
and further warnings to be enabled, to be warned of attributes to be added.
E.g. the following my_printf could use the attribute(format) specifier:
int my_printf(const char * format, ...) __attribute__((__format__(__printf__, 1, 2)));
int my_printf(const char * format, ...) {
va_list ap;
va_start(ap, format);
vprintf (format, ap);
va_end(ap);
return 0;
}
I am using ModelSim to simulate Verilog. I have created one define.v file and want to include this define.v in multiple other verilog modules.
part of define.v is as follows:
// defines
`define RSIZE 4
`define ISIZE 16
`define DSIZE 16
`define ASIZE 16
`define NREG 4
`define ADD 4'b0000
`define SUB 4'b0001
`define AND 4'b0010
`define OR 4'b0011
`define SLL 4'b0100
`define SRL 4'b0101
`define SRA 4'b0110
`define RL 4'b0111
`define LW 4'b1000
`define SW 4'b1001
`define LHB 4'b1010
`define LLB 4'b1011
`define BR 4'b1100
`define JAL 4'b1101
`define JR 4'b1110
`define EXEC 4'b1111
...
...
I have include this file in multiple other modules, for instance: the alu.v
//ALU.v
`include "define.v"
module alu(
input [`DSIZE-1:0] a, b, //operands
input [3:0] op, //operation code
input [3:0] imm, //immediate
output reg [`DSIZE-1:0] out, //output
output reg [2:0] flag //flag for N, V, Z in sequence
);
...
...
However, while compiling, it seems that the define file is not included, the error is as follows:
** Error: //psf/Home/Desktop/Projects/project1/alu.v(3):
Cannot open `include file "define.v".
How could I solve this problem?
If define.v is not within the current directory you need to instruct Modelsim to use the directory containing define.v when searching for files which are included.
The option to do this is +incdir+path.
So, for example, if you have the following file structure:
project/src/alu.v
project/include/define.v
And you run from project, then you need to include +incdir+include as an argument to Modelsim.
As a side note, if you are including the same file more than once, you should use "include guards" to avoid warnings about macros being redefined.
`ifndef DEFINE_V
`define DEFINE_V
`define RSIZE 4
`define ISIZE 16
....
`endif
I'm trying to compile seabios in a more debug-able state, and so I want to cancel function inlining.
To do so, I have added -fon-inline to the compilation flag, but then I get compilation error:
error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
Which is complaning on the following code:
asm volatile(
"calll __call16big_from32"
: "+a" (callregs), "+m" (*callregs)
:
: "ebx", "ecx", "edx", "esi", "edi", "cc", "memory");
I've looked this error up and found this means that compiler has ran out of registers so it can't compile that asm statement.
The thing is, the exact same code compile just fine without -fon-inline, why is that?
Why doesn't compile?
The first argument to the asm may not share a register with the address of the second because the first is modified. If the function is inlined callregs may be a constant or an offset from the stack pointer, and therefore a separate register is not required.
How to fix the program so it compiles
Given the presence of volatile and "memory", and no reference to it the second argument may be removed.
asm volatile(
"call __call16big_from32"
: "+a" (callregs)
:
: "ebx", "ecx", "edx", "esi", "edi", "cc", "memory");