<Chips4MakersakaS>
<eigenform[m]> "Wanda: i think they're doing..." <- Yeah, you need something like `set_property PACKAGE_PIN C7 [get_ports FIXED_IO_ps_clk]` in the xdc file. And Wanda seemed right the ps_clk is "C7".
frgo has quit [Ping timeout: 276 seconds]
frgo has joined #amaranth-lang
frgo has quit [Read error: Connection reset by peer]
<RobTaylor[m]>
Catherine: would it be s stupid idea to add toggle coverage to PySimEngine?
sugarbeet has quit [Ping timeout: 248 seconds]
vup has joined #amaranth-lang
anuejn has joined #amaranth-lang
<RobTaylor[m]>
s/s/a/
<whitequark[cis]>
i think you can compute that already from the VCD
<whitequark[cis]>
i would prefer to add a mechanism of extracting waveform data from the simulation engine that is not VCD over adding toggle coverage specifically, since the former would cover that as well as a number of other useful cases
<whitequark[cis]>
for example it would also make it quite easy to do enum coverage, something toggle coverage is quite useless for
<whitequark[cis]>
that would need some careful design in an RFC though, since it is not very obvious how to do it in an efficient manner
<Chips4MakersakaS>
Other metrics can also be computer from the waveform data like power consumption and where the hot spot are etc...
<Chips4MakersakaS>
s/computer/computed/
<RobTaylor[m]>
<whitequark[cis]> "i think you can compute that..." <- oh interesting, good point.
<RobTaylor[m]>
<whitequark[cis]> "i would prefer to add a mechanis..." <- thats an excellent idea.
<RobTaylor[m]>
<whitequark[cis]> "that would need some careful..." <- good point
<RobTaylor[m]>
<whitequark[cis]> "that would need some careful..." <- yeah, some experiments first and then see, i think
frgo has joined #amaranth-lang
frgo has quit [Ping timeout: 260 seconds]
frgo has joined #amaranth-lang
frgo has quit [Ping timeout: 265 seconds]
frgo_ has joined #amaranth-lang
frgo_ has quit [Remote host closed the connection]
frgo has joined #amaranth-lang
<RobTaylor[m]>
<RobTaylor[m]> "thats an excellent idea." <- So i'm thinking something like a observer pattern tracer interface, then VCDWriter and other cool stuff like a toggle coverage tool or an an FST writer would subscribe to that interface. Makes sense?
frgo has quit [Quit: Leaving...]
frgo has joined #amaranth-lang
adamse has quit [Ping timeout: 272 seconds]
adamse has joined #amaranth-lang
peepsalot has quit [Remote host closed the connection]
peepsalot has joined #amaranth-lang
<cr1901>
jfng: Are there any known issues with the amaranth-soc GPIO peripheral for pin_count != data_width? I have a sample SoC which works when pin_count=data_width=8, but when I make pin_count=16, writes to output don't seem to be reflected on the LEDs
zyp[m] has joined #amaranth-lang
<zyp[m]>
issue when output register is wider than the bus? remember that the register write won't take effect until you've written the whole register
<cr1901>
I tried that, both with "sh" and "sb twice" but the writes still don't seem to take effect.
<whitequark[cis]>
try high to low order
<whitequark[cis]>
actually, I may be misremembering
<whitequark[cis]>
ignore me please
<cr1901>
Gimme me a sec to make the script easy-to-run for others (PEP723)
<cr1901>
I swap out the I/O insn to write to the whole output reg between builds, so I don't understand what I'm doing wrong
<cr1901>
Oh son of a bitch, partially figured it out... "sw was misaligned"
<cr1901>
zyp[m]: I lied (partially...) I wasn't using "sh", I was using "sw".
<cr1901>
CPU doesn't have a misaligned load handler, so it died
<cr1901>
err store* handler
<cr1901>
Remind me... do reads > CSR bus width have any special considerations?
<cr1901>
Is that the high to low thing?
<cr1901>
Well, partial reads don't work either (if I want to read the high byte of a 16-bit reg on an Wishbone2CSRBridge, 8-byte CSR bus, I have to read 16-bits, not 1 byte at (REG_OFFSET + 1))
<cr1901>
I was "insulated from this by using 8 bit I/O ports for everything in AttoSoC, but wanted to play around. So now it bites me.
<zyp[m]>
IIRC a major point of the CSRs is that all registers are atomic, and your register access code should reflect that
<zyp[m]>
if you only need half the register, that's probably a sign it should be divided into two registers
<cr1901>
An 8-bit read is going to be atomic
<cr1901>
AFAICT, the GPIO peripheral does not allow you to split the ports into banks like that, unless I create a second GPIO peripheral (which, thinking about it more, I guess is how it's implemented on STM32 and MSP430)