<cr1901>
TL;DR msys2 git uses Unix style paths, basically any Windows tool that ingests "git rev-parse --show-toplevel" loses its mind over the lack of a drive letter
<cr1901>
Download Portablegit, put on your path, and use that git instead, since rev-parse "does the right thing". Your Amaranth install will succeed most likely. 1/2
<cr1901>
frostming is receptive to msys2 python patches, so I think a stopgap solution to 197 is to print a diagnostic for "wrong git binary"
<_whitenotifier-f>
[amaranth] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-896-470477a88f02dfc4af7452ad05c4c067f72cd0bd - https://github.com/amaranth-lang/amaranth
<gatin00b[m]>
@cr1901 thanks, I'll give it a go.
<gatin00b[m]>
Also, shouldn't the right thing be to just be fine with unix paths?
<_whitenotifier-f>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 0501acc - Deploying to main from @ amaranth-lang/amaranth@7582ec301c2ef8cb233f6c862b2aff600b4ba603 🚀
<gatin00b[m]>
right, what I meant was that most tools and libraries seem to deal just fine with the posix pathunder msys2/cygwin. So why does python packages have such a bad history dealing with it?
<gatin00b[m]>
And the question stems from my own very limited knowledge of python ecosystem.
<cr1901>
I don't know, I'm afraid :/.
<gatin00b[m]>
All fair, thanks a lot for the help
<gatin00b[m]>
Actually, I was able to "pdm install" amaranth, but whenever I import amaranth in a project, it's nowhere to be seen... what am I still doing wrong?
<whitequark[cis]>
<gatin00b[m]> "Actually, I was able to "pdm..." <- if you're using `pdm install` you should run the file with your toplevel with `pdm run`
<gatin00b[m]>
I just wanna get sweet sweet verilog and move on at this point.
<whitequark[cis]>
so one reason I like pdm is that porting is usually unnecessary as if the project is already using pyproject.toml then pdm consumes it fine
<whitequark[cis]>
but otherwise I think you'll find that most people are here because they don't find Verilog so sweet and prefer dealing with Python package management over that
<whitequark[cis]>
let's see...
<whitequark[cis]>
okay yeah that is really not using anything remotely up to date
<gatin00b[m]>
I tried importing the setup.py with the pdm setuptools gizmo, but still no amaranth available there.
<whitequark[cis]>
okay, so that README page instructs you to run python test_pcie_phy.py run; what happens when you pdm run python test_pcie_phy.py run ?
<gatin00b[m]>
But I can further modify the pytoml to use the git repo... that's easy
<cr1901>
Yea, "pdm use" might not be appropriate here. When you first init a pdm project, it gives you an option to choose a python version/interpreter.
<cr1901>
"pdm venv" may be the more appropriate command for "I need to create a new interpreter"
<cr1901>
My bad
<cr1901>
(pdm venv == maybe create a shiny new interpreter, pdm use == "look thru my system and find all the pythons"
<gatin00b[m]>
Using the amaranth git repo brings us back to the scm issue T_T
<cr1901>
"pdm run which git"
<gatin00b[m]>
Yeah, I haven't fixed that
<cr1901>
PDM_BUILD_SCM_VERSION=2.1.7 pdm install
<cr1901>
As a really horrible workaround you shouldn't be using, but I need to switch gears right now and work on something else
<cr1901>
Looks like 2.1.7 proper was released 13 hours ago, so try PDM_BUILD_SCM_VERSION=2.1.8.dev and see what happens. I do not promise this works
<gatin00b[m]>
Got it "working", still some more errors. At this point, I'm fairly sure it's better for everyone if I call quit and port this to verilog... though most of it is already ported to pdm so if anyone wants to take on this thing, they'll at least have that
<whitequark[cis]>
you could also talk to the person who wrote this originally?
<gatin00b[m]>
Nothing to lose I guess.
<cr1901>
I believe that is Degi, IIRC?
<gatin00b[m]>
No clue
<whitequark[cis]>
it is Degi_, yes (she is in this channel right now)
<gatin00b[m]>
Hi Degi_
Luke has quit [Quit: o/ 3w 6d 23h 59m 18s]
Degi_ has joined #amaranth-lang
Degi has quit [Ping timeout: 260 seconds]
Degi_ is now known as Degi
alinaqvi has joined #amaranth-lang
AmmarSaleem has joined #amaranth-lang
<AmmarSaleem>
I want to learn Amaranth HDL so kindly gave me link where i can learn it
<AmmarSaleem>
Also I want to work on soc so where can I learn kindly share some stuff about amaranth HDL
AmmarSaleem is now known as JohnnyFisher
<alinaqvi>
I also want to learn amaranth hdl
<whitequark[cis]>
that's a lot of new people
<whitequark[cis]>
where did you learn about Amaranth, if I may ask?
JohnnyFisher has quit [Quit: Client closed]
JohnnyFisher has joined #amaranth-lang
Muddassir_Ali has joined #amaranth-lang
<Muddassir_Ali>
whitequark[cis] these peoples are my group mates we have same project
<whitequark[cis]>
did someone assign you doing a project in Amaranth?
<Muddassir_Ali>
Yes this is our semester project
<whitequark[cis]>
may I ask which university it is? I'm very curious; I maintain Amaranth (with help from some others and the community), and this isn't the first time someone used it in an educational setting, but it's always odd to find out last about it
<Muddassir_Ali>
So we just want to learn amaranth language
<whitequark[cis]>
I don't think this meeting time is continuing to work for me to be honest
<whitequark[cis]>
I realize going the other way (early in the morning) is inconvenient for people in the US, but given how exhausted I am every time this meeting comes up these days, I might as well not conduct it at all
<mcc111[m]>
<whitequark[cis]> "FFSynchronizer is the Amaranth..." <- Thanks.
<mcc111[m]>
And I guess I just write some code to rotate a byte in myself?
<mcc111[m]>
Where is it on the line between painful and trivial to wire that FFSynchronizer up to, like, one of the amaranth.lib.fifo classes? (If the meeting is starting now this is not an urgent question.)
<nelgau_>
If the meeting continues, when ideally would you propose to move it to?
<whitequark[cis]>
early morning GMT
<whitequark[cis]>
think 0700-0800, maybe 0630 or something like that
<galibert[m]>
monday morning... I probably can manage it
nelgau_ has quit []
nelgau has joined #amaranth-lang
<galibert[m]>
Would be from work, but nobody will care
<nelgau>
At 0630 GMT, it's still plausible to attend from where I am on the west coast, but yes, much more inconvenient as you move further east
<nelgau>
It'd be a pity to lose these meetings. I learn so much from passively observing them. But I understand if it isn't a productive time for you
<whitequark[cis]>
right now it's unspecified exactly what the ShapeCastable.const() method returns, and this is making some of the downstream use cases annoying (namely, initializers for the fixnum work zyp's been doing)
<whitequark[cis]>
it seems like there is no downside to specifying that .const() can return a value-castable, but this is still an RFC change
<whitequark[cis]>
any comments?
<galibert[m]>
I see none either, it makes perfect sense in the extensibility story
<whitequark[cis]>
please respond with your comments or the disposition: merge or close
<galibert[m]>
merge
<whitequark[cis]>
jfng? agg?
<whitequark[cis]>
let me check who voted on #9
<whitequark[cis]>
also cr1901
<galibert[m]>
Not 100% sure on where the interaction is between ShapeCastable, ValueCastable, const and as_const though
<whitequark[cis]>
we have .as_const()?
<galibert[m]>
ok, remove that one, I got as_signed that messed with my brain
charlottia has joined #amaranth-lang
<charlottia>
there's also as_shape() in the mix
<whitequark[cis]>
ShapeCastable : as_shape :: ValueCastable : as_value; so these don't seem very confusing
<whitequark[cis]>
and ShapeCastable.const -> ValueCastable doesn't seem too bad either
<charlottia>
yepyep
<whitequark[cis]>
of course there is also ShapeCastable() -> ValueCastable for those shape-castables that implement the constructor syntax
<cr1901>
Merge
<charlottia>
whitequark[cis]: given it's python constructor syntax after all, that seems very natural/OK too.
<whitequark[cis]>
not sure if @agg is attending, let's wait for a bit
<whitequark[cis]>
Charlotte: yep! that was the design intent behind all these functions
<whitequark[cis]>
I spent quite a while looking into the best way to organize them
<cr1901>
Btw, having meetings early in the morning your time means meetings would be 1-2 in the morning for me
<charlottia>
4:10am local here, it's a mood for sure
<whitequark[cis]>
guess agg is not around
<cr1901>
I'm sorry 1:30-3:00 in the morning, depending on DST and the new time chosen
<_whitenotifier-f>
[amaranth-lang/amaranth-lang.github.io] whitequark 6794cb8 - Deploying to main from @ amaranth-lang/rfcs@4fbed5faf4168b2ce64c41267f973ad18f12bedd 🚀
<whitequark[cis]>
past week, some people (notably Chips4Makers (aka Staf Verhaegen)) have asked about a case where add_sync_process replaced with add_testbench would introduce a race condition
<Chips4MakersakaS>
In general where auto settle could cause a race.
<whitequark[cis]>
if bench1 and bench2 are added as add_sync_process, the result is defined (it always swaps the values of the signals)
<whitequark[cis]>
this happens because in a normal (non-bench) process, (starting with x=0) yield x.eq(1); print((yield x)) returns 0
<whitequark[cis]>
so until timeline is advanced (either for non-zero real time, or within zero real time by calling yield Settle()) it is quite literally impossible to introduce a race
<galibert[m]>
Dont Do That Then[tm]
<whitequark[cis]>
galibert: you might find this attitude to be more appreciated in languages such as Verilog
<galibert[m]>
It's not in Amaranth there, it's what you're allowed to do in simulation implementations
<whitequark[cis]>
please imagine them reset to 1 and 0 respectively
<cr1901>
okay
<whitequark[cis]>
galibert[m]: simulations are part of Amaranth, since Amaranth is what defines simulation semantics
<galibert[m]>
if you break the fundamental structure of sync processes in your sim code... well...
<charlottia>
whitequark[cis]: so `yield Settle()` at the top of both benches here makes it racey?
<Chips4MakersakaS>
Isn't that actuallly a combinatorial loop that should be disallowed ?
<whitequark[cis]>
whitequark[cis]: however once you introduce (implicit) `yield Settle()` between calls to `yield` that do not otherwise advance the timeline (e.g. between `yield x` and `yield x.eq(y)`), you also introduce races
<whitequark[cis]>
Chips4MakersakaS: no; when added with `add_sync_process` this is exactly equivalent to a pair of flops whose D and Q signals are cross-wired
<whitequark[cis]>
galibert[m]: on the past meeting a question was raised by Chips4Makers (aka Staf Verhaegen) as to why adding implicit `yield Settle()` everywhere would be problematic
<whitequark[cis]>
I was answering that question
<whitequark[cis]>
if we went with adding that implicit yield Settle(), it would be quite literally impossible to "Not Do That Then"
<whitequark[cis]>
that said, I see that you got upset, so discussing that today will probably not be productive.
<galibert[m]>
I'm not upset about this discussion
<galibert[m]>
At all
<whitequark[cis]>
<charlottia> "so `yield Settle()` at the top..." <- specifically what makes testbenches racey is adding settling (~advancing timeline within zero time) in between calls to `yield` that modify state
<charlottia>
yepyep ty, i read more carefully.
<galibert[m]>
I'm with Staf on that one though, for me it's semantically equivalent to a comb-loop, a pair of flops would need crossing a clock signal to change
<whitequark[cis]>
there's a yield at the top that waits for the sync clock to tick
<whitequark[cis]>
(in an add_sync_process or an add_testbench(domain="sync")
<zyp[m]>
I have a question to the deprecation of Settle: can you do a testbench for a fully combinatorial module without Settle?
<whitequark[cis]>
zyp: with `add_testbench`, yes, trivially, without needing any additional work
<cr1901>
The race specifically is `yield x`, `yield x.eq(y)`, `yield y`, and `yield y.eq(x)`, can run in any order if implict Settle() is between the two yield calls in each bench?
<whitequark[cis]>
I am really confused as to why this meeting is going the way it does... am I the only one here with a complete understanding of the simulation interface?
<whitequark[cis]>
cr1901: yep, `yield Settle()` is equivalent to any other advancement of time in that it causes another delta cycle
<cr1901>
Possibly, I still don't understand Settle(), at least can't map it to iverilog equivalent. And I tried understanding that blog post about delta cycles but couldn't really
<whitequark[cis]>
er, sorry, another sequence of delta cycles (but that includes delta cycles)
<cr1901>
need to try again
<whitequark[cis]>
* er, sorry, another sequence of delta cycles (but that includes a delta cycle)
<galibert[m]>
The problem I think is that it's impossible to correctly implement a ff in the sim interface in the presence of other sim processes. Because the semantics would have to be "on the next tick of that domain, set that signal to this value", not "wait for a tick, then set the signal to a value I compute afterwards"
<whitequark[cis]>
the flops in Amaranth Python simulator are implemented as a sim process
<whitequark[cis]>
so it is possible as evidenced by the fact that you can, well, simulate flops
<whitequark[cis]>
add_sync_process exposes this functionality, in a rather raw and confusing way, to designers
<Chips4MakersakaS>
In your example I think different processes waiting on the same Tick should all advance at the same time to avoid race.
<galibert[m]>
Catherine: but you do that in a single cothread, don't you?
<whitequark[cis]>
galibert: nope
<galibert[m]>
so you can compute all future values and commit them as a single transaction?
<cr1901>
whitequark[cis]: I'm going to be perfectly honest. No, I don't fully understand the simulation interface. Not understanding it fully has not stopped me from utilizing it effectively. I have some vague idea of what Settle() does, as you can gleam from my question you confirmed. But I'm not 100% on it.
<whitequark[cis]>
the whole point of having an eval/commit distinction is that it doesn't matter how many distinct processes you have running on the same clock cycle, or in what order
<galibert[m]>
As, Settle is a tick-without-a-tick?
<whitequark[cis]>
Chips4Makers (aka Staf Verhaegen): that's not really possible if you add `yield Settle()` in between non-advancing `yield` calls as you propose
<whitequark[cis]>
so yes, I agree, but your proposal makes that impossible
<nelgau>
I see. It's necessary to be able to freely sample signals and schedule updates to them without worrying that time is advancing beneath us
<Chips4MakersakaS>
You lost me...
<whitequark[cis]>
galibert: `Settle` advances "time within zero time"
<whitequark[cis]>
it doesn't matter that it doesn't advance the simulation by a nanosecond because the simulation is non-physical
<galibert[m]>
So eq queues a write, Settle commits them all, yield on a domain commits them all and advances the time
<gatin00b[m]>
So like #0 in verilog?
<whitequark[cis]>
you could imagine every call to yield Settle() be replaced by yield Sleep(1 femtosecond)
<whitequark[cis]>
gatin00b: more or less yes
<whitequark[cis]>
Chips4Makers (aka Staf Verhaegen): to recap: `add_sync_process` does not advance time when you do `yield v` or `yield v.eq()`. `add_testbench` does advance time by zero seconds and one simulation tick
<whitequark[cis]>
you were proposing replacing add_sync_process with add_testbench entirely and I am now showing you an example where this would introduce a race
<whitequark[cis]>
if you are manipulating design state in a Python process that is implementing a flop behaviorally, you need to be able to not advance time at all (including by zero seconds), i.e. stay within the same simulation tick for each of these processes in the same domain; implicit yield Settle() would break that
<galibert[m]>
I must admin I didn't entirely understood the sim interface. Interesting design
<galibert[m]>
s/admin/admit/
<whitequark[cis]>
most simulator processes do not, in fact, implement flops behaviorally; they implement testbenches where this behavior is explicitly undesirable
<whitequark[cis]>
but it is important to retain this ability to be able to implement blackboxes in Python (CXXRTL blackboxes naturally have this ability as an outcome of CXXRTL's design)
<cr1901>
"does not advance time" == "add this yield or yield foo.eq(bar) to a queue". So without advancing time due to implicit Settle, all 4 yields in bench1 and bench2 are evaluated at the same (zero time elapsed) tick?
<adamgreig[m]>
the simulator doesn't advance its state at all without a yield or yield Tick or yield Settle, right? you can just change input conditions or read current values with yield x or yield x.eq
<whitequark[cis]>
cr1901: I'm not sure what you mean by "add to queue"
<whitequark[cis]>
adamgreig: yes, correct!
<Chips4MakersakaS>
Need some more time to think about this.
<charlottia>
cr1901: the reads read from "now", the writes queue to "next"
<whitequark[cis]>
Chips4Makers (aka Staf Verhaegen): sounds good; we're running out of time anyway
<adamgreig[m]>
fwiw I'm happy with "keep add_sync_process but add new add_testbench that auto-settles since it's probably what many test benches expect"
<adamgreig[m]>
I also worry some of my existing test benches would immediately break if turned into add_testbench 😅
<whitequark[cis]>
I think most of them probably would
<whitequark[cis]>
which is why we keep add_sync_process for compatibility pretty much indefinitely even though the interface is kind of weird
<cr1901>
whitequark[cis]: By queue I mean "add to 'things to do when the next tick actually happens'"
<cr1901>
charlottia: Ack, that makes sense
<whitequark[cis]>
(for replacing flops and gates with a behavioral implementation, it would make more sense to have a function that gets called + a sensitivity list rather than a weird imperative interface; especially for comb this is important to detect and reject loops)
<cr1901>
if you do Settle(), that forces a tick, so "do your todo list that was created from writes/yield foo.eq(bar)"
<whitequark[cis]>
yes!
<galibert[m]>
It's more like a commit than a tick
<whitequark[cis]>
the function is literally called commit, yes
<galibert[m]>
Tick tends to have an implicit time meaning that can send people along the wrong path
<whitequark[cis]>
and the eval/commit pair is called a step
<whitequark[cis]>
(eval sets the .next, commit sets .curr to .next)
<charlottia>
s//`/, s//` on the signal state/
<cr1901>
And then Tick() is "Settle(), but advance time"?
<whitequark[cis]>
CXXRTL works ~the exact same way
<whitequark[cis]>
cr1901: yes
<cr1901>
Okay, I think it makes sense now coupled w/ the todo list analogy
<whitequark[cis]>
in principle, yes. in practice it also takes care of waking up sleeping processes
<whitequark[cis]>
(but that's just what "advancing time" could mean, I guess. it's not an important detail)
<galibert[m]>
cr1901: Settle then advance time, knowing that advnacing time can trigger another series of commits, this time from what you're testing
<galibert[m]>
if you consider that amaranth designs vs. testbench processes are assymetric
<galibert[m]>
You can abstract all that and try to make them identical, but that makes for more complex understanding :-)
<whitequark[cis]>
and unfortunately when I first introduced the Amaranth simulator I did not have this degree of understanding, and blindly copied some things from Migen just so that they'd pass tests
<whitequark[cis]>
it took like a year to realize that something is wrong with the simulator interface, and some more (including a lot of work on CXXRTL) to understand the eval/commit based simulator design in enough depth
<whitequark[cis]>
(as far as I remember anyway; I only have a hazy recollection of those years)
<cr1901>
>but that's just what "advancing time" could mean, I guess Yes, I've been handwaving "advance time". By advance time, I mean"processes have permission to continue past a 'bare yield' or 'yield Tick()' statement". Which would include sleeping processes.
<whitequark[cis]>
okay, we're out of time, still without a resolution
<whitequark[cis]>
see you next week
nyanotech has quit [Quit: No Ping reply in 180 seconds.]
nyanotech has joined #amaranth-lang
sporniket has joined #amaranth-lang
<sporniket>
Hello. So these days I had worked on using pdm and yowasp to make my project easier to work with (no need to compile yosys and friends with yowasp, thanks whitequark[cis])
<sporniket>
and more os independant with pdm scripts and using python scripts instead of bash scripts (thanks mcc111[m])
<sporniket>
And indeed, I could test on Windows and Mac that I only needed to install python.
<sporniket>
(to go until the generation of the bitstream)
<sporniket>
On windows, it worked flawlessly as soon as I did not use MSYS2