<vipqualitypost[m>
so I'm trying to use double dabble algorithm for putting data onto 7 segment displays, but I can't get this to generate any waveforms in the simulator, it just hangs. There is a small block that I commented out, that if I just put an empty m.d.comb in, then it will run (but obviously not generate correct result) : https://paste.jvnv.net/view/yKz4Z
<vipqualitypost[m>
Is there any way to get debug info from simulator? When I ctrl + C, it just gives me a short stack trace that ends in : `changed.update(self.pending)`
<vipqualitypost[m>
ah, trying to build seems yosys found a loop
Degi_ has joined #amaranth-lang
Degi has quit [Ping timeout: 255 seconds]
Degi_ is now known as Degi
Raito_Bezarius has quit [Ping timeout: 256 seconds]
Raito_Bezarius has joined #amaranth-lang
phire has quit [Quit: No Ping reply in 180 seconds.]
<sporniket>
for now I convinced the makefile to target the wanted host instead of targeting my host (with -e) ...
<sporniket>
but now it does not know how to make yices.h
<sporniket>
will have to look how to convince it to do it.
<sporniket>
On another subject, I try to follows the talks here and I also read current RFC about CSR
<sporniket>
And I have a little use case inspired by retro chips (like the MC6850) that use a same address to have 2 registers, depending whether the transaction initiator is reading or writing
<sporniket>
I am wondering if that behavior is possible at all ?
urja has quit [Read error: Connection reset by peer]
urja has joined #amaranth-lang
iposthuman[m] has joined #amaranth-lang
<iposthuman[m]>
Curious, how would I use an iCE40 PLL with Amaranth? Would I generate a PLL primitive and then use and instance (i haven't done this before). Or is there an Amaranth component that generates the appropriate "stuff"? 🤔
<galibert[m]>
The appropriate stuff is an Instance in the first place
<iposthuman[m]>
That's quite some effort, but cool.
<iposthuman[m]>
Thanks
<cr1901>
KidPix was always awesome. I never got the hang of Snood
<iposthuman[m]>
That is crazy. It finally booted and I was able to use it like a real OS 🙂
<whitequark[cis]>
it is a real OS
<iposthuman[m]>
Indeed. It has all kinds of apps and it responsive too.
<iposthuman[m]>
It's funny how they integrated their website/company in various files and folders.
<crzwdjk>
iposthuman[m]: you need to create an Instance, yes. You can precompute the parameters needed if you just want a fixed frequency, otherwise you would need code to compute them. Here's the code from my project: https://github.com/crzwdjk/uniterm/blob/main/gateware/icepll.py
<crzwdjk>
I still need to fix the issue that replacing the sync domain removes the BRAM workaround
<whitequark[cis]>
if you're using a PLL then that probably doesn't matter to you
<whitequark[cis]>
because a PLL takes time to lock and that adds a small delay
<duskwuff[m]>
I'm pretty sure they just repackaged https://infinitemac.org/ with their own disk image
duskwuff[m] has joined #amaranth-lang
jjsuperpower has quit [Ping timeout: 276 seconds]
<tpw_rules>
they did say they wrote their own app
<crzwdjk>
whitequark[cis]: good to know, I won't worry about it too much then.
<whitequark[cis]>
this is a big part of why the functionality is designed like this: if you have any explicit reset it probably doesn't matter for you
<whitequark[cis]>
(assuming you connected the PLL lock signal to the clock domain reset)
<crzwdjk>
Which I did do, this time around at least
<galibert[m]>
They say they used infinitemac
<galibert[m]>
And did work for tcp/ip and stuff
<whitequark[cis]>
today with gatecat we've had a thought about adding __len__ to data.View
<whitequark[cis]>
* about adding `__len__, * __len__` to
<whitequark[cis]>
it doesn't reserve a new name and it seems useful, since the alternative to len(x) is either len(x.as_value()) or x.shape().size, both of which are more awkward
<whitequark[cis]>
however an argument against it is that data.View isn't a container and len() is a method for containers
<whitequark[cis]>
I think, personally, I find the argument against persuasive, since we're doing as best as we can to actually adopt Python conventions for Amaranth code, rather than just reusing syntax
nelgau has joined #amaranth-lang
<Wanda[cis]>
that'd be particularly weird when an ArrayLayout is involved
<whitequark[cis]>
actually, since it implements __getitem__, it's necessary that for x in range(len(x)) would all result in [x]
<whitequark[cis]>
... yes, was about to bring that up
<whitequark[cis]>
we actually maybe should implement __len__, but only for ArrayLayout?
<Wanda[cis]>
hmmm.
<whitequark[cis]>
* we actually maybe should implement __len__, but only for views of ArrayLayout?
<Wanda[cis]>
maybe?
<whitequark[cis]>
(I think that one qualifies as a bug and wouldn't need an RFC)
<Wanda[cis]>
yeah
nelgau_ has joined #amaranth-lang
nelgau has quit [Read error: Connection reset by peer]
twamueller[m] has quit [Quit: Idle timeout reached: 172800s]
<zyp[m]>
Catherine: how do you feel about adding an optional `platform` argument to `Simulator` that gets passed into the DUT fragment? I figure it could be useful to provide a mock platform with simulated IO registers
<whitequark[cis]>
zyp: sgtm
<zyp[m]>
does it then also make sense to have an .add_fragment() that allows the mock platform to instance simulation models without them having to be coroutines? I figure for cxxsim it'd be beneficial to be able to model stuff like IO registers without having to return control to python every time they need to change
<whitequark[cis]>
that would have to go through a design cycle; I think we need a coherent approach to PHY replacement and not just adding bits piecewise
<whitequark[cis]>
I have a document (a private one at the moment, I should be able to share it) that outlines what I want to see
<zyp[m]>
ah, looks fairly similar to what I have in mind, except my use case is a layer lower, I want to simulate the actual PHY with simulated FPGA primitives, not mock the whole PHY
<zyp[m]>
so in my case, the mock platform would have a .request() that returns IO register models
<whitequark[cis]>
if you have a behavioral model of the IO primitive you can shove it into Instance
<whitequark[cis]>
it's not really documented but basically grab everything from the Module simulating the primitive and put it into the Instance fragment
<zyp[m]>
which instance fragment?
<whitequark[cis]>
Instance("SB_IO") for example
<whitequark[cis]>
whichever FPGA primitives you use
<zyp[m]>
yeah, sure, but whether the model is an amaranth fragment or an Instance, it still needs a way to get attached to the simulation
<whitequark[cis]>
I'm not sure I fully understand
<zyp[m]>
let's say Simulator() takes dut and platform as arguments, it'll then elaborate the DUT, which calls platform.request(), which creates simulation models that also needs to be attaced to the simulation
<whitequark[cis]>
oh, I see
<zyp[m]>
if I model things as coroutines, the platform could just call sim.add_process() and friends
<whitequark[cis]>
yeah, I think this should go through a design cycle first, since we do need some changes to enable adding Python/CXXRTL blackboxes, HDL whiteboxes, etc
<zyp[m]>
fair enough, short term I'm happy to model everything as coroutines anyway
<whitequark[cis]>
it might also make sense to migrate off platform.request and to a more sensible design simultaneously
<whitequark[cis]>
you can also always make your platform also a top-level elaboratable which adds everything requested to itself
<whitequark[cis]>
this is roughly what TemplatedPlatform does
<whitequark[cis]>
actually it does something considerably more cursed
<whitequark[cis]>
but the idea is the same
<zyp[m]>
adding stuff to the toplevel while its submodules are being elaborated is not gonna mess with elaboration?
<whitequark[cis]>
elaboration isn't some magic complicated process like it's in verilog
<whitequark[cis]>
the toplevel can control it entirely because its elaborate function is the entry point
<whitequark[cis]>
so if it does Fragment.get(self.top, self) it can collect anything it wants and then add it as submodules to itself
<whitequark[cis]>
elaborate is a normal function call and Fragment.get is just a loop
<zyp[m]>
okay
<zyp[m]>
I rewrote the simulation I did yesterday using the async API I did a couple of weeks ago: https://paste.jvnv.net/view/NUcbq
<zyp[m]>
gonna try this out a bit as I add streams and see how the ergonomics works out