peeps[zen] has quit [Remote host closed the connection]
peeps[zen] has joined #amaranth-lang
Degi has quit [Ping timeout: 256 seconds]
Degi_ has joined #amaranth-lang
Degi_ is now known as Degi
peeps has joined #amaranth-lang
DX-MON has quit [Quit: I'm not disconnecting, you're disconnecting!]
DX-MON has joined #amaranth-lang
peeps[zen] has quit [Read error: Connection reset by peer]
peeps is now known as peeps[zen]
<tpw_rules>
ugh modern leds are too good. i'm blinking a status led at 50% duty cycle and 25KHz period and the visible brightness is literally indistinguishable from a 100% on led next to it
<whitequark[cis]>
I've participated in the development of this RFC, so I don't have any significant concerns about it; let's hear what others think of the general approach first
ravenslofty[m] has quit [Quit: Idle timeout reached: 172800s]
<cr1901>
This seems useful for having well-defined fusesoc integration. I don't have any complaints, I'm not sure I'm going to use this.
<whitequark[cis]>
the CLI is likely to consult the annotations, eventually
<whitequark[cis]>
anyone else?
zyp[m] has joined #amaranth-lang
<zyp[m]>
there ought to be a way to pick up annotations on a Component
<jfng[m]>
zyp[m]: annotations can be attached to the signature of a component
Chips4MakersakaS has joined #amaranth-lang
<Chips4MakersakaS>
How generic do you expect the Annotations to be; are there other use cases than describing optional protocol variants ?
<whitequark[cis]>
Chips4Makers (aka Staf Verhaegen): Amaranth SoC is expected to heavily use annotations, such as to describe the SoC memory hierarchy, registers, and so on
<jfng[m]>
Chips4MakersakaS: you can use annotations to exchange constants, such as the FIFO depth of a flash controller
<jfng[m]>
that may be of use to software
<zyp[m]>
jfng[m]: yes, I'm thinking for components that pick up the signature implicitly from `In`/`Out` members
<Chips4MakersakaS>
whitequark[cis]: Is it going to superseed MemoryMap ?
<whitequark[cis]>
Chips4Makers (aka Staf Verhaegen): no. MemoryMap is the Python representation of the memory map, and an Annotation is what converts it for consumption elsewhere
<jfng[m]>
zyp[m]: you mean, of a signature created from variable annotations ? this is also possible, but the user will have to override `Component.signature` to attach an Annotation object to the newly created Signature
<jfng[m]>
Chips4MakersakaS: i have good hope that this will obsolete the `ConstantMap` feature in amaranth-soc, that is barely used anyway
frgo has joined #amaranth-lang
<jfng[m]>
whitequark[cis]: exporting the contents of an amaranth-soc `MemoryMap` (e.g. register addresses) is one of the motivating use cases of this RFC
<cr1901>
so it can be convered to e.g. SVD?
<zyp[m]>
maybe it'd be helpful to have an example of that added to the RFC
<whitequark[cis]>
yes
<jfng[m]>
zyp[m]: can do, i just didn't want it to be too amaranth-soc specific
<zyp[m]>
would the MemoryMap annotation be attached to the associated memory interface or the component itself?
<jfng[m]>
the memory map annotation is attached to the signature of a bus interface
<jfng[m]>
i have a prototype of this for amaranth-soc, hang on
<cr1901>
Yea, my feedback is "no complaints, looking forward to seeing how others use this feature to guide how I use it"
<whitequark[cis]>
zyp: re: annotations on Component: there is a bit of a type/value level split going on here. in `lib.wiring`, annotations go on signatures, not on interface objects (since they are annotating the type of an interface object)
<whitequark[cis]>
so you're supposed to be able to make assertions about an interface object without actually having that object (e.g. because it only exists in netlist form)
<zyp[m]>
so I suspect most annotations will be attached to specific interfaces and not components themselves, but if we envision having annotations on components at all, it'd be good to pick them up implicitly on components with implicit signatures
<whitequark[cis]>
I think that by the time you are building reusable objects with well-defined interfaces you should already have an explicit signature class defined, whatever it is you're building
<whitequark[cis]>
it's not a huge burden and it means that the signature of your component can be instantiated without instantiating the component itself, which is desirable
<whitequark[cis]>
consider where the documentation would go: it would have to be the signature class
<whitequark[cis]>
in that way, the lack of annotations on components is intentional
<whitequark[cis]>
I expect that ComponentMetadata might grow other properties (not related to annotations), like: name, author, version, git hash, copyright, anything else that e.g. a block diagram editor might want to know about a specific instantiated netlist
<whitequark[cis]>
an "annotation" is basically a "part of a type (in an abstract sense, not specifically Python type) of an interface object"; the name is kind of generic but I figured this was one of the best possible options
<cr1901>
Are two signatures w/ different annotations considered compatible for connect?
<whitequark[cis]>
i.e. so long as the signature and annotations all remain the same, you can keep the entire rest of your system while changing the netlist of the component with that signature and annotations
<whitequark[cis]>
cr1901: yes
<whitequark[cis]>
> should the version appear somewhere in the name ?
<whitequark[cis]>
no, I think it's OK to have it in the $schema field. having that lets consumers disambiguate different schemas if they *need* it, while letting everyone else be somewhat lax about names because most changes will be backward compatible and not require many consumer changes
<whitequark[cis]>
if we make versions appear in the name it will just mean everyone uses name.startswith() or a regex (both bad options) to compare instead of ==
<whitequark[cis]>
also, we can always start using versions in the name later.
<whitequark[cis]>
e.g. append an implicit ".v0" to anything that does not already have a ".v\d+" added or something. I think we probably do not need to aggressively version annotations, it is better to focus on preserving backwards comat
<whitequark[cis]>
s/\/\\/, s/comat/compat/
<whitequark[cis]>
re SVD: I think Amaranth-SoC should have code for bidirectional conversion with SVD
<jfng[m]>
yes, this is something we'll consider when working on BSP generation, and maybe earlier even
frgo_ has joined #amaranth-lang
<whitequark[cis]>
oh, another minor comment:
<whitequark[cis]>
- the RFC should explain how annotation names should be picked. namely that they should begin with a second level domain name registered to whoever is defining the annotation/schema, and which can be gleaned from the schema URL
<whitequark[cis]>
i.e. if the schema lives on https://amaranth-lang.org/whatever, the annotation name would start with org.amaranth-lang. we should probably enforce it. we can't really check that the schema is always live, so people who want to flaunt the rules can always use an arbitrary nonexistent domain in both cases
<jfng[m]>
as in, GET the schema as part of our CI ?
<cr1901>
What if you don't own a domai- ahhh
<whitequark[cis]>
no no, just check that the domain of the URL is the same (part-reversed) as the beginning of the schema name
<jfng[m]>
yes, we can do that
frgo has quit [Ping timeout: 256 seconds]
<jfng[m]>
as you may also have noticed, the RFC doesn't cover clock/reset signals
<jfng[m]>
which are going to be needed before it is acceptable, imo
<whitequark[cis]>
can you tell more about clock/reset signals here?
<jfng[m]>
i would like to include them in the "interface" section of the metadata
<whitequark[cis]>
I think this is already very useful, and in addition I'm not sure if we can easily add clock/reset handling at this moment, given that clocks and resets are still pending some changes that will happen in near future
<whitequark[cis]>
one problem is that in Amaranth, you cannot currently know the domains until you elaborate the design to a netlist
<jfng[m]>
their absence limits the RFC's usefulness for mixed HDL
<whitequark[cis]>
I agree
<whitequark[cis]>
my view is that we can start out with "okay, we define, by fiat, that every module has posedge clock clk and synchronous reset rst", which means mixed HDL usage is possible
<whitequark[cis]>
this is often true in even fairly complex designs that can have multiple levels of AHB, APB, etc buses
<whitequark[cis]>
yes, it is limited, but the interface library itself would have to be extended to handle multiclock designs well
<whitequark[cis]>
probably with an ability to associate in/out ports with clocks
<whitequark[cis]>
this is a major undertaking and I'm not sure we have the resources or the knowledge for doing it right now
<zyp[m]>
I also think it'd make sense to defer it to a later RFC, since there's natural extension points where it can be added later
<whitequark[cis]>
I expect we will basically have foo : In(1, domain="comb") / foo : In(1, domain="sync") (aside from "no domain specified" which retains current behavior), and then we'll have to extend everything else to actually enforce that
<whitequark[cis]>
the exact semantics of that "domain" argument is actually pretty tricky to capture
<whitequark[cis]>
because really what you are working with is a number of paths, which can have sync capture, sync drive, or comb from point to point
<jfng[m]>
so we'd hardcode`"clk": { "type": "port", ... }, "rst": ...` to every component metadata instance ?
<whitequark[cis]>
no, just leave it out entirely for no
<whitequark[cis]>
s/no/now/
<jfng[m]>
ok
<whitequark[cis]>
you don't actually know that these will be the ports that are present
<whitequark[cis]>
e.g. a comb only module would not have them
<whitequark[cis]>
imagine a block diagram designer, with this proposed implementation it could connect all clk/rst ports together 'blindly'
<whitequark[cis]>
and then add multiclock support later
<jfng[m]>
yeah, i guess that arbitrary clock/reset support would make for a substantial RFC in itself
<whitequark[cis]>
yes
<cr1901>
Implicit (lack of) clk is fine w/ me for now
<zyp[m]>
collecting metadata from multiple components, is that out of the scope for this RFC?
<jfng[m]>
i assume you mean, independent components ? if so, yes it is out of scope
<whitequark[cis]>
I imagine a CLI would let you specify a list of components potentially
<zyp[m]>
as in, if I wanted to export a json file of the whole design hierarchy during build
<jfng[m]>
you may pass annotations originating from submodules (e.g. memory maps), but this RFC only covers the interface of the top-level component in the metadata
<zyp[m]>
right, makes sense, it's interface metadata, not hierarchy metadata
<whitequark[cis]>
zyp[m]: that doesn't seem all that useful
<zyp[m]>
having a json with the component hierarchy, their subinterfaces and how they're connected would make it easy to e.g. have graphwiz consume it and make a rough block diagram of how stuff fits together
<zyp[m]>
especially if you filter it for interface types like memory buses or streams
jjsuperpower has joined #amaranth-lang
adamgreig[m]1 has quit [Quit: Idle timeout reached: 172800s]
<jfng[m]>
<zyp[m]> "so I suspect most annotations..." <- as an observation, the gateware i write tends to be parameterized (e.g signal widths), and therefore their signature cannot use variable annotations; i'm starting to believe that components which can use variable annotations are the exception more than the norm
qookie has quit [Remote host closed the connection]
qookie has joined #amaranth-lang
nelgau has quit [Ping timeout: 260 seconds]
<whitequark[cis]>
<jfng[m]> "as an observation, the gateware..." <- yeah, these are intended for a quick creation of simple components
galibert[m] has joined #amaranth-lang
<galibert[m]>
what's a variable annotation?
<jfng[m]>
`foo: unsigned(1)`
scipoly has joined #amaranth-lang
<jfng[m]>
(which is a bit confusing, as we were also talking about metadata `Annotation`s in this meeting)
<galibert[m]>
Ah, that would be foo: In(unsigned(1)) in this case, right?
<jfng[m]>
right
<galibert[m]>
I'm surprised that all your components are parametrized. All your elaboratables have a signature, right?
<jfng[m]>
yeah
<galibert[m]>
I guess you plonk everything on a bus then
<galibert[m]>
I don't remember minerva to be parametrizable for instance though
<jfng[m]>
it is: the signature may change if you add the riscv-formal interface
<jfng[m]>
(though the public version doesn't use components, yet)
<galibert[m]>
ahhhhh
<jfng[m]>
also, the ibus/dbus may not need CTI/BTE if you don't have a L1 caches, etc
frgo_ has quit [Remote host closed the connection]
frgo has joined #amaranth-lang
frgo has quit [Ping timeout: 256 seconds]
<cr1901>
jfng[m]: I should've brought this up at the SoC meeting, but... is there any provision for wishbone tags in -soc?
frgo has joined #amaranth-lang
frgo has quit [Ping timeout: 255 seconds]
<jfng[m]>
not atm, e.g TGA/TGC signals are missing