make[3]: Leaving directory
/home/craig/cocotb/tests/test_cases/issue_120' make[2]: Leaving directory /home/craig/cocotb/tests/test_cases/issue_120'
cd test_cases/issue_134 && make
make[2]: Entering directory
/home/craig/cocotb/tests/test_cases/issue_134' make results.xml make[3]: Entering directory /home/craig/cocotb/tests/test_cases/issue_134'
cd sim_build &&

LD_LIBRARY_PATH=/home/craig/cocotb/build/libs/i686::/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib

MODULE=test_reals,test_integers TESTCASE= TOPLEVEL=sample_module
GPI_EXTRA= TOPLEVEL_LANG=verilog

PYTHONPATH=/home/craig/cocotb/build/libs/i686:/home/craig/cocotb:/home/craig/cocotb/tests/test_cases/issue_134:

vsim -c -do runsim.do 2>&1 | tee sim.log
Reading pref.tcl
10.4c
do runsim.do
Model Technology ModelSim DE vlog 10.4c Compiler 2015.07 Jul 19 2015
Start time: 22:03:30 on Feb 24,2016
vlog -work work -timescale 1ns/100ps -mfcu "+acc=rmb" -sv

/home/craig/cocotb/tests/test_cases/issue_134/../../../tests/designs/sample_module/sample_module.v

-- Compiling package sample_module_v_unit
-- Compiling module sample_module

Top level modules:
sample_module
End time: 22:03:30 on Feb 24,2016, Elapsed time: 0:00:00
Errors: 0, Warnings: 0
vsim -onfinish exit -pli "libvpi.so" work.sample_module
Start time: 22:03:30 on Feb 24,2016
// ModelSim DE 10.4c Jul 19 2015 Linux 3.16.0-45-generic
//
// Copyright 1991-2015 Mentor Graphics Corporation
// All Rights Reserved.

//
Loading sv_std.std
Loading work.sample_module_v_unit
Loading work.sample_module
Loading /home/craig/cocotb/build/libs/i686/libvpi.so
-.--ns INFO cocotb.gpi
GpiCommon.cpp:91 in gpi_print_registered_impl VPI registered
0.00ns INFO cocotb.gpi
gpi_embed.c:248 in embed_sim_init Running on ModelSim DE
version 10.4c 2015.07
0.00ns INFO cocotb.gpi
gpi_embed.c:249 in embed_sim_init Python interpreter
initialised and cocotb loaded!
0.00ns INFO cocotb
init.py:115 in _initialise_testbench Running tests with
Cocotb v1.0 from /home/craig/cocotb
0.00ns INFO cocotb
init.py:131 in _initialise_testbench Seeding Python random
module with<PHONE_NUMBER>
0.00ns INFO cocotb.regression
regression.py:161 in initialise Found test
cocotb.decorators.test_integer
0.00ns INFO cocotb.regression
regression.py:161 in initialise Found test
test_reals.assign_double
0.00ns INFO cocotb.regression
regression.py:262 in execute Running test 1/2:
test_integer
0.00ns INFO ..coroutine.test_integer.0x57776d2c
decorators.py:189 in send Starting test:
"test_integer"

Description: None
0.00ns INFO ..coroutine.test_integer.0x57776bac
decorators.py:189 in send Starting test:
"test_integer"

Description:

Test access to integers

0.03ns INFO cocotb.test
test_integers.py:25 in test_integer dut.stream_out_int
= 4
0.03ns INFO cocotb.test
test_integers.py:26 in test_integer dut.stream_in_int
= 4
0.03ns INFO ..coroutine.test_integer.0x57776d2c
decorators.py:199 in send
0.03ns INFO cocotb.regression
regression.py:209 in handle_result Test Passed:
test_integer
0.03ns INFO cocotb.regression
regression.py:262 in execute Running test 2/2:
assign_double
0.03ns INFO ..oroutine.assign_double.0x577766ec
decorators.py:189 in send Starting test:
"assign_double"

Description:

Assign a random floating point value, read it back from the DUT and
check

it matches what we assigned

0.03ns INFO cocotb.test
test_reals.py:21 in assign_double Setting the value
2.98395e+307
0.03ns INFO cocotb.test
test_reals.py:26 in assign_double Read back value
2.98395e+307
0.03ns INFO cocotb.regression
regression.py:209 in handle_result Test Passed:
assign_double
0.03ns INFO cocotb.regression
regression.py:170 in tear_down Passed 2 tests (0
skipped)
0.03ns INFO cocotb.regression
regression.py:176 in tear_down Shutting down...
** Note: $finish : UNKNOWN(-1)
Time: 35 ps Iteration: 0 Instance: /sample_module
End time: 22:03:33 on Feb 24,2016, Elapsed time: 0:00:03
Errors: 0, Warnings: 0
make[3]: Leaving directory
/home/craig/cocotb/tests/test_cases/issue_134' make[2]: Leaving directory /home/craig/cocotb/tests/test_cases/issue_134'
cd test_cases/issue_142 && make
make[2]: Entering directory
/home/craig/cocotb/tests/test_cases/issue_142' make results.xml make[3]: Entering directory /home/craig/cocotb/tests/test_cases/issue_142'
cd sim_build &&

LD_LIBRARY_PATH=/home/craig/cocotb/build/libs/i686::/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib

MODULE=issue_142 TESTCASE= TOPLEVEL=sample_module
GPI_EXTRA= TOPLEVEL_LANG=verilog

PYTHONPATH=/home/craig/cocotb/build/libs/i686:/home/craig/cocotb:/home/craig/cocotb/tests/test_cases/issue_142:

vsim -c -do runsim.do 2>&1 | tee sim.log
Reading pref.tcl
10.4c
do runsim.do
Model Technology ModelSim DE vlog 10.4c Compiler 2015.07 Jul 19 2015
Start time: 22:03:37 on Feb 24,2016
vlog -work work -timescale 1ns/100ps -mfcu "+acc=rmb" -sv

/home/craig/cocotb/tests/test_cases/issue_142/../../../tests/designs/sample_module/sample_module.v

-- Compiling package sample_module_v_unit
-- Compiling module sample_module

Top level modules:
sample_module
End time: 22:03:37 on Feb 24,2016, Elapsed time: 0:00:00
Errors: 0, Warnings: 0
vsim -onfinish exit -pli "libvpi.so" work.sample_module
Start time: 22:03:37 on Feb 24,2016
// ModelSim DE 10.4c Jul 19 2015 Linux 3.16.0-45-generic
//
// Copyright 1991-2015 Mentor Graphics Corporation
// All Rights Reserved.

//
Loading sv_std.std
Loading work.sample_module_v_unit
Loading work.sample_module
Loading /home/craig/cocotb/build/libs/i686/libvpi.so
-.--ns INFO cocotb.gpi
GpiCommon.cpp:91 in gpi_print_registered_impl VPI registered
0.00ns INFO cocotb.gpi
gpi_embed.c:248 in embed_sim_init Running on ModelSim DE
version 10.4c 2015.07
0.00ns INFO cocotb.gpi
gpi_embed.c:249 in embed_sim_init Python interpreter
initialised and cocotb loaded!
0.00ns INFO cocotb
init.py:115 in _initialise_testbench Running tests with
Cocotb v1.0 from /home/craig/cocotb
0.00ns INFO cocotb
init.py:131 in _initialise_testbench Seeding Python random
module with<PHONE_NUMBER>
0.00ns INFO cocotb.regression
regression.py:161 in initialise Found test
issue_142.issue_142_overflow_error
0.00ns INFO cocotb.regression
regression.py:262 in execute Running test 1/1:
issue_142_overflow_error
0.00ns INFO ..sue_142_overflow_error.0x5777674c
decorators.py:189 in send Starting test:
"issue_142_overflow_error"

Description: Tranparently convert ints too long to pass

through the GPI interface natively into BinaryValues
17.50ns INFO cocotb.regression
regression.py:209 in handle_result Test Passed:
issue_142_overflow_error
17.50ns INFO cocotb.regression
regression.py:170 in tear_down Passed 1 tests (0
skipped)
17.50ns INFO cocotb.regression
regression.py:176 in tear_down Shutting down...
** Note: $finish : UNKNOWN(-1)
Time: 17501 ps Iteration: 0 Instance: /sample_module
End time: 22:03:40 on Feb 24,2016, Elapsed time: 0:00:03
Errors: 0, Warnings: 0
make[3]: Leaving directory
/home/craig/cocotb/tests/test_cases/issue_142' make[2]: Leaving directory /home/craig/cocotb/tests/test_cases/issue_142'
cd test_cases/issue_253 && make
make[2]: Entering directory
/home/craig/cocotb/tests/test_cases/issue_253' Skipping issue_253 only runs on icarus make[2]: Leaving directory /home/craig/cocotb/tests/test_cases/issue_253'
cd test_cases/issue_330 && make
make[2]: Entering directory
/home/craig/cocotb/tests/test_cases/issue_330' make results.xml make[3]: Entering directory /home/craig/cocotb/tests/test_cases/issue_330'
cd sim_build &&

LD_LIBRARY_PATH=/home/craig/cocotb/build/libs/i686::/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib

MODULE=issue_330 TESTCASE= TOPLEVEL=sample_module
GPI_EXTRA= TOPLEVEL_LANG=verilog

PYTHONPATH=/home/craig/cocotb/build/libs/i686:/home/craig/cocotb:/home/craig/cocotb/tests/test_cases/issue_330:

vsim -c -do runsim.do 2>&1 | tee sim.log
Reading pref.tcl
10.4c
do runsim.do
Model Technology ModelSim DE vlog 10.4c Compiler 2015.07 Jul 19 2015
Start time: 22:03:43 on Feb 24,2016
vlog -work work -timescale 1ns/100ps -mfcu "+acc=rmb" -sv

/home/craig/cocotb/tests/test_cases/issue_330/../../../tests/designs/sample_module/sample_module.v

-- Compiling package sample_module_v_unit
-- Compiling module sample_module

Top level modules:
sample_module
End time: 22:03:43 on Feb 24,2016, Elapsed time: 0:00:00
Errors: 0, Warnings: 0
^C^C^CSegmentation fault (core dumped)
make[3]: *** [results.xml] Interrupt
make[2]: *** [sim] Interrupt
make[1]: *** [issue_330] Interrupt
make: *** [do_tests] Interrupt
craig@craig-VirtualBox:~/cocotb (master)$
On Wed, Feb 24, 2016 at 8:52 PM, Luke Darnell <
notifications<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:

Craig,
My guess is that the python lib dir isn't successfully being added
to
LD_LIBRARY_PATH.
See the empty 2nd entry:

LD_LIBRARY_PATH=/home/craig/cocotb/build/libs/i686::/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib

The makefile fragment that sets this is in
cocotb/makefiles/Makefile.pylib.Linux
You'll need to do some debug and figure out why PYTHON_LIBDIR isn't
being
set.
Can you try running this command:
python -c 'from future import print_function; from distutils
import
sysconfig; print(sysconfig.get_config_var("LIBDIR"))'
Luke

From: Craig Swanson<EMAIL_ADDRESS><EMAIL_ADDRESS>notifications<EMAIL_ADDRESS>

