include VHDL package in SystemVerilog Testbench - package

I have this Systemverilog testbench, in which I want to use a package written in VHDL.
When I do: 'include "desired_pkg.vhd", it appararantly interpretes is a Verilog package, as ModelSim reports:
Error: (vlog-13069) ** while parsing file included at C:/Users/VHDL/CO_code/CO_18_03/simulation/ed_sim/models/tb_top.sv(22)
** at C:/Users/VHDL/CO_code/CO_18_03/CO_simulation/mentor/020_regmaps_struct_pkg.vhd(1): near "--": syntax error, unexpected --, expecting class.
So it tries to interpret -- (comment in VHDL) as something in Verilog. How to include this package without rewriting it into Verilog?

you dont use include as that is a pre-processor directive, and assumes the included code is verilog. You need to import the code:
import vhdl_lib::desired_pkg::*
But be aware, importing VHDL from verilog is not defined by any standard, and is purely down to the tool whether it even works, and what items in the package are supported.

Thanks. It works with Modelsim.
In the seek of completeness, let me add some details below:
I compiled the Vhdl package with -mixedsvvh
I also added -mixedsvvh when compiling my SystemVerilog module
I added import my_pkg::*; at the beginning of my SystemVerilog module file
beware of case: it seems all variables are imported in low case (I mean, sometimes people are used to define Vhdl constants in HIGH_CASE but if you copy paste as is in your SystemVerilog, you will get "Undefined Variable")
My two cents ;)

Related

How to understand this Common Lisp package behavior?

I am new to Common Lisp. Even more when the topic is packages and systems. I am working with a program and something intrigues me. Btw, I am using SBCL and Slime (Emacs).
Being on the top-level (CL-USER) I can do:
CL-USER> (application-name/file-name::%function-on-parenscript)
This works! Then, I change to be inside the package:
CL-USER> (in-package :application-name)
Ok. So, I thought that after being inside the application name:
APPLICATION-NAME>
I would be able to do just:
APPLICATION-NAME> (file-name::%function-on-parenscript)
However, this does not work. It just works if I do:
APPLICATION-NAME> (application-name/file-name::%function-on-parenscript)
1 - Why is the application-name necessary if I am inside application-name?
2 - Why sometimes I need to use :: and other times I use just : to call things?
Common Lisp packages are there to solve namespaces problems. But they really intrigue me.
application-name/file-name and application-name are two distinct packages that are similar in names only for human readers but are otherwise unrelated.
Symbols are either written with a package prefix or not. The package is the part on the left of the colon or double-colon when there's a package prefix.
The double colon is a way to refer to symbols that are not exported from the package (they are private).
A single colon is for symbols that are exported.
If the symbol you want to refer is "accessible" in the current package, for example because you are "using" it's package and it is exported, then you can write the symbol without a package prefix
See Programming in the Large: Packages and Symbols for details

Getting errors in classes like NSObject.h,NSObjCRuntime.h while running tests in xcode

I am currently writing a test class in objective c and in that class i am writing unit test cases for the c classes (old classes) that is there in the project.To do unit test i have imported the header file in the test class and in xcode i am able to acess those functions defined in that c class.
But when i try to run unit test cases then i am so many errors in the Foundation framework.
I have tried
Thousand of errors in base classes like NSObject.h,NSObjCRuntime.h
Renamed the .c class to .m which created a list of more errors.
Error I am getting in xcode
I have been hitting my head for last couple of days to fix this !!.
Can anyone have any suggestions or solutions to this issue?
The problem is that .c files are treated as pure C files (in actuality C++) and presumably you are co-mingling C code with Obj-C.
By default, C and C++ files will be set to be Default - C++ Source.
You have two choices.
You could rename the extensions of the offending files to .mm.
Alternatively to preserve the file name, go to File Inspector and change the type to Objective C++ Source. I'm showing you what it would look like. Note since this is a .mm file, it is automatically set to Objective C++ Source. Just set the C files to this type.

Go compile returns duplicate symbols for architecture x86_64 error when I import 2 different packages which use C package via Cgo

