<d1b2>
<pln> Hi Folks I had some icebreaker/amaranth questions, and used the icebreaker channel for those. This question is more amaranth specific so I try here. I want to simulate a memory component, and have the following in my testbench: python sim = Simulator(mem) sim.add_clock(1e-6) sim.add_sync_process(bench) with sim.write_vcd( "mem.vcd", "mem.gtkw", traces=[addr, w_data, we, r_data] ): I want to add the implicitly generated clock to the
<d1b2>
traces, is that possible, or would I need to define a clock domain manually somehow. (In gtkwave I can right click the top component and append/insert all traces, and there I get two clk (among a billion other signals that I don't want ;)). I guess what I see there is the clk signals of the read/write ports, I looked at the generated .vcd and indeed: python $scope module rdport $end $var wire 5 ! mem_r_addr $end $var wire 32 $ mem_r_data $end
<d1b2>
$var wire 1 * clk $end I tried (and failed) to add the internal clock signal of the rdport to the traces (guess its not supposed it should be exposed). Also its not really the rdport clk I'd like to trace but the overarching clk driving both rdport and wrport (although in this case they are the same).
<cesar>
pln: Sorry for not directly answering your question, but I wrote a Python-based mini-language for writing .gtkw files, with colors, signal groupings, and other features. See https://fosdem.org/2022/schedule/event/gtkwavecss/ It would be nice to have more adopters...
<Degi>
pln: Does ClockSignal() as a trace work?
wlkO`Rety has quit [Ping timeout: 246 seconds]
<d1b2>
<pln> I can try
wlkO`Rety has joined #amaranth-lang
<d1b2>
<pln> seems its not found in the amaranth lib
<Degi>
Hmm right, maybe in your module have a signal, like clock_sig = Signal() in the init and in the elaborate do m.d.comb
<Degi>
+= clock_sig.eq(ClockSignal())
<d1b2>
<pln> atm, I don't really have an explicit module in the test bench, I just create an instance sim = Sumulator(dut)
<Degi>
Hmm I see, not sure if you can access ClockSignal() then
<d1b2>
<pln> so there is obviously a clock added, question is if it is accessible somehow
<d1b2>
<dragonmux> it is not directly - but then you also control that clock as it'll only cycle when you yield from the test bench with no argument to the yield statement
<d1b2>
<dragonmux> that said, if your DUT does the trick Degi suggested, it will create a signal that directly observes the clock
<d1b2>
<pln> by the way, is there a diff between yield Tick() and just yield (I'1m using Tick() for now...)
<d1b2>
<dragonmux> yes, don't do the former.
<d1b2>
<pln> ahh is it some old nmigen leftover ...
<d1b2>
<dragonmux> it's more.. Tick is an internal implementation detail of the simulator
<d1b2>
<dragonmux> the public API is to yield with no arguments
<d1b2>
<pln> So its working. What is the best preferred/best practice, to define interfaces with arguments like: python class Mem(Elaboratable): def __init__( self, # in addr: Signal(5), w_data: Signal(32), we: Signal(), # out r_data: Signal(32), ): Or "bind" the signals from outside?
GenTooMan has quit [Ping timeout: 250 seconds]
GenTooMan has joined #amaranth-lang
<Degi>
I use a mix of both
<Degi>
(Though do not add default arguments to signals, otherwise the same signal instance will be used for all instances of the class)
<d1b2>
<pln> same instance? even if overridden, or....
<d1b2>
<dragonmux> we typically define the signals as attributes of the instance and then bind from outside.. it's not more expensive to do it that way
<d1b2>
<pln> expensive as just less ergonomic, or regarding the synthesis?
<d1b2>
<dragonmux> regarding synthesis
<d1b2>
<pln> I guess its just a matter of taste than, or ...
<d1b2>
<dragonmux> we find the attributes-on-a-class interface to be more ergonomic because of how the elaboratables plug together
<d1b2>
<dragonmux> esp as not all signals have to be connected up for it to be valid..
<d1b2>
<pln> ahh that's a good point
<d1b2>
<dragonmux> but it is preference at the end of the day
<d1b2>
<dragonmux> also, don't forget that the type annotations are nothing more than a hint/suggestion
<d1b2>
<dragonmux> there would be nothing stopping someone passing a Signal(64) to w_data, for example
<d1b2>
<dragonmux> er.. s/to/as/
<d1b2>
<pln> I guess the type annotations are used internally for coersions?
<d1b2>
<dragonmux> used externally for type checking by linters and static type checkers
<d1b2>
<pln> oki
<whitequark>
there's an upcoming RFC that will let you use type annotations more meaningfully than just for documentation
<d1b2>
<dragonmux> ooo, we look forward to that
<whitequark>
excellent :)
nak has joined #amaranth-lang
<Degi>
pln: Like if you have two instances of a class with a signal as a default argument (and it was not overridden during instantiation), then both have the same signal
<d1b2>
<absurdfatalism> Would this be a place to ask questions about a Litex design in migen?
<tpw_rules>
there is a #litex channel
<tpw_rules>
but i don't think it's bridged anywhere except matrix
<d1b2>
<absurdfatalism> I think I found the IRC channel - havent seen a discord channel
<d1b2>
<dragonmux> on the 1b² Discord server, most Litex questions tend to land in #fpga.. the libera.chat channel is probably a better starting point though