<hcsch>
Does anything speak against passing the GlasgowAnalyzer down into the I2C gateware as an optional parameter for registering the I2C signals upstream? That I can for example easily get traces for what my 24-series emulation thingy is doing without also having to attach an external logic analyzer
<whitequark[cis]>
have you seen glasgow run --trace?
itsmk has joined #glasgow
FFY00_ has quit [Read error: Connection reset by peer]
itsmk has quit [Ping timeout: 265 seconds]
itsmk has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
nyanotech has quit [Remote host closed the connection]
nyanotech has joined #glasgow
Tom has joined #glasgow
dne has quit [Remote host closed the connection]
dne has joined #glasgow
mal has quit [Quit: mal]
alephbias[m] has quit [Quit: Idle timeout reached: 172800s]
gue[m] has joined #glasgow
<gue[m]>
Printed and fits like a glove! Thank you for sharing.
mal has joined #glasgow
<grazianom[m]>
Awesome! Glad my effort is helping out more than just myself
MyNetAz has quit [Remote host closed the connection]
MyNetAz has joined #glasgow
<hcsch>
> have you seen glasgow run --trace?
<hcsch>
Yes, but that currently doesn't capture events of the I2C gateware signals AFAICT (I only got fifo evens in my trace vcd with --trace)
<whitequark[cis]>
sorry, by I2C gateware what do you mean specifically?
<hcsch>
ah sorry, the signals from I2CTarget or I2CBus for example from software/glasgow/gateware/i2c.py
<whitequark[cis]>
in which context would these be instantiated? i.e. which applet would be running?
<hcsch>
in the 24x-emu thingy, or maybe also in the i2c-target/initiator applet
<hcsch>
AFAICT so far, you get the analyzer for --trace runs via the hardware target passed into build and can then register events with that, with only the fifos being in there by default?
<whitequark[cis]>
yes. now that i understand what specifically is the request, my answer is yes: let's have it
<whitequark[cis]>
i kind of neglected the analyzer because i was not very competent when i designed it and it has a large impact on delay
<whitequark[cis]>
this should just be fixed at some point
<hcsch>
ah ok, I hadn't paid any attention to delays that might have been introduced so far, but it didn't seem to have hurt my probably rather slow I2C connection with ~20 analyzer event streams
<whitequark[cis]>
sorry, by "delay" i mean "Fmax"
<whitequark[cis]>
if you put "too much" stuff into the analyzer your design stops meeting timing
<hcsch>
ahh ok, yeah, makes sense. I'm still a bit new to this stuff ^^
<whitequark[cis]>
i think the analyzer predates nextpnr so i couldn't really optimize it even if i had the skills to do it back then
<hcsch>
I should probably make my 24x-emu thingy a PR already so I can point at stuff more sensibly, but good to know that you'd be up for adding more events to the analyzer :)
<whitequark[cis]>
oh, you're fine, I was using terms in a somewhat weird way anyway