<josuah>
something interesting with a standard library: once address mapping are generated, the firmware driving might not need to change much in any language
<josuah>
so if one use an amaranth FPGA CPU core and a small firmware for "business logic", it can go kind of fast to get some kind of tiny "SDK" or "HAL" going
<josuah>
only the application-specific cores need some binding then
<byteit101>
hmm... my FSM isn't resetting, how do I configure that?
<byteit101>
Wait, it's resetting in sims, but not on-target
<jn>
on which target platform?
<byteit101>
artix-7 (xilinx)
<byteit101>
basys 3 board
<byteit101>
All of my verilog glue logic Is resetting, but none of the amaranth logic is resetting
<byteit101>
If I'm not doing anything fancy I don't need to add a resetinserter or anything like that? Just wire up .rst(reset) ?
Dm30 has joined #amaranth-lang
<d1b2>
<marble> Is there a way in amaranth to get a list of all available pads of a platform with a specific device and package? like LatticeECP5Platform with LFE5U-25F in a BG256
<d1b2>
<marble> i would like to write a generic pin scan
<byteit101>
I simplified it down to a simple state machine, and it also fails to reset. Bug?
<byteit101>
Oh! are amaranth resets synchronous or async?
<vup>
@marble do you want to iterate over the pads used in a platform definition or do you want to know about all pads of the device? The latter information is not know to amaranth currently. There was some discussion about using similar information to perform validation checks of platform definitions, but no conclusion / concrete design was reached: https://github.com/amaranth-lang/amaranth-boards/issues/128
<vup>
byteit101: your choice, when creating a `ClockDomain` you can use `async_reset=True` to create a clockdomain with a async reset. By default this option is false. This also applies to the default `sync` domain that is created if you do not create it yourself.
<byteit101>
How do I use ClockDomain? my source dosn't have that right now
<vup>
you can add a clock domain using `m.domains += ClockDomain("domain_name")`, which can then be used using `m.d.domain_name += stmts`
<byteit101>
so at the top level I can just say "sync" and all the children domains are now async?
<vup>
what do you mean by children domains?
<byteit101>
*Children modules
<byteit101>
*submodules
<vup>
right
<vup>
by default clock domains are global in amaranth. This means you can add a `ClockDomain` anywhere in the design hierarchy and any (sub)module using a clock domain with the same name will use this `ClockDomain`
<vup>
optionally you can make a `ClockDomain` local (`local=True`), which will cause it to only propagate downwards in the design hierarchy
<vup>
Finally the `ClockDomain` used by a module instance can be changed using `DomainRenamer` (this way in a multi clock design you can write all your modules using the `sync` domain and then use `DomainRenamer` when adding them as a submodule to make them use the "correct" `ClockDomain`)
<byteit101>
Ah, handy! It would be great if this was documented somewhere
<Sarayan>
documentation is worked on but bottlenecked :-)
<vup>
Yeah, the documentation is WIP. FWIW the tests, examples are pretty useful aswell as the documentation of the source code.
<Sarayan>
not a choice I'm happy with for a default
<Sarayan>
I hate spooky actions at a distance
<vup>
yeah, I agree. In general im am not fully convinced even the late binding mechanism for the clock and reset domains is that useful. For my code I prefer clock domains to be eagerly bound and only propagated downwards.
<Sarayan>
that would be my natural inclination too