<whitequark[cis]>
anyway, Tom's docs, the source code, and write_cxxrtl -help are the only documentation
<whitequark[cis]>
vancz: that's hooked up to the yosys-standard `-help` option, yes
<vancz>
To X-Y problem this a bit, what I'm actually looking for is anything that will let me run HDL as a library from C.
<whitequark[cis]>
sure, cxxrtl will do that
<vancz>
The initial idea was to try using verilator but that doesn't provide a C API so I'd have to write my own binding.
<vancz>
This is all very experimental for me, I might have to end up specifying my own API for my project anyway, but I thought I might be able to avoid some work.
<vancz>
Do you know if there is any other tool that I might want to look at?
<whitequark[cis]>
cxxrtl's C API is enough for that
<whitequark[cis]>
(and if i thought other tools sufficient i wouldn't write my own, so the answer is no)
<vancz>
Also I can't quite figure out how Im supposed to build and link the c/c++ code. The twitter debian paste examples links have expired and I don't see which headers exactly you're including.
<vancz>
If I try to compile myproject.cpp into a .o with g++ that works, but then stuff doesn't work right when I try to link it against my main.c with gcc.
galibert[m] has joined #prjunnamed
<galibert[m]>
you need to link with g++ I'm pretty sure
<vancz>
It makes some sense that the C side wouldn't know about C++ ABI.
<galibert[m]>
exactly
<vancz>
but then that makes the C bindings not exactly C bindings?
<galibert[m]>
doesn't mean your main.c can't be C of course
<vancz>
Technically I think I need something I can compile with GCC
<vancz>
well, the C compiler rather
<galibert[m]>
why?
<vancz>
I can of course presumably modify the build system, but Id like to integrate this into an existing build.
<galibert[m]>
you can still compile your C with gcc -c. It's only the final link that needs to be done with g++
<vancz>
and hopefully upstream what I'm doing if they wil have me (probably not)
<galibert[m]>
an option may be to turn it into a .so
<vancz>
actually isnt this the whole point of the extern C though? <vancz> It makes some sense that the C side wouldn't know about C++ ABI.
<galibert[m]>
the link also links in some language-support libraries and objects, and while the c++ lib handles c, it doesn't work the other way around
<galibert[m]>
constructors at least, probably some other stuff
<vancz>
Why would using a .so fix my problem?
<vancz>
or do you mean build the whole thing separately and then use dlopen from the C side?
<vancz>
well, given that the whole C API header is wrapped in #ifdef __cplusplus (to prevent the kind of foot shooting I'm doing) I guess there's no way to use the API from pure C.
<vancz>
(even if I do build the C++ side as a .so)
<vancz>
Oh wait, I can't read. The ifdef is only around the extern lines.
<vancz>
I think I got it. This mixed things up a little at the end;
<vancz>
The foot shooting continues. For the code I'm playing with, when I inspect a given internal signal it's always zero even though it should be doing something...
<vancz>
maybe it's optimized out?
<vancz>
No I guess not.
<galibert[m]>
how do you reach it?
<galibert[m]>
the signal, that is
<galibert[m]>
oh, you're reaching it from c or c++?
<vancz>
oh
<vancz>
It looks like its being optiimzed out in the yosys build
<galibert[m]>
that's... not supposed to happen I think
<galibert[m]>
did you do more than just write_cxxrtl?
<vancz>
Yosys is like inlining the wires or something, but the symbols still end up visible in the API? (cc whitequark[cis] ?)
<vancz>
I passed -O0 to write_cxxrtl and it seems to work, unless I'm goofing something.
<vancz>
Ill post my code I guess
<vancz>
hmm
<vancz>
looking closer at the code maybe the generated cpp does still have the wires, but the behavior certainly depends on the yosys optimization level...
<whitequark[cis]>
<vancz> "Well, I was copying from these..." <- the backslahes are exclusively a Verilog thing
<whitequark[cis]>
<vancz> "It looks like its being optiimze..." <- you have to call a function on signals that are optimized out in order to get their value, it's in cxxrtl_object
<whitequark[cis]>
if you show me your current code i'll review it