<datenwolf>
so-offish: maybe? Does it happen when you try to assign timing budget though the UI?
<datenwolf>
If so, yeah, I tackled it.
<datenwolf>
It's a twofold problem: Signals not properly transferred over thread boundaries (UI -> Worker). Easy to solve, just use "Qt::QueuedConnection" as additional, last paramter to all the signal/slot connects in worker.cc
<datenwolf>
The other issue (the actual exception that with then collide with Qt) is locale related.
so-offishul has quit [Remote host closed the connection]
so-offish has quit [Ping timeout: 260 seconds]
so-offish has joined #yosys
<datenwolf>
so-offish: I was huting down a very similar issue. TTBT the whole thing is unearthing bad memories (I had this huge application I wrote, and after the Qt version bump, it was riddled with threading bugs, we had a deadline approaching, my superiors were breathing down my neck "why isn't this getting done")
<datenwolf>
so-offish: anyway, the "I no longer care, screw it" approach, that's also somewhat YOLO is to make each and every signal-slot connection Qt::QueuedConnection.
<so-offish>
datenwolf: What is the downside? (I assume overhead of some sort)
<datenwolf>
so-offish: overhead, and probably some other things, but I never bothered finding out what they were.
<datenwolf>
Eventually I did drop Qt for my stuff entirely. For the time being I now use GLFW+ImGui until I finally get around finishing my own UI toolkit.
<datenwolf>
NextPNR does already ship with ImGui; ImGui has a really nice draw list implementation. To be honest, I think it would be a lot easier to draw the schematic with that. The OpenGL based drawing code is okay-ish..., but the shader geek that I am really itches to turn the whole thing into a single draw call fragment shader, that does *everything* on the GPU.
citypw has quit [Ping timeout: 255 seconds]
<datenwolf>
Pretty sure that in a GPU code golf challenge jix would beat me though.
<so-offish>
datenwolf: Do you have any pointers for how to setup my build of nextpnr such that I could open it in, say, QtCreator to debug it? Or, how would you debug this issue?
<so-offish>
datenwolf: I've never done any shader programming; it's on my list.
<so-offish>
datenwolf: I think I can get CMake to spit out a Qt Creator project, and from there I can get a nice debugging environment
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #yosys
<datenwolf>
as someone who's "living" on the command line: Sorry, no experience with QtCreator here. I basically just put GDB breakpoints on every signal/slot boundary (I manually followed the flow from UI event to worker slot invocation), continuing breakpoint by breakpoint. After identifying the coarse whereabouts of the crash I had a single breakpoint before that, 'next'-ing line by line, identifying the
<datenwolf>
crashing function call, set breakpoint on that function, recursively working down until finding the very offending statement.
singham has joined #yosys
<singham>
In an always block, can I do something like
singham has quit [Remote host closed the connection]
singham has joined #yosys
singham has quit [Remote host closed the connection]
singham has joined #yosys
<bl0x>
singham: I'd use an if block for the other conditions.
<singham>
bl0x: Thanks :)
<singham>
Your mean always@(posedge clk_eink) begin if(empty && datacounter<=16'h1000) foo; end
<singham>
Something like this?
<lofty>
singham: yeah
<datenwolf>
singham: yes. Level triggers don't map that well to your typical FPGA with D-flipflops anyway.
<lofty>
Synthesisable Verilog is a pretty strict subset of the actual Verilog specification, and it's often a good idea to try to visualise the kind of hardware you expect your Verilog to produce.
<datenwolf>
Indeed. The usual approach to writing Synth-Verilog is to first sketch out the gate level logic that does what one intended, then write the combinatorial and behavioral descriptions that one had in mind when sketching that logic.
<singham>
Understood. I thought the tool would create hardware of latter 2 and feed it to D-latch
<singham>
I mean & the logic within block with (empty && datacounter<=16'h1000) and send it through a D-latch
<datenwolf>
Consider an always@(...) to be the clock input for all the D-latches that make up the behavior block.
<singham>
Understood.
<singham>
I have corrected it now.
<singham>
As a matter of practice, do you ever combine edge and value triggers?
singham has quit [Remote host closed the connection]
singham has joined #yosys
<datenwolf>
singham: For synthesis? Maybe combinatorically on a wire that goes into the @always, but the idiomatic way is to put value-level stuff into the behavior, esp. if you're using it to reset registers to zero.
<singham>
Yes, synthesis.
<singham>
Yes, I think event triggered stuff is best kept away from absolute value driven stuff.
ec has quit [Ping timeout: 255 seconds]
<datenwolf>
singham: The thing with level-triggers is, that you're either going to need an independent clock sampling the level, or you'll have to fiddle with delay lines to take the time derivative of your level to find the edges. Asynchronous designs are frustrating to do.
<singham>
True. I believed for a while in async designs but they indeed are inferior.
* singham
ought to leave now. Thanks bl0x lofty datenwolf for the help!