| *** tpb <[email protected]> has joined #yosys | 00:00 | |
| *** bl0x <[email protected]> has joined #yosys | 01:09 | |
| *** bl0x_ <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 01:10 | |
| datenwolf | so-offish: maybe? Does it happen when you try to assign timing budget though the UI? | 05:28 |
|---|---|---|
| datenwolf | If so, yeah, I tackled it. | 05:28 |
| 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 | 05:30 |
| datenwolf | The other issue (the actual exception that with then collide with Qt) is locale related. | 05:30 |
| *** krispaul <[email protected]> has joined #yosys | 07:02 | |
| *** kristianpaul <kristianpaul!~paul@user/kristianpaul> has quit IRC (Ping timeout: 252 seconds) | 07:04 | |
| *** ZipCPU_ <[email protected]> has joined #yosys | 08:17 | |
| *** ZipCPU <[email protected]> has quit IRC (Ping timeout: 255 seconds) | 08:19 | |
| *** ZipCPU_ is now known as ZipCPU | 08:19 | |
| *** lexano <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 08:59 | |
| *** lexano <[email protected]> has joined #yosys | 09:12 | |
| *** jryans <jryans!~jryans@2001:470:69fc:105::1d> has joined #yosys | 12:41 | |
| *** lambda <[email protected]> has quit IRC (Ping timeout: 248 seconds) | 12:53 | |
| *** peeps <peeps!~peepsalot@openscad/peepsalot> has joined #yosys | 13:21 | |
| *** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 268 seconds) | 13:23 | |
| *** lambda <[email protected]> has joined #yosys | 13:38 | |
| *** krispaul <[email protected]> has quit IRC (Quit: WeeChat 2.3) | 14:26 | |
| *** kristianpaul <kristianpaul!~paul@user/kristianpaul> has joined #yosys | 14:26 | |
| *** citypw <citypw!~citypw@gateway/tor-sasl/citypw> has joined #yosys | 14:43 | |
| so-offish | datenwolf: it sounds like it might be related! https://github.com/YosysHQ/nextpnr/issues/1133 | 15:13 |
| so-offish | datenwolf: Oh mine wasn't trying to assign timing though. Hm. Drat. | 15:13 |
| *** so-offishul <[email protected]> has joined #yosys | 15:14 | |
| *** so-offishul <[email protected]> has quit IRC (Remote host closed the connection) | 15:15 | |
| *** so-offish <so-offish!~so-offish@2610:148:610:2b11::11> has quit IRC (Ping timeout: 260 seconds) | 15:17 | |
| *** so-offish <so-offish!~so-offish@2610:148:610:2b11::10> has joined #yosys | 15:18 | |
| 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") | 15:26 |
| 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. | 15:27 |
| so-offish | datenwolf: What is the downside? (I assume overhead of some sort) | 15:27 |
| datenwolf | so-offish: overhead, and probably some other things, but I never bothered finding out what they were. | 15:28 |
| 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. | 15:30 |
| 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. | 15:33 |
| *** citypw <citypw!~citypw@gateway/tor-sasl/citypw> has quit IRC (Ping timeout: 255 seconds) | 15:36 | |
| datenwolf | Pretty sure that in a GPU code golf challenge jix would beat me though. | 15:36 |
| 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? | 15:47 |
| so-offish | datenwolf: I've never done any shader programming; it's on my list. | 15:50 |
| 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 | 15:51 |
| *** cr1901 <cr1901!~cr1901@2601:8d:8600:911:79c2:728d:d50d:c315> has quit IRC (Read error: Connection reset by peer) | 16:08 | |
| *** cr1901 <cr1901!~cr1901@2601:8d:8600:911:1997:a090:3300:232a> has joined #yosys | 16:09 | |
| 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 | 16:10 |
| datenwolf | crashing function call, set breakpoint on that function, recursively working down until finding the very offending statement. | 16:10 |
| *** singham <singham!~singham@2405:201:f:1e5a:f53d:213e:e018:d1cb> has joined #yosys | 16:21 | |
| singham | In an always block, can I do something like | 16:22 |
| singham | always @(posedge clk_eink && empty && datacounter<=16'h1000) | 16:22 |
| singham | Is that above valid syntax? | 16:23 |
| singham | Combining edge and level triggers? | 16:25 |
| so-offish | datenwolf: I'll try that, thank you! | 16:44 |
| *** singham <singham!~singham@2405:201:f:1e5a:f53d:213e:e018:d1cb> has quit IRC (Remote host closed the connection) | 17:23 | |
| *** singham <singham!~singham@2405:201:f:1e5a:f53d:213e:e018:d1cb> has joined #yosys | 17:23 | |
| *** singham <singham!~singham@2405:201:f:1e5a:f53d:213e:e018:d1cb> has quit IRC (Remote host closed the connection) | 17:41 | |
| *** singham <singham!~singham@2405:201:f:1e5a:f53d:213e:e018:d1cb> has joined #yosys | 17:42 | |
| bl0x | singham: I'd use an if block for the other conditions. | 17:45 |
| singham | bl0x: Thanks :) | 17:53 |
| singham | Your mean always@(posedge clk_eink) begin if(empty && datacounter<=16'h1000) foo; end | 17:54 |
| singham | Something like this? | 17:54 |
| lofty | singham: yeah | 17:58 |
| datenwolf | singham: yes. Level triggers don't map that well to your typical FPGA with D-flipflops anyway. | 17:59 |
| 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. | 18:01 |
| 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. | 18:05 |
| singham | Understood. I thought the tool would create hardware of latter 2 and feed it to D-latch | 18:05 |
| singham | I mean & the logic within block with (empty && datacounter<=16'h1000) and send it through a D-latch | 18:06 |
| datenwolf | Consider an always@(...) to be the clock input for all the D-latches that make up the behavior block. | 18:08 |
| singham | Understood. | 18:16 |
| singham | I have corrected it now. | 18:16 |
| singham | As a matter of practice, do you ever combine edge and value triggers? | 18:18 |
| *** singham <singham!~singham@2405:201:f:1e5a:f53d:213e:e018:d1cb> has quit IRC (Remote host closed the connection) | 18:46 | |
| *** singham <singham!~singham@2405:201:f:1e5a:f53d:213e:e018:d1cb> has joined #yosys | 18:46 | |
| 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. | 18:51 |
| singham | Yes, synthesis. | 19:01 |
| singham | Yes, I think event triggered stuff is best kept away from absolute value driven stuff. | 19:02 |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Ping timeout: 255 seconds) | 19:04 | |
| 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. | 19:06 |
| singham | True. I believed for a while in async designs but they indeed are inferior. | 19:15 |
| * singham ought to leave now. Thanks bl0x lofty datenwolf for the help! | 19:16 | |
| singham | Au revior, mulaanno | 19:16 |
| *** singham <singham!~singham@2405:201:f:1e5a:f53d:213e:e018:d1cb> has left #yosys | 19:16 | |
| *** nak <nak!~nak@yosys/nak> has joined #yosys | 19:24 | |
| *** markov_twain <markov_twain!~markov_tw@user/markov-twain/x-1620001> has joined #yosys | 20:16 | |
| *** nonchip <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 22:10 | |
| *** nonchip <[email protected]> has joined #yosys | 22:10 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!