<sensille>
hm. now my design build again, but fails timing. not sure if it's because of the move from nmigen to amaranth or because i also updated the rest of the toolchain too :-/
<whitequark>
it's probably not because of the former
indy has joined #amaranth-lang
<robtaylor>
hmm, installed with [builtin-yosys], but when i `python3 -m amaranth_boards.ecpix5`, i'm getting `Could not find required tool nextpnr-ecp5 in PATH` - is that expected?
<whitequark>
yeah. builtin-yosys is only for the Verilog backend
<robtaylor>
ahhh
<robtaylor>
how tricky would it be to include the various backend tools? is it a big job, or something i could hack together?
<robtaylor>
Catherine: how do i get amaranth-boards to use it?
<adamgreig[m]>
Set environment variables like YOSYS=yowasp-yosys NEXTPNR_ECP5=yowasp-nextpnr-ecp5 ECPPACK=yowasp-ecppack
<robtaylor>
ah
<adamgreig[m]>
Amaranth checks env vars for each tool name
<robtaylor>
any reason it's not using those as default when installed [builtin-yosys] ?
<adamgreig[m]>
builtin-yosys is basically unrelated to the yowasp tools except that both are clever webasm stuff, it's a minimal yosys just for making verilog, doesn't imply any ecp5 or nextpnr support
<adamgreig[m]>
(well I mean both are whitequark, too, so not exactly unrelated...)
<robtaylor>
ah, so it'd make sense to have a [builtin-yowasp] for amaranth-boards?
<whitequark>
it's not in any way related to amaranth-boards either
<robtaylor>
next issue `$ python3 -m amaranth_boards.ecpix5
<robtaylor>
ERROR: Module `\SGSR' referenced in module `\cd_sync' in cell `\U$$2' is not part of the design.`
<whitequark>
I do not want to introduce yowasp as a preferred toolchain in any way
<whitequark>
it's not Amaranth's business how the toolchain is installed
<whitequark>
the builtin-yosys thing exists because you should not have to build the FOSS toolchain from source just to use Vivado
<robtaylor>
nod understood
<adamgreig[m]>
yea, having the env var override thing works perfectly for me
<adamgreig[m]>
i guess it would be neat to have some way to make it easier to use the yowasp toolchain once it's installed, maybe a wrapper or something that sets the env vars
<adamgreig[m]>
probably that's already there and i just haven't looked, heh
<whitequark>
it does
<whitequark>
you can write a shell script exporting the env vars and set the AMARANTH_ENV_Trellis environment variable to that shell script
<whitequark>
the same as for Vivado, Quartus, etc
<whitequark>
should add that to the docs but the section where it'd live does not exist
<adamgreig[m]>
> <@rob_chipflow:matrix.org> next issue `$ python3 -m amaranth_boards.ecpix5
<adamgreig[m]>
> ERROR: Module `\SGSR' referenced in module `\cd_sync' in cell `\U$$2' is not part of the design.`
<adamgreig[m]>
dunno what's going on with this, though. amaranth instantiates SGSR for you as part of the ecp5 platform support if you don't specify your own sync clock domain, but it's a standard cell that should be found.... are you specifying YOSYS=yowasp-yosys or still using the builtin-yosys?
<whitequark>
i think that shouldn't matter either way
<robtaylor>
using builtin-yosys
<robtaylor>
mm, but its amaranth latest release rather than head, could it be a clash between yosys versions?
<d1b2>
<dragonmux> builtin-yosys does not contain any of the techmap files needed to target ECP5, you must use either yowasp-yosys or another source of yosys
<d1b2>
<dragonmux> wq meant what she said about it only being usable for Verilog output, no more
<whitequark>
yeah but how are you using builtin-yosys for synthesis?
<whitequark>
(I mean, you could technically if you really put in effort, but)
<robtaylor>
oh, i don't know if i am, all i know is i installed with [builtin-yosys]
<whitequark>
then you aren't
<whitequark>
and in any case having YOSYS= takes priority iirc
<robtaylor>
hmm, why didn't i get an error from a missing yosys install then? o_o
<adamgreig[m]>
but if you don't have YOSYS=, and run synthesis, won't amaranth use builtin-yosys to try and synthesise?
<whitequark>
adamgreig[m]: no
<whitequark>
there is no logic for that because it will never work
<adamgreig[m]>
if you do install yowasp-yosys and put YOSYS=yowasp-yosys, do you get the same error?
<adamgreig[m]>
hah, fair enough
<whitequark>
Rob Taylor: are you setting YOSYS=yowasp-yosys?
<robtaylor>
ahhhh. I did have a yosys installed, but not yowasp
<robtaylor>
* not yowasp-yosys
<adamgreig[m]>
whitequark: aah, I forgot that for synth it's a shell script that has a yosys to run in it, which obviously can't ever be the builtin-yosys
<whitequark>
yeah
<adamgreig[m]>
but must be some yosys so maybe it is running some weird or old yosys binary you have installed?
<robtaylor>
mismatched yosys then, i guess!
<whitequark>
adamgreig[m]: yes
<robtaylor>
YOSYS=yowasp-yosysseems to be working with
<robtaylor>
* seems to be working with YOSYS=yowasp-yosys
<robtaylor>
whitequark: yep, that was it
<whitequark>
yeah, you need matching yosys/nextpnr too, so if you use one from yowasp, you need to use the other too
<robtaylor>
i'm assuming i'll need openFPGALoader installed normally (not in yowasp)?
<adamgreig[m]>
it's not in yowasp
<whitequark>
yeah. there is the YosysHQ fpga-toolchain build that includes programming tools too
<whitequark>
yowasp intentionally excludes those
<robtaylor>
nod
<adamgreig[m]>
could you even run libusb etc in wasm?
<tpw_rules>
there is WebUSB...
<whitequark>
i looked into it
<whitequark>
no, WebUSB is unrelated
<adamgreig[m]>
I'm not surprised :P just realised asking you if you "could" do x in y is probably the wrong question
<whitequark>
wasmtime (the engine used in yowasp) doesn't include any web APIs
<robtaylor>
whitequark: i guess that's been superseded by oss-cad-suite-build ?
<tpw_rules>
well it is precedent
<whitequark>
yes
<whitequark>
webusb is actually harder to use than adding libusb support through wasmtime
<whitequark>
i could port openocd to wasmtime fairly easily but it would require a system or python-shipped libusb
<whitequark>
porting openocd to webusb is considerably harder
<whitequark>
though iirc someone did it
<adamgreig[m]>
lot of interest in having libusb-based tools running in the browser I guess
<adamgreig[m]>
be neat for web based fpga programming among a ton of other uses
<whitequark>
it's doable, most of the pieces for running Amaranth and the toolchain entirely in the browser are there
<whitequark>
the wavedrom guy has been very rude to me about it but i have a non-published build of yosys and nextpnr targeting actual web apis
<whitequark>
I would prefer if you filed an issue stating what is not working, rather than submitting a fix without a description of what is being fixed
<whitequark>
Rob Taylor: I've pushed an update to amaranth-yosys
<whitequark>
in a few minutes you'll be able to install a version that's compatible with M1
<robtaylor>
nice!
<whitequark>
also, I was quite rude to you, and that was uncalled for; I'm sorry
<robtaylor>
oh, thank you, that is appreciated
<robtaylor>
just figuring this out =)
<whitequark>
I should make it clear that I strongly prefer issues being filed over going straight to patches
<robtaylor>
i expect I'll get a lot more wrong in future.
<robtaylor>
I could do a README?
<whitequark>
an issue allows the maintainers to discuss what is being solved and the appropriate approach to doing so, and provide the context new contributors do not have
<robtaylor>
that makes a lot of sense with the underlying complexity here
<whitequark>
I'll update the README in a sec
<tpw_rules>
there's also a lot of projects that are emphatically the opposite
<whitequark>
tpw_rules: yes, which is why it is fair for Rob Taylor to have an assumption that patches are preferred
<whitequark>
this is something I need to state in a CONTRIBUTING.md file or the like
<robtaylor>
I've used a PR checklist for things like that before
<whitequark>
oh, that's a good idea
<whitequark>
thank you
<robtaylor>
whitequark: I am an inveterate drive-by patcher..
<robtaylor>
robtaylor: not always the best habit ><
<whitequark>
unless the patch is truly trivial I either consult the project documentation or ask around
<_whitenotifier-7>
[amaranth-lang/amaranth-yosys] whitequark 5e514bd - README: add a note on build and development platforms.
<whitequark>
I've updated the README
<robtaylor>
the risk is more when you end up accidentally a maintainer of something like dbus... 😅
<robtaylor>
that probably closes #4 as well
<whitequark>
no, they're using the right Ubuntu version
<tpw_rules>
should it be worded in a less open manner? "To reduce maintenance overhead, the only development environment we will support for this repository is x86_64 Linux."
<robtaylor>
whitequark: I think if I set the secret for my testpypi account and make the branch name 'develop' in my repo, it might work.. but I think better i just submit with the fixes and not try that..
<whitequark>
yeah but the names are already reserved on testpypi