00:47 <whitequark[cis]> it's not really off-topic is it?

00:48 <whitequark[cis]> my general feeling is that because of the plethora of issues such as these, maybe it's a good idea for the core Amaranth language to include the absolute bare minimum necessary to support other people's FV flows, where they're responsible for making the UX good

00:48 <whitequark[cis]> it's either that or making it our responsibility but... FV is not the core competency of any major contributor to Amaranth and we have our hands very full

02:29 <cr1901> Compared to say, 1.5+ years ago, I have ideas for bespoke-yet-turnkey formal scripts that aren't a huge maintenance burden (be it using pydoit, boolector-wasm, getting bitwuzla packaged, whatever).

07:59 <Mimil> Hello, I am very new to hardware design, and I am currently developing a design for an Artix-7 fpga on a CMOD-A7. I ran into some timing constraints issues with the UART communication with the serial module from amaranth.stdio : the design is clocked at 280MHz and we use a baudrate of 115200, which result in a 12 bits timer. In practice it worked

07:59 <Mimil> fine, but the time reports of vivado reported some issues. The solution I cooked is to use a custom "pipelined" timer. I don't know if pipelined is the right term but essentially the timer is divided in smaller chunks and each time it is decremented we memorize which chunks will underflow at their next decrement so that a chunk is decremented when

07:59 <Mimil> all less significant chunks underflow. What's important is that this solves the timing issues and works well. What I would like to know is what have I done wrong to need it and if nothing, if this timer would be an useful contribution to amaranth.stdio. In which case, I would be able to make a clean and tested pull request next week. I don't want

07:59 <Mimil> to sound pretentious, I am still very new to this and I probably missed something, only I have the time to make this contribution if you think it's useful.

08:35 <Wanda[cis]> oh yeah, I wrote something similar once

08:35 <Wanda[cis]> https://github.com/GlasgowEmbedded/glasgow/blob/main/software/glasgow/gateware/accumulator.py

08:39 <Wanda[cis]> but also hm. a 12-bit counter not meeting timing is kinda a sign that your clock may be a little too fast

08:41 <Wanda[cis]> 280MHz is definitely overkill for serial

08:49 <Mimil> The 280MHz is required for the main functionality of the design (QPSK modulation at 70MHz) and the custom timer was needed for some bigger counters in that part too

08:50 <Mimil> So I guess the proper way to meet timing would have been to use a slower clock domain ?

09:33 <vup> so with https://github.com/YosysHQ/yosys/pull/4877 it should be possible to get statement labels for `assert`, `assume`, `cover` from amaranth by adding a `name=` argument to the respective amaranth cells that gets forwarded to the cell name in the rtlil backend. Does that sound reasonable enough to submit a RFC for?

23:33 <cr1901> So I have an issue trying to add a new platform... the platform presents itself as a mass storage device for programming. It expects a JEDEC file from Lattice Diamond. It looks for a specific string "NOTE: <device name>*'. The end asterisk is important.

23:34 <cr1901> The ddtcmd step to copy the JEDEC file from the Implementation directory in Amaranth's machxo2 scripts strips this asterisk (while still being a legal JEDEC file, according to my reading of the JEDEC spec)

23:35 <cr1901> If the programmer firmware doesn't find the exact string I listed above, including the asterisk, it'll refuse to program, because of course it does

23:36 <cr1901> What recourse do I have (as in what patch will be accepted) to skip the ddtcmd step to copy the JEDEC file and "just" "cp" it from the Implementation dir? Unclear how common this firmware is in the wild; it's based on an STM32 mass storage programmer (STEPLINK)

23:38 <cr1901> I thought about overloading the command_templates property inside the platform file with a nice comment, and adding the "cp" there (with a check for Windoze of course)