nyanotech has quit [Remote host closed the connection]
nyanotech has joined #amaranth-lang
notgull has joined #amaranth-lang
notgull has quit [Ping timeout: 264 seconds]
Chips4MakersakaS has joined #amaranth-lang
<Chips4MakersakaS>
I most likely won't make it to the IRC meeting later today. Regarding RFC #30, I had a chat with Catherine and made [comment](https://github.com/amaranth-lang/rfcs/pull/30#issuecomment-1878680293) on github. With that comment taken into account I can change my vote from abstain to following the majority of the other voters.
feldim2425 has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
feldim2425 has joined #amaranth-lang
tarmo has joined #amaranth-lang
<tarmo>
hi, I have an altera de10 standard, i have seen that in amaranth boards are de10lite, de10nano and de1 is it compatible any of this configurations with my fpga?
<whitequark[cis]>
I think you might have to check yourself
<whitequark[cis]>
relatively few people use Altera devices or boards
<tarmo>
Ok, thanks, I was just wondering if anyone had the same problem as me.
<tarmo>
maybe I should upgrade my fpga :)
<galibert[m]>
The quartus aspects are the same, the on-board peripherals are obviously different
<galibert[m]>
what is your problem?
<tarmo>
At the moment none, I have never used amaranth and I wanted to give it a try on my fpga
tarmo has quit [Quit: Client closed]
<anuejn>
Chips4MakersakaS: I am also rather confused by the schema stuff
<anuejn>
do I need to be able to retrieve the schemas as a user?
<anuejn>
do I need to make one?
<anuejn>
do I need to have the possibility to host files on the internet to make schemas?
<whitequark[cis]>
jfng: ^
<anuejn>
I am a bit confused the whole schema and domain stuff actually does
<whitequark[cis]>
the schemas are useful if you want to build a tool based on Amaranth which communicates with other tools based on Amaranth
<whitequark[cis]>
for example, person A should be able to build a tool based on Amaranth (Amaranth SoC) that creates register maps, and person B should be able to build a tool based on Amaranth (BSP generator) that consumes these register maps
<whitequark[cis]>
this requires them to agree on an interchange format, which is what the schema represents
<whitequark[cis]>
if you are not touching any of those, you can completely ignore the existence of schemas
<anuejn>
but why do the schemas have to live in the internet?
<anuejn>
why are they not part of some object hierarchy in the python process?
<whitequark[cis]>
because an interchange format should be publicly accessible and machine-verifiable
FFY00 has joined #amaranth-lang
<whitequark[cis]>
you're not necessarily even talking to a python process here. it could be a tool written in Rust or whatever
<anuejn>
I mean why can the schema not be provided in the same way the data is provided
<whitequark[cis]>
once Amaranth has generated the netlist, what is done with the netlist is out of our hands, and people will use it with all sorts of non-Amaranth infrastructure that we don't even want to cover in our scope, or where it's impossible to put it into our scope
<whitequark[cis]>
because a schema is closer to code in nature than to data like a netlist
<whitequark[cis]>
if the schema changes, you need to change your code manually. this means that a schema must have a unique global identifier you can compare against
<anuejn>
why can the schema then not live next to the code?
<whitequark[cis]>
we could use an UUID (if we were working for Microsoft *ahem*) but we used an URI which also makes a way to retrieve the schema
<whitequark[cis]>
anuejn: it does
<whitequark[cis]>
it's just that you can't dig out a schema out of some arbitrary Python code in order to check whether an input conforms to it
<whitequark[cis]>
in Amaranth itself, the schema is going to be a Python dict, which is published as a part of the release process to the amaranth-lang.org website
<anuejn>
but couldnt we just write it as a file next to the data when we output it
<anuejn>
instead of putting it on some website?
<whitequark[cis]>
would you suggest to do the same with documentation?
<galibert[m]>
Does that mean that amaranth is going to go download things from the internet at compile time?
<whitequark[cis]>
when you ship someone a Verilog netlist, do you attach a copy of the Verilog spec, or do you say "this is in the IEEE 1800-2008 format"?
<whitequark[cis]>
galibert[m]: no
<whitequark[cis]>
most of the time, the schema URI is treated as an opaque identifier
<galibert[m]>
ok good, because that would be problematic
<whitequark[cis]>
however, you also have the option to download it to check if an arbitrary input conforms or not
<anuejn>
I really appreachiate that I can do that with rustdoc for example
<jfng[m]>
for an example of how a schema lives next to the code itself
<anuejn>
okay
<anuejn>
so can I just leave out the $id field if I do not host that at a stable location?
<anuejn>
I am all for hosted documentation
Camilo[m] has joined #amaranth-lang
<Camilo[m]>
Hi All, got a question im learning amaranth while trying to make it a default tool in my job :), I am for now integrating modules i write in amaranth and then export to verilog so i can use them in vivado, so i always use something like v = verilog.convert(top, name=module_name, ports=[],emit_src=False, strip_internal_attrs=True) , so now I was reading the code to generate verilog in gh repo but cant find a way for it to export
<Camilo[m]>
verilog parameters of a module, I was thinking write_verilog_opts would but but it seems is for something else, any hints? is that even possible?
<galibert[m]>
anuejn: well, it's very case in point, given the id field is 404
<whitequark[cis]>
anuejn: the thing I want to avoid is a proliferation of ancillary data which does not have any specification whatsoever but which tools still have to try and parse by basically guessing what it means, or emailing the author
<whitequark[cis]>
I want you to publicly document anything you put into these fields when you interchange data with others
<anuejn>
but sometimes it is to cumbersome to setup doc hosting for small little projects and I still want to be able to view them
<whitequark[cis]>
in fact, the website should host not only the schema itself but the documentation for the metadata
<anuejn>
whitequark[cis]: I can totally see that
<jfng[m]>
the presence of '$id' is not required as per the JSON Schema spec, but we do require it
<jfng[m]>
you are not obligated to actually host the schema, but not doing so limits their usefulness a lot i think
<anuejn>
I think I may not have gotten the point of the schema stuff
<whitequark[cis]>
Camilo[m]: Camilo: Amaranth cannot create modules that include Verilog parameters. in Verilog terms, it creates a "post-elaboration" module (which is an intermediate stage of processing Verilog code that Verilog frontends also use)
<anuejn>
probably nevermind me then
<whitequark[cis]>
anuejn: what kind of metadata do you expect to be adding to designs?
<anuejn>
stuff like "cycles of delay that a block that ingests and outputs a stream" has
<Camilo[m]>
whitequark[cis]: thanks!
<anuejn>
and then I would build a tool that checks if some two streams that go through different blocks still have the same delay after going through the blocks
<whitequark[cis]>
do you expect to be combining blocks in some higher-level tool like a block diagram editor?
<whitequark[cis]>
or are you going to be doing everything in one Python process?
<anuejn>
probably that
<anuejn>
(really just making up a usecase here)
<whitequark[cis]>
which one of the two cases I listed?
<anuejn>
ah sorry everything in one python process
<anuejn>
actually I would like to use it to annotate signals as as being readable via some debug interface
* anuejn
ducks
<anuejn>
but I think that is kinda deliberately not the intended usecase?
<whitequark[cis]>
if everything is in one Python process you just use normal Python attributes
<whitequark[cis]>
the metadata stuff is specifically for export to other tools when you're done (Python or not)
<whitequark[cis]>
as for the debug interface, that sounds more in scope
<whitequark[cis]>
but I'd need to hear more details to understand it better
<anuejn>
oh interesting
<anuejn>
okay maybe I just completely misunderstood what this RFC is about
<anuejn>
I think I am not really the target audience and just read stuff into it that is not the usecase
<whitequark[cis]>
it's for (a) bringing information from other tools into Amaranth (b) exporting information from Amaranth for other tools (c) very rarely, for composing Amaranth blocks together when you ship them as prebuilt netlists (maybe your core is proprietary or something)
<anuejn>
I would like to mark Signals that I want read the value of in a running design (for example via JTAG) for debugging purposes
<anuejn>
then elaborate the design and get an elaborated design and a list of all these signals
<galibert[m]>
that's similar in a fashion to a memory map
<anuejn>
to then add the elaborated design and the signals to some kind of debug harness that connects them to the JTAG
<anuejn>
but I see, that thats only very remotely connected to what the RFC is for 😅
<whitequark[cis]>
I think you can use an attribute for that
<whitequark[cis]>
that use case is also something we'll eventually add to Amaranth, but it's a medium-term goal I think
<anuejn>
okay
<anuejn>
yeah I currently have a Hack for that and thought that this RFC might be the way to get rid of that
<anuejn>
but I can very well understand that it is a different yack to shave
<anuejn>
but I would be interested in doing so :)
<whitequark[cis]>
this RFC actually doesn't touch inner signals at all, only signals at the interface
<whitequark[cis]>
so it's not applicable for that case
<anuejn>
okay
<anuejn>
will the RFC 30 metadata be possible to query from the cli?
<anuejn>
if so, will the schemas also be possible to query via the cli?
<anuejn>
I think that would be nice, but thats about all the feedback I have for that then
<anuejn>
and sorry for bothering
<whitequark[cis]>
anuejn: the CLI will output metadata as a .json file next to your .il or .v file, probably
<whitequark[cis]>
eg design.v + design.v.json
<anuejn>
can it then also output the schema? I think that would be handy for reducing the risk of bitrot
<anuejn>
(I also really appreachiate if builds of software include the documentation)
<whitequark[cis]>
jfng: we have that data in Python objects, right?
<jfng[m]>
yes
<whitequark[cis]>
anuejn: then yeah, we could have an option outputting the schema as well. eg `design.v` + `design.v.json` + `design.v.json-schema`
<whitequark[cis]>
I expect it will be used basically by just you but I see no reason to oppose having it
<whitequark[cis]>
the .json-schema would be a mapping from URIs to schemas, as a JSON file
<whitequark[cis]>
anuejn: can you post a summary of this as a GH comment please?
<anuejn>
sounds very nice :)
<anuejn>
Yes, can do
<jfng[m]>
whitequark[cis]: you can access it through the `.schema` property of a `meta.Annotation` subclass
<whitequark[cis]>
please respond with your comments or proposed disposition: merge or close
<whitequark[cis]>
do note that the RFC has had some minor changes just pushed to it by @jfng to address past feedback
<zyp[m]>
I have a question
<tpw_rules>
not sure if responding is required; i personally do not have enough familiarity to have a disposition
<zyp[m]>
how do we extend this if/when we later want to add more metadata for shape-castables to the interface metadata?
<whitequark[cis]>
tpw_rules: participation is not required
<galibert[m]>
Hi, sorry I'm late
<zyp[m]>
e.g. in the example there's a rx_err signal that's a struct
<whitequark[cis]>
hi galibert
<cr1901>
I still don't like users having to write their own schema. Is there a tool we can suggest that infers a schema from a JSON string/file to at least get users started w/ a skeleton?
<whitequark[cis]>
cr1901: is it that difficult to write a schema once you have documentation for your new metadata?
<whitequark[cis]>
(I don't think inferring a schema is an operation that makes any sense, any more than inferring documentation would be. Maybe ask ChatGPT?)
<galibert[m]>
cr1901: I'm with catherine there, writing a schema is not a real difficulty
<cr1901>
_I_ find it a PITA. Apparently no one else agrees.
<galibert[m]>
DId I miss something or there still isn't anything about of to get the information out?
<zyp[m]>
I don't think adding new metadata types is something most users will do
<whitequark[cis]>
galibert: that sentence doesn't parse
<zyp[m]>
galibert[m]: `.signature.annotations`
<zyp[m]>
and also Component.metadata
<whitequark[cis]>
I just tried ChatGPT and it does a completely abysmal job
<whitequark[cis]>
which is to say it outputs a syntactically valid schema but does not infer anything about the structure, just summarizes it all
<galibert[m]>
You have Elaboratable with metadata on them in your tree, you get a design at the top, do you have a way to get the annotations of the Elaboratables in the tree so that you can do something with them, starting with dumping them in a file?
<tpw_rules>
is there a meta-validator to determine whether you've written a valid JSON schema? i checked the "getting started with json schema" page on their site and it finishes with "Learning JSON Schema is often confusing, but don't worry, we are here to help! You can start a thread on GitHub Discussions, connect with us on Slack, or join our live Office Hours."
<jfng[m]>
<zyp[m]> "how do we extend this if/when we..." <- the annotations of the signature using those shape-castables could be annotated to pass such information
<jfng[m]>
this can either be done in an ad-hoc fashion as of this RFC
<jfng[m]>
a further RFC could maybe allow port members to carry annotations too
<jfng[m]>
tpw_rules: there is, see the `jsonschema` library
<jfng[m]>
we are a bit more stringent than it, though e.g. we require the `$id` property, whereas it doesn't
<whitequark[cis]>
yeah, Amaranth doesn't let you either use an invalid schema, or emit output that doesn't match your schema
<whitequark[cis]>
we're really serious about the quality of data we output
<jfng[m]>
the possibility of making our own meta-schema has come up during prototyping, but we dismissed it as it seemed overcomplicated for our use-cases
<galibert[m]>
If amaranth goes on the web to retrieve a schema without asked this code will be ripped out with a white-hot knife
<jfng[m]>
jfng[m]: (as in, a metaschema specific to amaranth annotations)
<zyp[m]>
the reference schema in the RFC has a 0.5 in $id, is the intention that this will be updated each Amaranth release?
<whitequark[cis]>
it obviously would not make web requests without being asked. Amaranth doesn't assume anything about your build environment, including the availability of a network
<zyp[m]>
IMO it'd be more reasonable with separate versioning that only gets incremented when the schema changes
<whitequark[cis]>
or that you'll have working DNS
<galibert[m]>
s/asked/asking/
<whitequark[cis]>
zyp: it's intended to get incremented when the schema changes, but the value that is used is the same as the Amaranth version at the time of the change
<whitequark[cis]>
i.e. we might have 0.5 forever there, or go from 0.5 to 0.9 directly for example
<whitequark[cis]>
it's an opaque identifier that doesn't say anything about the compatibility of the schema
<whitequark[cis]>
galibert: it doesn't. it uses the URI as, well, an universal resource identifier
<whitequark[cis]>
neither would most tools based on this proposal which talk to Amaranth; they will simply compare the URI by equality to detect that they are indeed interpreting the JSON correctly
<zyp[m]>
galibert[m]: if I'm reading the RFC right, `ComponentMetadata.schema` will supply a local copy of the schema for validation
<whitequark[cis]>
but in addition to that you have the option of running a generic validator yourself, which will go to the URL, fetch the resource, and validate the JSON object this way
<jfng[m]>
zyp[m]: correct
<galibert[m]>
So we need some sort of file store with the uris and the contents so that, I cite "Amaranth doesn't let you either use an invalid schema, or emit output that doesn't match your schema"
<whitequark[cis]>
what?
<tpw_rules>
i see cr1901's point, the meta-schema looks somewhat unwieldy. a thing where you paste in your JSON and then it sets up the schema structure and you touch up stuff like regexes would be nice i think
<cr1901>
zyp[m]: The schema itself also has a URL (tho I imagine you could safely ignore that)
<tpw_rules>
but if few people will be writing their own, then maybe that's less of a concern
<galibert[m]>
oh, you provide the schema too, I missed that point
<whitequark[cis]>
yes
<tpw_rules>
jfng[m]: does the current implementation use `jsonschema` internally?
<galibert[m]>
what happens if you have Elaboratables which, through the power of fucked up copy/paste, have different schemas under the same iru?
<whitequark[cis]>
publishing it at the URI is providing the machine readable documentation for a schema you provide to others
<galibert[m]>
s/iru/uri/
<whitequark[cis]>
galibert[m]: the downstream tools get to deal with that
<jfng[m]>
whitequark[cis]: such a validator will not be able to check that the $id url follows our conventions (as they are not specified in a metaschema), but should nonetheless be able to validate everything else
<jfng[m]>
tpw_rules: yes, see the PR linked in the RFC
<galibert[m]>
(or if someone a little too insane generates parametrics schemas...)
<whitequark[cis]>
galibert: if you have a mix of schemas, the downstream tools would have to be able to read all of them, which will probably involve either copy/paste whenever the version changes, or some set of if/else conditions
<cr1901>
Can someone remind me what you're supposed to put in $id if you don't own a website?
<whitequark[cis]>
if you have a github repo, you can use github.io
<whitequark[cis]>
which provides every github repo with a corresponding website if you push some stuff to the gh-pages branch
<cr1901>
Ahhh
<whitequark[cis]>
so does gitlab, codeberg, and most other modern source code exchanges
<tpw_rules>
so $id lets downstream tools verify that they are operating on an expected schema/look it up in their internal database, rather than necessarily needing to retrieve it from the destination? i see that the schema itself is in the amaranth code
<tpw_rules>
and share galibert[m]'s concern that at no point should this be reaching out to the network
<whitequark[cis]>
tpw_rules: yes. it is an universal identifier
<whitequark[cis]>
it's not easy to get a truly universal identifier that is human readable
<whitequark[cis]>
basically the only easy way is DNS
<whitequark[cis]>
if we didn't care about it being human readable, I would propose UUIDs
<tpw_rules>
so human readable precludes UUIDs, yeah
<galibert[m]>
Catherine: nah, sha256sum of the schema!
<whitequark[cis]>
the fact that you can use the identifier to get at the schema is a nice bonus
<Wanda[cis]>
not sure if it's any problem in practice
<tpw_rules>
(why would we care? there's already a name and an annotation)
<whitequark[cis]>
galibert: I am partial to that, but then you need to define a normal form for JSON, including things like field order
<zyp[m]>
I think I'm overall happy with this, apart from the lack of value-castable metadata, which can be added by a later RFC
<cr1901>
Basically $id is a unique identifier that serves as a dual role of "here's is the canonical copy of the schema if you want it, but it's here locally too"
<galibert[m]>
Catherine: It's json, like anyone cares ;-)
<whitequark[cis]>
tpw_rules: I want metadata authors to document their metadata
<whitequark[cis]>
you can put comments into JSON Schema
<cr1901>
dual role of unique id
<jfng[m]>
tpw_rules: such tools won't have to depend on python, or pull in amaranth as a dependency
<whitequark[cis]>
so you can document every bit of your metadata this way
<tpw_rules>
whitequark[cis]: confused what this has to do with the meaning of the "$id" property
<tpw_rules>
and human-readability
<galibert[m]>
Anyway, I have no use-case for that rfc, so I'll stay on abstain
<whitequark[cis]>
tpw_rules: (a) the schema itself is both machine-readable and human-readable therefore it serves as documentation (b) requiring everyone to post their schema at an http server makes this documentation accessible
<cr1901>
Is "here's is the canonical copy of the schema if you want it, but it's here locally too" an accurate, if glib, description of what the url in the $id represents?
<whitequark[cis]>
yes, it's accurate
<zyp[m]>
I vote merge
<cr1901>
merge
<tpw_rules>
are private companies gonna have problems with that?
<whitequark[cis]>
I think in that case you would deploy the schema on the intranet and put an intranet URI in there
<jfng[m]>
this url can be served on an intranet; the point is just that it is accessible to its users
<tpw_rules>
okay. it just seems that in cases where you'd have the "$id" you'd have a complete copy of the schema too. or maybe not if amaranth starts exporting files
<zyp[m]>
if private companies are gonna define and publish custom metadata, they ought to publish its scheme in any case
<whitequark[cis]>
this whole RFC is written so that files can be exported from Amaranth
<whitequark[cis]>
(and imported, potentially)
<tpw_rules>
and those might contain just the $id as opposed to the whole schema?
<whitequark[cis]>
the JSON metadata output has a $schema field, iirc
<whitequark[cis]>
with the same URI
<whitequark[cis]>
it does not directly inline a copy of the schema
<jfng[m]>
no, $schema is the URI of the metaschema of an annotation schema
<cr1901>
tpw_rules: I don't think the $id exists independent of the schema as described by this RFC
<whitequark[cis]>
oh, right
<cr1901>
in other words, you're dealing with at least a local copy, and a canonical copy pointed to by $id
<cr1901>
it's up to tooling whether it verifies the local/canonical copy matches
<jfng[m]>
the local copy may or may not be there
<cr1901>
then how do you get the $id?
<jfng[m]>
i think it is good practice to include it though, as @libera_anuejn:catircservices.org pointed out
<jfng[m]>
the $id is a required attribute of any metadata instance
<zyp[m]>
jfng[m]: but the actual metadata could also have a `$schema`
<cr1901>
ahhh
<tpw_rules>
if it's an attribute of the instance, shouldn't it be called "$schema"?
<whitequark[cis]>
jfng: I wonder if we should not replace the annotation name with the schema URI
<whitequark[cis]>
(I actually thought this is how it already works, but I misremembered)
<whitequark[cis]>
the reason being that then we'll have the version in there too
<jfng[m]>
this is a case where we are stricted than the JSON Schema spec, as we require the presence of $id
<jfng[m]>
hmm
<whitequark[cis]>
otherwise, how do you know which version of the annotation you are dealing with?
<tpw_rules>
"metadata instance" to me means a thing against which you validate your component schema
<Wanda[cis]>
I'd vote for allowing a little less strict URI format
<jfng[m]>
the question of including versions in annotation names has come up previously, iirc
<tpw_rules>
or rather which is validated against your component schema
<Wanda[cis]>
this would make it hostable in per-project gh-pages, not just per-user/per-org
<whitequark[cis]>
I can't think of any purpose annotation names serve at this point, given the strict correspondence rules to the URI
<cr1901>
It seems the annotation name is derived from $id
<whitequark[cis]>
cr1901: in the original revision of the RFC, `$id` was not required, and the annotation name was the unique human readable identifier, tied to a *domain*, like a Java package name
<cr1901>
"An Annotation name should be retrievable from the "$id"" etc etc
<jfng[m]>
i think it is mainly here to be more readable than an URI, at the cost of being non-unique (because versions aren't included)
<cr1901>
ahhh
<whitequark[cis]>
jfng: I think we should just use the URI
<whitequark[cis]>
the benefit is clear and the readability improvement is marginal at best (I actually think the URI is a bit more readable since it includes the vendor domain as-is. DNS domains are backwards but it's way too late to fix that)
<whitequark[cis]>
this also addresess Wanda's concern, since the URI would be free-form now
<jfng[m]>
using an URI has the added benefit of loosening our conventions
<jfng[m]>
yeah
<jfng[m]>
was going to say that
<whitequark[cis]>
we can leave the existing text in as a recommendation rather than requirement
<tpw_rules>
i think it should be defined as "the contents of the $id field" and then have the "$id" defined as a valid URI with a recommended convention
<whitequark[cis]>
and add a short note that schema versioning can be decoupled from package versioning
<tpw_rules>
in case the format of $id gets expanded later
<jfng[m]>
this also removes some Amaranth-isms that downstream tool have to deal with when validating schemas
<galibert[m]>
Can we have a example that shows how the metadata is intended to be used, if only to put it in a file? I have this feeling that I am missing something
<whitequark[cis]>
galibert: there is an example in the RFC
<tpw_rules>
ah i see, names are used as the annotation key
<whitequark[cis]>
zyp: re metadata on shape-castables, there will be an interface/members/<name>/annotations key with the metadata for those
<zyp[m]>
yes, that's how I understood it, that sounds good
<whitequark[cis]>
and presumably lib.data will come with predefined annotations
<galibert[m]>
We don't need that kind of mechanism just to get at the signature of a top-level elaboratable to publish it to external verilog
<cr1901>
(The remaining two RFCs are merges from me, and "merge where $id is unique identifier" for me/get rid of the name field. I need to go for a bit.)
<whitequark[cis]>
galibert: there are two mechanisms at play in this RFC
<galibert[m]>
Listening
<whitequark[cis]>
the first one is a canonical serialization of the signature of the elaboratable to JSON, which is something that you do need if you want to talk to tools which are not a part of Amaranth
<galibert[m]>
Yeah, that makes perfect sense
<galibert[m]>
No problem whatsoever about that
<whitequark[cis]>
the second one is the ability to add arbitrary additional payload next to this serialization
<whitequark[cis]>
Amaranth SoC will use this to publish memory and register maps
<galibert[m]>
Next to? Does that mean a memory map is going to come accompanied with the signature of Decoder all the time?
<whitequark[cis]>
why would that be the case?
<galibert[m]>
Why wouldn't it be? Only Decoder knows about the memory map
<whitequark[cis]>
jfng: procedural note: "Amaranth issue" does not point to a PR, it points to a tracking issue
<jfng[m]>
should there be a tracking issue for an RFC and its implementation ?
<whitequark[cis]>
yes, once the RFC is accepted
<jfng[m]>
ok
<whitequark[cis]>
jfng: actually, I have a major concern about the RFC
<whitequark[cis]>
did we not decide that memory maps should be attached to Interface, not Signature?
<galibert[m]>
We did
<whitequark[cis]>
in that case, how would this RFC or its implementation even work for Amaranth SoC?
<jfng[m]>
oh
<jfng[m]>
yeah, that happened in the meantime
<whitequark[cis]>
we can't require the presence of a .annotations property on every interface object, I think
<whitequark[cis]>
but we can have a def annotations(self, interface) method on Signature which does the same thing (but now has access to the interface
<jfng[m]>
hmm
<whitequark[cis]>
as usual, Signature acts as a faux-type
<galibert[m]>
what's wrong with having a annotations attribute on the elaboratable?
<jfng[m]>
yeah, i think this works
<galibert[m]>
Especially now that Component can generate the signature-ish part of it?
<zyp[m]>
galibert[m]: non-elaboratable interfaces can also have annotations
<zyp[m]>
I think the signature method sounds reasonable
<galibert[m]>
zyp: example?
<whitequark[cis]>
a WishboneInterface would have an annotation containing its memory map
<galibert[m]>
What's a WishboneInterface?
<whitequark[cis]>
the memory map is not a property of the elaboratable, it is a property of the particular interface through which the elaboratable is used
<galibert[m]>
(very serious question, I'm lost there)
<whitequark[cis]>
amaranth_soc.wishbone.Interface
<jfng[m]>
amaranth_soc.wishbone.Interface
<zyp[m]>
the thing is that the annotations can't be on the signature, since it's immutable, and it's inconvenient to have it on every interface since that's an arbitrary type with a signature
<galibert[m]>
Every .bus on any component would have a memory map?
<jfng[m]>
may, as it is not required (e.g. for a bus initiator interface)
<zyp[m]>
so the solution of having a method on the signature that knows how to interpret mutable data stored in the interface instance sounds good
<jfng[m]>
yeah, it is a similar pattern as our ComponentMetadata class, that nows how to introspect a component to extract its metadata
<jfng[m]>
knows*
<whitequark[cis]>
galibert[m]: if you use Amaranth SoC, it is the intent that (with or without this RFC) every .bus where it's feasible has a memory map
<whitequark[cis]>
that fact is a motivation for this RFC
<galibert[m]>
Ok, let's say I have a cpu core with internal memory-mapped registers who wants to publish the memory map of those registers, connected to a Decoder with a series of components at various addresses, some of those components have an internal CSR map. I have the a top-level-ish component wrapping all that, how do I get the different maps?
<galibert[m]>
To give to the firmware writer
<zyp[m]>
the benefit of having a memory map on anything with a bus is that you'll have metadata even when you just export a single core
<whitequark[cis]>
the Amaranth meeting is concluded. we have discovered significant a issue with RFC #30 and we'll revisit it next Monday provided it's amended by then
<zyp[m]>
as you connect together stuff, a bus interconnect would collect all the downstream memory maps, merge them with offsets and present it upstream
<galibert[m]>
It would?
<jfng[m]>
it does (minus the issue that arised since memory maps were moved to interfaces; that we just addressed)
<galibert[m]>
where, how, when?
<whitequark[cis]>
Amaranth SoC already implements all that
<whitequark[cis]>
in fact it has implemented that since like 2019
<whitequark[cis]>
as the memory map handling code has been one of the first things I designed for it
<tpw_rules>
so a consumer would have to crawl it recursively
<galibert[m]>
That's... picking up the components csr-derived internal memory maps? They're in origin.windows()?
<jfng[m]>
yes
<galibert[m]>
And if I have a cpu core with a Decoder for its internal memory-mapped registers, and the rest of the code adds an Arbiter (for dma) under it and a Decoder (for the map) under the arbiter the cpu core will have a way to delegate the memory map request to its Decoder, and the Decoder to go pick up the second decoder's map under the arbiter?
<jfng[m]>
i didn't understand the part of the sentence after "and the rest of the code ..."
<galibert[m]>
ok, lemme try again
<galibert[m]>
you have an execution core which initiates a bus. On this bus it puts a decoder with its internal registers and an open window for "external comms". The "external window" endpoint is what it presents to the rest of the world
<galibert[m]>
you have a head of external bus with an arbiter to allow sharing the bus between the cpu and component-initiated dma, followed by a decoder to decode the bus
<jfng[m]>
ok, i see what you mean, i think
<galibert[m]>
then you have components on the bus
<galibert[m]>
I'm not imagining overcomplicated stuff, it's what I encounter all the time when emulating socs :-)
<whitequark[cis]>
the specific use case on which we are initially focusing is being able to export peripherals for use eg from SystemVerilog, and importing eg SystemVerilog peripherals for use in an Amaranth SoC
<jfng[m]>
no, it wouldn't work as of now, because memory maps are not forwarded in Arbiters
<jfng[m]>
this is a valid use case
<galibert[m]>
Ok, I'm just asking to think of letting the door open to make that possible, eventually
<jfng[m]>
we should support this
<whitequark[cis]>
if your CPU is in Amaranth, then the thing connected to the external window is like a peripheral (it's a collection of peripherals), so you would write the metadata for it yourself (possibly by exporting it from another Amaranth module) and then generate the SVD for this in Amaranth-land, starting at the CPU itself
<whitequark[cis]>
in this case, the metadata for the CPU wouldn't really be used for anything, it's the metadata for the external stuff that will be
<galibert[m]>
Yeah, while I'm not interesting with getting outside of amaranth, I'm really interesting in documenting what's inside :-)
<galibert[m]>
s/interesting/interested/
<whitequark[cis]>
if you ship the CPU to someone else as a netlist, nothing in the component metadata would help them generate an SVD file, mainly because only Amaranth SoC at the moment can turn Amaranth SoC annotations into eg SVD
<galibert[m]>
yeah, I'm staying in "all source available, all in amaranth, nothing hidden" territory
<galibert[m]>
complexities can be added later :-)
<whitequark[cis]>
if you disregard the external stuff for the moment, then you would, inside of your CPU, grab the memory map and pass it to the SVD generator, which directly turns the JSON representation of the memory map into SVD XML (replace SVD with Rust code generator, C code generator, etc)
<jfng[m]>
regardless of this metadata RFC, we should forward the memory map of the shared bus of an arbiter to its initiators
<galibert[m]>
The cpu doesn't know how it's called, where is it, anything. It's going to have a problem naming its output in the first place
<galibert[m]>
* The cpu doesn't know how it's called, where it is, anything. It's going to have a problem naming its output in the first place
<whitequark[cis]>
if you are generating an SVD file for accessing registers from the point of view of the CPU's initiator, you have all of the information you need inside the CPU
<galibert[m]>
Yeah, but cpu cpu has no idea where it is within the design. If you have two cpus of the same type, how do you ensure the outputs don't collide?
<galibert[m]>
s/cpu/the/
<whitequark[cis]>
what does that mean?
<galibert[m]>
say you have a h8 core. You instanciate two of them in separate parts of your design. Each cpu wants to helpfully generate a svd xml output. How does it name the file?
<jfng[m]>
each cpu core would take an external parameter that would allow its built-in generator to disambiguate it
<whitequark[cis]>
I will note that file naming conventions are completely out of scope of this RFC, because it never once talks about files
<whitequark[cis]>
but yes, something somewhere in the hierarchy would know where to put these files. we don't have anything specific yet on that front, it's a bit early
<galibert[m]>
what's I'm trying to ascertain is how much support will be needed in whatever intantiates the cpu core and in whatever instantiates the whatever, recursively, to make all that usable and nice
<galibert[m]>
and bringing up things with different schemas feels... nontrivial
<whitequark[cis]>
this is not something where this RFC is relevant, I think
<jfng[m]>
our schemas are quite mild so far, compared to say prjbureau
<whitequark[cis]>
your use case does not include Amaranth exporting or importing component metadata to or from external tools; it involves generating data from just the in-memory Python design, something that is already possible without the RFC
<galibert[m]>
Not sure I understand. Exporting is "generating data from just the in-memory Python design"
<whitequark[cis]>
this RFC exists mainly to cover the case where either (a) a peripheral is written in another language but is integrated in an Amaranth SoC or (b) a peripheral is written in Amaranth but is integrated in another external SoC
<whitequark[cis]>
for this purpose, it defines a serialization of Amaranth and Amaranth SoC data structures that is readable or writable by external tools independent from the Amaranth project
<whitequark[cis]>
you are doing neither, so the functionality of this RFC is not relevant to you
<galibert[m]>
Okay :-)
<whitequark[cis]>
the SVD generator may or may not internally use the JSON serialization defined for memory map metadata, but in any case as long as you stay entirely in Amaranth it's not something you'd have to think about
<jfng[m]>
the question of "from where do we extract the memory map(s) of a SoC" is a bit to early to answer, given that we haven't started work on our BSP generator
<jfng[m]>
we are currently focused on SoC peripherals, then we will move upwards until we get to the top-level of a SoC
<jfng[m]>
then, we will have the pieces of the puzzle to answer this question
<galibert[m]>
Board Support Package? (Pretty sure it's not binary space partitioning)
<jfng[m]>
yes
<galibert[m]>
I’ll be interested to see how it goes. I suspect some future aspects will be relevant to my interests
<jfng[m]>
nice, firefox has a built-in JSON viewer when opening application/json files
<whitequark[cis]>
iirc chrome does too
<jfng[m]>
then maybe not chromium ? iirc it just downloads the file
nyanotech has quit [Ping timeout: 256 seconds]
<whitequark[cis]>
ah hm
<whitequark[cis]>
maybe not
<zyp[m]>
IIRC I've got a chrome extension installed to prettify json
nyanotech has joined #amaranth-lang
nyanotech has quit [Ping timeout: 276 seconds]
nyanotech has joined #amaranth-lang
notgull has joined #amaranth-lang
notgull has quit [Ping timeout: 245 seconds]
notgull has joined #amaranth-lang
notgull has quit [Ping timeout: 276 seconds]
cr1901 has quit [Read error: Connection reset by peer]
<whitequark[cis]>
finally wrote docs about ResetInserter and EnableInserter
* anuejn
congratulates 🎉
<galibert[m]>
Cool, time to change it all then ;-)
<whitequark[cis]>
I actually don't imagine any of what I wrote will be affected
<galibert[m]>
Probably not
<galibert[m]>
"all of its submodules can refer to that domain under the same name" -- there may be a "by default" needed there, since you can override a name, rename it away, etc
<_whitenotifier>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 09e3df4 - Deploying to main from @ amaranth-lang/amaranth@95538a3e07e5335381b3f00c381d945de7aa86a9 🚀
<whitequark[cis]>
cr1901: by the way, while `AsyncFIFO` clearly needs to be in our stdlib, it's less clear with `SyncFIFO`
<whitequark[cis]>
can you come up with a reason that unambiguously includes SyncFIFO but unambiguously excludes CRC?
<whitequark[cis]>
* can you come up with a rule that unambiguously includes SyncFIFO but unambiguously excludes CRC?
<cr1901>
I'm thinking, but tentatively, my answer is "No, I don't have a _good_ reason to include one but exclude the other".
<whitequark[cis]>
there is basically one correct way to write a SyncFIFO and basically one correct way to write CRC; while you could potentially want a CRC with some more esoteric configuration or feature, the same also applies to SyncFIFO (we even have similar omissions, like how we don't support FIFOs with asymmetric ports)
<whitequark[cis]>
* there is basically one correct way to write a SyncFIFO and basically one correct way to write CRC; while you could potentially want a CRC with some more esoteric configuration or feature, the same also applies to SyncFIFO (we even have similar omissions, like how we don't support FIFOs with asymmetric ports that do a partial read/write, and we don't support CRC computation for partial inputs)
<cr1901>
I did have a user for a non-FWFT when I originally wrote efbutils in Verilog, but since Verilog is "what's a standard library", I was quite alright importing a FuseSoC one.
<whitequark[cis]>
in my view, we should continue to include things that have basically one correct implementation in the stdlib, provided that they meet some subjective relevance and applicability criteria
<whitequark[cis]>
but we should also be conservative about this, while not focusing on being conservative for things that are platform-dependent
<whitequark[cis]>
I think PRBSn should be included for the same reasons, and in the same style, as the CRC generator
<cr1901>
That would be interesting. I should've held off when I said "I changed my mind/I don't think CRCs should be in stdlib". I'm not sure where the boundary should be.
<whitequark[cis]>
I don't know that there can be a strict boundary
<whitequark[cis]>
if we had more people maintaining Amaranth, we could potentially include things like a 8b10b decoder
<cr1901>
I changed my mind/I don't think CRCs should be in stdlib <-- this is true to the extent that "since the CRC RFC, I read through Ross' paper completely, and am much more familiar w/ CRCs now than I was during the RFC. I need to re-review the CRC module and maybe poke agg"
<cr1901>
The "I changed my mind" was a comment I should've kept to myself :P
<cr1901>
much more familiar w/ CRC implementation now*. The math I've understood for a while lol
<whitequark[cis]>
I see
adamgreig[m] has joined #amaranth-lang
<adamgreig[m]>
having read the paper, you think it's more or less true that CRC should be in stdlib?
<adamgreig[m]>
the parameterisation of the amaranth crc is the same as in the ross paper, but the implementation is quite different from any he discusses iirc
<cr1901>
adamgreig[m]: Does CRC module do one bit at a time or a 256-entry (or more) table to process more than one bit at a time?
<adamgreig[m]>
neither, those are "software" concerns imo
<adamgreig[m]>
it does m bits at a time, configured at instantiation time