whitequark[cis] changed the topic of #prjunnamed to: FPGA toolchain project · rule #0 of prjunnamed: no one should ever burn out building software · https://prjunnamed.org · https://github.com/prjunnamed/prjunnamed · logs: https://libera.catirclogs.org/prjunnamed
jn has quit [Ping timeout: 276 seconds]
jn_ has joined #prjunnamed
jn_ has joined #prjunnamed
jn_ has quit [Changing host]
<vancz> I might have gotten cxxrtl to deadlock or hang or something
<vancz> nevermind, im quite sure im just tired and paused the debugger in that part of the loop
<vancz> OK so I'm raisin g a signal and nothing is happening and I cannot figure out why or where nothing is happening :V
<whitequark[cis]> can you show your code
<vancz> I asked the LLM and it was empirically right ;_;
<vancz> one second
<vancz> getting some sleep also seems to have helped
<whitequark[cis]> going "the llm" with the same cadence as "the wife"
<vancz> Im trying to actually get better at things instead of just seeing what sticks, but I'm kinda dumb. Also getting unstuck is nice. (When it actually does help.) Im a low key AI doomer waiting to become completely obsolete...
<vancz> whitequark[cis]: https://bpa.st/7FLQ
<vancz> So anway I had to add this to the IRQ machine:
<vancz> irq_pending <= 0;
<vancz> else if (read_state == DO_READ && irq_pending && !valid) begin
<vancz> end
<vancz> instead of this in the read machine:
<vancz> //irq_pending <= 0;
<vancz> I'm not great at running state machines in my head, I think the delay and synchronization provided by clocking should make the two machines not race on this line, but this seems to have actually fixed the problem.
<vancz> The whole thing is supposed to be an echo machine (talking to a virtual serial device)
<vancz> and verilator didnt give me any warnings, though I haven't tried too hard to set it up. So maybe I missed something, or this just isn't something to warn on.
<vancz> ohmygosh it's actually kind of working :O https://bpa.st/SLWA
<vancz> Ok I need to figure out how to do this VCD thing you implemented.
<vancz> I need to stop running head first at the wall with this so much,
<whitequark[cis]> tomverbeure's posts should show it
<vancz> yeah I see code samples
<vancz> does something just get very unhappy if multiple always blocks access a given line and i shouldnt even _try_ to do that regardless of if there are races or not?
<whitequark[cis]> by line you mean wire?
<whitequark[cis]> s/wire/reg/
<whitequark[cis]> only one always block should assign a reg
<vancz> apparently so
* vancz tries to find a style guide or something that has that in its list
<vancz> I imagine this is a super basic thing everyone knows
* vancz should go check / skim the sutherland book again later
<vancz> its suggested that maybe tools should warn about this but I dont see verilator or yosys giving me any warnings for this
<vancz> well, yosys -p "read_verilog blink.v; hierarchy; proc; opt; check -assert" shows:
<vancz> 4.7. Executing OPT_CLEAN pass (remove unused cells and wires).
<vancz> Removed 17 unused cells and 65 unused wires.
<vancz> Warning: Driver-driver conflict for \valid between cell $auto$ff.cc:266:slice$143.Q and constant 1'0 in top: Resolved using constant.
<vancz> Finding unused cells or wires in module \top..
<vancz> <suppressed ~19 debug messages>
<vancz> so with a different flow that there shows up at least
<vancz> whitequark[cis]: by virtue of your library and the work of many others;
<vancz> I got a really shitty PoC implementation of running HDL in place of the emulated cpu in QEMU working today; https://bpa.st/ZJUA
<vancz> :puppy eyes: is this good for anything?
jn_ is now known as jn