Here is my code:
package main
import (
kusb "github.com/karalabe/usb"
tusb "github.com/trezor/trezord-go/usb"
)
func main() {
kusb.Enumerate(0, 0)
tusb.InitHIDAPI(nil)
}
When I compile (I'm using go mod to manage the packages), it returns this error:
duplicate symbol _libusb_dev_mem_alloc in:
/var/folders/fm/1rln65d94mn45s0h5l78tdyh0000gp/T/go-link-624554542/000002.o
/var/folders/fm/1rln65d94mn45s0h5l78tdyh0000gp/T/go-link-624554542/000020.o
ld: 136 duplicate symbols for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Why?
Some investigation i had:
The both packages use the same hidapi and libusb C packages in order to interact with usb devices.
Those C packages are identical, hence it defines the same functions so i think it is directly related to the error.
in trezord-go/usb, they include .C file, not the header file.
It is very counterintuitive to me because in the perspective of package users, I shouldn't need to worry about how a C package is used in the internal of the package, only the exposed types, functions and its behaviors.
Can anyone really explain what is going on here and how can I import both of them? They do different functions, eventhough they use the same C package.
From here: https://www.repustate.com/blog/go-duplicate-symbols-for-architecture-x86_64/
"What does this mean? Well, it means we're trying to link the same symbol name (in our case, a method) from two (or more) different source files. The fix was easy: rename one of the methods by updating the header file, the source file (.c or .cpp file) and lastly, updating your references to the symbol in your Go code, if it is directly referenced there."
Will it help ?
I was running into the same issue for hours and finally found the fix on a google groups channel
A package you import could be using cgo, you don't have to be using it directly
...
You can try CGO_ENABLED=0 go build and if it works then it is cgo related.
This was the charm that i was looking for! Hope this works for you too.

perl syntax check without loading c library

I would like to check syntax of my perl module (as well as for imports), but I don't want to check for dynamic loaded c libraries.
If I do:
perl -c path_to_module
I get:
Can't locate loadable object for module B::Hooks::OP::Check in #INC
because B::Hooks::OP::Check are loading some dynamic c libraries and I don't want to check that...
You can't.
Modules can affect the scripts that use them in many ways, including how they are parsed.
For example, if a module exports
sub f() { }
Then
my $f = f+4;
means
my $f = f() + 4;
But if a it were to export
sub f { }
the same code means
my $f = f(+4);
As such, modules must be loaded to parse the script that loads it. To load a module is simply to execute it, be it written in Perl or C.
That said, some folks put together PPI to address the needs of people like you. It's not perfect —it can't be perfect for the reasons previously stated— but it will give useful results nonetheless.
By the way, the proper way to syntax check a module is
perl -e'use Module;'
Using -c can give errors where non exists and vice-versa.
The syntax checker loads the included libraries because they might be applying changes to the syntax. If you're certain that this is not happening, you could prevent the inclusion by manipulating the loading path and providing a fake b::Hooks::OP::Check.

Interface Go with C libraries

How does one interface a Go program with a C library?
I've been browsing Go's source code but I still didn't figured it out. If someone has already done so, could you share, please?
UPDATED: Thanks to #fserb, I am posting some documentation from the Go sources:
Cgo enables the creation of Go
packages that call C code.
Usage: cgo [compiler options] file.go
The compiler options are passed
through uninterpreted when invoking
gcc to compile the C parts of the
package.
The input file.go is a syntactically
valid Go source file that imports the
pseudo-package "C" and then refers to
types such as C.size_t, variables such
as C.stdout, or functions such as
C.putchar.
If the import of "C" is immediately
preceded by a comment, that comment is
used as a header when compiling the C
parts of the package. For example:
// #include <stdio.h>
// #include <errno.h>
import "C"
Cgo transforms the input file into
four output files: two Go source
files, a C file for 6c (or 8c or 5c),
and a C file for gcc.
The standard package makefile rules in
Make.pkg automate the process of using
cgo. See $GOROOT/misc/cgo/stdio and
$GOROOT/misc/cgo/gmp for examples.
Cgo does not yet work with gccgo.
Check cgo. Also, take a look at misc/cgo/gmp on the Go source code for an example code on how to wrap a C library in Go.

Resources