notifications<EMAIL_ADDRESS><EMAIL_ADDRESS>
Sent: Tuesday, 23 February 2016 4:34 PM
To: potentialventures/cocotb
Cc: Luke Darnell
Subject: Re: [cocotb] Modelsim as a simulator in 64-bit platform
(#137)
Luke,
Sorry for being so brain dead. I appreciate your feedback.
So I cleaned up my repository with the following commands:
sudo apt-get autoremove
sudo apt-get update
sudo apt-get install python2.7:i386
sudo apt-get python2.7-dev:i386
then re-ran the make file and saw it was calling "python" so I did
the
following:
/usr/bin/ sudo ln -s python2.7 python
Now when I run it, I get the following error:
Error Message: (vsim-50) A call to

system("/opt/mentor/modelsim/modelsim_dlx/gcc-4.7.4-linux/bin/c++filt"

"_Py_TrueStruct" >'/tmp/questatmp.U7imPr' 2>&1) returned error code
'127'.
[Probably a bad shell].
The logfile contains the following messages:
sh: 1:
/opt/mentor/modelsim/modelsim_dlx/gcc-4.7.4-linux/bin/c++filt:
not
found
Here is the short history on my terminal screen:
craig@craig-VirtualBox:~/cocotb (master)$ make SIM=modelsim
ARCH=i686
make -k -C tests
make[1]: Entering directory /home/craig/cocotb/tests' cd test_cases/issue_120 && make make[2]: Entering directory /home/craig/cocotb/tests/test_cases/issue_120'
make results.xml
make[3]: Entering directory
`/home/craig/cocotb/tests/test_cases/issue_120'
cd sim_build &&

LD_LIBRARY_PATH=/home/craig/cocotb/build/libs/i686::/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib

MODULE=issue_120 TESTCASE= TOPLEVEL=sample_module
GPI_EXTRA= TOPLEVEL_LANG=verilog

PYTHONPATH=/home/craig/cocotb/build/libs/i686:/home/craig/cocotb:/home/craig/cocotb/tests/test_cases/issue_120:

vsim -c -do runsim.do 2>&1 | tee sim.log
Reading pref.tcl
10.4c
do runsim.do
Model Technology ModelSim DE vlog 10.4c Compiler 2015.07 Jul 19

2015

Start time: 11:19:53 on Feb 23,2016
vlog -work work -timescale 1ns/100ps -mfcu "+acc=rmb" -sv

/home/craig/cocotb/tests/test_cases/issue_120/../../../tests/designs/sample_module/sample_module.v

-- Compiling package sample_module_v_unit
-- Compiling module sample_module

Top level modules:
sample_module
End time: 11:19:53 on Feb 23,2016, Elapsed time: 0:00:00
Errors: 0, Warnings: 0
vsim -onfinish exit -pli "libvpi.so" work.sample_module
Start time: 11:19:53 on Feb 23,2016
// ModelSim DE 10.4c Jul 19 2015 Linux 3.16.0-45-generic
//
// Copyright 1991-2015 Mentor Graphics Corporation
// All Rights Reserved.

//
Error Message: (vsim-50) A call to

system("/opt/mentor/modelsim/modelsim_dlx/gcc-4.7.4-linux/bin/c++filt"

"_Py_TrueStruct" >'/tmp/questatmp.U7imPr' 2>&1) returned error code
'127'.
[Probably a bad shell].
The logfile contains the following messages:
sh: 1:
/opt/mentor/modelsim/modelsim_dlx/gcc-4.7.4-linux/bin/c++filt:
not
found
No such file or directory. (errno = ENOENT)
Loading sv_std.std
Loading work.sample_module_v_unit
Loading work.sample_module
Loading /home/craig/cocotb/build/libs/i686/libvpi.so
** Error (suppressible): (vsim-3197) Load of
"/home/craig/cocotb/build/libs/i686/libvpi.so" failed:
/home/craig/cocotb/build/libs/i686/libgpilog.so: undefined symbol:
_Py_TrueStruct.
** Error (suppressible): (vsim-PLI-3002) Failed to load PLI object

file

"/home/craig/cocotb/build/libs/i686/libvpi.so".
Time: 0 ps Iteration: 0 Root: /
Error loading design
Error loading design
On Tue, Feb 23, 2016 at 6:20 AM, Luke Darnell <
notifications<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>

wrote:

Following the clues from the command outputs will usually give you
some
clues.
In this case, apt needs to install python2.7:i386 before you can
install
the package that gives you the Python headers
(python2.7:i386).
What does "sudo apt-get install python2.7:i386" tell you?
Luke
On 23 Feb 2016, at 2:10 PM, Craig Swanson <
notifications<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
Stuart,
Thank you again for your support. I am anxious to get through this
phase
so any help you can give is much appreciated.
Here are my results:
craig@craig-VirtualBox:~/cocotb (master)$ sudo apt-get install
python2.7-dev:i386
[sudo] password for craig:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
python2.7-dev:i386 : Depends: python2.7:i386 (= 2.7.6-8ubuntu0.2)
but
it
is not going to be installed
E: Unable to correct problems, you have held broken packages.
On Mon, Feb 22, 2016 at 8:47 PM, Stuart Hodgson <
notifications<EMAIL_ADDRESS><EMAIL_ADDRESS>notifications<EMAIL_ADDRESS>

<EMAIL_ADDRESS>wrote:

@cfswanson https://github.com/cfswanson,
Since modelsim in your case is 32bit you must have ARCH=i686 set
when
you
call make, you where doing this earlier.
The error you are seeing when running make while having ARCH set
seems
to
be because the python header file is not installed
$> sudo apt-get install python2.7-dev:i386
Stuart

Reply to this email directly or view it on GitHub
<

https://github.com/potentialventures/cocotb/issues/137#issuecomment-187471070

.

Reply to this email directly or view it on GitHub<

https://github.com/potentialventures/cocotb/issues/137#issuecomment-187501545

.

Reply to this email directly or view it on GitHub
<

https://github.com/potentialventures/cocotb/issues/137#issuecomment-187659117

.

Reply to this email directly or view it on GitHub<

https://github.com/potentialventures/cocotb/issues/137#issuecomment-187777221

.

Reply to this email directly or view it on GitHub
<

https://github.com/potentialventures/cocotb/issues/137#issuecomment-188557566

.

Reply to this email directly or view it on GitHub<

https://github.com/potentialventures/cocotb/issues/137#issuecomment-188581215

.

Reply to this email directly or view it on GitHub
<

https://github.com/potentialventures/cocotb/issues/137#issuecomment-188614536

.

Reply to this email directly or view it on GitHub<

https://github.com/potentialventures/cocotb/issues/137#issuecomment-188616823

.

Reply to this email directly or view it on GitHub
<
https://github.com/potentialventures/cocotb/issues/137#issuecomment-188639421
.

Reply to this email directly or view it on GitHub<
https://github.com/potentialventures/cocotb/issues/137#issuecomment-189990263

.

—
Reply to this email directly or view it on GitHub
https://github.com/potentialventures/cocotb/issues/137#issuecomment-190035250
.

Luke,
So I figured out my Modelsim wave viewer problem and not I am running into
a problem with numpy.  I installed it and then after running a python
script which references the library I encountered this error:
ImportError: /usr/lib/python2.7/dist-packages/numpy/core/multiarray.so:
wrong ELF class: ELFCLASS64
I have tried various solutions online but none have worked so far.  I
believe it has to do with running 32 vs 64 bit libraries.
Craig
On Sun, Feb 28, 2016 at 11:43 PM, Luke Darnell<EMAIL_ADDRESS>wrote:

Timer(2) advances two simulation cycles, the units of which are dependent
on your simulation setup.
cocotb.readthedocs.orghttp://cocotb.readthedocs.org has info on this.
You should check there first.
It is totally decoupled from your dut.
If you're not getting to "Info 2" I'm guessing there's a loop in your code.
Can you do single step debugging?
Luke
On 29 Feb 2016, at 12:30 PM, Craig Swanson<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
Luke,
I am trying to advance my simulation in python but I cannot get it past
Info 1. I am trying to get it to Info 2 but it seems like the yield Timer
(2) is not working. What does the "2" signify? Is it 2 ns or 2 clock
cycles? How does it tie into my DUT? What file specifies this connection
between 2 and my clock?
Simple tests for an agc module
import cocotb
from cocotb.triggers import Timer
from cocotb.result import TestFailure
from agc_model import agc_model
import random
@cocotb.test()
def agc_basic_test(dut):
"""Test for 5 + 10"""
dut.log.infohttp://dut.log.info("Info 1")
yield Timer(2)
dut.log.infohttp://dut.log.info("Info 2")
yield Timer(2)
dut.log.infohttp://dut.log.info("Info 3")
realIn = 5
imagIn = 10
dut.realIn = realIn
dut.imagIn = imagIn
yield Timer(2)
Craig
On Thu, Feb 25, 2016 at 1:47 AM, Luke Darnell<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:

The E310 SDR looks pretty cool.
I use cocotb to verify wifi designs, so I guess I qualify.
For signal processing in Python, take a look at scipy, numpy and
matplotlib.
Using them with cocotb should be trivial.
cheers,
Luke
On 25 Feb 2016, at 4:04 PM, Craig Swanson<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
Luke,
My application is using a transceiver in a GNUradio environment running
RFNoC on an E310 SDR which has a Xilinx Zync 7020. So I hope to be
generating test vectors that have a signal processing feel to it. Do you
know of anyone who has used cocotb for that approach? Any help would be
appreciated.
Thanks,
Craig
On Wed, Feb 24, 2016 at 11:51 PM, Luke Darnell<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:

Looks good Craig.
On 25 Feb 2016, at 2:08 PM, Craig Swanson<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
Luke,
I think I just had a HUGE breakthrough. I decided to run "make clean".
Then I ran "make SIM=modelsim ARCH=i686" and now I think it works!
Please look at the output from my terminal window and tell me if this
is
correct.

//
Loading sv_std.std
Loading work.sample_module_v_unit
Loading work.sample_module
Loading /home/craig/cocotb/build/libs/i686/libvpi.so
-.--ns INFO cocotb.gpi
GpiCommon.cpp:91 in gpi_print_registered_impl VPI registered
0.00ns INFO cocotb.gpi
gpi_embed.c:248 in embed_sim_init Running on ModelSim DE
version 10.4c 2015.07
0.00ns INFO cocotb.gpi
gpi_embed.c:249 in embed_sim_init Python interpreter
initialised and cocotb loaded!
0.00ns INFO cocotb
init.py:115 in _initialise_testbench Running tests with
Cocotb v1.0 from /home/craig/cocotb
0.00ns INFO cocotb
init.py:131 in _initialise_testbench Seeding Python random
module with<PHONE_NUMBER>
0.00ns INFO cocotb.regression
regression.py:161 in initialise Found test
issue_120.issue_120_scheduling
0.00ns INFO cocotb.regression
regression.py:262 in execute Running test 1/1:
issue_120_scheduling
0.00ns INFO ..e.issue_120_scheduling.0x57776a4c
decorators.py:189 in send Starting test:
"issue_120_scheduling"

Description: None
15.00ns INFO cocotb.regression
regression.py:209 in handle_result Test Passed:
issue_120_scheduling
15.00ns INFO cocotb.regression
regression.py:170 in tear_down Passed 1 tests (0
skipped)
15.00ns INFO cocotb.regression
regression.py:176 in tear_down Shutting down...
** Note: $finish : UNKNOWN(-1)
Time: 15001 ps Iteration: 0 Instance: /sample_module
End time: 22:03:27 on Feb 24,2016, Elapsed time: 0:00:03
Errors: 0, Warnings: 0
make[3]: Leaving directory
/home/craig/cocotb/tests/test_cases/issue_120' make[2]: Leaving directory /home/craig/cocotb/tests/test_cases/issue_120'
cd test_cases/issue_134 && make
make[2]: Entering directory
/home/craig/cocotb/tests/test_cases/issue_134' make results.xml make[3]: Entering directory /home/craig/cocotb/tests/test_cases/issue_134'
cd sim_build &&

LD_LIBRARY_PATH=/home/craig/cocotb/build/libs/i686::/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib

MODULE=test_reals,test_integers TESTCASE= TOPLEVEL=sample_module
GPI_EXTRA= TOPLEVEL_LANG=verilog

PYTHONPATH=/home/craig/cocotb/build/libs/i686:/home/craig/cocotb:/home/craig/cocotb/tests/test_cases/issue_134:

vsim -c -do runsim.do 2>&1 | tee sim.log
Reading pref.tcl
10.4c
do runsim.do
Model Technology ModelSim DE vlog 10.4c Compiler 2015.07 Jul 19 2015
Start time: 22:03:30 on Feb 24,2016
vlog -work work -timescale 1ns/100ps -mfcu "+acc=rmb" -sv

/home/craig/cocotb/tests/test_cases/issue_134/../../../tests/designs/sample_module/sample_module.v

-- Compiling package sample_module_v_unit
-- Compiling module sample_module

Top level modules:
sample_module
End time: 22:03:30 on Feb 24,2016, Elapsed time: 0:00:00
Errors: 0, Warnings: 0
vsim -onfinish exit -pli "libvpi.so" work.sample_module
Start time: 22:03:30 on Feb 24,2016
// ModelSim DE 10.4c Jul 19 2015 Linux 3.16.0-45-generic
//
// Copyright 1991-2015 Mentor Graphics Corporation
// All Rights Reserved.

//
Loading sv_std.std
Loading work.sample_module_v_unit
Loading work.sample_module
Loading /home/craig/cocotb/build/libs/i686/libvpi.so
-.--ns INFO cocotb.gpi
GpiCommon.cpp:91 in gpi_print_registered_impl VPI registered
0.00ns INFO cocotb.gpi
gpi_embed.c:248 in embed_sim_init Running on ModelSim DE
version 10.4c 2015.07
0.00ns INFO cocotb.gpi
gpi_embed.c:249 in embed_sim_init Python interpreter
initialised and cocotb loaded!
0.00ns INFO cocotb
init.py:115 in _initialise_testbench Running tests with
Cocotb v1.0 from /home/craig/cocotb
0.00ns INFO cocotb
init.py:131 in _initialise_testbench Seeding Python random
module with<PHONE_NUMBER>
0.00ns INFO cocotb.regression
regression.py:161 in initialise Found test
cocotb.decorators.test_integer
0.00ns INFO cocotb.regression
regression.py:161 in initialise Found test
test_reals.assign_double
0.00ns INFO cocotb.regression
regression.py:262 in execute Running test 1/2:
test_integer
0.00ns INFO ..coroutine.test_integer.0x57776d2c
decorators.py:189 in send Starting test:
"test_integer"

Description: None
0.00ns INFO ..coroutine.test_integer.0x57776bac
decorators.py:189 in send Starting test:
"test_integer"

Description:

Test access to integers

0.03ns INFO cocotb.test
test_integers.py:25 in test_integer dut.stream_out_int
= 4
0.03ns INFO cocotb.test
test_integers.py:26 in test_integer dut.stream_in_int
= 4
0.03ns INFO ..coroutine.test_integer.0x57776d2c
decorators.py:199 in send
0.03ns INFO cocotb.regression
regression.py:209 in handle_result Test Passed:
test_integer
0.03ns INFO cocotb.regression
regression.py:262 in execute Running test 2/2:
assign_double
0.03ns INFO ..oroutine.assign_double.0x577766ec
decorators.py:189 in send Starting test:
"assign_double"

Description:

Assign a random floating point value, read it back from the DUT and
check

it matches what we assigned

0.03ns INFO cocotb.test
test_reals.py:21 in assign_double Setting the value
2.98395e+307
0.03ns INFO cocotb.test
test_reals.py:26 in assign_double Read back value
2.98395e+307
0.03ns INFO cocotb.regression
regression.py:209 in handle_result Test Passed:
assign_double
0.03ns INFO cocotb.regression
regression.py:170 in tear_down Passed 2 tests (0
skipped)
0.03ns INFO cocotb.regression
regression.py:176 in tear_down Shutting down...
** Note: $finish : UNKNOWN(-1)
Time: 35 ps Iteration: 0 Instance: /sample_module
End time: 22:03:33 on Feb 24,2016, Elapsed time: 0:00:03
Errors: 0, Warnings: 0
make[3]: Leaving directory
/home/craig/cocotb/tests/test_cases/issue_134' make[2]: Leaving directory /home/craig/cocotb/tests/test_cases/issue_134'
cd test_cases/issue_142 && make
make[2]: Entering directory
/home/craig/cocotb/tests/test_cases/issue_142' make results.xml make[3]: Entering directory /home/craig/cocotb/tests/test_cases/issue_142'
cd sim_build &&

LD_LIBRARY_PATH=/home/craig/cocotb/build/libs/i686::/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib

MODULE=issue_142 TESTCASE= TOPLEVEL=sample_module
GPI_EXTRA= TOPLEVEL_LANG=verilog

PYTHONPATH=/home/craig/cocotb/build/libs/i686:/home/craig/cocotb:/home/craig/cocotb/tests/test_cases/issue_142:

vsim -c -do runsim.do 2>&1 | tee sim.log
Reading pref.tcl
10.4c
do runsim.do
Model Technology ModelSim DE vlog 10.4c Compiler 2015.07 Jul 19 2015
Start time: 22:03:37 on Feb 24,2016
vlog -work work -timescale 1ns/100ps -mfcu "+acc=rmb" -sv

/home/craig/cocotb/tests/test_cases/issue_142/../../../tests/designs/sample_module/sample_module.v

-- Compiling package sample_module_v_unit
-- Compiling module sample_module

Top level modules:
sample_module
End time: 22:03:37 on Feb 24,2016, Elapsed time: 0:00:00
Errors: 0, Warnings: 0
vsim -onfinish exit -pli "libvpi.so" work.sample_module
Start time: 22:03:37 on Feb 24,2016
// ModelSim DE 10.4c Jul 19 2015 Linux 3.16.0-45-generic
//
// Copyright 1991-2015 Mentor Graphics Corporation
// All Rights Reserved.

//
Loading sv_std.std
Loading work.sample_module_v_unit
Loading work.sample_module
Loading /home/craig/cocotb/build/libs/i686/libvpi.so
-.--ns INFO cocotb.gpi
GpiCommon.cpp:91 in gpi_print_registered_impl VPI registered
0.00ns INFO cocotb.gpi
gpi_embed.c:248 in embed_sim_init Running on ModelSim DE
version 10.4c 2015.07
0.00ns INFO cocotb.gpi
gpi_embed.c:249 in embed_sim_init Python interpreter
initialised and cocotb loaded!
0.00ns INFO cocotb
init.py:115 in _initialise_testbench Running tests with
Cocotb v1.0 from /home/craig/cocotb
0.00ns INFO cocotb
init.py:131 in _initialise_testbench Seeding Python random
module with<PHONE_NUMBER>
0.00ns INFO cocotb.regression
regression.py:161 in initialise Found test
issue_142.issue_142_overflow_error
0.00ns INFO cocotb.regression
regression.py:262 in execute Running test 1/1:
issue_142_overflow_error
0.00ns INFO ..sue_142_overflow_error.0x5777674c
decorators.py:189 in send Starting test:
"issue_142_overflow_error"

Description: Tranparently convert ints too long to pass

through the GPI interface natively into BinaryValues
17.50ns INFO cocotb.regression
regression.py:209 in handle_result Test Passed:
issue_142_overflow_error
17.50ns INFO cocotb.regression
regression.py:170 in tear_down Passed 1 tests (0
skipped)
17.50ns INFO cocotb.regression
regression.py:176 in tear_down Shutting down...
** Note: $finish : UNKNOWN(-1)
Time: 17501 ps Iteration: 0 Instance: /sample_module
End time: 22:03:40 on Feb 24,2016, Elapsed time: 0:00:03
Errors: 0, Warnings: 0
make[3]: Leaving directory
/home/craig/cocotb/tests/test_cases/issue_142' make[2]: Leaving directory /home/craig/cocotb/tests/test_cases/issue_142'
cd test_cases/issue_253 && make
make[2]: Entering directory
/home/craig/cocotb/tests/test_cases/issue_253' Skipping issue_253 only runs on icarus make[2]: Leaving directory /home/craig/cocotb/tests/test_cases/issue_253'
cd test_cases/issue_330 && make
make[2]: Entering directory
/home/craig/cocotb/tests/test_cases/issue_330' make results.xml make[3]: Entering directory /home/craig/cocotb/tests/test_cases/issue_330'
cd sim_build &&

LD_LIBRARY_PATH=/home/craig/cocotb/build/libs/i686::/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib

MODULE=issue_330 TESTCASE= TOPLEVEL=sample_module
GPI_EXTRA= TOPLEVEL_LANG=verilog

PYTHONPATH=/home/craig/cocotb/build/libs/i686:/home/craig/cocotb:/home/craig/cocotb/tests/test_cases/issue_330:

vsim -c -do runsim.do 2>&1 | tee sim.log
Reading pref.tcl
10.4c
do runsim.do
Model Technology ModelSim DE vlog 10.4c Compiler 2015.07 Jul 19 2015
Start time: 22:03:43 on Feb 24,2016
vlog -work work -timescale 1ns/100ps -mfcu "+acc=rmb" -sv

/home/craig/cocotb/tests/test_cases/issue_330/../../../tests/designs/sample_module/sample_module.v

-- Compiling package sample_module_v_unit
-- Compiling module sample_module

Top level modules:
sample_module
End time: 22:03:43 on Feb 24,2016, Elapsed time: 0:00:00
Errors: 0, Warnings: 0
^C^C^CSegmentation fault (core dumped)
make[3]: *** [results.xml] Interrupt
make[2]: *** [sim] Interrupt
make[1]: *** [issue_330] Interrupt
make: *** [do_tests] Interrupt
craig@craig-VirtualBox:~/cocotb (master)$
On Wed, Feb 24, 2016 at 8:52 PM, Luke Darnell <
notifications<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:

Craig,
My guess is that the python lib dir isn't successfully being added to
LD_LIBRARY_PATH.
See the empty 2nd entry:

LD_LIBRARY_PATH=/home/craig/cocotb/build/libs/i686::/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib

The makefile fragment that sets this is in
cocotb/makefiles/Makefile.pylib.Linux
You'll need to do some debug and figure out why PYTHON_LIBDIR isn't
being
set.
Can you try running this command:
python -c 'from future import print_function; from distutils
import
sysconfig; print(sysconfig.get_config_var("LIBDIR"))'
Luke

From: Craig Swanson<EMAIL_ADDRESS><EMAIL_ADDRESS>notifications<EMAIL_ADDRESS>

notifications<EMAIL_ADDRESS><EMAIL_ADDRESS>
Sent: Tuesday, 23 February 2016 4:34 PM
To: potentialventures/cocotb
Cc: Luke Darnell
Subject: Re: [cocotb] Modelsim as a simulator in 64-bit platform
(#137)
Luke,
Sorry for being so brain dead. I appreciate your feedback.
So I cleaned up my repository with the following commands:
sudo apt-get autoremove
sudo apt-get update
sudo apt-get install python2.7:i386
sudo apt-get python2.7-dev:i386
then re-ran the make file and saw it was calling "python" so I did
the
following:
/usr/bin/ sudo ln -s python2.7 python
Now when I run it, I get the following error:
Error Message: (vsim-50) A call to

system("/opt/mentor/modelsim/modelsim_dlx/gcc-4.7.4-linux/bin/c++filt"

"_Py_TrueStruct" >'/tmp/questatmp.U7imPr' 2>&1) returned error code
'127'.
[Probably a bad shell].
The logfile contains the following messages:
sh: 1: /opt/mentor/modelsim/modelsim_dlx/gcc-4.7.4-linux/bin/c++filt:
not
found
Here is the short history on my terminal screen:
craig@craig-VirtualBox:~/cocotb (master)$ make SIM=modelsim
ARCH=i686
make -k -C tests
make[1]: Entering directory /home/craig/cocotb/tests' cd test_cases/issue_120 && make make[2]: Entering directory /home/craig/cocotb/tests/test_cases/issue_120'
make results.xml
make[3]: Entering directory
`/home/craig/cocotb/tests/test_cases/issue_120'
cd sim_build &&

LD_LIBRARY_PATH=/home/craig/cocotb/build/libs/i686::/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib

MODULE=issue_120 TESTCASE= TOPLEVEL=sample_module
GPI_EXTRA= TOPLEVEL_LANG=verilog

PYTHONPATH=/home/craig/cocotb/build/libs/i686:/home/craig/cocotb:/home/craig/cocotb/tests/test_cases/issue_120:

vsim -c -do runsim.do 2>&1 | tee sim.log
Reading pref.tcl
10.4c
do runsim.do
Model Technology ModelSim DE vlog 10.4c Compiler 2015.07 Jul 19

2015

Start time: 11:19:53 on Feb 23,2016
vlog -work work -timescale 1ns/100ps -mfcu "+acc=rmb" -sv

/home/craig/cocotb/tests/test_cases/issue_120/../../../tests/designs/sample_module/sample_module.v

-- Compiling package sample_module_v_unit
-- Compiling module sample_module

Top level modules:
sample_module
End time: 11:19:53 on Feb 23,2016, Elapsed time: 0:00:00
Errors: 0, Warnings: 0
vsim -onfinish exit -pli "libvpi.so" work.sample_module
Start time: 11:19:53 on Feb 23,2016
// ModelSim DE 10.4c Jul 19 2015 Linux 3.16.0-45-generic
//
// Copyright 1991-2015 Mentor Graphics Corporation
// All Rights Reserved.

//
Error Message: (vsim-50) A call to

system("/opt/mentor/modelsim/modelsim_dlx/gcc-4.7.4-linux/bin/c++filt"

"_Py_TrueStruct" >'/tmp/questatmp.U7imPr' 2>&1) returned error code
'127'.
[Probably a bad shell].
The logfile contains the following messages:
sh: 1: /opt/mentor/modelsim/modelsim_dlx/gcc-4.7.4-linux/bin/c++filt:
not
found
No such file or directory. (errno = ENOENT)
Loading sv_std.std
Loading work.sample_module_v_unit
Loading work.sample_module
Loading /home/craig/cocotb/build/libs/i686/libvpi.so
** Error (suppressible): (vsim-3197) Load of
"/home/craig/cocotb/build/libs/i686/libvpi.so" failed:
/home/craig/cocotb/build/libs/i686/libgpilog.so: undefined symbol:
_Py_TrueStruct.
** Error (suppressible): (vsim-PLI-3002) Failed to load PLI object

file

"/home/craig/cocotb/build/libs/i686/libvpi.so".
Time: 0 ps Iteration: 0 Root: /
Error loading design
Error loading design
On Tue, Feb 23, 2016 at 6:20 AM, Luke Darnell <
notifications<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>

wrote:

Following the clues from the command outputs will usually give you
some
clues.
In this case, apt needs to install python2.7:i386 before you can
install
the package that gives you the Python headers
(python2.7:i386).
What does "sudo apt-get install python2.7:i386" tell you?
Luke
On 23 Feb 2016, at 2:10 PM, Craig Swanson <
notifications<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
Stuart,
Thank you again for your support. I am anxious to get through this
phase
so any help you can give is much appreciated.
Here are my results:
craig@craig-VirtualBox:~/cocotb (master)$ sudo apt-get install
python2.7-dev:i386
[sudo] password for craig:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
python2.7-dev:i386 : Depends: python2.7:i386 (= 2.7.6-8ubuntu0.2)
but
it
is not going to be installed
E: Unable to correct problems, you have held broken packages.
On Mon, Feb 22, 2016 at 8:47 PM, Stuart Hodgson <
notifications<EMAIL_ADDRESS><EMAIL_ADDRESS>notifications<EMAIL_ADDRESS>

<EMAIL_ADDRESS>wrote:

@cfswanson https://github.com/cfswanson,
Since modelsim in your case is 32bit you must have ARCH=i686 set
when
you
call make, you where doing this earlier.
The error you are seeing when running make while having ARCH set
seems
to
be because the python header file is not installed
$> sudo apt-get install python2.7-dev:i386
Stuart

Reply to this email directly or view it on GitHub
<

https://github.com/potentialventures/cocotb/issues/137#issuecomment-187471070

.

Reply to this email directly or view it on GitHub<

https://github.com/potentialventures/cocotb/issues/137#issuecomment-187501545

.

Reply to this email directly or view it on GitHub
<

https://github.com/potentialventures/cocotb/issues/137#issuecomment-187659117

.

Reply to this email directly or view it on GitHub<

https://github.com/potentialventures/cocotb/issues/137#issuecomment-187777221

.

Reply to this email directly or view it on GitHub
<

https://github.com/potentialventures/cocotb/issues/137#issuecomment-188557566

.

Reply to this email directly or view it on GitHub<

https://github.com/potentialventures/cocotb/issues/137#issuecomment-188581215

.

Reply to this email directly or view it on GitHub
<

https://github.com/potentialventures/cocotb/issues/137#issuecomment-188614536

.

Reply to this email directly or view it on GitHub<

https://github.com/potentialventures/cocotb/issues/137#issuecomment-188616823

.

Reply to this email directly or view it on GitHub
<
https://github.com/potentialventures/cocotb/issues/137#issuecomment-188639421
.

Reply to this email directly or view it on GitHub<
https://github.com/potentialventures/cocotb/issues/137#issuecomment-189990263

.

—
Reply to this email directly or view it on GitHub
https://github.com/potentialventures/cocotb/issues/137#issuecomment-190035250
.

@cfswanson you are correct - the problem here is that when you import numpy your PYTHONPATH is pointing to the 64-bit version.  numpy has loads of C extensions which it can't load because they're 64-bit libraries.
You'll need to try and install 32-bit numpy:  sudo apt-get install python-numpy:i686 python-scipy:i686

Chris,
Here is what I tried:
craig@craig-VirtualBox:~$ sudo apt-get install python-numpy:i686
python-scipy:i686
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package python-numpy
E: Unable to locate package python-scipy
On Sat, Mar 5, 2016 at 1:54 AM, Chris Higgs<EMAIL_ADDRESS>wrote:

@cfswanson https://github.com/cfswanson you are correct - the problem
here is that when you import numpy your PYTHONPATH is pointing to the
64-bit version. numpy has loads of C extensions which it can't load
because they're 64-bit libraries.
You'll need to try and install 32-bit numpy: sudo apt-get install
python-numpy:i686 python-scipy:i686
—
Reply to this email directly or view it on GitHub
https://github.com/potentialventures/cocotb/issues/137#issuecomment-192598066
.

.  Chris,
Is there any way to pass parameters from my python testbench to my VHDL
code? Instead of assigning a value to dut.enable, I want to assign a value
to dut.attackRate and dut.decayRate that I would change during the test.
Or maybe that is not a good idea?  Maybe I should keep the GENERIC values
static?  Or can I recompile the vhdl code and run it using cocotb?  The
only way I see a practical solution is for me to change the attackRate and
decayRate to PORT assignments, if I plan on changing the values during a
test.

You'll need to try and install 32-bit numpy: sudo apt-get install
python-numpy:i686 python-scipy:i686
—
Reply to this email directly or view it on GitHub
https://github.com/potentialventures/cocotb/issues/137#issuecomment-192598066
.

--
Craig Swanson
770-298-9156
<EMAIL_ADDRESS>Cumming, GA 30040

Chris,
An interesting behavior I am seeing is that when I run make, if I have an
error in my python testbench, it seems to overwrite my runsim.do.  In my
runsim.do file I have some extra commands inserted that add signals to wave
so I can view them.  As long as I don't have any errors in the python, it
seems to leave my runsim.do alone.  Otherwise, I have to re-insert them.
Any ideas why?
Craig
On Sat, Mar 5, 2016 at 1:54 AM, Chris Higgs<EMAIL_ADDRESS>wrote:

@cfswanson https://github.com/cfswanson you are correct - the problem
here is that when you import numpy your PYTHONPATH is pointing to the
64-bit version. numpy has loads of C extensions which it can't load
because they're 64-bit libraries.
You'll need to try and install 32-bit numpy: sudo apt-get install
python-numpy:i686 python-scipy:i686
—
Reply to this email directly or view it on GitHub
https://github.com/potentialventures/cocotb/issues/137#issuecomment-192598066
.

--
Craig Swanson
770-298-9156
<EMAIL_ADDRESS>Cumming, GA 30040

Hi @cfswanson,
Overriding generics in modelsim is already supported. I haven't tried setting reals, but integers can be set like this from the command line:
> make GENERICS="fractionalBits=20 linearBitWidth=16"

Note that there is currently an issue: different values of GENERICS on successive invocations of make are not picked up correctly. You can get around this problem by always doing make clean before you change the GENERICS.
runsim.do is generated by Makefile.questa and as you already discovered, it's not a good idea to edit this file directly as it will be overwritten when the make dependencies change. You can take some inspiration from Makefile.aldec and insert following snippet to Makefile.questa at line 79:
ifdef SCRIPT_FILE
	echo "do $(SCRIPT_FILE)" >> $@
endif

Then put whatever commands you need in a my_script.do file and set the SCRIPT_FILE variable from the command line:
> make SCRIPT_FILE="my_script.do"

Hope this helps

Luke,
I installed and got working cocotb with Modelsim DE 10.4c and Xilinx Vivado
2015.2 under Ubuntu 14.04 running on my Windows 7 Virtualbox.   After
spending a few weeks getting to know cocotb, I decided to revisit the
initial installation which I thrashed around until I got working.  Now I
want to make sure I can repeat the install process.  The first time I got
cocotb working it was by accident.  What I mean by that is that I was
trying different commands and stumbled upon a command that suddently worked.
So now I am trying to repeat the process:

Fresh install of Ubuntu 14.04 running under Windows 7 Virtualbox
Installed Guest Additions
Installed Linux Xilinx Vivado System Edition 2015.2
Installed Linux Modelsim DE 10.4c
Installed Ettus Research USRP FPGA HDL Source (
https://github.com/EttusResearch/fpga) which is the environment that
Modelsim and Vivado will be running under
Installed git clone https://github.com/pentialventures/cocotb.  So
now cocotb is located at craig@craig-VirtualBox
:~/cocotb/examples/adder/tests$
Followed your instructions above:

sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt-get install -y build-essential
sudo apt-get install -y gcc-multilib g++-multilib lib32z1
lib32stdc++6 lib32gcc1 expat:i386 fontconfig:i386 libfreetype6:i386
libexpat1:i386 libc6:i386 libgtk-3-0:i386 libcanberra0:i386
libpng12-0:i386 libice6:i386 libsm6:i386 libncurses5:i386 zlib1g:i386
libx11-6:i386 libxau6:i386 libxdmcp6:i386 libxext6:i386 libxft2:i386
libxrender1:i386 libxt6:i386 libxtst6:i386

Received the error:craig@craig-VirtualBox:~/cocotb/examples/adder/tests$
make SIM=modelsim ARCH=i686
make results.xml
make[1]: Entering directory /home/craig/cocotb/examples/adder/tests' mkdir -p sim_build echo "if [file exists work] {vdel -lib work -all}" > sim_build/runsim.do echo "vlib work" >> sim_build/runsim.do echo "vlog -work work +define+COCOTB_SIM -timescale 1ns/100ps -mfcu +acc=rmb -sv  /home/craig/cocotb/examples/adder/tests/../hdl/adder.v" >> sim_build/runsim.do echo "vsim -onfinish exit -pli libvpi.so work.adder" >> sim_build/runsim.do echo "run -all" >> sim_build/runsim.do echo "quit" >> sim_build/runsim.do mkdir -p /home/craig/cocotb/build/obj/i686 mkdir -p /home/craig/cocotb/build/libs/i686 make -C /home/craig/cocotb/lib/utils make[2]: Entering directory /home/craig/cocotb/lib/utils'
gcc -m32 -Werror -Wcast-qual -Wcast-align -Wwrite-strings -Wall
-Wno-unused-parameter -fno-common -g -DDEBUG -fpic -Wstrict-prototypes
-Waggregate-return -c -I/home/craig/cocotb/include
-I/usr/include/python2.7  -o
/home/craig/cocotb/build/obj/i686/cocotb_utils.o cocotb_utils.c
gcc -m32 -Werror -Wcast-qual -Wcast-align -Wwrite-strings -Wall
-Wno-unused-parameter -fno-common -g -DDEBUG -fpic -Wstrict-prototypes
-Waggregate-return -shared -Xlinker -L/usr/lib -o
/home/craig/cocotb/build/libs/i686/libcocotbutils.so
/home/craig/cocotb/build/obj/i686/cocotb_utils.o
make[2]: Leaving directory /home/craig/cocotb/lib/utils' make -C /home/craig/cocotb/lib/gpi_log make[2]: python-config: Command not found make[2]: Entering directory /home/craig/cocotb/lib/gpi_log'
gcc -m32 -Werror -Wcast-qual -Wcast-align -Wwrite-strings -Wall
-Wno-unused-parameter -fno-common -g -DDEBUG -fpic -Wstrict-prototypes
-Waggregate-return -DFILTER -c -I/home/craig/cocotb/include
-I/usr/include/python2.7  -o
/home/craig/cocotb/build/obj/i686/gpi_logging.o gpi_logging.c
gpi_logging.c:30:20: fatal error: Python.h: No such file or directory
#include <Python.h>
^
compilation terminated.
make[2]: *** [/home/craig/cocotb/build/obj/i686/gpi_logging.o] Error 1
make[2]: Leaving directory /home/craig/cocotb/lib/gpi_log' make[1]: *** [/home/craig/cocotb/build/libs/i686/libgpilog.so] Error 2 make[1]: Leaving directory /home/craig/cocotb/examples/adder/tests'
make: *** [sim] Error 2

On Mon, Feb 22, 2016 at 5:50 AM, Chris Higgs<EMAIL_ADDRESS>wrote:

I have experimented with using Modelsim on Travis-CI using their Ubuntu
14.04 Trusty infrastructure.
To use Cocotb from a fresh OS install is relatively straightforward using
the system package manager to install necessary 32-bit libraries:
sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt-get install -y build-essential
sudo apt-get install -y gcc-multilib g++-multilib lib32z1 lib32stdc++6 lib32gcc1 expat:i386 fontconfig:i386 libfreetype6:i386 libexpat1:i386 libc6:i386 libgtk-3-0:i386 libcanberra0:i386 libpng12-0:i386 libice6:i386 libsm6:i386 libncurses5:i386 zlib1g:i386 libx11-6:i386 libxau6:i386 libxdmcp6:i386 libxext6:i386 libxft2:i386 libxrender1:i386 libxt6:i386 libxtst6:i386
Then to run Cocotb:
make SIM=modelsim ARCH=i686
—
Reply to this email directly or view it on GitHub
https://github.com/potentialventures/cocotb/issues/137#issuecomment-187120965
.

--
Craig Swanson
770-298-9156
<EMAIL_ADDRESS>Cumming, GA 30040

@cfswanson the error is telling you that Python.h is missing on your system.
Typically, you can resolve such errors by determining what package you need to install to provide this file.  This can be done in various ways (see this answer for some suggestions.
In this case, Python.h is provided by the python-dev package.  Given that you're trying to run using Modelsim 32-bit, it's probably safest to install both 64-bit and 32-bit packages whenever you're installing a dependency package, e.g python-dev and python-dev:i386.

Luke,
I am close to being able to exactly replicate my install repeatedly with
reliability.  The last hurdle I seem to be running into is when I run "make
SIM=modelsim ARCH=i686", I get the following errors:
make[2]: python-config: Command not found
** Error (suppressible): (vsim-3197) Load of
"/home/craig/cocotb/build/libs/i686/libvpi.so" failed:
/home/craig/cocotb/build/libs/i686/libgpilog.so: undefined symbol:
_Py_TrueStruct.
** Error (suppressible): (vsim-PLI-3002) Failed to load PLI object file
"/home/craig/cocotb/build/libs/i686/libvpi.so".
Here are more details:
make[2]: Leaving directory /home/craig/cocotb/lib/embed' make -C /home/craig/cocotb/lib/gpi EXTRA_LIBS= EXTRA_LIBDIRS= make[2]: Entering directory /home/craig/cocotb/lib/gpi'
g++ -m32 -Werror -Wcast-qual -Wcast-align -Wwrite-strings -Wall
-Wno-unused-parameter -fno-common -g -DDEBUG -fpic -DVPI_CHECKING
-DLIB_EXT=so -DSINGLETON_HANDLES -c -I/home/craig/cocotb/include
-I/usr/include/python2.7  -o /home/craig/cocotb/build/obj/i686/GpiCbHdl.o
GpiCbHdl.cpp
g++ -m32 -Werror -Wcast-qual -Wcast-align -Wwrite-strings -Wall
-Wno-unused-parameter -fno-common -g -DDEBUG -fpic -DVPI_CHECKING
-DLIB_EXT=so -DSINGLETON_HANDLES -c -I/home/craig/cocotb/include
-I/usr/include/python2.7  -o /home/craig/cocotb/build/obj/i686/GpiCommon.o
GpiCommon.cpp
gcc -m32 -Werror -Wcast-qual -Wcast-align -Wwrite-strings -Wall
-Wno-unused-parameter -fno-common -g -DDEBUG -fpic -DVPI_CHECKING
-DLIB_EXT=so -DSINGLETON_HANDLES -Wstrict-prototypes -Waggregate-return
-shared -Xlinker -L/usr/lib -o
/home/craig/cocotb/build/libs/i686/libgpi.so
/home/craig/cocotb/build/obj/i686/GpiCbHdl.o
/home/craig/cocotb/build/obj/i686/GpiCommon.o  -lcocotbutils -lgpilog
-lcocotb -lstdc++ -L/home/craig/cocotb/build/libs/i686
make[2]: Leaving directory /home/craig/cocotb/lib/gpi' make -C /home/craig/cocotb/lib/simulator make[2]: python-config: Command not found make[2]: Entering directory /home/craig/cocotb/lib/simulator'
vsim -onfinish exit -pli "libvpi.so" work.adder
Start time: 20:04:44 on Mar 13,2016
//  ModelSim DE 10.4c Jul 19 2015 Linux 3.16.0-30-generic
//
//  Copyright 1991-2015 Mentor Graphics Corporation
//  All Rights Reserved.

//
Loading sv_std.std
Loading work.adder
Loading /home/craig/cocotb/build/libs/i686/libvpi.so
** Error (suppressible): (vsim-3197) Load of
"/home/craig/cocotb/build/libs/i686/libvpi.so" failed:
/home/craig/cocotb/build/libs/i686/libgpilog.so: undefined symbol:
_Py_TrueStruct.
** Error (suppressible): (vsim-PLI-3002) Failed to load PLI object file
"/home/craig/cocotb/build/libs/i686/libvpi.so".
Time: 0 ps  Iteration: 0  Root: /
Error loading design
Error loading design
End time: 20:04:47 on Mar 13,2016, Elapsed time: 0:00:03
Errors: 2, Warnings: 0
make[1]: Leaving directory `/home/craig/cocotb/examples/adder/tests'
craig@craig-VirtualBox:~/cocotb/examples/adder/tests$
On Wed, Feb 24, 2016 at 11:51 PM, Luke Darnell<EMAIL_ADDRESS>wrote:

Looks good Craig.
On 25 Feb 2016, at 2:08 PM, Craig Swanson<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
Luke,
I think I just had a HUGE breakthrough. I decided to run "make clean".
Then I ran "make SIM=modelsim ARCH=i686" and now I think it works!
Please look at the output from my terminal window and tell me if this is
correct.

//
Loading sv_std.std
Loading work.sample_module_v_unit
Loading work.sample_module
Loading /home/craig/cocotb/build/libs/i686/libvpi.so
-.--ns INFO cocotb.gpi
GpiCommon.cpp:91 in gpi_print_registered_impl VPI registered
0.00ns INFO cocotb.gpi
gpi_embed.c:248 in embed_sim_init Running on ModelSim DE
version 10.4c 2015.07
0.00ns INFO cocotb.gpi
gpi_embed.c:249 in embed_sim_init Python interpreter
initialised and cocotb loaded!
0.00ns INFO cocotb
init.py:115 in _initialise_testbench Running tests with
Cocotb v1.0 from /home/craig/cocotb
0.00ns INFO cocotb
init.py:131 in _initialise_testbench Seeding Python random
module with<PHONE_NUMBER>
0.00ns INFO cocotb.regression
regression.py:161 in initialise Found test
issue_120.issue_120_scheduling
0.00ns INFO cocotb.regression
regression.py:262 in execute Running test 1/1:
issue_120_scheduling
0.00ns INFO ..e.issue_120_scheduling.0x57776a4c
decorators.py:189 in send Starting test:
"issue_120_scheduling"

Description: None
15.00ns INFO cocotb.regression
regression.py:209 in handle_result Test Passed:
issue_120_scheduling
15.00ns INFO cocotb.regression
regression.py:170 in tear_down Passed 1 tests (0
skipped)
15.00ns INFO cocotb.regression
regression.py:176 in tear_down Shutting down...
** Note: $finish : UNKNOWN(-1)
Time: 15001 ps Iteration: 0 Instance: /sample_module
End time: 22:03:27 on Feb 24,2016, Elapsed time: 0:00:03
Errors: 0, Warnings: 0
make[3]: Leaving directory /home/craig/cocotb/tests/test_cases/issue_120' make[2]: Leaving directory /home/craig/cocotb/tests/test_cases/issue_120'
cd test_cases/issue_134 && make
make[2]: Entering directory /home/craig/cocotb/tests/test_cases/issue_134' make results.xml make[3]: Entering directory /home/craig/cocotb/tests/test_cases/issue_134'
cd sim_build &&
LD_LIBRARY_PATH=/home/craig/cocotb/build/libs/i686::/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib
MODULE=test_reals,test_integers TESTCASE= TOPLEVEL=sample_module
GPI_EXTRA= TOPLEVEL_LANG=verilog
PYTHONPATH=/home/craig/cocotb/build/libs/i686:/home/craig/cocotb:/home/craig/cocotb/tests/test_cases/issue_134:

vsim -c -do runsim.do 2>&1 | tee sim.log
Reading pref.tcl
10.4c
do runsim.do
Model Technology ModelSim DE vlog 10.4c Compiler 2015.07 Jul 19 2015
Start time: 22:03:30 on Feb 24,2016
vlog -work work -timescale 1ns/100ps -mfcu "+acc=rmb" -sv
/home/craig/cocotb/tests/test_cases/issue_134/../../../tests/designs/sample_module/sample_module.v
-- Compiling package sample_module_v_unit
-- Compiling module sample_module

Top level modules:
sample_module
End time: 22:03:30 on Feb 24,2016, Elapsed time: 0:00:00
Errors: 0, Warnings: 0
vsim -onfinish exit -pli "libvpi.so" work.sample_module
Start time: 22:03:30 on Feb 24,2016
// ModelSim DE 10.4c Jul 19 2015 Linux 3.16.0-45-generic
//
// Copyright 1991-2015 Mentor Graphics Corporation
// All Rights Reserved.

//
Loading sv_std.std
Loading work.sample_module_v_unit
Loading work.sample_module
Loading /home/craig/cocotb/build/libs/i686/libvpi.so
-.--ns INFO cocotb.gpi
GpiCommon.cpp:91 in gpi_print_registered_impl VPI registered
0.00ns INFO cocotb.gpi
gpi_embed.c:248 in embed_sim_init Running on ModelSim DE
version 10.4c 2015.07
0.00ns INFO cocotb.gpi
gpi_embed.c:249 in embed_sim_init Python interpreter
initialised and cocotb loaded!
0.00ns INFO cocotb
init.py:115 in _initialise_testbench Running tests with
Cocotb v1.0 from /home/craig/cocotb
0.00ns INFO cocotb
init.py:131 in _initialise_testbench Seeding Python random
module with<PHONE_NUMBER>
0.00ns INFO cocotb.regression
regression.py:161 in initialise Found test
cocotb.decorators.test_integer
0.00ns INFO cocotb.regression
regression.py:161 in initialise Found test
test_reals.assign_double
0.00ns INFO cocotb.regression
regression.py:262 in execute Running test 1/2:
test_integer
0.00ns INFO ..coroutine.test_integer.0x57776d2c
decorators.py:189 in send Starting test:
"test_integer"

Description: None
0.00ns INFO ..coroutine.test_integer.0x57776bac
decorators.py:189 in send Starting test:
"test_integer"

Description:

Test access to integers

0.03ns INFO cocotb.test
test_integers.py:25 in test_integer dut.stream_out_int
= 4
0.03ns INFO cocotb.test
test_integers.py:26 in test_integer dut.stream_in_int
= 4
0.03ns INFO ..coroutine.test_integer.0x57776d2c
decorators.py:199 in send
0.03ns INFO cocotb.regression
regression.py:209 in handle_result Test Passed:
test_integer
0.03ns INFO cocotb.regression
regression.py:262 in execute Running test 2/2:
assign_double
0.03ns INFO ..oroutine.assign_double.0x577766ec
decorators.py:189 in send Starting test:
"assign_double"

Description:

Assign a random floating point value, read it back from the DUT and check

it matches what we assigned

0.03ns INFO cocotb.test
test_reals.py:21 in assign_double Setting the value
2.98395e+307
0.03ns INFO cocotb.test
test_reals.py:26 in assign_double Read back value
2.98395e+307
0.03ns INFO cocotb.regression
regression.py:209 in handle_result Test Passed:
assign_double
0.03ns INFO cocotb.regression
regression.py:170 in tear_down Passed 2 tests (0
skipped)
0.03ns INFO cocotb.regression
regression.py:176 in tear_down Shutting down...
** Note: $finish : UNKNOWN(-1)
Time: 35 ps Iteration: 0 Instance: /sample_module
End time: 22:03:33 on Feb 24,2016, Elapsed time: 0:00:03
Errors: 0, Warnings: 0
make[3]: Leaving directory /home/craig/cocotb/tests/test_cases/issue_134' make[2]: Leaving directory /home/craig/cocotb/tests/test_cases/issue_134'
cd test_cases/issue_142 && make
make[2]: Entering directory /home/craig/cocotb/tests/test_cases/issue_142' make results.xml make[3]: Entering directory /home/craig/cocotb/tests/test_cases/issue_142'
cd sim_build &&
LD_LIBRARY_PATH=/home/craig/cocotb/build/libs/i686::/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib
MODULE=issue_142 TESTCASE= TOPLEVEL=sample_module
GPI_EXTRA= TOPLEVEL_LANG=verilog
PYTHONPATH=/home/craig/cocotb/build/libs/i686:/home/craig/cocotb:/home/craig/cocotb/tests/test_cases/issue_142:

vsim -c -do runsim.do 2>&1 | tee sim.log
Reading pref.tcl
10.4c
do runsim.do
Model Technology ModelSim DE vlog 10.4c Compiler 2015.07 Jul 19 2015
Start time: 22:03:37 on Feb 24,2016
vlog -work work -timescale 1ns/100ps -mfcu "+acc=rmb" -sv
/home/craig/cocotb/tests/test_cases/issue_142/../../../tests/designs/sample_module/sample_module.v
-- Compiling package sample_module_v_unit
-- Compiling module sample_module

Top level modules:
sample_module
End time: 22:03:37 on Feb 24,2016, Elapsed time: 0:00:00
Errors: 0, Warnings: 0
vsim -onfinish exit -pli "libvpi.so" work.sample_module
Start time: 22:03:37 on Feb 24,2016
// ModelSim DE 10.4c Jul 19 2015 Linux 3.16.0-45-generic
//
// Copyright 1991-2015 Mentor Graphics Corporation
// All Rights Reserved.

//
Loading sv_std.std
Loading work.sample_module_v_unit
Loading work.sample_module
Loading /home/craig/cocotb/build/libs/i686/libvpi.so
-.--ns INFO cocotb.gpi
GpiCommon.cpp:91 in gpi_print_registered_impl VPI registered
0.00ns INFO cocotb.gpi
gpi_embed.c:248 in embed_sim_init Running on ModelSim DE
version 10.4c 2015.07
0.00ns INFO cocotb.gpi
gpi_embed.c:249 in embed_sim_init Python interpreter
initialised and cocotb loaded!
0.00ns INFO cocotb
init.py:115 in _initialise_testbench Running tests with
Cocotb v1.0 from /home/craig/cocotb
0.00ns INFO cocotb
init.py:131 in _initialise_testbench Seeding Python random
module with<PHONE_NUMBER>
0.00ns INFO cocotb.regression
regression.py:161 in initialise Found test
issue_142.issue_142_overflow_error
0.00ns INFO cocotb.regression
regression.py:262 in execute Running test 1/1:
issue_142_overflow_error
0.00ns INFO ..sue_142_overflow_error.0x5777674c
decorators.py:189 in send Starting test:
"issue_142_overflow_error"

Description: Tranparently convert ints too long to pass

through the GPI interface natively into BinaryValues
17.50ns INFO cocotb.regression
regression.py:209 in handle_result Test Passed:
issue_142_overflow_error
17.50ns INFO cocotb.regression
regression.py:170 in tear_down Passed 1 tests (0
skipped)
17.50ns INFO cocotb.regression
regression.py:176 in tear_down Shutting down...
** Note: $finish : UNKNOWN(-1)
Time: 17501 ps Iteration: 0 Instance: /sample_module
End time: 22:03:40 on Feb 24,2016, Elapsed time: 0:00:03
Errors: 0, Warnings: 0
make[3]: Leaving directory /home/craig/cocotb/tests/test_cases/issue_142' make[2]: Leaving directory /home/craig/cocotb/tests/test_cases/issue_142'
cd test_cases/issue_253 && make
make[2]: Entering directory /home/craig/cocotb/tests/test_cases/issue_253' Skipping issue_253 only runs on icarus make[2]: Leaving directory /home/craig/cocotb/tests/test_cases/issue_253'
cd test_cases/issue_330 && make
make[2]: Entering directory /home/craig/cocotb/tests/test_cases/issue_330' make results.xml make[3]: Entering directory /home/craig/cocotb/tests/test_cases/issue_330'
cd sim_build &&
LD_LIBRARY_PATH=/home/craig/cocotb/build/libs/i686::/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib
MODULE=issue_330 TESTCASE= TOPLEVEL=sample_module
GPI_EXTRA= TOPLEVEL_LANG=verilog
PYTHONPATH=/home/craig/cocotb/build/libs/i686:/home/craig/cocotb:/home/craig/cocotb/tests/test_cases/issue_330:

vsim -c -do runsim.do 2>&1 | tee sim.log
Reading pref.tcl
10.4c
do runsim.do
Model Technology ModelSim DE vlog 10.4c Compiler 2015.07 Jul 19 2015
Start time: 22:03:43 on Feb 24,2016
vlog -work work -timescale 1ns/100ps -mfcu "+acc=rmb" -sv
/home/craig/cocotb/tests/test_cases/issue_330/../../../tests/designs/sample_module/sample_module.v
-- Compiling package sample_module_v_unit
-- Compiling module sample_module

Top level modules:
sample_module
End time: 22:03:43 on Feb 24,2016, Elapsed time: 0:00:00
Errors: 0, Warnings: 0
^C^C^CSegmentation fault (core dumped)
make[3]: *** [results.xml] Interrupt
make[2]: *** [sim] Interrupt
make[1]: *** [issue_330] Interrupt
make: *** [do_tests] Interrupt
craig@craig-VirtualBox:~/cocotb (master)$
On Wed, Feb 24, 2016 at 8:52 PM, Luke Darnell<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:

Craig,
My guess is that the python lib dir isn't successfully being added to
LD_LIBRARY_PATH.
See the empty 2nd entry:

LD_LIBRARY_PATH=/home/craig/cocotb/build/libs/i686::/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib

The makefile fragment that sets this is in
cocotb/makefiles/Makefile.pylib.Linux
You'll need to do some debug and figure out why PYTHON_LIBDIR isn't being
set.
Can you try running this command:
python -c 'from future import print_function; from distutils import
sysconfig; print(sysconfig.get_config_var("LIBDIR"))'
Luke

From: Craig Swanson<EMAIL_ADDRESS><EMAIL_ADDRESS>

Sent: Tuesday, 23 February 2016 4:34 PM
To: potentialventures/cocotb
Cc: Luke Darnell
Subject: Re: [cocotb] Modelsim as a simulator in 64-bit platform (#137)
Luke,
Sorry for being so brain dead. I appreciate your feedback.
So I cleaned up my repository with the following commands:
sudo apt-get autoremove
sudo apt-get update
sudo apt-get install python2.7:i386
sudo apt-get python2.7-dev:i386
then re-ran the make file and saw it was calling "python" so I did the
following:
/usr/bin/ sudo ln -s python2.7 python
Now when I run it, I get the following error:
Error Message: (vsim-50) A call to
system("/opt/mentor/modelsim/modelsim_dlx/gcc-4.7.4-linux/bin/c++filt"
"_Py_TrueStruct" >'/tmp/questatmp.U7imPr' 2>&1) returned error code
'127'.
[Probably a bad shell].
The logfile contains the following messages:
sh: 1: /opt/mentor/modelsim/modelsim_dlx/gcc-4.7.4-linux/bin/c++filt: not
found
Here is the short history on my terminal screen:
craig@craig-VirtualBox:~/cocotb (master)$ make SIM=modelsim ARCH=i686
make -k -C tests
make[1]: Entering directory /home/craig/cocotb/tests' cd test_cases/issue_120 && make make[2]: Entering directory /home/craig/cocotb/tests/test_cases/issue_120'
make results.xml
make[3]: Entering directory
`/home/craig/cocotb/tests/test_cases/issue_120'
cd sim_build &&

LD_LIBRARY_PATH=/home/craig/cocotb/build/libs/i686::/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib:/usr/lib

MODULE=issue_120 TESTCASE= TOPLEVEL=sample_module
GPI_EXTRA= TOPLEVEL_LANG=verilog

PYTHONPATH=/home/craig/cocotb/build/libs/i686:/home/craig/cocotb:/home/craig/cocotb/tests/test_cases/issue_120:

vsim -c -do runsim.do 2>&1 | tee sim.log
Reading pref.tcl
10.4c
do runsim.do
Model Technology ModelSim DE vlog 10.4c Compiler 2015.07 Jul 19 2015
Start time: 11:19:53 on Feb 23,2016
vlog -work work -timescale 1ns/100ps -mfcu "+acc=rmb" -sv

/home/craig/cocotb/tests/test_cases/issue_120/../../../tests/designs/sample_module/sample_module.v

-- Compiling package sample_module_v_unit
-- Compiling module sample_module

Top level modules:
sample_module
End time: 11:19:53 on Feb 23,2016, Elapsed time: 0:00:00
Errors: 0, Warnings: 0
vsim -onfinish exit -pli "libvpi.so" work.sample_module
Start time: 11:19:53 on Feb 23,2016
// ModelSim DE 10.4c Jul 19 2015 Linux 3.16.0-45-generic
//
// Copyright 1991-2015 Mentor Graphics Corporation
// All Rights Reserved.

//
Error Message: (vsim-50) A call to
system("/opt/mentor/modelsim/modelsim_dlx/gcc-4.7.4-linux/bin/c++filt"
"_Py_TrueStruct" >'/tmp/questatmp.U7imPr' 2>&1) returned error code
'127'.
[Probably a bad shell].
The logfile contains the following messages:
sh: 1: /opt/mentor/modelsim/modelsim_dlx/gcc-4.7.4-linux/bin/c++filt: not
found
No such file or directory. (errno = ENOENT)
Loading sv_std.std
Loading work.sample_module_v_unit
Loading work.sample_module
Loading /home/craig/cocotb/build/libs/i686/libvpi.so
** Error (suppressible): (vsim-3197) Load of
"/home/craig/cocotb/build/libs/i686/libvpi.so" failed:
/home/craig/cocotb/build/libs/i686/libgpilog.so: undefined symbol:
_Py_TrueStruct.
** Error (suppressible): (vsim-PLI-3002) Failed to load PLI object file
"/home/craig/cocotb/build/libs/i686/libvpi.so".
Time: 0 ps Iteration: 0 Root: /
Error loading design
Error loading design
On Tue, Feb 23, 2016 at 6:20 AM, Luke Darnell<EMAIL_ADDRESS><EMAIL_ADDRESS>

wrote:

Following the clues from the command outputs will usually give you some
clues.
In this case, apt needs to install python2.7:i386 before you can
install
the package that gives you the Python headers
(python2.7:i386).
What does "sudo apt-get install python2.7:i386" tell you?
Luke
On 23 Feb 2016, at 2:10 PM, Craig Swanson<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
Stuart,
Thank you again for your support. I am anxious to get through this
phase
so any help you can give is much appreciated.
Here are my results:
craig@craig-VirtualBox:~/cocotb (master)$ sudo apt-get install
python2.7-dev:i386
[sudo] password for craig:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
python2.7-dev:i386 : Depends: python2.7:i386 (= 2.7.6-8ubuntu0.2) but
it
is not going to be installed
E: Unable to correct problems, you have held broken packages.
On Mon, Feb 22, 2016 at 8:47 PM, Stuart Hodgson <
notifications<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:

@cfswanson https://github.com/cfswanson,
Since modelsim in your case is 32bit you must have ARCH=i686 set when
you
call make, you where doing this earlier.
The error you are seeing when running make while having ARCH set
seems
to
be because the python header file is not installed
$> sudo apt-get install python2.7-dev:i386
Stuart

Reply to this email directly or view it on GitHub
<

https://github.com/potentialventures/cocotb/issues/137#issuecomment-187471070

.

Reply to this email directly or view it on GitHub<

https://github.com/potentialventures/cocotb/issues/137#issuecomment-187501545

.

Reply to this email directly or view it on GitHub
<

https://github.com/potentialventures/cocotb/issues/137#issuecomment-187659117

.

Reply to this email directly or view it on GitHub<

https://github.com/potentialventures/cocotb/issues/137#issuecomment-187777221

.

Reply to this email directly or view it on GitHub
<
https://github.com/potentialventures/cocotb/issues/137#issuecomment-188557566
.

Reply to this email directly or view it on GitHub<
https://github.com/potentialventures/cocotb/issues/137#issuecomment-188581215

.

—
Reply to this email directly or view it on GitHub
https://github.com/potentialventures/cocotb/issues/137#issuecomment-188614536
.

--
Craig Swanson
770-298-9156
<EMAIL_ADDRESS>Cumming, GA 30040

elgorwi,
Thanks for the tip.  That is definitely helpful and I will try it out right
now.
Craig
On Wed, Mar 9, 2016 at 5:03 AM, elgorwi<EMAIL_ADDRESS>wrote:

Hi @cfswanson https://github.com/cfswanson,
Overriding generics in modelsim is already supported. I haven't tried
setting reals, but integers can be set like this from the command line:

make GENERICS="fractionalBits=20 linearBitWidth=16"

Note that there is currently an issue: different values of GENERICS on
successive invocations of make are not picked up correctly. You can get
around this problem by always doing make clean before you change the
GENERICS.
runsim.do is generated by Makefile.questa and as you already discovered,
it's not a good idea to edit this file directly as it will be overwritten
when the make dependencies change. You can take some inspiration from
Makefile.aldec and insert following snippet to Makefile.questa at line 79:
ifdef SCRIPT_FILE
echo "do $(SCRIPT_FILE)" >> $@endif
Then put whatever commands you need in a my_script.do file and set the
SCRIPT_FILE variable from the command line:

make SCRIPT_FILE="my_script.do"

Hope this helps
—
Reply to this email directly or view it on GitHub
https://github.com/potentialventures/cocotb/issues/137#issuecomment-194218849
.

--
Craig Swanson
770-298-9156
<EMAIL_ADDRESS>Cumming, GA 30040

elgorwi,
I could be wrong, but it appears the GENERICS option is not working.
Here is a little bit of my source code:
agc_wrapper #(
.MAX_LEN_LOG2(12),
.WIDTH(32))
agc_wrapper_i_inst (
.clk(ce_clk),
.reset(ce_rst),
Here is a little bit of my command output
craig@craig-VirtualBox:~/cocotb/examples/receiver/tests (master)$ make
GENERICS="MAX_LEN_LOG2=12 WIDTH=32"
...
..
.
-- Compiling entity agc_wrapper
-- Compiling architecture Structural of agc_wrapper
End time: 16:20:45 on Mar 29,2016, Elapsed time: 0:00:00
Errors: 0, Warnings: 0
vsim -onfinish exit -foreign "cocotb_init libfli.so" work.agc_wrapper
Start time: 16:20:45 on Mar 29,2016
//  ModelSim DE 10.4c Jul 19 2015 Linux 3.16.0-30-generic
//
//  Copyright 1991-2015 Mentor Graphics Corporation
//  All Rights Reserved.

//
Loading std.standard
Loading std.textio(body)
Loading ieee.std_logic_1164(body)
Loading ieee.numeric_std(body)
Loading work.agc_wrapper(structural)
** Fatal: (vsim-3350) Generic "MAX_LEN_LOG2" has not been given a value.
Time: 0 ns  Iteration: 0  Instance: /agc_wrapper File:
/home/craig/uhd/rfnoc-devel/usrp3/lib/rfnoc/agc_wrapper.vhd Line: 9
FATAL ERROR while loading design
Error loading design
Error loading design
End time: 16:20:45 on Mar 29,2016, Elapsed time: 0:00:00
Errors: 1, Warnings: 0
make[1]: Leaving directory `/home/craig/cocotb/examples/receiver/tests'
On Wed, Mar 9, 2016 at 5:03 AM, elgorwi<EMAIL_ADDRESS>wrote:

Hi @cfswanson https://github.com/cfswanson,
Overriding generics in modelsim is already supported. I haven't tried
setting reals, but integers can be set like this from the command line:

make GENERICS="fractionalBits=20 linearBitWidth=16"

Note that there is currently an issue: different values of GENERICS on
successive invocations of make are not picked up correctly. You can get
around this problem by always doing make clean before you change the
GENERICS.
runsim.do is generated by Makefile.questa and as you already discovered,
it's not a good idea to edit this file directly as it will be overwritten
when the make dependencies change. You can take some inspiration from
Makefile.aldec and insert following snippet to Makefile.questa at line 79:
ifdef SCRIPT_FILE
echo "do $(SCRIPT_FILE)" >> $@endif
Then put whatever commands you need in a my_script.do file and set the
SCRIPT_FILE variable from the command line:

make SCRIPT_FILE="my_script.do"

Hope this helps
—
Reply to this email directly or view it on GitHub
https://github.com/potentialventures/cocotb/issues/137#issuecomment-194218849
.

--
Craig Swanson
770-298-9156
<EMAIL_ADDRESS>Cumming, GA 30040

Luke,
I am making good progress in using cocotb and I am finding it very useful.
So now I am trying to simulate a Xilinx axi_fir from their FIR compiler
v7.2.5 and I am getting protected region errors in when using Modelsim.
How can I get around this?
Here is the output:
do runsim.do
Model Technology ModelSim DE vmap 10.4c Lib Mapping Utility 2015.07 Jul
19 2015
vmap fir_compiler_v7_2_5 fir_compiler_v7_2_5
Copying /opt/mentor/modelsim/modelsim_dlx/linuxpe/../modelsim.ini to
modelsim.ini
Modifying modelsim.ini
Model Technology ModelSim DE vcom 10.4c Compiler 2015.07 Jul 19 2015
Start time: 16:58:42 on Mar 30,2016
vcom -work fir_compiler_v7_2_5
/home/craig/uhd/rfnoc-devel/usrp3/lib/rfnoc/noc_block_Receiver_tb/build-ip/xc7k410tffg900-2/axi_fir/fir_compiler_v7_2_5/hdl/fir_compiler_v7_2_vh_rfs.vhd
~/uhd/rfnoc-devel/usrp3/lib/rfnoc/noc_block_Receiver_tb/build-ip/xc7k410tffg900-2/axi_fir/fir_compiler_v7_2_5/hdl/fir_compiler_v7_2_5.vhd
-- Loading package STANDARD
** Error:
/home/craig/uhd/rfnoc-devel/usrp3/lib/rfnoc/noc_block_Receiver_tb/build-ip/xc7k410tffg900-2/axi_fir/fir_compiler_v7_2_5/hdl/fir_compiler_v7_2_vh_rfs.vhd(51):
in protected region
** Error:
/home/craig/uhd/rfnoc-devel/usrp3/lib/rfnoc/noc_block_Receiver_tb/build-ip/xc7k410tffg900-2/axi_fir/fir_compiler_v7_2_5/hdl/fir_compiler_v7_2_vh_rfs.vhd(52):
(vcom-1136) Unknown identifier "".
** Error:
/home/craig/uhd/rfnoc-devel/usrp3/lib/rfnoc/noc_block_Receiver_tb/build-ip/xc7k410tffg900-2/axi_fir/fir_compiler_v7_2_5/hdl/fir_compiler_v7_2_vh_rfs.vhd(54):
VHDL Compiler exiting
End time: 16:58:42 on Mar 30,2016, Elapsed time: 0:00:00
Errors: 3, Warnings: 0
** Error: /opt/mentor/modelsim/modelsim_dlx/linuxpe/vcom failed.
Error in macro ./runsim.do line 5
Craig
On Sun, Feb 21, 2016 at 6:13 PM, Luke Darnell<EMAIL_ADDRESS>wrote:

@cfswanson https://github.com/cfswanson What were your problems
exactly?
Hard to help without some specific error messages or problems.
Posting you command line output is a good start.
—
Reply to this email directly or view it on GitHub
https://github.com/potentialventures/cocotb/issues/137#issuecomment-186941000
.

--
Craig Swanson
770-298-9156
<EMAIL_ADDRESS>Cumming, GA 30040

Hi Craig,
I think there's some hoops to jump through to get the Xilinx encrypted vhdl to run in modelsim.
Google throws up a few answers on this topic.
This is a general problem with including encrypted ip and not related to cocotb.
Luke
On 31 Mar 2016, at 8:06 AM, Craig Swanson <notifications<EMAIL_ADDRESS>wrote:
Luke,
I am making good progress in using cocotb and I am finding it very useful.
So now I am trying to simulate a Xilinx axi_fir from their FIR compiler
v7.2.5 and I am getting protected region errors in when using Modelsim.
How can I get around this?
Here is the output:
do runsim.do
Model Technology ModelSim DE vmap 10.4c Lib Mapping Utility 2015.07 Jul
19 2015
vmap fir_compiler_v7_2_5 fir_compiler_v7_2_5
Copying /opt/mentor/modelsim/modelsim_dlx/linuxpe/../modelsim.ini to
modelsim.ini
Modifying modelsim.ini
Model Technology ModelSim DE vcom 10.4c Compiler 2015.07 Jul 19 2015
Start time: 16:58:42 on Mar 30,2016
vcom -work fir_compiler_v7_2_5
/home/craig/uhd/rfnoc-devel/usrp3/lib/rfnoc/noc_block_Receiver_tb/build-ip/xc7k410tffg900-2/axi_fir/fir_compiler_v7_2_5/hdl/fir_compiler_v7_2_vh_rfs.vhd
~/uhd/rfnoc-devel/usrp3/lib/rfnoc/noc_block_Receiver_tb/build-ip/xc7k410tffg900-2/axi_fir/fir_compiler_v7_2_5/hdl/fir_compiler_v7_2_5.vhd
-- Loading package STANDARD
** Error:
/home/craig/uhd/rfnoc-devel/usrp3/lib/rfnoc/noc_block_Receiver_tb/build-ip/xc7k410tffg900-2/axi_fir/fir_compiler_v7_2_5/hdl/fir_compiler_v7_2_vh_rfs.vhd(51):
in protected region
** Error:
/home/craig/uhd/rfnoc-devel/usrp3/lib/rfnoc/noc_block_Receiver_tb/build-ip/xc7k410tffg900-2/axi_fir/fir_compiler_v7_2_5/hdl/fir_compiler_v7_2_vh_rfs.vhd(52):
(vcom-1136) Unknown identifier "".
** Error:
/home/craig/uhd/rfnoc-devel/usrp3/lib/rfnoc/noc_block_Receiver_tb/build-ip/xc7k410tffg900-2/axi_fir/fir_compiler_v7_2_5/hdl/fir_compiler_v7_2_vh_rfs.vhd(54):
VHDL Compiler exiting
End time: 16:58:42 on Mar 30,2016, Elapsed time: 0:00:00
Errors: 3, Warnings: 0
** Error: /opt/mentor/modelsim/modelsim_dlx/linuxpe/vcom failed.
Error in macro ./runsim.do line 5
Craig
On Sun, Feb 21, 2016 at 6:13 PM, Luke Darnell <notifications<EMAIL_ADDRESS>wrote:

@cfswanson https://github.com/cfswanson What were your problems
exactly?
Hard to help without some specific error messages or problems.
Posting you command line output is a good start.

Reply to this email directly or view it on GitHub
https://github.com/potentialventures/cocotb/issues/137#issuecomment-186941000
.

--
Craig Swanson
770-298-9156
craigfswanson<EMAIL_ADDRESS>Cumming, GA 30040

You are receiving this because you commented.
Reply to this email directly or view it on GitHubhttps://github.com/potentialventures/cocotb/issues/137#issuecomment-203636282

Luke,
Do you know of anyone who has used cocotb also used any Xilinx IP with the
tool? I would be interested in seeing their Makefile.questa file.
Craig
On Wed, Mar 30, 2016 at 6:13 PM, Luke Darnell<EMAIL_ADDRESS>wrote:

Hi Craig,
I think there's some hoops to jump through to get the Xilinx encrypted
vhdl to run in modelsim.
Google throws up a few answers on this topic.
This is a general problem with including encrypted ip and not related to
cocotb.
Luke
On 31 Mar 2016, at 8:06 AM, Craig Swanson<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
Luke,
I am making good progress in using cocotb and I am finding it very useful.
So now I am trying to simulate a Xilinx axi_fir from their FIR compiler
v7.2.5 and I am getting protected region errors in when using Modelsim.
How can I get around this?
Here is the output:
do runsim.do
Model Technology ModelSim DE vmap 10.4c Lib Mapping Utility 2015.07 Jul
19 2015
vmap fir_compiler_v7_2_5 fir_compiler_v7_2_5
Copying /opt/mentor/modelsim/modelsim_dlx/linuxpe/../modelsim.ini to
modelsim.ini
Modifying modelsim.ini
Model Technology ModelSim DE vcom 10.4c Compiler 2015.07 Jul 19 2015
Start time: 16:58:42 on Mar 30,2016
vcom -work fir_compiler_v7_2_5
/home/craig/uhd/rfnoc-devel/usrp3/lib/rfnoc/noc_block_Receiver_tb/build-ip/xc7k410tffg900-2/axi_fir/fir_compiler_v7_2_5/hdl/fir_compiler_v7_2_vh_rfs.vhd
~/uhd/rfnoc-devel/usrp3/lib/rfnoc/noc_block_Receiver_tb/build-ip/xc7k410tffg900-2/axi_fir/fir_compiler_v7_2_5/hdl/fir_compiler_v7_2_5.vhd
-- Loading package STANDARD
** Error:
/home/craig/uhd/rfnoc-devel/usrp3/lib/rfnoc/noc_block_Receiver_tb/build-ip/xc7k410tffg900-2/axi_fir/fir_compiler_v7_2_5/hdl/fir_compiler_v7_2_vh_rfs.vhd(51):
in protected region
** Error:
/home/craig/uhd/rfnoc-devel/usrp3/lib/rfnoc/noc_block_Receiver_tb/build-ip/xc7k410tffg900-2/axi_fir/fir_compiler_v7_2_5/hdl/fir_compiler_v7_2_vh_rfs.vhd(52):
(vcom-1136) Unknown identifier "".
** Error:
/home/craig/uhd/rfnoc-devel/usrp3/lib/rfnoc/noc_block_Receiver_tb/build-ip/xc7k410tffg900-2/axi_fir/fir_compiler_v7_2_5/hdl/fir_compiler_v7_2_vh_rfs.vhd(54):
VHDL Compiler exiting
End time: 16:58:42 on Mar 30,2016, Elapsed time: 0:00:00
Errors: 3, Warnings: 0
** Error: /opt/mentor/modelsim/modelsim_dlx/linuxpe/vcom failed.
Error in macro ./runsim.do line 5
Craig
On Sun, Feb 21, 2016 at 6:13 PM, Luke Darnell<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:

@cfswanson https://github.com/cfswanson What were your problems
exactly?
Hard to help without some specific error messages or problems.
Posting you command line output is a good start.

Reply to this email directly or view it on GitHub
<
https://github.com/potentialventures/cocotb/issues/137#issuecomment-186941000
.

--
Craig Swanson
770-298-9156
craigfswanson<EMAIL_ADDRESS>Cumming, GA 30040

You are receiving this because you commented.
Reply to this email directly or view it on GitHub<
https://github.com/potentialventures/cocotb/issues/137#issuecomment-203636282

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/potentialventures/cocotb/issues/137#issuecomment-203662931

--
Craig Swanson
770-298-9156
<EMAIL_ADDRESS>Cumming, GA 30040

No, sorry Craig.

Hi Craig,
I did; as far as I remember the fifo_generator Xilinx IP worked. I don't have any example now, and not sure what you have tried so far but you should try:
1/ compile libraries for questa (Vivado->Tools->Compile Simulation Libraries or compile_simlib command),
2/ (in simulation settings) set generate scripts only (or just hit simulation). This will generate three scripts compile.do elaborate.do simulate.do and I believe modelsim.ini
I think I did a quick hack, combined these 3 scripts and run instead runsim.do generated by cocotb. I also used modelsim.ini generated by Vivado in cocotb.
I cannot remember whether fifo_generator IP files had any protected regions.
Marcin

@cfswanson,
Could you provide the port definition of your toplevel module? And also the content of runsim.do?
Note only generics of the toplevel module can be overridden from the make variable 'GENERICS'. Have you tried overriding a single generic, rather than two at the same time?
Also, Try running the 'mean' example with GUI=1. You can play with the GENERICS variable inside the makefile to see if that has an effect.

Marcin,
Thank you so much for your input.  That definitely helped and now I am up
and running thanks to your helpful suggestions.
Craig
On Wed, Mar 30, 2016 at 7:34 PM, marcinwoj<EMAIL_ADDRESS>wrote:

Hi Craig,
I did; as far as I remember the fifo_generator Xilinx IP worked. I don't
have any example now, and not sure what you have tried so far but you
should try:
1/ compile libraries for questa (Vivado->Tools->Compile Simulation
Libraries or compile_simlib command),
2/ (in simulation settings) set generate scripts only (or just hit
simulation). This will generate three scripts compile.do elaborate.do
simulate.do and I believe modelsim.ini
I think I did a quick hack, combined these 3 scripts and run instead
runsim.do generated by cocotb. I also used modelsim.ini generated by Vivado
in cocotb.
I cannot remember whether fifo_generator IP files had any protected
regions.
Marcin
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/potentialventures/cocotb/issues/137#issuecomment-203684102

--
Craig Swanson
770-298-9156
<EMAIL_ADDRESS>Cumming, GA 30040

elgorwi,
Thanks for helping me with this.  I am working on a more urgent issue right
now, so give me some time to get back to the GENERICS problem.
Here is my more urgent problem:
If my toplevel verilog module has a 64 bit input, how do I drive that dut.
in python?
input [31:0] i_tdata,
I would like to drive it in my test_python.py module with
dut.i_tdata = 0
But it appears that is only driving the lower 32 bits.
Craig
On Thu, Mar 31, 2016 at 5:31 AM, elgorwi<EMAIL_ADDRESS>wrote:

@cfswanson https://github.com/cfswanson,
Could you provide the port definition of your toplevel module? And also
the content of runsim.do?
Note only generics of the toplevel module can be overridden from the make
variable 'GENERICS'. Have you tried overriding a single generic, rather
than two at the same time?
Also, Try running the 'mean' example with GUI=1. You can play with the
GENERICS variable inside the makefile to see if that has an effect.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/potentialventures/cocotb/issues/137#issuecomment-203849585

--
Craig Swanson
770-298-9156
<EMAIL_ADDRESS>Cumming, GA 30040

Hi @cfswanson,
This looks like a modelsim issue. The workaround is to use BinaryValue(int) instead of an int to drive the input using vpi interface.
You can find more details in issue #409.
You're running modelsim under linux, right? Would be nice if you could try running test case issue_142 and report results in #409.
Thanks

Luke,
I am not sure how to add these in my makefile  When I add multiple lines
for things such as VERILOG_INCLUDE_DIRS, it gives me an error.
In this example, this is a typical modelsim command that is a bit long
winded:
vlog -reportprogress 300 "+define+SIM_RUNTIME_US=1000"
"+define+WORKING_DIR=/home/craig/uhd/rfnoc-devel/usrp3/lib/rfnoc/noc_block_Receiver_tb"
-incr -sv -work work
/home/craig/uhd/rfnoc-devel/usrp3/lib/rfnoc/noc_block_Receiver_tb/noc_block_Receiver_tb.sv
"+incdir+/home/craig/uhd/rfnoc-devel/usrp3/sim/general"
"+incdir+/home/craig/uhd/rfnoc-devel/usrp3/sim/rfnoc"
vcom -reportprogress 300 -work work -93
/home/craig/uhd/rfnoc-devel/usrp3/lib/rfnoc/hardware_pkg.vhd
Do I put the following in my makefile? Unfortunately I am not good at
understanding the code in Makefile.questa
VERILOG_SOURCES += ~/cocotb/examples/noc_block_Receiver/noc_block_Receiver.v
VERILOG_INCLUDE_DIRS += /home/craig/uhd/rfnoc-devel/usrp3/sim/general
VERILOG_INCLUDE_DIRS += /home/craig/uhd/rfnoc-devel/usrp3/sim/rfnoc
EXTRA_ARGS += -reportprogress 300
EXTRA_ARGS += "+define+SIM_RUNTIME_US=1000"
EXTRA_ARGS += -93
EXTRA_ARGS +=
+define+WORKING_DIR=/home/craig/uhd/rfnoc-devel/usrp3/lib/rfnoc/noc_block_Receiver_tb
What if I want to compile a module into a certain working directory such as
below.  In this example, my work directory is fir_complier_v7_2
vcom -reportprogress 300 -work fir_compiler_v7_2 -93
/home/craig/uhd/rfnoc-devel/usrp3/lib/rfnoc/noc_block_Receiver_tb/build-ip/xc7k410tffg900-2/axi_fir/fir_compiler_v7_2/hdl/fir_compiler_v7_2_vh_rfs.vhd
Craig
On Sun, Feb 21, 2016 at 6:13 PM, Luke Darnell<EMAIL_ADDRESS>wrote:

@cfswanson https://github.com/cfswanson What were your problems
exactly?
Hard to help without some specific error messages or problems.
Posting you command line output is a good start.
—
Reply to this email directly or view it on GitHub
https://github.com/potentialventures/cocotb/issues/137#issuecomment-186941000
.

--
Craig Swanson
770-298-9156
<EMAIL_ADDRESS>Cumming, GA 30040


Implement proper scaling of wallet app for high-DPI devices

It would be great to have the app scale properly on high-DPI displays.
I'm using the Windows version of the wallet and it has the scaling issues like many other programs on these high-DPI displays.

@Leberer Do you have the same problems with the Bitcoin Core?

@wrinkl3 I have never run the Bitcoin Core client. I'll try it in the next few days.

There might be a way to add high-DPI support via the Qt config, I'll look into it.

@wrinkl3 So I tried Bitcoin Core. It also doesn't look pretty (small fonts etc)
But there everything at least was readable.
I only realized recently (after seeing a screenshot of a correctly displayed wallet) that there is a field missing in my "Send" tab. I never sent anything with the desktop wallet so far but I guess that's the most important problem.
Would be awesome if that could be improved!


Can you add a license?

Hello,
Thanks for the work. However, without license information, "no one may reproduce, distribute, or create derivative works from your work." (source), so could you specify a e.g. MIT license?
Thanks in advance.

Thanks! Yes it does.


Server listen on unix socket

Hello,
This is my first issue for Miniflux and I would like to warmly thank you for your brilliant work. Miniflux is rock stable, fast and i totally adhere to its "opinionated " and "minimalism" design.
This issue is a feature request to support listening on unix domain socket.
I am using Miniflux behind a reverse proxy and favor usage of unix sockets to communicate between the proxy and my backends for security and performance reasons. My objective is to sandbox my backends as much as possible, and isolate them from the local network in particular.
Thanks to systemd i am able to isolate Miniflux using systemd socket activation and systemd-socket-proxyd but this is additional work and maintenance on the user side.
Would you consider adding support for listening on unix sockets please ?

Listening on Unix socket has been added in this commit https://github.com/miniflux/miniflux/commit/1315282c7ff46f1ac048022f7eeb0b4d09eedb57
You can find a configuration example here: https://docs.miniflux.app/en/latest/howto.html#reverse-proxy-with-a-unix-socket

Hello,
Thank you very much for your work.
I just tested your commit and I have an issue: miniflux creates the socket with permissions 755 but the web server is not running with the same user as the one running miniflux.
I see 2 options:

create the socket with permissions 770 and let the administrator add the http user to the miniflux group.
create the socket with permissions 777 and let the administrator secure access to the socket with directory permissions. This is the solution I am using with netdata proxying for instance.

What do you think ? Do you have other options ?
Cheers.

This commit https://github.com/miniflux/miniflux/commit/7838870a0ca57d48ed230e9dd58c79b0cfd9f809 changes the socket permissions to 666. I updated the example in the documentation. Perhaps it should configurable somehow.
If you want to play with socket activation and systemd, there is an experimental implementation in commit https://github.com/miniflux/miniflux/commit/af4c68feac8e01631cc156ee3b48b85b75e59085. There is an example in the docs: https://docs.miniflux.app/en/2.0.13/howto.html#systemd-socket-activation

This commit 7838870 changes the socket permissions to 666. I updated the example in the documentation. Perhaps it should configurable somehow.

Thanks I will test ASAP and let you know. It could indeed be a plus to have it configurable, but this is not mandatory. As mentioned above I use directory permissions to handle access control to the socket.

If you want to play with socket activation and systemd, there is an experimental implementation in commit af4c68f.

Excellent. This looks the most natural way to handle this issue on Linux. In theory the permissions can be fully handled by systemd, provided that miniflux does not overrides the initial permissions. I will test this ASAP too.
Cheers.

I have this working with unix sockets now.

I confirm unix socket is working like a charm. A big thank you to you !
I have not tested systemd activation yet.

You can have systemd create the /run directory for you and guarantee it remains during the service's lifetime with the RuntimeDirectory option:
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#RuntimeDirectory=


fix: renovate config cannot use private preset

Closes #28
See https://github.com/renovatebot/renovate/discussions/9002

Aggregating the available private presets into a single one to start off with. We may use a public preset later on, if needed.

Isn't it mandatory for renovate to extend something? At least "config:base"? shrug

I don't know. Will look into it (for example the base config doesn't extend anything, it seems). For sure I think I've deleted one excess line (the schema one)

Is there a dashboard (an issue; explained here on how to build one) associated with the config presented in this PR?

I suppose this is part of the config itself

@RemiMattheyDoret (/cc @sjiekak ):

we're not obliged to extend any preset
tried to perform several kinds of dry runs, even running renovate of the whole repo and open the dashboard: #34 . However, this was possible maybe just because I was using a github token of mine
as short-term fix we may just barely copy the required config, until we get a public preset


Feat/search in books

Initial Notebooks viewlet search implementations:
UI has the following:

Seach Widget: an input box that takes in the search terms.
SearchResults viewpane : Collapsible view pane that displays the search results. When user enters a search term and hits enter, the search result pane will expand automatically with results.
Notebooks viewpane
Provided Books viewpane

Search Experience:

Following files are modified versions from vscode search (since 1. they're tightly coupled with search view, I couldn't reuse them and had to make copies of them and customize them for notebooks 2. I didn't want to modify vscode search files and keep adding the //SQL Carbon Edit for sanity and maintainability):

notebookSearchView
notebookSearchResultsView

Am concerned about copying the styles from their search.css directly. I need feedback/guidance on how to reuse their styles.
Unit tests are currently pending.

Coverage decreased (-0.7%) to 34.804% when pulling 65de0466d67f17cd994f5b5f0f686363a9e6ef29 on feat/searchInBooks into fb52760be1c16f9ce3004ae32ab832c3b55bd747 on main.


PAGE format extension in Transkribus

https://github.com/Transkribus/TranskribusPageformat/blob/master/pagecontent_extension.xsd

Is this extension of the PAGE format still relevant? I see that the latest changes in this repo are from March 2017.

Is this extension of the PAGE format still relevant? I see that the latest changes in this repo are from March 2017.

It is, but IIUC the schema has moved to https://gitlab.com/readcoop/transkribus/TranskribusCore/-/blob/master/src/main/resources/xsd/pagecontent_extension.xsd
We could now support it as transkribus by adding a script based on https://github.com/kba/transkribus-to-prima

Yes, something like ocr-transform transkribus-page page2019 for ocr{d_,-}fileformat will be next steps to properly integrate this into OCR-D.

Maybe page-transkribus? Or page-readcoop? Or page2013t?

It's 2022 and we are not short of bytes any longer: I recommend against such abbreviations.
Also: page2013transkribus

We already have cryptical short names like gcv (that's why I suggested to extend the help message), but page2013transkribus is fine for me, too.


Steam Prefill stops after downloading 1-2 apps

Describe the bug
Steam Prefill frequently stops after downloading 1-2 apps. Troubleshooted by removing all saved data from AppData, but no improvement found. Need to force quit with Ctrl+C to start downloading the next few apps.
Additional Details

Platform: ich777's Unraid App
Region: West US

Screenshots

Could you try running the prefill on a Windows machine and see if the same issue keeps happening?

Here are my Docker launch arguments.
docker run
  -d
  --name='LANCache-Prefill'
  --net='br0'
  -e TZ="America/Los_Angeles"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="catNAS"
  -e HOST_CONTAINERNAME="LANCache-Prefill"
  -e 'ENABLE_BN'='false'
  -e 'CRON_SCHED_BN'='0 5 * * *'
  -e 'ENABLE_EPIC'='false'
  -e 'PREFILL_PARAMS_EPIC'=''
  -e 'CRON_SCHED_EPIC'='30 4 * * *'
  -e 'ENABLE_STEAM'='true'
  -e 'PREFILL_PARAMS_STEAM'='--recent'
  -e 'CRON_SCHED_STEAM'='30 3 * * *'
  -e 'UPDATES'='true'
  -e 'PREFILL_ONSTARTUP'='false'
  -e 'LOGCLEANUP'='true'
  -e 'CRON_SCHED_GLOBAL'=''
  -e 'UID'='99'
  -e 'GID'='100'
  -e 'DATA_PERM'='770'
  -e 'UMASK'='000'
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.icon='https://raw.githubusercontent.com/ich777/docker-templates/master/ich777/images/prefill.png'
  -v '/mnt/user/appdata/lancache-prefill':'/lancacheprefill':'rw'
  --restart=unless-stopped
  --dns=<IP_ADDRESS> 'ich777/lancache-prefill'

@ich777 could you help out with this?

@andritolion from what I can see everything is configured correctly.
I can't reproduce that behavior over here and it is working just fine. Does the cron schedule also do the same or is it not working there too?

Need to force quit with Ctrl+C to start downloading the next few apps.

The container was not meant to do that directly from the command line but it should not change anything if you do it like you do it.
Have you yet considered to set PREFILL_ONSTARTUP to true and if it does the same?

@tpill90 & @andritolion I have now verified over the weekend that the container is working as expected on my system and also on a system from another user.
On my system it automatically updated four apps in one go with the automatic update. I also tried it the next day from the command line and it also updated five apps.
@tpill90 If no further response is given I would recommend to close this issue.
@andritolion I got now a few other reports that the updates from game containers are not working sometimes properly so I think this is actually an issue with the Steam CDN in general.

Apologies for no update until now. Been busy the last few days. It doesn't seem like the cron schedule can completely update my library. Reproduced the issue a bit ago, same pausing after one app. I'll try and see if setting that variable to true makes an improvement.

@andritolion What region are you in? I'm curious since sometimes it can have an effect.
Also could you add the flag --debug to your prefill command and try to reproduce again? Might give us some more info

I am in the Los Angeles, United States region. Crashed this time, completely different cause though.

Think I see it trying to pull a style from a local location that does not exist (your Dropbox).

@andritolion any update on this?

@ich777 I'm having some very similar issues to @andritolion
I've made a post over in the unRAID forums as well.

@ss1gohan13 your issue sounds more like a lancache issue itself not like a prefill issue.
I‘m also not a huge fan of posting multiple times.

Closing this as no additional info was given