Open whitequark opened 5 days ago
Like this? (#602) My Amaranth is very rusty and I don't have how to actually test this. Is there an easy way to make sure an Amaranth/Python change is an RTL no-op?
Is there an easy way to make sure an Amaranth/Python change is an RTL no-op?
No, but the changes are simple enough I expect to catch most issues during review, even if it's tedious.
Improvements to the general applet infrastructure will continue at a decent pace for the next half year or so, and I expect I'll have to sit down and manually test every single applet at the end of it, hopefully while also adding some better tests. It's going to be painful but what can you do?..
Also I don't even know where my HX711 board is, much less have a load cell on hand...
Any tips on sequencing updates across multiple modules, eg. with UART(pads/ports) being used by multiple applets?
Is there a temporary/transitional mechanism that I could use to first update the applets (or libraries?) and then the other side?
I'd suggest leaving updating the libraries (UART and I2C in particular) to some later point, they're kind of a pain and I'm going to rewrite UART at least soon, anyway.
For the rest, unfortunately we don't have real applet composability so the answer is suffering. Making things composable is on my TODO list but it goes after this.
The two mechanisms are similar conceptually and mainly differ syntactically. The following command can illustrate the changes required:
List of applets that still need migration: