peepsalot has quit [Read error: Connection reset by peer]
Degi has quit [Ping timeout: 240 seconds]
Degi_ is now known as Degi
peepsalot has joined #amaranth-lang
<d1b2>
<TheManiacalLemon> Is there a 'proper' way to hijack an existing clock domain's reset signal? Let's say I want to take m.d.sync and add a pulse stretcher to rst, i.e. if the original sync rst signal gets a pulse, the output signal gets held for a minimum number of clock cycles
<d1b2>
<TheManiacalLemon> I tried to use ClockDomain('sync') to obtain the rst signal, but apparently that just creates an entirely new domain unrelated to m.d.sync
<d1b2>
<TheManiacalLemon> basically I want to lift the reset signal, fiddle with it, and then replace the original signal with the output of the new module
Vonter has quit [Ping timeout: 256 seconds]
Vonter has joined #amaranth-lang
<d1b2>
<dragonmux> you want to use ResetSignal('sync') to pull the current sync's reset signal
<d1b2>
<TheManiacalLemon> Is there a way to reassign it in a similar manner?
<d1b2>
<TheManiacalLemon> so for instance I could do: m.d.comb += resetter.rst_i.eq(ResetSignal('sync')) to insert it, but assigning rst_o back to the original reset is what confuses me
<d1b2>
<dragonmux> from within the domain, no, but for all submodules, yes - do your clock stretching on a new Signal() that's driven from ResetSignal('sync'), then use ResetInserter(newSignal)(submodule) to provide that new reset signal as the reset signal for sync in the submodule
<d1b2>
<TheManiacalLemon> Oh, I see. So I will need to put the reset stretcher one level above where it's used
<d1b2>
<dragonmux> yes
<d1b2>
<TheManiacalLemon> I suppose that makes sense because otherwise I'm dealing with an already-created signal and then trying to rip it out
<d1b2>
<TheManiacalLemon> thanks! I'll give that a shot
<d1b2>
<TheManiacalLemon> Hmm. It seems in doing so it causes .rst() to exist alongside the new .rst_stretch() signal in the generated Verilog. It's got some casez statements that check the stretched reset and then the original reset signal, which doesn't seem quite right. I'll dig in to see if it's something I'm doing wrong or if there's examples of how to use this
<d1b2>
<twam> I'm getting a python's MemoryError when using a Memory inside a simulation: memory = Memory(width=8, depth=320*240) m.submodules.memory_write_spi = memory_write_spi = memory.write_port(domain="scl") Is 320*240 already too large for the simulation to handle? Doesn't sound that extram to me. Limit seems to be slight above 2000.
<Sarayan>
that's 256*320*240 though
<Sarayan>
ah no
<Sarayan>
320*240*8
<Sarayan>
so 600K signals
<d1b2>
<twam> Is too much more for the simulator? What's the limiting factor? Any suggestions how to simulate a design with a larger RAM?
<Degi>
You can simulate the RAM with some python code
<Degi>
And then use a python or numpy array as the memory itself
<Degi>
I think something like "yield data.eq(python_array[(yield address)])" should work to read a memory array and vice versa for write
bvernoux has quit [Read error: Connection reset by peer]
<Sarayan>
Alternatively, you can see about using cxxrtl. It's a little more difficult than simulating in python, but performance and capabilities are higher
Vonter has quit [Ping timeout: 240 seconds]
<d1b2>
<twam> The Memory is currently inside the module under test, so I would need to factor this out and inject?
<Degi>
Hmm, I'd replace the ReadPort and WritePort with signals which you can access in the simulation code and then simulate the memory based on these signals
<Degi>
Is using a smaller memory an option maybe? You could use smaller values instead of 320x240 in simulation. Also useful for timers, which otherwise count up to a few million...
<agg>
+1 on exposing addr/data signals at the module and then using them to fake a big memory in the simulator, you can do that as a separate process to your main testbench to keep it simple too
<agg>
though a small memory might work too for a simple test? if you can just make the memory size a parameter of the module
<d1b2>
<twam> Interestingly I already commented on that issue 😉 But in the past I was stumbling upon a RecursionError and not the MemoryError. Having the memory smaller for the test seems to be at least for the current module a viable and simple option.
Vonter has joined #amaranth-lang
<d1b2>
<twam> Another question, where I could need some input/guidance: Basically I'm trying to build an sniffer for an SPI display. Currently I use the SPI's clk as a clock domain and on every 8'th pulse of the clock I push the data into the memory. As I'm doing the write enable of the memory on the SPI's clk, the memory doesn't get updated on the last pixel until the next transmission which is a bit unfortunate. I thought of using the edge on CS for
<d1b2>
triggering the memory a last time, but no good idea, how to hack that in. Is this a good idea anyhow or better suggestions? I wanted to avoid oversampling the SPI as it is already quite fast (~40-60 MHz).
<Degi>
Do you only get 7 edges on the last byte?
<Degi>
Maybe you could have one ClockDomain with the SPI clock which pushes it bit for bit into a FIFO and then have another domain which reads that FIFO and turns it into bytes at a higher frequency than the SPI domain