<whitequark[cis]1>
I've still not caught up with backlog
<whitequark[cis]1>
in a hour or so
<mcc111[m]>
Oh, sorry, I thought the line of text I'd sent along with it had been sent. It was: "Was reading Analogue's instructions on how to build their sample file and encountered an actual "Draw the rest of the owl" line "
<mcc111[m]>
I then told Quartus Lite to create an empty project. It went into Windows "not responding" state and stayed there for half an hour until I killed it D:
<mcc111[m]>
I am not asking for help yet mind you! But I might soon
<mcc111[m]>
s/soon/tomorrow/
<mcc111[m]>
I guess one short question: Is any of a .qsf, .qpf, a .sdc, a .qip, or a .mif file indicative of a quartus file already resident in a directory?
<mcc111[m]>
hm, it let me open the .qpf…
<cr1901>
I wish it hadn't been literally 10 years since I used Quartus, otherwise I'd probably be able to help :(
<mcc111[m]>
It built… something. I'm gonna ask the people who've actually used this device at this point
<mcc111[m]>
as i'm about to hit a weird bespoke packaging system
<cr1901>
it's a bit of a hack, because I use a single entry point for all fusesoc generation (due to limitations in fusesoc). But... I've split it so it's possible to either use this repo as part of fusesoc or generate your own Verilog via CLI at-will
<whitequark[cis]1>
about halfway there with the template repo rework
<cr1901>
Ack. I am stopping for tonight (midnight here and have to be up tomorrow semi-early). Tyvm for your effort!
trabucay1e is now known as trabucayre
richlatticefae[m has joined #amaranth-lang
<richlatticefae[m>
Same
<whitequark[cis]1>
what is wrong with pytest
<whitequark[cis]1>
why does it do something really questionable with sys.path?
<whitequark[cis]1>
oh
<whitequark[cis]1>
oh it doesn't, that was a standard python behavior (wrong pytest binary being executed); pytest's path manipulation was a red herring
<_whitenotifier>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] c70e52a - Deploying to main from @ amaranth-lang/amaranth@525c7e2be03c5f8e2e4702e57f1b4bd54515cb85 🚀
<_whitenotifier>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 84fd6de - Deploying to main from @ amaranth-lang/amaranth@6683c3a916257d629ba91cd0b2568d829edb5cc6 🚀
<whitequark[cis]1>
I'm actually going to expand that PR a bit more with deprecation warnings
<whitequark[cis]1>
so I could add one on platform.request("x").eq(...) but not the other way around (it's mired in python metaclasses)
<_whitenotifier>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 979a2dd - Deploying to main from @ amaranth-lang/amaranth@a9d03805fff8c3d4f6769320323dbf44619fe422 🚀
<crzwdjk>
Calling .eq on a Pin was both a common pattern and led to some inscrutable bugs for me, happy that that trap has been removed
<cr1901>
whitequark[cis]1: Tyvm, will apply to my code immediately once I get back from errand
<cr1901>
Is src/pkgname/__init__.py the new way to do python packages now?
<whitequark[cis]1>
yeah
<whitequark[cis]1>
Amaranth doesn't do it itself and probably won't, but I'm happy to recommend whatever the community best practice is in the template repo
<cr1901>
Does python -m "module.submodule" still work if I do the src/ layout, or is "python -m" one of the things the community is moving away from?
* cr1901
will prob spend today learning PDM, now that he corrected most of yesterday's breakage
<whitequark[cis]1>
python -m loads modules from PYTHONPATH
<whitequark[cis]1>
by default PYTHONPATH includes .
<whitequark[cis]1>
this obviously does not work with an src/ layout
<whitequark[cis]1>
however, you would be using PDM anyway, since you want your dependencies on PYTHONPATH
<whitequark[cis]1>
in this case, you can run pdm run python -m ... which works fine, since the package itself is installed in executable mode
<cr1901>
Oh so it's like "cargo run"
<whitequark[cis]1>
sorta?
<whitequark[cis]1>
it runs any executable
<whitequark[cis]1>
doesn't have to be python
<cr1901>
Cool... the template "just works", even in my screwed-up Python setup (aside from a single minor bug which isn't relevant to anyone but me and I can work around)
<cr1901>
Is there a "user-supplied" version of .env.toolchain (so that I can use my already-install nextpnr, etc)?
<whitequark[cis]1>
yep that was the idea when shipping it ^^
<whitequark[cis]1>
cr1901: hm, no; the template offers you two options
<whitequark[cis]1>
the option that's in the template as it's shipped is to use yowasp binaries checked into your version control
<whitequark[cis]1>
the option you can exercise by removing .env.toolchain and yowasp-* from dependencies is to use system binaries
<whitequark[cis]1>
i see these two as completely separate
<whitequark[cis]1>
if you want to have your yowasp binaries be installed system-wide you do need to set the environment vars in your shell init file
<cr1901>
Indeed, I'll probably exercise that option to use my system binaries (the WASM binaries are very cool, just using the system binaries is what I'm used to :P)
<adamgreig[m]>
I don't love the extra src/ folder, feels a bit java-y :p
<adamgreig[m]>
I guess it makes some sense when you split your things between multiple packages and/or if you want . on the pythonpath without putting all the modules on it though, but still
<whitequark[cis]1>
adamgreig: I was following the pytest recommendation
<whitequark[cis]1>
I think it might be nice for newcomers since it tells you exactly where your stuff is
<cr1901>
Yea, that was the pytest recommendation I explicitly avoided, but my rationale might be off 1/2
<adamgreig[m]>
but I don't love that it's useful because I think it looks ugly
<cr1901>
I expect a user of efbutils to be able to run e.g. "python -m efbutils.gen.page_buffer" and have that spit out a Verilog core
<cr1901>
I could work around this by making a unified entry point, say, efbutils-gen.exe
<cr1901>
But I think running a module as a binary is neat (and amaranth-boards also does it)
<whitequark[cis]1>
cr1901: if you are using PDM it is not enough for them to do that no matter what
<whitequark[cis]1>
it has to be prefixed with pdm run
<whitequark[cis]1>
and once that's the case, you can continue using python -m efbutils.gen.page_buffer
<whitequark[cis]1>
this is assuming the end user does not install the package
<whitequark[cis]1>
if they do install the package, the two remaining options (not involving pip --break-system-packages) are install it in a venv manually (which is equivalent to using PDM here) and install it with pipx (which requires you to add an entry point)
<whitequark[cis]1>
bare python -m works like that in two cases (without --break-system-packages): where it is run in a venv, and where the module is in a system package
<whitequark[cis]1>
does that make sense?
<cr1901>
I've never used pipx, so I'll take your word for it. But I see what you mean now; once you opt into PDM, you need to use PDM as the entry point for any application code you write in Python.
<cr1901>
Unless you install the package, which will likely break shit w/o a venv
<whitequark[cis]1>
yes, exactly
<cr1901>
or the pipx thing you suggest that I've never tried
<whitequark[cis]1>
pipx is just another tool that makes a venv for you
<whitequark[cis]1>
the difference from pdm is that it installs the entry points system-wide and not only inside the venv
<adamgreig[m]>
you should be able to "pip install ." even if you're using pdm, right? at least you can with poetry
<adamgreig[m]>
and then you could "python -m bla" too
<adamgreig[m]>
or if you happen to have all the dependencies installed system-wide anyway, you can "python -m bla" from inside src/ too I suppose, but that's not really something to suggest
<adamgreig[m]>
doesn't pdm's pyproject.toml work with pip? surely you need that to be able to publish and install it from pypi?
<whitequark[cis]1>
this is what i get on latest debian
<adamgreig[m]>
is that debian's pip or upstream pip?
<whitequark[cis]1>
this is an upstream pip feature
<cr1901>
I'm targeting the hypothetical use case where "someone needs to interface to MachXO2 EFB, and they decided to use my Python package in a Verilog codebase" 1/2
<adamgreig[m]>
interesting, ok, hadn't seen that before from my pip
<whitequark[cis]1>
the message comes from debian, but it's just a text file somewhere in the site-packages
<whitequark[cis]1>
the change is fairly recent
<adamgreig[m]>
does it complain the same if you try and pip install an application or library from pypi?
<whitequark[cis]1>
yes
<whitequark[cis]1>
even with --user
<adamgreig[m]>
wow, that's gonna break a lot of things lol
<whitequark[cis]1>
and regretfully, the complaint is accurate
<whitequark[cis]1>
i have broken my system packages by doing pip --user installs before and it was a pain to debug
<whitequark[cis]1>
(because user installs supersede system installs in loading order)
<adamgreig[m]>
even so
<whitequark[cis]1>
adamgreig[m]: I think things were broken before, tbh
<whitequark[cis]1>
this is just making the breakage obvious
<cr1901>
They have two options: Integrate w/ Fusesoc using core files I provide, or generate an e.g. EFB instance on the command-line. How do I make this easy for the end user, preferably without them needing to "chdir efbutils" each time they need to regenerate Verilog IP?
<whitequark[cis]1>
cr1901: this use case is explicitly something I consider desirable to cover
<adamgreig[m]>
do you only see it on recent distributions then?
<cr1901>
I don't _think_ the core files will need to be rewritten, b/c the gen.py entry point to Fusesoc dynamically modifies sys.path; gen.py knows where the efbutils module lives relative to itself.
<whitequark[cis]1>
adamgreig: yes
<cr1901>
(And this fact remains true even if I swap to a src/-based tree)
<whitequark[cis]1>
cr1901: okay, this is something that I want to see in core Amaranth eventually (at least the Verilog part, not sure about FuseSoC)
<whitequark[cis]1>
it will need an RFC, I think we might as well brainstorm the approach now
* cr1901
nods
<whitequark[cis]1>
I think it would be nice to have a single unified runner that lets you take an Amaranth component, configure it, and get Verilog or RTLIL or what you have out of it, without writing a single line of Python
<whitequark[cis]1>
I'm not sure what a "core file" is exactly so I'll leave that for later
<whitequark[cis]1>
for Verilog, we currently have one half of the story
<whitequark[cis]1>
obviously it is ridiculous to ask the end user to provide the list of ports, but we solved this by making verilog.convert aware of component ports
<galibert[m]>
Yeah, signatures is a way better story there
<whitequark[cis]1>
however this does not cover constructor arguments, which are just as crucial
<cr1901>
How do you "name" the component that Amaranth should generate Verilog for? Using Python module syntax (and an importlib call inside digests it)?
<whitequark[cis]1>
there are two options
<whitequark[cis]1>
the first one is exactly what you said
<whitequark[cis]1>
the second one is making use of the "entry points" functionality to tell Amaranth that a Python class is available for generation under some other name
<whitequark[cis]1>
"entry points" are mostly useful because you can enumerate them (unlike stuff in random Python files, which you can't reasonably load due to side effects)
<whitequark[cis]1>
however in this case we're pretty sure already exactly what we want to load, meaning it's fine to just use that directly
<whitequark[cis]1>
so it would be something like amaranth generate verilog efbutils.page_buffer page_buffer.v
<cr1901>
What would an entry point invocation look like? Do you have to install your package (as a system dep) for that to work? Or would you still "somehow" feed that entry point to the unified Verilog generator?
<whitequark[cis]1>
you do have to install the package for entry points to work, as opposed to just having it importable
<whitequark[cis]1>
I think entry points are probably not the right choice here
<cr1901>
Agreed, especially considering that PDM applications (the best practice we want to encourage)... kinda discourage that
<whitequark[cis]1>
* so it would be something like amaranth generate verilog efbutils.page_buffer.PageBuffer page_buffer.v
<whitequark[cis]1>
with pdm it would be like pdm amaranth generate verilog efbutils.page_buffer.PageBuffer page_buffer.v
<cr1901>
Yes that's reasonable. I'm sure pdm and verilog trees (for a mixed project) can coexist just fine
<cr1901>
you'd put "pdm amaranth generate..." as a step in your top-level build script (or regen manually as needed without having to deal with pesky paths)
<whitequark[cis]1>
yeah
<whitequark[cis]1>
we can actually do something interesting here
<cr1901>
And so can cargo for that matter. It's a minimum common denominator
<whitequark[cis]1>
CMake can also do this via add_custom_command(DEPFILE)
<whitequark[cis]1>
cr1901: want me to prototype the `amaranth generate verilog` command?
<cr1901>
whitequark[cis]1: If it is not too much work, and you want to do it, yes. I haven't started the PDM port yet; improving gen is a better thing for me to work on rn.
<whitequark[cis]1>
yea sure i was curious how it'd use in practice for some time
<whitequark[cis]1>
btw, I think I can make --deps work even with completely unrelated files
<whitequark[cis]1>
like not just python modules, but any data files you open
<cr1901>
Huh ._.
<cr1901>
I can explain the fusesoc side of things as well if you want (it is, in fact a natural extension of "amaranth generate verilog", but you have to deal w/ a fusesoc quirk)
<whitequark[cis]1>
sure why not
<cr1901>
Okay the first thing about fusesoc is: it works, it's a package manager, it works fine IME. No need to reinvent the wheel there. It has a few rough edges, only one of them is relevant here. I think olofk has an unsaid feature freeze for fusesoc right now due to work/needing a break.
<cr1901>
Using the linked code as an example, a generator will be run like the following: "python3 gen.py autogenerated_yaml_file_baed_on_parameter_settings_and_other_stuff"
<cr1901>
This is unfortunately, hardcoded. You get a single interpreter argument, a single script argument, and a YAML file with everything else. I don't know how to work around that for "amaranth generate verilog"
<whitequark[cis]1>
cr1901: that (the overall file not just the lines) looks like a build system to me?
<galibert[m]>
it's more gentoo than arch I guess? :-)
<cr1901>
Well, yes, fusesoc is both a package manager and build system. I'm focusing on the package management part b/c that's the only part relevant to Amaranth
<galibert[m]>
more seriously, it's the side effect of lto-in-practice?
<whitequark[cis]1>
so much for not reinventing the wheel >_>
<cr1901>
I use it as a build system rn instead of Amaranth b/c of inertia :P
<whitequark[cis]1>
(not a complaint towards you)
<cr1901>
I understand. I can elaborate on the inertia part later
<whitequark[cis]1>
sure!
<cr1901>
>I don't know how to work around that for "amaranth generate verilog" <-- so I cheat a bit to make fusesoc gen work for my codebase right now, b/c of the input argument limitation.
<whitequark[cis]1>
work around what?
<whitequark[cis]1>
oh sorry I missed a message
<whitequark[cis]1>
I think this just needs to be fixed in fusesoc?
<cr1901>
Yea, I think so too. I just don't know if olofk has bandwidth for fixes. I can talk to him.
<cr1901>
I already know from nightmares about a certain snake package manager that NONE of use want to maintain one. I think reusing pip with PDM solves the amaranth-depends-on-amaranth side of things, "amaranth generate verilog" will solve the "verilog-depends-on-amaranth" side of things, and "fusesoc" can help solve the "amaranth-depends-on-verilog" and "verilog-depends-on-amaranth" cases as well
<cr1901>
Not _much_ extra work mind you, but enough for me to be like "okay I'll just put the I/O I need and call it a day" :P
<whitequark[cis]1>
oh haha, I wonder if we could make it easier to make board files
<whitequark[cis]1>
maybe a web UI or something
<cr1901>
Oh, and this probably doesn't matter in practice, but Amaranth will manually instantiate a GSR and create a global reset, whereas I don't in my code current, and can't tell offhand whether Diamond bothers (IIRC it actually does NOT infer a GSR for sync resets, but Amaranth adds logic to make a sync reset work w/ GSR)
<cr1901>
Web UI would be interesting/cool. I could also just not be lazy lmao
<whitequark[cis]1>
Diamond does not infer GSR
<cr1901>
One of their APNOTEs says it does. I'll see if I can find it (and if I misread well I'm wrong then :P)
<whitequark[cis]1>
huh, interesting
<whitequark[cis]1>
I might be wrong
<cr1901>
HowtouseGSRPURandTSALL.PDF <-- It was ISPLever, whoops
<cr1901>
Of course it was worth the RIIA, but honestly it was also worth doing the initial EFButils in Verilog. For better or worse, it took me a while to get a handle on how to interface with the EFB and how to consistently write to/read from it. I caved and used Lattice Reveal at least once :P.
* cr1901
started in Diamond, moved everything to fusesoc, and now it's a fusesoc/Amaranth hybrid
<whitequark[cis]1>
cr1901: done, testing with your code now
<cr1901>
Cool, on standby. Which branch? main or rearrange?
<cr1901>
See, the plan before today was "create some adhoc CLI to convert command line options to the dicts I actually use to populate the EFB Component's constructor
<whitequark[cis]1>
ah, hm
<cr1901>
Althought not represented in the code as-is, I would have a way to distinguish "I want to generate for fusesoc" from "I want to generate standalone verilog"
<whitequark[cis]1>
let me do something real quick
<cr1901>
(Emphasis on "not represented in the code as-is")
<whitequark[cis]1>
okay this now works: amaranth g amaranth.lib.fifo:SyncFIFO -p width 16 -p depth 128 verilog -v -
<whitequark[cis]1>
(in the branch)
<cr1901>
Very nice :D
<whitequark[cis]1>
it uses type annotations to convert from strings to whatever you accept
<cr1901>
Most excellent :D
* cr1901
is trying to fix a PDM bug, and then he'll try out the functionality
<whitequark[cis]1>
which bug
<cr1901>
Well, there's two and they're both msys2-related things (one about the git binary returning Unix-style paths, another one about virtualenv respecting the /bin /lib hierarchy on Windows sometimes)
<cr1901>
latter is a very easy two line patch (check for /bin /lib on Windows). The first... eeeeeehhh lmfao
FFY00 has quit [Remote host closed the connection]