whitequark[cis] changed the topic of #glasgow to: https://glasgow-embedded.org · digital interface explorer · https://www.crowdsupply.com/1bitsquared/glasgow · code https://github.com/GlasgowEmbedded/glasgow · logs https://libera.catirclogs.org/glasgow · matrix #glasgow-interface-explorer:matrix.org · discord https://1bitsquared.com/pages/chat
be65da6e451238ff has quit [Ping timeout: 260 seconds]
redstarcomrade has quit [Read error: Connection reset by peer]
isabelburgos[m] has joined #glasgow
<isabelburgos[m]> It’s just scan control so there’s not really a way to break a SEM by scanning too fast or anything
<SnoopJ> if we're assuming "these questions will *only* be asked about the scanning code", I guess?
jn has quit [Ping timeout: 268 seconds]
jn has joined #glasgow
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
galibert[m] has quit [Quit: Idle timeout reached: 172800s]
f_ has quit [Ping timeout: 252 seconds]
f_ has joined #glasgow
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
galibert[m] has joined #glasgow
<galibert[m]> Fuck
<galibert[m]> I: g.hardware.build_plan: build: ERROR: Max frequency for clock 'applet0_clk': 46.35 MHz (FAIL at 48.00 MHz)
<whitequark[cis]> probably need a register stage somewhere
<whitequark[cis]> post the code?
<galibert[m]> I'm kinda vibe-coding it but without a LLM :-)
<galibert[m]> I measured that lr cycled every 128 clk edges, so I'm trying to send 128-bits frames of datam aligned with lr
<whitequark[cis]> this is probably the 25-bit count counter
<whitequark[cis]> on ice40, i do not recommend making counters much larger than 16 bits
<whitequark[cis]> 20 is about the upper edge of what's okay
<whitequark[cis]> there's a class in glasgow.gateware for making big counters
<galibert[m]> just fyi, it was working-but-not-going-what-I-want when m.d.sync += srb.eq(Cat(srb[8:], C(0, 8))) had the Cat parameters swapped
<whitequark[cis]> glasgow.gateware.accumulator
redstarcomrade has quit [Read error: Connection reset by peer]
<galibert[m]> but lemme just remove the counter, it's irrelevant
<galibert[m]> same error with the counter removed
<whitequark[cis]> interesting. post the complete log?
<whitequark[cis]> btw you don't need the [] when adding multiple statements to m.d.domain +=
<whitequark[cis]> (and the led stuff i usually do as leds = Cat(platform.request("led", n).o for n in range(5)); m.d.comb += leds.eq(count[18:]))
<whitequark[cis]> but this isn't important, just saves you some typing
<whitequark[cis]> ok, the key information is in `Critical path report for clock 'applet0_clk' (posedge -> posedge):`
<whitequark[cis]> you have a gigantic carry chain somewhere
<galibert[m]> I have two 128-bits shift registers, one bit-per-bit, one byte-per-byte
<whitequark[cis]> sr + 1 creates a 128-bit adder
<galibert[m]> the fuck?
<galibert[m]> that's 100% a bug
<whitequark[cis]> i mean... you wrote it...
<galibert[m]> what the hell did I have in mind
<galibert[m]> Must thanks for fiding it
<galibert[m]> * Much thanks for finding it
<whitequark[cis]> anyway, this is actually much better performance than what i recall. hm. i might need to reevaluate my guidelines for how big a counter is reasonable
<galibert[m]> heh
<whitequark[cis]> i definitely had some cases where a 32-bit counter broke some code
<galibert[m]> yeah, 24 worked perfectly well
<whitequark[cis]> it might be more of a problem with bigger designs
<galibert[m]> possibly yeah
<galibert[m]> nice, it kinda works
<galibert[m]> it's unstable, damnit
be65da6e451238ff has joined #glasgow
<galibert[m]> hmmm, the message sending over the stream is unreliable
<galibert[m]> there's a |uniq there so it only prints when the packet changes
anubis has joined #glasgow
<whitequark[cis]> are you checking for o_stream.ready?
<galibert[m]> No, didn't know I had to
<galibert[m]> lemme add that
<galibert[m]> not enough
<galibert[m]> valid needs to be 1 for one sync or it needs more?
be65da6e451238ff has quit [Quit: WeeChat 4.6.3]
mei[m] has joined #glasgow
<mei[m]> every clock cycle when valid and ready are both 1, one byte is transferred, iirc
<galibert[m]> nice, easy semantics
<mei[m]> (i believe i read this in a draft of an rfc, so take it with a grain of salt)
<galibert[m]> it reminds me of something too
<galibert[m]> pretty sure I read the amaranth rfc at the time
<galibert[m]> 122% cpu, I'm starting to have a feeling that python can't handle the bandwidth
<galibert[m]> 5.6Mb + overhead
<galibert[m]> 706k bytes/s
anubis has quit [Remote host closed the connection]
anubis has joined #glasgow
anubis has quit [Remote host closed the connection]
anubis has joined #glasgow
anubis_ has joined #glasgow
anubis has quit [Ping timeout: 272 seconds]
Lord_Nightmare has quit [Quit: ZNC - http://znc.in]
Lord_Nightmare has joined #glasgow
DragoonAethis has quit [Quit: hej-hej!]
DragoonAethis has joined #glasgow
anubis_ has quit [Ping timeout: 272 seconds]
balrog has joined #glasgow
balrog_ has quit [Ping timeout: 276 seconds]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow