<whitequark[cis]>
and which is frankly a much less painful approach than what you're currently doing (which will eventually result in you being in Python packaging hell)
<mcc111[m]>
I'm using pip
<whitequark[cis]>
mcc111[m]: it does, `pip install package==version.number`
<whitequark[cis]>
mcc111[m]: yes. I am suggesting you stop using pip.
<mcc111[m]>
Sorry, I mean for your dependencies
<mcc111[m]>
hm ok
<mcc111[m]>
well i'll look at that then
<whitequark[cis]>
you can use pip and venvs to achieve the exact same result as what's in that template repo
<whitequark[cis]>
but that requires you to be very experienced with Python packaging, and you wouldn't be asking this question if you were
<whitequark[cis]>
I'm going to heavily encourage using PDM in the upcoming tutorial because of ... this
<whitequark[cis]>
the situation you're currently in
<mcc111[m]>
i installed pypy exclusively to run this app
<mcc111[m]>
so i was expecting to just get whatever versions are most appropriate
<mcc111[m]>
like it can just scribble all over my package hierarchy
<whitequark[cis]>
yes, but wouldn't it save us both a lot of time if I could have you run one command and result in it running versions that I know will work, rather than this iterative back-and-forth where you study failure modes of Python package management?
<mcc111[m]>
ok
<whitequark[cis]>
e.g. putting amaranth-boards on PYTHONPATH isn't really supported
<whitequark[cis]>
people keep doing that so I have a workaround to have it not break horribly right away, but I really wish I didn't have to
<mcc111[m]>
How does the "template" repo get amaranth-boards?
<mcc111[m]>
Oh, okay, I see what I was doing wrong now
<whitequark[cis]>
but it installs it as a package into the virtual environment
<whitequark[cis]>
rather than just putting it on PYTHONPATH
<mcc111[m]>
okay. so the reason i was checking out a local -boards instead of attempting to "install" it
<mcc111[m]>
is that i need to add a board
<whitequark[cis]>
to do that, you can have an "editable install"
<mcc111[m]>
okay. is this similar to an npm pin or something
<whitequark[cis]>
if you pip install -e ..., it will make a symlink to the package root instead of copying it
<whitequark[cis]>
more or less
<mcc111[m]>
okay
<mcc111[m]>
that works then
<whitequark[cis]>
the other thing the template repo handles for you is setting the right environment variables to use YoWASP as your synthesis toolchain
<whitequark[cis]>
if you run build(do_build=False), Amaranth gives you a "build plan", which is basically an archive of all the files a build needs
<whitequark[cis]>
it does this in case you want to put your stuff into an archive and send them for a bug report, or maybe build on your desktop instead of your underpowered laptop
<whitequark[cis]>
but you can also just grab the debug verilog from it
<whitequark[cis]>
it's called "debug verilog" because with ice40, Amaranth doesn't need or use Verilog as an intermediate step in synthesis; it emits directly the Yosys intermediate representation
<mcc111[m]>
can i just pypy3.10 -m pdm and that will do what i want?
<whitequark[cis]>
for pdm: pdm venv create pypy3.10
<whitequark[cis]>
this creates a virtualenv in the $PWD/.venv/ directory
<whitequark[cis]>
and yes, once you're using pdm, you can remove anything amaranth-related from your global pip package directory
<whitequark[cis]>
the advantages of this are that even if you e.g. remove the venv and kill your pypy install, or switch to another interpreter, it would be easy to get the exact same package versions that worked for you before
<whitequark[cis]>
and if you are using yowasp, you get fully reproducible builds as well (I think you might have to fix the random seed for nextpnr?)
<whitequark[cis]>
I cannot overstate how important it is for you to be able to get to a 2-year-old project and have it build afresh the way it built before, including the FPGA toolchain
<tpw_rules>
^
<mcc111[m]>
I have been warned against pyenv on current homebrew because homebrew will routinely break interpreter paths
<mcc111[m]>
However, I would very much like npm/cargo style reproducibility on python, yes
<whitequark[cis]>
pdm gives you something closely resembling cargo reproducibility
<whitequark[cis]>
and unlike several other solutions, it actually works reliably and in a way that doesn't cause constant frustraion
<whitequark[cis]>
(evaluating these things is literally a part of my job)
<mcc111[m]>
wait
<mcc111[m]>
venv and pyenv are different programs head in hands
<whitequark[cis]>
yes
<mcc111[m]>
sorry i literally haven't written python in like 4 years
<whitequark[cis]>
I mean, it is reasonable to also want pyenv
<mcc111[m]>
i used to use venv a lot and when i mentioned i was writing some python people were like "oh, use pyenv" and was like is that the thing i used to use or something else hm
<mcc111[m]>
Now realizing the thing I used was virtualenv not venv and I'm experiencing distress
<whitequark[cis]>
virtualenv and venv are almost but not quite the same thing
<whitequark[cis]>
"venv" is built into Python
<whitequark[cis]>
"virtualenv" is a package that's not built into Python, is compatible with "venv" but provides more... stuff
<whitequark[cis]>
both of them create something called "a virtualenv"
<whitequark[cis]>
the naming is horrible
<whitequark[cis]>
pdm is creating "a virtualenv" using "virtualenv", internally, I think
<whitequark[cis]>
I don't actually know why "virtualenv" exists
<whitequark[cis]>
"virtualenv" is made by the same people who make Python
<whitequark[cis]>
because for libraries, [project.dependencies] specifies the ones that would be a part of e.g. the package you upload on PyPI
Degi has quit [Ping timeout: 246 seconds]
Degi has joined #amaranth-lang
<whitequark[cis]>
and there's no way to express "editable dependency" in that case
<whitequark[cis]>
I think it's kind of a weird thing to mandate
<whitequark[cis]>
in your particular case, I think you can just move it to dev-dependencies
<mcc111[m]>
so what i'm used to with this sort of app is a "temporary" change that doesn't change the local repo but allows me to edit out of a on-disk directory
<mcc111[m]>
for example, because the change is not checked in yet, much less pubished to a website or something
<whitequark[cis]>
yeah
<mcc111[m]>
so the advice is to just switch it to being a devdependency then make sure not to check that in. … ok
<whitequark[cis]>
there's a better way
<whitequark[cis]>
so remember you ran pdm venv create?
<whitequark[cis]>
run pdm venv create --with-pip pypy3.10
<whitequark[cis]>
now, you can do $(pdm venv activate) and then, once the venv is active, pip install -e ../path/to/amaranth-boards
<mcc111[m]>
okay, and I assume a pdm install will override that but NOT a pdm run ?
<whitequark[cis]>
pdm run doesn't even check that your lockfile matches what you have installed
<whitequark[cis]>
it just... well, runs
<mcc111[m]>
ok
<mcc111[m]>
that much is good to know
<mcc111[m]>
When I used to use virtualenv it would modify the PS1. Would you expect pdm venv activate to do this? Or is that something I need to configure to make it do that
<mcc111[m]>
no, wait, i was just doing it wrong. now i see it
<mcc111[m]>
<adamgreig[m]> "you basically just need https..." <- hey, you offered to type up a Doppler board py earlier, I was like well I'll give it a shot first… I, uh… I thought I'd be able to do this but I could not.
<mcc111[m]>
I got as far as `device = "iCE40UP5K"` and then realized I had no idea what to put for package and didn't know how to read the pin numbers off the schematic * _ *
<mcc111[m]>
Anyway any help much appreciated. I could also be talked into buying a different FPGA dev board— I'm mainly interested in this one because it's what I have and it lets me start doing stuff, like, now today. (Also it is pretty convenient this one has a conventional CPU as helper.)
<adamgreig[m]>
Not at a computer right now, but you want to use the schematic pdf I linked to, it has a page with the FPGA where you can see what's connected to every pin, as well as the fpga part number conveniently
<adamgreig[m]>
That pinout table tells you about the whole board, but not so much about every pin of the fpga
<adamgreig[m]>
Huh, I have to say it's not actually the most useful schematic though... For some reason they have decided to not show pin numbers and basically none of the net names are very meaningful, how unhelpful
<adamgreig[m]>
Still, all the information needed is there, just a bit annoying. I'll have a go in a few hours.
peepsalot has quit [Ping timeout: 250 seconds]
GenTooMan has quit [Ping timeout: 240 seconds]
indy_ is now known as indy
GenTooMan has joined #amaranth-lang
peepsalot has joined #amaranth-lang
<whitequark[cis]>
mcc111: the UP5K has only one non-CSP package... I think that one is SG44?
<adamgreig[m]>
this doesn't need to go in amaranth_boards or anything, that's just a convenient repo for popular dev boards, you can just stick doppler.py (or the class itself) in your project and use it as usual
<adamgreig[m]>
it looks like they expect to use the fpga's built in clock, so that's what this one does too, and I left the mcu sercom connection bidirectional as you might want the fpga or the mcu to master it
<adamgreig[m]>
I've just added an example module that should flash an led when the button is held down as a little example of using it (untested of course), if you put it in the same directory as doppler.py and run counter.py it should generate build/top.bin which is what you need to program to the fpga (via having a firmware on the mcu, which seems kind of annoying but there you go)
<_whitenotifier-8>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] bb72610 - Deploying to main from @ amaranth-lang/amaranth@9dfaa931a3d6f8d60dfccf34a661731b6dbd273c 🚀
<whitequark[cis]>
you might want to use lib.data instead, or the upcoming RFC #2
<wehnelt[m]>
thankie!
<wehnelt[m]>
thanks for the cool project btw
<whitequark[cis]>
you're welcome
<wehnelt[m]>
oh yeah -- is there a sort of simple example you might suggest for how to structure an amaranth project?
<wehnelt[m]>
I'm not sure where's a good place to put my tests. At the bottom of a module inside a ``if __name__ == '__main__':`` seems convenient
<wehnelt[m]>
but it doesn't seem to be the way most projects I come across do it
<whitequark[cis]>
take a look at the standard library unittest, or you could also use a third party module like pytest
<Wanda[cis]>
<whitequark[cis]> "it's going to be removed soon" <- ... so do we need a "migrate glasgow off `Record`" campaign now?
<whitequark[cis]>
though even doing the __main__ thing is fine
<whitequark[cis]>
Wanda[cis]: there's no time pressure on that since the worst case is just copying `Record` into the Glasgow source tree
<whitequark[cis]>
which is also the recommended migration path for anyone impacted by removal who can't migrate to lib.data or RFC #2 for some reason
<whitequark[cis]>
that said, I think in Glasgow, we'll end up having our own data model classes, for transparent serialization/deserialization
<whitequark[cis]>
and we can have one of those generate data.StructLayout or whatever
<whitequark[cis]>
so there's no particular rush
<Wanda[cis]>
... oh, there's a grand total of 2 uses left, in applets
<whitequark[cis]>
yes
<whitequark[cis]>
we can just migrate that to data.StructLayout already or something
<Wanda[cis]>
yeah
<whitequark[cis]>
lol ps2_host
<Wanda[cis]>
added to our todolist to the "when sufficiently bored" section
<whitequark[cis]>
tbh the ps2_host applet would be a good thing to trial the new glasgow communication system on
<whitequark[cis]>
since it has variable length packets that can be sent unsolicited
<Wanda[cis]>
oh!
<Wanda[cis]>
we actually looked at this already
<Wanda[cis]>
and came to the conclusion that the ps2_host use is insane
<Wanda[cis]>
because it creates a record and then uses the record as a shift register
<Wanda[cis]>
so... it's not actually in the supposed data format at all, except for the initial cycle
<whitequark[cis]>
yeah I think it's very clever o:3
<Wanda[cis]>
but also
<Wanda[cis]>
now that we actually remember this
<Wanda[cis]>
we had a question
<whitequark[cis]>
yeah?
<Wanda[cis]>
is there a good way to create a struct-typed value out of a bunch of signals without going through m.d.comb and an intermediate struct-typed signal?
<whitequark[cis]>
no, because a struct is one signal
<whitequark[cis]>
the entire lib.data is built around giving you views into a single bit container
<whitequark[cis]>
however, now that I said it, I realize I'm actually wrong
<whitequark[cis]>
it's one value
<whitequark[cis]>
and you could make it a Cat
<Wanda[cis]>
basically I want something like StructLayout.const constructor, except one that works on arbitrary values on input, and gives you a view
<whitequark[cis]>
yeah
<whitequark[cis]>
we... could have this
<whitequark[cis]>
but this would only work for structs, not for unions
<Wanda[cis]>
hmmm
<Wanda[cis]>
why?
<whitequark[cis]>
I suppose for arrays too
<whitequark[cis]>
well how would it deal with overlaps?
<Wanda[cis]>
a union can just cat with padding?
<Wanda[cis]>
and restrict to single field on input
<whitequark[cis]>
alright yea we can define it on Layout
<whitequark[cis]>
want to write your first RFC?
<Wanda[cis]>
... we walked right into it, haven't we
<whitequark[cis]>
yes
<Wanda[cis]>
yeah
<Wanda[cis]>
can't give you an ETA, but
<Wanda[cis]>
sure
<Wanda[cis]>
there's a bunch of interesting questions in the details, heh
<whitequark[cis]>
there usually is, yes
<Wanda[cis]>
(consider: should the result support being assigned to)
<whitequark[cis]>
oh, that's easy
<wehnelt[m]>
super basic question -- what's the right way to generate a lookup table? Like say for an NCO theta to sine table.
<whitequark[cis]>
Wanda[cis]: Views are assignable if the underlying container is assignable
<whitequark[cis]>
and you are creating a normal View
<whitequark[cis]>
really, all that you would be doing is turning a bunch of fields into a Ca
<whitequark[cis]>
s/Ca/Cat/
<Wanda[cis]>
it also involves fixing up their sizes
<whitequark[cis]>
yes
<whitequark[cis]>
I think you can skip that whole part
<whitequark[cis]>
by requiring their size matches the size of the field
<Wanda[cis]>
and that's another one for the "alternatives" section, yes
<Wanda[cis]>
but I don't think we should
<Wanda[cis]>
for one, it'd be sad if this function didn't support just passing a plain integer as a value of some field
<whitequark[cis]>
right
nak has quit [Ping timeout: 240 seconds]
<Wanda[cis]>
consistency dictates it should look like Layout.const, but we can't think of a good name for it; Layout.construct? sounds a little too heavyweight for what's a simple operation
<wehnelt[m]>
actually do I want a like... const array?
<wehnelt[m]>
is that a thing?
<Wanda[cis]>
wehnelt[m]: depends on how large of a LUT we're talking here
<wehnelt[m]>
256 elements maybe?
<Wanda[cis]>
if it's large enough that you'd want it lowered to dedicated ROM cells, you'd need to deal with Memory; otherwise, what you need is Array
<Wanda[cis]>
for the second case, just build the LUT as a normal list, wrap it in Array, and bam you can index it with a signal
<wehnelt[m]>
should one be faster than the other?
<Wanda[cis]>
LUT = Array([2, 1, 3, 7])
<Wanda[cis]>
idx = Signal(2)
<Wanda[cis]>
m.d.sync += abc.eq(LUT[idx])
<Wanda[cis]>
something like that should work
<wehnelt[m]>
for a ``Memory``, is there anything to specify it's read-only?
<Wanda[cis]>
nothing in particular
<wehnelt[m]>
or do you just give it an init= it and roll
<Wanda[cis]>
a Memory is a ROM iff it doesn't have a write port, and that's it
<wehnelt[m]>
s//``/, s/=/=``/, s/it//
<wehnelt[m]>
love that!
<whitequark[cis]>
Wanda: `Layout.make`?
<whitequark[cis]>
Layout.compose?
<Wanda[cis]>
btw the Array thing also works with non-const signal elements, if you ever end up needing that
<Wanda[cis]>
mmm, make sounds nice
<whitequark[cis]>
the thing is
<Wanda[cis]>
though not quite there
<whitequark[cis]>
this sort of obsoletes Layout.const?
<Wanda[cis]>
not really
<Wanda[cis]>
hm
<Wanda[cis]>
I think there's value in distinguishing a function that deals specifically with const
<whitequark[cis]>
yes, but it still feels odd
<Wanda[cis]>
also, const belongs to ShapeCastable, right?
<whitequark[cis]>
I guess .const is defined by its own RFC and ... yeah
<whitequark[cis]>
whereas this thing is exclusive to Layout
<whitequark[cis]>
I like compose by the way
<Wanda[cis]>
it has uses even if we could roll back time on that RFC
<galibert[m]>
Being on a bike leaves me (too much) time to think. Is there a way to do something to all the storage of a module and it’s descendants? Use case: transparent state saving and reloading
<whitequark[cis]>
not really, no
<whitequark[cis]>
not at the time anyway
<whitequark[cis]>
with the new middle end there could be
<wehnelt[m]>
is minerva the "I need a simple risc-v cpu to control this design" cpu?
<wehnelt[m]>
it features an icache and dcache and branch predictor so it seems maybe a little more complex than I'd like, but it looks like the icache and dcache can be disabled, so maybe it's quite flexible?
<whitequark[cis]>
you could use it, though the author of minerva (@jfng) has some regrets about its design
<wehnelt[m]>
I guess there's also misato? Admittedly I'm not looking for perfection. Just something I can compile rust to and provide a vaguely GPIB-like interpreter
<whitequark[cis]>
I don't know anything about misato
<whitequark[cis]>
it seems it hasn't been updated in years?
<wehnelt[m]>
maybe it's just "done"? Idk. I'll probably just use minerva. Does amaranth-soc prefer a particular soc?
<wehnelt[m]>
s/soc/cpu/
<whitequark[cis]>
no, amaranth-soc is made to be CPU-agnostic
<whitequark[cis]>
and things are rarely "done", Amaranth keeps evolving
<galibert[m]>
Minerva is definitely easy to use. It’s not yet using -soc’s wishbone support which is a problem, but not fixable yet because rfc #2.
<wehnelt[m]>
nice! Yeah I'm just looking for really simple. I'd likely be happy with some minimal forth thingy
<galibert[m]>
Beware that Minerva does not handle compressed instructions and the compilers love to generate them if you’re not forceful
jfng[m] has joined #amaranth-lang
<jfng[m]>
it is compliant with RV32I (and passes riscv-formal), except for its interrupt handling, which is non-standard (inspired by LM32)
<jfng[m]>
<wehnelt[m]> "is minerva the "I need a..." <- it has the benefit of being somewhat simple to understand, and can be used with amaranth's simulator
<jfng[m]>
my main issue with it is that compared to other "microcontroller" risc-v cores, it is neither performant nor small
<wehnelt[m]>
if you were going to start a new design and just needed the smallest functional cpu that rust will target, what would you reach for, assuming you're doing a design in amaranth? Would you use a CPU also written in amaranth or would you reach outside the ecosystem?
<jfng[m]>
minerva is also overdue for a refactoring, as the amaranth language as significantly improved since
<galibert[m]>
Personally I’d go for Minerva and change whatever I don’t like
<jfng[m]>
wehnelt[m]: the amaranth simulator is so good that i wouldn't want to reach outside its ecosystem
<jfng[m]>
i'd either rewrite minerva or use another amaranth core
<galibert[m]>
jfng: what would you charge at this point (assuming interfaces are in) ?
<jfng[m]>
i actually went pretty far into a v2 two years ago, but paused it before completion for personal reasons
<jfng[m]>
i'd need to revisit it anyway, due to new amaranth features (structs, interfaces, CSRs)
<Wanda[cis]>
Catherine: another interesting question is what kind of values should be accepted for fields in `compose` — do we require nested structs to go through another `compose` call, for one
<Wanda[cis]>
.const calls .const recursively, but it's a little messier with .compose being Layout-specific I guess
<Wanda[cis]>
unless
<Wanda[cis]>
we solve both problems by overloading __call__
<Wanda[cis]>
but that has another problem: ValueCastable and Sequence/Mapping aren't necessarily exclusive
<whitequark[cis]>
.compose would use Value.cast, no?
<Wanda[cis]>
mhm
<Wanda[cis]>
I mean, it could
<Wanda[cis]>
but that's a downgrade from .const
<Wanda[cis]>
which calls `<shape>.const`, not `Const.cast`, and thus allows nested structures without additional `StructWhatever.const()` wrapping
<whitequark[cis]>
<_<
<Wanda[cis]>
oh, by the way
<Wanda[cis]>
the analogy to .const breaks down for another reason
<Wanda[cis]>
.const does not actually produce a view
<Wanda[cis]>
it just produces a plain Const
<whitequark[cis]>
oh, yeah
<whitequark[cis]>
it would produce a number if not for width/signedness
<whitequark[cis]>
(which I've done to avoid unintended clipping)
<galibert[m]>
jfng: are those csrs memory-mapped or special instructions?
<Wanda[cis]>
galibert: CSRs in RISC-V are accessed via special instructions
<Wanda[cis]>
Catherine: how do you feel about just overloading `__call__`, actually
<galibert[m]>
Ok, so the current csr rfc is not relevant
<whitequark[cis]>
we overload that in a lot of places already
<Wanda[cis]>
oh?
<Wanda[cis]>
no, I mean specifically ShapeCastable.__call__
<whitequark[cis]>
there is already Layout.__call__
<Wanda[cis]>
to take things other than ValueCastable
<whitequark[cis]>
hm
<jfng[m]>
galibert[m]: it depends, currently they are all accessed by instructions, but a better design would move many of them to memory-mapped peripherals
<whitequark[cis]>
what would it take?
<Wanda[cis]>
depends on ShapeCastable, in this particular case a Sequence or Mapping just like Layout.const
<whitequark[cis]>
I don't know
<Wanda[cis]>
messy, isn't it
<whitequark[cis]>
this isn't a "I don't want it but won't say it" "don't know", I legitimately don
<whitequark[cis]>
* legitimately don't
<whitequark[cis]>
yes
<Wanda[cis]>
this is, unfortunately, consistent with the generally loose approach to constructor argument typing in Python
<Wanda[cis]>
(I mean this isn't a constructor but also it kinda is)
<Wanda[cis]>
or... is it? I lost track of how many levels of metaclasses we're on
<whitequark[cis]>
<_<
<Wanda[cis]>
which is a great sign
<galibert[m]>
jfng: wouldn’t that require some kind of integration in the system that uses the cpu? Having two levels of decoders sounds inefficient (I know real processors do that, but heh)
<galibert[m]>
Also, how many csrs do you really need and want in a cpu instantiated for a specific design?
<galibert[m]>
Everything you can const is better after all
<jfng[m]>
no, because the goal is to closely follow the risc-v standard, in which out-of-core registers are memory mapped (e.g. the PLIC registers)
<jfng[m]>
galibert[m]: in a minimal design, very few iirc (<10), but it's been a long time and i forgot most of the spec
<galibert[m]>
Probably won’t be here for the meeting, but my POV for that new rfc #17 is merge
<whitequark[cis]>
all right
<galibert[m]>
Just fyi
<galibert[m]>
(I’m at a bar in Harleem with the wife, we’re going to choose a restaurant in 15mn and honestly life is very good)
<jfng[m]>
nice, enjoy yourselves
<whitequark[cis]>
likewise from me
<whitequark[cis]>
good evening everyone, it is time for our weekly meeting
<whitequark[cis]>
who is attending?
<jfng[m]>
o/
<whitequark[cis]>
agg: ?
<whitequark[cis]>
we aren't going to do much with just two people, really
<jfng[m]>
whitequark[cis]: i'm still working on the issues in the CSR RFC that came up when you looked at it friday, so i don't think we can resume the review just now
<jfng[m]>
otherwise, there is RFC 17
<whitequark[cis]>
I mean you already know I agree
<jfng[m]>
yeah
<whitequark[cis]>
I think we should just postpone this meeing
<whitequark[cis]>
Staf is missing, galibert is missing, zyp is not around, it seems
<whitequark[cis]>
zyp: what do you think of RFC 17?
<Wanda[cis]>
the migration suggestions need work
<Wanda[cis]>
(for RFC 17)
<Wanda[cis]>
int(log2(n)) is just truncated log2, not an equivalent of need_pow2=True
<jfng[m]>
Wanda[cis]: can you give an example where `log2_int(n, need_pow2=True)` and `int(log2(n))` give different results ?
<jfng[m]>
(assuming n is a po2)
<Wanda[cis]>
lack of exception is different result
<zyp[m]>
it's when n is not a power of two that they behave different
<zyp[m]>
you'd need to add something like `assert n & (n-1) == 0` to get the same behavior
<Wanda[cis]>
notably: amaranth.lib.fifo uses log2_int with need_pow2=True explicitly for validation purposes
<whitequark[cis]>
and that could use a better diagnostic, honestly
<whitequark[cis]>
oh, wait
<whitequark[cis]>
sorry. that could use a different condition for the diagnostic
<whitequark[cis]>
it makes the code easier
<whitequark[cis]>
I think
<zyp[m]>
I've never used the function, so I'm not opposed to removing it, and at least for me it's faster to reach for the standard math functions than to go looking for something like this
<zyp[m]>
it seems faster, I should say
<whitequark[cis]>
jfng: yeah I think it's a good idea to write a patch for `lib.fifo` first
<jfng[m]>
Wanda[cis]: agreed, the 3rd suggestion ("if n == 0 or n < 0 are valid, the caller must handle them explicitly") was made with `lib.fifo` in mind
<jfng[m]>
IIRC, if it used `math.log2` instead, it wouldn't have to reject the case where `depth` is 0
<adamgreig[m]>
(sorry, was travelling, I've started writing an rfc for lfsr/prbs but not ready for review yet)
<jfng[m]>
<zyp[m]> "it's when n is not a power of..." <- yeah, but i think such assumptions should be explicit on the caller side
pbsds has quit [Ping timeout: 260 seconds]
<jfng[m]>
jfng[m]: > <@jfng:matrix.org> agreed, the 3rd suggestion ("if n == 0 or n < 0 are valid, the caller must handle them explicitly") was made with `lib.fifo` in mind
<jfng[m]>
rather, it *had* to explicitly reject 0, because `log2_int` would have accepted it otherwise
<jfng[m]>
> IIRC, if it used `math.log2` instead, it wouldn't have to reject the case where `depth` is 0
<mcc111[m]>
<adamgreig[m]> "this doesn't need to go in..." <- Thank you so much!
<mcc111[m]>
If I test this and find it works, would it make sense to upstream to amaranth-boards?
<whitequark[cis]>
yes please
<mcc111[m]>
I'll let you know how it goes
<jfng[m]>
so, before RFC 17 is merged, i'll need to:
<jfng[m]>
- clarify the suggested migration paths
<jfng[m]>
- make a PR to migrate lib.fifo
<jfng[m]>
anything else ?
<whitequark[cis]>
would like more people to chime in since there's been some questions already
<whitequark[cis]>
but that's it for this meeting
<Wanda[cis]>
also utils.bits_for uses int_log2 and likewise needs to be migrated (to direct bit_length calls, presumably)
<Wanda[cis]>
but about math.log2
<Wanda[cis]>
whenever I see anything involving floats in what should be entirely integer math, I instantly become distrustful
<whitequark[cis]>
oh, that's a good point
<Wanda[cis]>
the value of int_log2 over ceil(math.log2(...)) is that I can be certain of its properties without having to look in cpython code and tracing how it behaves on edge cases
<whitequark[cis]>
Wanda: can you comment with this on the RFC thread?
<Wanda[cis]>
(which, by the way, I've been doing for the last 20 minutes or so)
<Wanda[cis]>
its behavior on negative numbers (and, arguably, 0) is plain wrong and needs to be fixed, but IMO the function is useful
<jfng[m]>
yeah, but it does more than just restricting n to integers
<jfng[m]>
admittedly, not raising a ValueError on 0 bothers me
<jfng[m]>
the idea of this RFC is that calling log2_int a log2, is very laxist
<Wanda[cis]>
that is true
pbsds has joined #amaranth-lang
<Wanda[cis]>
it's two separate functions really, ceil_div2 and exact_log2
<Wanda[cis]>
both of which are useful when dealing with hardware description
<jfng[m]>
`ceil_div2(n)` would return `ceil(n / 2)`
<jfng[m]>
`exact_log2(n)` would return `log2(n)`, but `n` must be an a po2 ?
<Wanda[cis]>
argh, sorry, ceil_log2
<whitequark[cis]>
ceil_div2 is a really weird function to have
<mcc111[m]>
Hey so um. I think I got amaranth to build something but, which is the file I actually upload to the fpga? Like what is the bitstream? Is it top.bin?
<Wanda[cis]>
yes
<Wanda[cis]>
(the others are various reports or intermediate build artifacts)
<mcc111[m]>
Thanks
Bluefoxicy_ has joined #amaranth-lang
Bluefoxicy has quit [Ping timeout: 250 seconds]
Bluefoxicy_ is now known as Bluefoxicy
vipqualitypost[m has quit [Quit: Idle timeout reached: 172800s]