<vipqualitypost[m>
@galibert @adamgrieg i was trying to avoid using the main clock to sample the a/b encoder as I was under the impression the logic would be simpler + combinatorial but indeed it was more difficult. i ended up writing this in the regular sync domain and everything worked out great!
<vipqualitypost[m>
thanks for the input earlier
<vipqualitypost[m>
a side question: does anyone know if it's possible to use a 'relative' path in the emitted verilog files? i want to include the emitted verilog in my project on github, but I also don't want a huge filetree with my personal name taking up every other line in the annotations
Degi_ has joined #amaranth-lang
<adamgreig[m]>
You can turn off the annotations in the generated verilog, but I don't remember how off the top of my head and can't look it up right now
<vipqualitypost[m>
there was some buzz in the discord #general-chit-chat about prjoxide in the past week
<josuah>
vrakaslabs[m]: "should I" is difficult to answer
<josuah>
but it is definitely possible to use a Nexus-family FPGA with the YosysHQ toolchains
<josuah>
ECP5 has been supported for longer
<josuah>
it is all about what you wih to build :)
<josuah>
Need support for that particular SERDES? Need to check for support for that particular SERDES, while with ECP5 it can be assumed that enough water went down the bridge for someone bringing support for most things
<josuah>
meanwhile, a million of ants (which is more like 2 or 3 vailant folks) get their code editor agitated to bring more support for these... I'm not one of them but lots of thanks to prjoxide!
<galibert[m]>
jfng: do you really want Signature in \_\_all\_\_? That's going to interfere with amaranth's
jfng[m] has joined #amaranth-lang
<jfng[m]>
so will Interface, Arbiter, etc
<galibert[m]>
they exist in amaranth?
<jfng[m]>
the library is meant to be imported as `from amaranth_soc import wishbone`
<jfng[m]>
then `iface = wishbone.Signature(...)`
<galibert[m]>
Doesn't __all__ only have an impact on from amaranth_soc.wishbone import *?
<jfng[m]>
galibert[m]: they exist for CSRs, and will probably for any other bus protocol we implement
<jfng[m]>
i guess, but it also communicates the "public" parts of the API
<jfng[m]>
* = wishbone.Signature(...).create()`
<galibert[m]>
Feature is to be considered private?
<jfng[m]>
good catch
<galibert[m]>
:-)
<galibert[m]>
Should the test use the features names or the enum?
<galibert[m]>
s/test/tests/
<galibert[m]>
also, that PR is going to be very cool
<jfng[m]>
the feature names are useful for brevity
<galibert[m]>
I was thinking more along the lines of whether code would use the enum or the strings, and that test code should follow whatever convention is chosen
<galibert[m]>
s/would/should/
<galibert[m]>
Because it's one of the places people are going to look for examples
<jfng[m]>
i assume downstream code to use strings too
<galibert[m]>
ok, that works then
GenTooMan has quit [Remote host closed the connection]
<jfng[m]>
<cr1901> "jfng: https://github.com/..."; <- so that `.features` contains members of `Feature`, even if they were given as strings to `.__init__()`
<cr1901>
ooooh, makes sense
<cr1901>
I thought maybe only an iterable of Features would be allowed
<jfng[m]>
features={Feature.ERR, Feature.RTY, ...} can get quite verbose vs. features={"err", "rty", ...}
<whitequark[cis]>
it is the time for the weekly regular meeting for the Amaranth language and standard library
<galibert[m]>
Got a kitten in my arms, expect less reactivity
<whitequark[cis]>
there is one planned item on our agenda, which is less than usual, so I expect we'll be able to spend more time discussing other things
<galibert[m]>
886 has the potential to be very useful
<whitequark[cis]>
it introduces a Signature.flatten function that turned out to be quite difficult to implement in the end, because dimensional ports (and signatures too) result in many signals being generated for the same name
<galibert[m]>
At least for people interfacing with verilog
<whitequark[cis]>
it's useful for anyone writing a toplevel in amaranth
<cr1901>
Do you have any particular concerns for exposing it to the user (as opposed to it being an internal convenience method for 886 to work)?
<whitequark[cis]>
actually, that's not entirely true re: toplevel, you can't have an inout port in a Signature. I'm thinking of something I have in mind for platform re-design, we can ignore that for now I think
<whitequark[cis]>
cr1901: it could be quite useful to anyone who wants to enumerate the ports in a signature
<whitequark[cis]>
not just members, but the actual Amaranth values
<whitequark[cis]>
as such it is a natural counterpart to SignatureMembers.flatten
<cr1901>
Yea I agree. _I_ can't think of any reason to _not_ merge this.
<whitequark[cis]>
the latter iterates through the description of the signature, the former through the concrete values
<galibert[m]>
Yeah, obvious merge
<galibert[m]>
Even if my toplevels have no input or outputs
<whitequark[cis]>
you could use this to e.g. insert a logic analyzer at the boundary of a component
<whitequark[cis]>
or even just add simulation traces for the component
Chips4MakersakaS has joined #amaranth-lang
<Chips4MakersakaS>
I also don't have any objections
<whitequark[cis]>
anyone else attending?
<jfng[m]>
merge
<whitequark[cis]>
so be it
<whitequark[cis]>
I actually missed another agenda item because it's a PR. (we really need a written procedure for meetings)
<whitequark[cis]>
this PR is an effort to convert the platform system off Record, and in doing so enable some degree of integration with lib.wiring
<whitequark[cis]>
currently this is very minimal. Pin remains a Record for the time being, but it also becomes an interface object
<galibert[m]>
Platform is lib level?
<whitequark[cis]>
I'm doing this change sneakily without an RFC because it's mostly backwards compatible and I want to redesign Pin later anyway, but I'd rather run questionable changes by the meeting anyway
<whitequark[cis]>
platform can use lib stuff
<whitequark[cis]>
just like backend
<galibert[m]>
Ok then no problem. Getting rid of record would be rather nice
<whitequark[cis]>
so when Record gets removed, Pin will become an Interface subclass and any code that moved to using connect with pins will remain functional
<cr1901>
I like it. Merge.
<whitequark[cis]>
galibert: the only thing that can't use `lib` is `hdl` because this would prevent someone from building their own `lib` which i want to enable
<whitequark[cis]>
I don't want people to end up unintentionally trapped by my choices
<whitequark[cis]>
and I do want to advance fairly aggressively in development and deprecation
<cr1901>
Well, you can still use e.g. led_driver.pins.eq(foo) if you want once pin becomes an interface subclass, correct?
<whitequark[cis]>
you will need to use led_driver.pins.o.eq(foo)
<whitequark[cis]>
which is already recommended but will become mandatory once Pin has no eq
<whitequark[cis]>
tbf, this is a good point, we need a warning on Pin
<cr1901>
oh, that's fine. That's a literal find+replace change for legacy code
<galibert[m]>
I didn’t even realise you could directly eq a pin
<whitequark[cis]>
galibert: it's unintentional
<jfng[m]>
merge if it doesn't break existing code; otherwise i'd favor waiting until a comprehensive platform redesign
<whitequark[cis]>
it's a side effect of Record and UserValue design flaws
<galibert[m]>
That only works for pure inputs, right?
<whitequark[cis]>
jfng: so the plan is to remove `Record` before that
<cr1901>
galibert[m]: It may also a migen-ism I carried over. Or just a mistake that happily compiled. Or both.
<whitequark[cis]>
jfng: that said, I cannot imagine a way in which this would break existing code
<whitequark[cis]>
Pin would never have a signature currently
<galibert[m]>
Yeah, a number of migen-isms are mistakes in hindsight
<whitequark[cis]>
migen actually didn't have eq on Record
<galibert[m]>
Are there multiple kinds of pins? Input, output, both?
<whitequark[cis]>
that one is my mistake
<whitequark[cis]>
I was trying to fix another pattern and in turn introduced something worse. one of the worst decisions in Amaranth
<whitequark[cis]>
but it eventually gave us ValueCastable, which I'm quite happy about
<whitequark[cis]>
the shape-castable and value-castable system in Amaranth is something unique that Migen doesn't have anything even close to, and it enables completely novel uses
<whitequark[cis]>
galibert: yes
<whitequark[cis]>
input or inout has i, output or inout has o, inout has oe
<whitequark[cis]>
zyp: your take on `Signature.flatten`?
<whitequark[cis]>
you usually have valuable feedback on lib.wiring stuff
<cr1901>
No objections. Any old Amaranth code I can update
<zyp[m]>
whitequark[cis]: sorry, I haven't read back that far yet, I just got home
<whitequark[cis]>
all right, will hold it off for a bit
<whitequark[cis]>
now that we're done with agenda items (pending @zyp's feedback) I'd like to share some plans for managing the relationship with the community
<whitequark[cis]>
this will all be done post-0.4
<whitequark[cis]>
first, I'd like to introduce a weekly newsletter, "This Week in Amaranth". I have the domain purchased and some preliminary setup done. this is how I'd like to disseminate RFC work and solicit feedback to a wider audience, some of which doesn't use IRC or Matrix
<zyp[m]>
Signature.flatten looks reasonable to me
<whitequark[cis]>
zyp: thanks!
<galibert[m]>
you sure you want to add more work ?
<whitequark[cis]>
second, I'd like to formalize a number of processes so that I'm not the sole person who knows how to do these
<whitequark[cis]>
I will probably add a separate documentation section explaining how the community development process functions, what the teams are, and also the team member affiliations
<whitequark[cis]>
such as the important information that both me and JF work at ChipFlow, but the Amaranth project is a community project distinct from ChipFlow Limited with its own trajectory and stakeholders
<whitequark[cis]>
after that, I'd like to formalize just a bit our meeting process, to recognize the fact that there is a growing group of people who do not necessarily develop code for Amaranth but provide valuable feedback in the design process
<whitequark[cis]>
in essence I want a written down list of the people from whom feedback should be solicited before the person leading the sub-project makes decisions on its future
<whitequark[cis]>
the list is ultimately up to the person in leadership, but I think it is important to recognize people who put ongoing effort into providing valuable feedback shaping the project for the better
<whitequark[cis]>
re "more work": it will be mostly a collection of links, most of which is gathered mechanically
<whitequark[cis]>
and I do think it is important to have an ongoing pulse
<whitequark[cis]>
any feedback on this?
<whitequark[cis]>
oh, and the other thing I want to formalize is that Amaranth development, at least currently, happens in the open. there are no secret groups where people make secret decisions and then bullshit everyone else
<galibert[m]>
Just that you have very interesting and fundamental evolutions planned for post-0.4, it would be sad to have you drowing in other stuff instead
<whitequark[cis]>
I think it's very important to keep the project functioning transparently even as it grows
<adamgreig[m]>
I like the newsletter concept, automating it will probably be important to making sure it actually happens
<whitequark[cis]>
galibert: anyone from the community who steps up could be the newsletter editor, or barring that, ChipFlow has an employee who should be able to commit some time to editing it (pending internal discussion)
<adamgreig[m]>
I don't know if it needs to be weekly most of the time but perhaps there's enough happening now to be worth it?
<cr1901>
I like all of this, but second galibert[m]'s concern re: burnout. Re: secrecy, I think we're collectively a bit less conflict-avoidant group of people (which is good). But time will tell
<whitequark[cis]>
adamgreig: yeah I've been thinking about building something that queries the GitHub API
<jfng[m]>
sgtm, more transparency and clearly defined process is healthy
<jfng[m]>
re: reaching to a wider audience, amaranth could use a logo !
<whitequark[cis]>
oh absolutely, we do need it
<whitequark[cis]>
I have an idea of how I want it to look like
<whitequark[cis]>
but I need to commission somebody and I'm inexperienced in that
<whitequark[cis]>
adamgreig: registered this-month-in-amaranth.org as well :D
<whitequark[cis]>
covering all the bases etc
<adamgreig[m]>
not this-month-in.amaranth-lang.org? :P
<cr1901>
I think I should make explicit: Right now, probably the only bandwidth I have for making projects in Amaranth is the pet project efbutils and refactoring codebases.
<whitequark[cis]>
adamgreig: hmm, we could have the latter be an alias for the former
<whitequark[cis]>
I don't have a super strong opinion on this
<adamgreig[m]>
<whitequark[cis]> "in essence I want a written down..." <- is this sort of like "instead of teams of people that vote on RFCs, we have lists of people to ping who might give feedback, but if they don't give it in time then the vote remains whoever-was-at-the-meeting" or so?
<whitequark[cis]>
adamgreig: I think we may eventually have teams of people that vote on RFCs, but right now the reality is that I'm making decisions on lang/std and JF is making decisions on soc
<adamgreig[m]>
my vague feedback from rewg is it's quite easy to end up with a lot of people on a lot of teams in a way that makes it quite slow to get any rfcs voted through
<adamgreig[m]>
whereas often all you really needed was an idea of who to get feedback from on particular ideas
<whitequark[cis]>
there is no formal requirement of having everyone in unanimous agreement on a feature
<galibert[m]>
Well, we have to remember that we're currently, like, ten at most?
<Chips4MakersakaS>
I also feel weekly is quite rapid pace.
<whitequark[cis]>
however there is a social expectation that the sub-project leader will consult the stakeholders and take it into account
<whitequark[cis]>
this avoids the voting paralysis
<adamgreig[m]>
I still quite like the voting majority rules we came up with where the number of approving votes required as a fraction of the electorate drops over time until it's just "one other person said yes and no one said no"
<adamgreig[m]>
but, I don't think it's useful here at the moment
<galibert[m]>
At the current size the meetings work
<whitequark[cis]>
in practice, team members (even non-leader members) in, say, Rust have a lot of power and can get decisions in that would not fly without their position being what it is
<whitequark[cis]>
so I think I'm not going to achieve much by setting up formal voting
<whitequark[cis]>
Amaranth isn't a democracy
<adamgreig[m]>
yea, agreed, I think the current approach works well
<Chips4MakersakaS>
adamgreig[m]: +1
<whitequark[cis]>
especially if the team leader is acting not in the best interest of the community, Rust has absolutely nothing that would really stop it
<whitequark[cis]>
the value of the additional bureaucracy is vanishing or negative
<whitequark[cis]>
(for Amaranth, I mean)
<cr1901>
Meetings work fine for now, punt additional bureucracy until later?
<whitequark[cis]>
cool
<whitequark[cis]>
Chips4Makers (aka Staf Verhaegen): adamgreig: so if we only have a monthly newsletter this means the Final Comment Period will be at least a month
<whitequark[cis]>
and the average time-to-RFC-merge will be 1.5 months
<galibert[m]>
we'll talk about it again when we reach triple-digits people in the meetings :-)
<whitequark[cis]>
I don't like that
<adamgreig[m]>
if it's very automated as a list of "here are some rfcs to please look at, consider this your notice", plus whatever manual items someone has submitted for that week, I think weekly's fine
<adamgreig[m]>
I mean, I'll read it weekly in my rss reader alongside twir or whatever
<adamgreig[m]>
but it's potentially a lot of work and many weeks might not see anything
<adamgreig[m]>
you're right that if it was monthly that means even a simple pr ends up with a really long wait
<Chips4MakersakaS>
Didn't realize you wanted to couple newsletter with procedurals on RFC etc. I thought it was just news.
<galibert[m]>
I think it should be just news, and say that if you want to participate to the design here are the rfcs and the meetings
<whitequark[cis]>
how else would people learn about new RFCs without subscribing to the RFC repo (which can get overwhelming)
<whitequark[cis]>
I think it's pretty important for the RFC process to work well
<cr1901>
subscribe to a mailing list :)
<whitequark[cis]>
literally that is a part of it
<whitequark[cis]>
you will be able to get the newsletter to your mailbox
<whitequark[cis]>
anyway, the current plan is to have the issues be named like "Amaranth Newsletter 2023-W36" and if we ever need to switch to monthly it'll be "Amaranth Newsletter 2023-09" instead
<cr1901>
I think there should be a news section and RFC section. Basically, what adamgreig[m] said
<adamgreig[m]>
I'm +1 on having RFCs be in the newsletter, defo
<adamgreig[m]>
probably with status like "new this week" or "fcp" or whatever
<whitequark[cis]>
yes
<whitequark[cis]>
I can automate a lot of it via the GH API, I think
<whitequark[cis]>
put up like a bot so that you don't have to muck with the console
<cr1901>
And it's low enough traffic that I don't _mind_ subscribing to this mailing list :P
<adamgreig[m]>
it makes a PR with this week's .md file, and when a new md is merged it gets emailed to everyone and published on github pages with the website and rss feed?
<whitequark[cis]>
yes
<adamgreig[m]>
plus some way for people to add their own items for the week
<whitequark[cis]>
PRs into the PR
<whitequark[cis]>
cursed I know
<adamgreig[m]>
in rewg we had a md with status:draft in the metadata and anyone could PR new items to it, then when it was done the status is updated
<adamgreig[m]>
and the page building action ignores drafts (or rather they are excluded from front page and rss, but you can still see them via direct link)
<whitequark[cis]>
yep i like that
<adamgreig[m]>
perhaps the scheduled automation makes a PR that sets status draft->published and adds all current RFC details and creates a new draft for the next one
<adamgreig[m]>
and then accepts and merges its own pr I guess, heh
<whitequark[cis]>
yep something like that!
<whitequark[cis]>
it would be a massive PITA to design and test
<cr1901>
What library do you use to make your GH bots?
<whitequark[cis]>
fwiw the meeting has ended, i will proceed to updates
<whitequark[cis]>
galibert: I've nominated your strobe generator RFC for discussion on the next meeting
jfng[m] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
jer_emy[m] has quit [Quit: Bridge terminating on SIGTERM]
adamgreig[m] has quit [Quit: Bridge terminating on SIGTERM]
galibert[m] has quit [Quit: Bridge terminating on SIGTERM]
vipqualitypost[m has quit [Quit: Bridge terminating on SIGTERM]
whitequark[cis] has quit [Quit: Bridge terminating on SIGTERM]
mcc111[m] has quit [Quit: Bridge terminating on SIGTERM]
zyp[m] has quit [Quit: Bridge terminating on SIGTERM]
Chips4MakersakaS has quit [Quit: Bridge terminating on SIGTERM]
Wanda[cis] has quit [Quit: Bridge terminating on SIGTERM]
vrakaslabs[m] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has joined #amaranth-lang
galibert[m] has joined #amaranth-lang
<galibert[m]>
Thanks
galibert[m] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
<_whitenotifier>
[amaranth-lang/amaranth-lang.github.io] whitequark 79f8687 - Deploying to main from @ amaranth-lang/rfcs@4edf8cc0d6d7e69edc2c0967c2457d1b5e772846 🚀
<whitequark[cis]>
strobe generators don't fall into one of these three categories which means there needs to be more motivation why it should be in the stdlib
<galibert[m]>
Then crc doesn’t belong there either, and I wouldn’t remove it
<whitequark[cis]>
I didn't say these are the only things that go into the stdlib
<galibert[m]>
:-)
<whitequark[cis]>
I said these are the things which require no additional motivation
<whitequark[cis]>
for CRCs, there is an understanding that there is the one correct way to implement them, and the one list of algorithms everyone agrees on
<whitequark[cis]>
so there's no point in endlessly copying/rewriting that
<whitequark[cis]>
plus they're very widely used
<galibert[m]>
Anyway, I have no intention to argue against crc
<whitequark[cis]>
for enable trains, there are two main points of question:
<whitequark[cis]>
- there are subtle design decisions that not everyone may want to do the same. mainly the way dithering is made, but there are others
<whitequark[cis]>
- strobe generation will often be folded into a larger module controlling clocking and usually containing CSRs
<_whitenotifier>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] b6c42bb - Deploying to main from @ amaranth-lang/amaranth@33c2246311ab2c59a84ac71eb5187c6b06ac12d8 🚀
<whitequark[cis]>
in addition I don't think something like VariableSimplifiedStrobeGenerator should be in the stdlib at all
<galibert[m]>
We’ll see what others think, I’ll have the implementation for me and whoever else wants it in any case
<galibert[m]>
Yeah, that one is very arguable
<whitequark[cis]>
I mean there's not going to be an argument about it, this is a plain no from me as the lead
<whitequark[cis]>
I would like to discuss the others though
<galibert[m]>
Works
<galibert[m]>
Looking at that vhdl code in the middle of the verilog Atari st emu gave me hives
<galibert[m]>
It’s horrible in synth too
<whitequark[cis]>
I haven't fully considered it but my gut feel is that there should not be a VariableStrobeGenerator/FixedStrobeGenerator distinction at all
<galibert[m]>
Gcd?
<whitequark[cis]>
hm
<whitequark[cis]>
yeah this is the kind of microoptimizations I don't know if we should pursue at all
<whitequark[cis]>
I really do not like the amount of additional concepts someone will face when first opening the doc page for this, all for the sake of saving a few flops
<whitequark[cis]>
does it even affect the critical path?
<galibert[m]>
It affects the size of the adder and the mux
<whitequark[cis]>
so?
<whitequark[cis]>
if this is just about area, I don't think this justifies an additional module
<whitequark[cis]>
I'm tired and can't tell if this causes the critical path to grow or not
<whitequark[cis]>
I have a related comment
<whitequark[cis]>
which is that here you specify the frequencies as frequencies, but in many cases it makes a lot of sense to use periods
<whitequark[cis]>
(periods in terms of the base clock)
<galibert[m]>
As a float?
<whitequark[cis]>
integer
<whitequark[cis]>
(well, fixed point)
<galibert[m]>
Then you use the period as base clock and 1 in fixed point as the strobe clock
<whitequark[cis]>
yeah okay, having a bigger adder does affect the critical path
<galibert[m]>
The netlist is so small it’s all critics
<galibert[m]>
Also lib or not you’re more than welcome to use that code is Glasgow or wherever if it’s in any way useful
<whitequark[cis]>
I would rather have everyone who wants a strobe generator to find that there isn't one in the stdlib, pause, think, discover there are tradeoffs, and pick which tradeoffs they want explicitly than to use something in the stdlib just because it's in the stdlib
<whitequark[cis]>
and there are definitely tradeoffs here
feldim2425 has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
feldim2425 has joined #amaranth-lang
josuah has quit [Quit: josuah]
josuah has joined #amaranth-lang
<cr1901>
Anyone have a GHA config they use for Amaranth (preferably w/ pytest)? cc: agg
trabucay1e has joined #amaranth-lang
<galibert[m]>
What’s gha?
<cr1901>
GitHub Actions
<galibert[m]>
Ahhhhh
cyrozap_ has joined #amaranth-lang
Degi_ has joined #amaranth-lang
whitequark[cis]1 has joined #amaranth-lang
richardeoin has quit [Ping timeout: 246 seconds]
whitequark[cis] has quit [Ping timeout: 246 seconds]
trabucayre has quit [Ping timeout: 246 seconds]
Degi has quit [Read error: Connection reset by peer]
Degi_ is now known as Degi
cyrozap has quit [Ping timeout: 246 seconds]
oter has quit [Write error: Connection reset by peer]
richardeoin has joined #amaranth-lang
oter has joined #amaranth-lang
<cr1901>
Btw, if anyone was using the links that were posted earlier to my code using Signatures/Components: sorry, those links are probably going to become invalid soon as I do a (painful!) rearrangement of source code.
<cr1901>
It needs to be done, might as well do it now :/
<whitequark[cis]1>
you can press "y" on a github page to change the URL to be a permalink
<whitequark[cis]1>
cr1901: I feel like extending the official template repository with CI
<cr1901>
I've never used poetry, but yes, this does help very much
<whitequark[cis]1>
want to wait until I do? later today
<cr1901>
Yes, that's fine to wait. I probably broke _a lot_ of shit anyway rearranging folders and will need time to suss the breakage out
<whitequark[cis]1>
I recommend PDM rather than poetry for some good reasons
<whitequark[cis]1>
it also results in an easier test work flow
<adamgreig[m]>
Yea, I think the ci should look pretty similar with pdm, sadly for me I started using poetry before pdm was a thing and it doesn't seem worth swapping yet
<adamgreig[m]>
Having already swapped from pipenv to poetry -_-
<_whitenotifier>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] cf41446 - Deploying to main from @ amaranth-lang/amaranth@4e078322a04042b5f840006c200f123c3c42273b 🚀
<cr1901>
I installed PDM, so I'll play with that whenever the template's ready
<cr1901>
`git commit -m "Restructure entire repo to closer to original vision. Almost certainly everything is broken."`
crzwdjk has joined #amaranth-lang
richardeoin has quit [Ping timeout: 246 seconds]
Degi has quit [Ping timeout: 246 seconds]
electronic_eel has quit [Ping timeout: 246 seconds]
Degi has joined #amaranth-lang
richardeoin has joined #amaranth-lang
electronic_eel has joined #amaranth-lang
balrog has quit [Quit: Bye]
balrog has joined #amaranth-lang
<crzwdjk>
Thinking about the whole uninitialized Memory thing, I was pondering analogies with Rust's handling of uninitialized data and things like MaybeUninit::assume_init(), and I guess what I would do in that vein is have a module that just initializes the uninitialized memory and keeps the reset asserted on everything else in the meantime. Then the stuff that reads the memory can assume it is a
<crzwdjk>
regular initialized memory, and the memory-initializer module (which is some kind of "unsafe" code in the analogy) only writes the memory, never actually seeing the uninitialized values which are nonetheless there.
<cr1901>
Okay I have a problem. And this very much not a joke...