az0re has quit [Remote host closed the connection]
emeb has left #yosys [#yosys]
emeb_mac has joined #yosys
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #yosys
Xark has joined #yosys
rlee287 has quit [Quit: Konversation terminated!]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
jmamish has joined #yosys
citypw has joined #yosys
jmamish has quit [Ping timeout: 272 seconds]
jmamish has joined #yosys
jmamish has quit [Ping timeout: 256 seconds]
jmamish has joined #yosys
futarisIRCcloud has joined #yosys
jmamish has quit [Ping timeout: 256 seconds]
FFY00 has quit [Ping timeout: 256 seconds]
Degi has quit [Ping timeout: 246 seconds]
Degi has joined #yosys
BinaryLust has quit [Ping timeout: 240 seconds]
jmamish has joined #yosys
jmamish has quit [Ping timeout: 272 seconds]
az0re has joined #yosys
<az0re>
whitequark, you around?
<az0re>
It looks like RUSAGE_CHILD is not the solution. I modified it to use RUSAGE_CHILD and still don't see proper measurement. The man page says, "Return resource usage statistics for all children [...] that have terminated and been waited for"
<az0re>
Hmm, wait, maybe I'm wrong, I still see RUSAGE_SELF in the strace output for some reason...
citypw has quit [Ping timeout: 240 seconds]
develonepi3 has quit [Remote host closed the connection]
<az0re>
Yeah indeed I fucked it up somehow, nevermind
craigo has joined #yosys
BinaryLust has joined #yosys
kgugala_ has joined #yosys
kgugala has quit [Ping timeout: 240 seconds]
citypw has joined #yosys
dys has quit [Ping timeout: 256 seconds]
mwk has joined #yosys
N2TOH has quit [Ping timeout: 265 seconds]
bzztploink has quit [Ping timeout: 264 seconds]
dys has joined #yosys
emeb_mac has quit [Quit: Leaving.]
acleaver has joined #yosys
citypw has quit [Ping timeout: 240 seconds]
kgugala_ has quit [Read error: Connection reset by peer]
FFY00 has joined #yosys
kgugala has joined #yosys
jakobwenzel has joined #yosys
gorbak25 has quit [Ping timeout: 264 seconds]
kraiskil has joined #yosys
bzztploink has joined #yosys
Asu has joined #yosys
bzztploink has quit [Ping timeout: 240 seconds]
bzztploink has joined #yosys
<Lofty>
lambda: I think you might as well start writing code and see where that leads
<lambda>
Lofty: I honestly have better uses for my time than writing code that may or may not be thrown out for arbitrary reasons
<whitequark>
lambda: i'll raise the question re: memories at the next yosys meeting
<whitequark>
which i think happens next week
<lambda>
whitequark: thanks <3
<whitequark>
and i agree that design discussion should happen before writing code, for something like this at least
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #yosys
vidbina has joined #yosys
N2TOH has joined #yosys
citypw has joined #yosys
develonepi3 has joined #yosys
N2TOH_ has joined #yosys
N2TOH has quit [Read error: Connection reset by peer]
<thardin>
starting to get the hang of verilog and making smaller and faster designs
develonepi3 has quit [Remote host closed the connection]
<Lofty>
thardin: it's a tricky thing
<thardin>
ye. especially when you need to do initialization of some chips
<thardin>
I've ordered myself some more pmods. the max11300 one I have is too much hassle for now
<thardin>
but very versetile if I could get it working the way I want
<thardin>
in the timing output after routing, <async> means combinatorics right?
<whitequark>
i think it means "no clock domain known to nextpnr"
<thardin>
hmm
<thardin>
Info: Clock 'PMOD1$SB_IO_OUT_$glb_clk' has no interior paths
<thardin>
"normally this warning is a result of a design being optimised away excessively"
<thardin>
alright so it's just yosys doing a good job :)
<thardin>
woo my pmods have been shipped
BinaryLust has quit [Ping timeout: 260 seconds]
jfcaron has joined #yosys
vidbina has quit [Ping timeout: 265 seconds]
kgugala has quit [Ping timeout: 258 seconds]
kgugala_ has joined #yosys
jfcaron has quit [Quit: Leaving]
jakobwenzel has quit [Remote host closed the connection]
jfcaron has joined #yosys
strongsaxophone has joined #yosys
vidbina has joined #yosys
citypw has quit [Ping timeout: 240 seconds]
acleaver has quit [Remote host closed the connection]
dys has quit [Ping timeout: 256 seconds]
<tnt>
So yosys has `ltp`. But is there a way to get a histogram of the paths ? Like that many of length N, that many of length N-1, etc ... ?
<whitequark>
probably not, would be cool to have
<az0re>
+1
<whitequark>
in fact i would even add that to the `check` label of synth scripts
lambda has quit [Ping timeout: 260 seconds]
lambda has joined #yosys
craigo has quit [Quit: Leaving]
emeb_mac has joined #yosys
vidbina has quit [Ping timeout: 256 seconds]
<ross_s>
Has anyone ecountered / got tips for debugging nextpnr when it stalls? I have a design that gets to 'Setting up routing queue', then after 5000-9000 IterCnt busy loops indefinitely.
<ross_s>
the position where it stalls seems to be consistent for a given input json
<ross_s>
randomly sampling the program by interrupting under gdb while in this state always seems to return nextpnr_ecp5::Arch::route / nextpnr_ecp5::router1 / (anonymous namespace)::Router1::route_arc, pip values do seem to be different each time so if it is stuck in a cycle it's not an immediately obvious one (to me at least)
<Lofty>
daveshah: ^
<Lofty>
The main tip I have for debugging nextpnr is to ping Dave about it :P
<tnt>
ross_s: how full is the device ?
<daveshah>
Run with --debug --verbose
<ross_s>
in terms of trellis slice, ~35%
<daveshah>
that will print what the router is doing
<ross_s>
sorry for the delay, computer chugging a bit. The output has slowed for arcs such as the following: Routing arc 0 on net wb_intercon0.wb_arbiter_spi0.wbs_ack_i_LUT4_A_1_Z_LUT4_A_Z_LUT4_C_Z_LUT4_D_Z_TRELLIS_FF_DI_Q[1] (1 arcs total):
<ross_s>
I can kill and paste the full output somewhere if that's useful, or just the segment around that line
<deadman>
hi all, i'm trying to use two PLLs on the TinyFPGA board but can't seem to have both of them placed: "couldn't be placed anywhere, no suitable BEL found."
<deadman>
I know there's some restrictions based on the IOs used and stuff, but I can't seem to figure out a solution given that the onboard oscillator is stuck to pin B2
<ross_s>
Which TinyFPGA board? If it's the BX, I think that the LP8K only has 1PLL in the 81ucBGA package
<deadman>
the first clock, I have to derive from the onboard oscillator. The second is derived from the output of the first, is that possible?
<deadman>
Yes, the BX, oh!
<deadman>
*facepalm
<ross_s>
It's a bit sneaky, looking at the ice 40 datasheet it says 2, but if you follow the annotation there's a note at the bottom about that package
<deadman>
really? I saw nextpnr's output with "ICESTORM_PLL: 1/2" used, and assumed I have two to play with
<deadman>
dang
<deadman>
now I gotta rethink this, and thanks for the quick answer! Been messing with this for hours
<deadman>
just pulled up the PLL design guide. yup, 1 pll on the cm8 package, right on the frontpage. should have picked that up. Thanks!
<ross_s>
no problem
<ross_s>
daveshah: let me know if there's any additional info you need on that routing problem. I've left it running, and its still strugging. Visiting 1459178 nodes for each arc.
<daveshah>
I think it's just a congested placement even though utilisation is low. I'm working on a fix for this long term but it will be a while.
<daveshah>
never mind, i'ts not that
<daveshah>
it's an occasional bug in clock placement that I need to track down
<daveshah>
but `wb_intercon0.wb_arbiter_spi1.wbs_ack_i_LUT4_A_Z_LUT4_A_Z_LUT4_C_Z_LUT4_D_1_Z_TRELLIS_FF_DI_Q[2]` as a clock doesn't look correct to me
<ross_s>
hmm indeed that is not a clock
<ross_s>
though, since I don't have that many globals kicking about, it seems like it should be safe to route it as one without bogging down?
<daveshah>
yes, that's what I mean as "occasional bug in clock placement"
<ross_s>
ah gotcha
<daveshah>
it sometimes picks two global sites where the DCC inputs are shared so it isn't routeable
<ross_s>
is there a workaround?
<daveshah>
No, but in this case I think the design should be fixed
<daveshah>
otherwise, trying a different seed might fix it
<ross_s>
Hmm if something is wrong with the design I'll definitely try to fix that first
<daveshah>
It looks like there might be some logic in between
<daveshah>
a general search for any suspicious posedges in the design should fix it
<daveshah>
if not I will try and fix the nextpnr issue in the next few days, but depending on the exact circumstances I wouldn't trust logic generated clocks to actually work reliably
<ross_s>
aha, git grep for posedge did reveal a botched @(posedge stb) that should be @(posedge clk) if (stb) ...
<ross_s>
rebuilding to see if that solves it
<ross_s>
yup, only the core clock has been promoted this time
<ross_s>
completed with no problems. That's an interesting gotcha, I'll be on the lookout for that if it happens again