vnksnkr_ has quit [Remote host closed the connection]
vnksnkr has joined #nmigen
<sensille>
i could use some help with pypy. i managed to install pypy3.7 (from source, thanks debian). do i now have to rebuild anything from the nmigen toolchain, or reinstall it? at least pypy hasn't any knowledge of nmigen yet
<sensille>
or is it just a matter of adjusting pypys library path?
pftbest has joined #nmigen
<whitequark[m]>
you need to use pypy's pip i think
<sensille>
ok, i runs with in a virtualenv, but with pypy it's significantly slower than with python itself :-/
<sensille>
*it
<sensille>
strange
<sensille>
a simple benchmark show pypy 50 times faster than python, but simulation for my module takes twice as long
<whitequark>
are you reusing a simulator?
<whitequark>
i.e. create Simulator() once, then reset() it for every unit test
<sensille>
no, single use
<whitequark>
that means that the JITted code most likely gets dropped and recreated for every test
<whitequark>
if the tests don't run a lot of logic, this could slow it down significantly
<sensille>
just one run, one test. a long test
<whitequark>
oh, hm.
<whitequark>
and is that your entire test suite?
<sensille>
currently, yes. just a fuzzing test
<sensille>
but i had to build nearly everything from source. something might be off somewhere
slan has joined #nmigen
<slan>
sensille: Could you post your benchmark? I just ran my own test with pypy and it's slightly slower that cpython (installed from binary)
<sensille>
what is the intended way to end a simulation on failure? raise?
vnksnkr has quit [Quit: vnksnkr]
vnksnkr has joined #nmigen
Bertl_zZ is now known as Bertl
<sensille>
wow, finally found the bug in the design. it never fails to astonish me how hard it is to write good tests
hexastorm has joined #nmigen
<hexastorm>
Hey all, I have a created a project which allows you to control a 3D printer with nmigen. CNC machine is already moving see https://youtu.be/-0uB2MydtrE
<hexastorm>
There is a lot to be improved.. but as far I know.. this is the first working core :-)
revolve_ has quit [Ping timeout: 260 seconds]
<sensille>
hexastorm: nice, i'm working on the same :)
<hexastorm>
so your board would only be usefull if I have some pins to connect my laser module
<sensille>
what do you need for laser scanning?
<sensille>
the board has endless ways to connect
<hexastorm>
scanhead pcb needs 12V, SDA connection to set laser voltage, pulse for mirror motor, pulse for two laser channels and pulse read out of photodiode
<hexastorm>
but focussed on a plurality of bundles..
<hexastorm>
there are applications also in laser induced forward transfer etc.. but the main thing I need is a working setup where I can reliable expose a substrate..
<hexastorm>
if this is programmed in python with nmigen and easy to read .. it might convince a lot of people to explore it
<hexastorm>
anyhow sensille, I would try to copy part of my codes or start from it.. it is more work than you think.. also I am curious which parts you do not like
<hexastorm>
I am off.. gonna hack on :-)
hexastorm has quit [Quit: Connection closed]
yosys-questions has quit [Quit: Connection closed]
FFY00_ has quit [Remote host closed the connection]
FFY00_ has joined #nmigen
* lkcl
waves to whitequark.
<whitequark[m]>
hi
<lkcl>
am just about to embark on a rather... hurried (tape-out deadline apr 12th) use of cxxrtl to do ASIC simulation, based on that really good tutorial
<lkcl>
there will be *three hundred* vhdl components to pull in :)
<whitequark[m]>
good luck
<lkcl>
there's no rush: i had a suggestion / idea for the yosys cxxrtl
<lkcl>
yeah lol :)
vnksnkr has quit [Remote host closed the connection]
<whitequark[m]>
which idea?
<lkcl>
to have it output separate .h and .cpp files rather than the struct be a part of the cpp file
<lkcl>
in future
<lkcl>
or, is there an option to write_cxxsim to already do that?
<lkcl>
#include "blink.cpp" is fine for small designs. when there's 300 and it's expected to produce a 200mb binary that's a leetle big :)
<lkcl>
i can write a temporary hack/extractor to split out the struct
<whitequark[m]>
there is an option, please see the help text
<lkcl>
ahh fantastic!
<lkcl>
wheww :)
<lkcl>
ok back to focussing on seriously tight deadlines
<lkcl>
thanks whitequark[m]
<whitequark[m]>
np
<lkcl>
ah that's interesting. a 12-bit counter works uint32_t counter = top.p_counter.get<uint32_t>();
<lkcl>
but a 4-bit value does not (compile error)
<lkcl>
nope. my stupid mistake. doh
<lkcl>
works perfectly
<lkcl>
in case anyone's interested, we've an ASIC to test via JTAG.
<lkcl>
but before getting there, the RTL (nmigen, litex) needs testing before it goes into the P&R tool
<lkcl>
coriolis2 happens to use a subset of VHDL for its cells, so after P&R that VHDL can be put *back* into the exact same simulation... and tested to make sure it's the same as the nmigen original
<lkcl>
so the plan is: write a cxxrtl unit test that back-ends JTAG into the openocd "jtagremote" protocol
<lkcl>
then connect to *all three* cxxsim simulations using openocd JTAG
<whitequark>
this is the kind of thing cxxrtl has been developed for