<awygle>
huh so Elaboratable doesn't actually do anything other than the must use warnings? interesting
<whitequark>
that's its only purpose
<whitequark>
the thing is that in migen it was very common to forget to hook up a module to a design somewhere
<whitequark>
and then spend hours debugging it
<awygle>
I expected it to at least require me to implement elaborate somehow
<awygle>
Although that does of course get caught in another way
<awygle>
And I kind of expected a lot of the stuff that lives in fragment to be inside Elaboratable somehow
<whitequark>
awygle: right so it is possible to derive from ABCMeta
<whitequark>
well, use a metaclass for ABCMeta
<whitequark>
er
<whitequark>
ok you know what I'm asleep at the wheel
<whitequark>
let me finish this sentence and discuss the rest tomorrow
<whitequark>
it's possible to use ABCMeta as metaclass and declare elaborate as an abstract method
<awygle>
sure, ttyt
<whitequark>
however, the idea behind Elaboratable originally was that it would be very lightweight and not impose undue burden on user classes
<awygle>
(Elaboratable does have ABCMeta as the metaclass)
<whitequark>
yeah, that's a mistake in the initial commit I think
<whitequark>
I initially used ABCMeta as a metaclass and then decided against it
<whitequark>
because what if use code wants to use a different metaclass?
<whitequark>
e.g. in case it does some weird metaprogramming
<whitequark>
and I think I just forgot that `metaclass=ABCMeta` in
<awygle>
mm I see
<whitequark>
anyway, I'm not sure how it really should go, you could make a case for either
<whitequark>
it's not super important to check that there's an elaborate method because it's just one method (not a bunch of them like in most interfaces) so if you forget it?
<awygle>
I mean what we have works now
<whitequark>
then the first time you actually use the elaboratable it'll break loudly
<awygle>
So nbd
<awygle>
Well I was gonna ask you some stuff but you're sleeping. So, manana it is
<whitequark>
weird UART from 2001 unlike anything else i've seen
<whitequark>
except our FXMAs except why would anyone intentionally make their UART worse
<awygle>
huh. I'm far from certain but it makes me think of LIN which is kind of like a multi drop UART...
<Ultrasauce>
the other kind of return to zero coding
<whitequark>
yeah that's the current best hypothesis
<whitequark>
so weird
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #nmigen
<awygle>
i am going to count that result as "i was right" lol
<awygle>
not to dimish the value of the proof
<awygle>
oh _wow_. i can't believe i just got caught on `sig > 0 | othersig` reducing to `sig > othersig`.
<awygle>
i'm usually so paranoid about order of operations.
<awygle>
plz fix operator precedence in a half dozen languages so my intuition matches reality kthx
<cr1901_modern>
Galaxy brain: You don't have to learn operator precedence if you use gratuitous parentheses
<awygle>
that's what i _usually_ do
<awygle>
and then let clippy remove the useless ones :p
<awygle>
man i wrote some C the other day and apparently i've been writing more Rust than i thought because i kept forgetting the parentheses after `if` >_>
thinknok has joined #nmigen
Guest30583 has joined #nmigen
chipmuenk has joined #nmigen
Asu has joined #nmigen
proteus-guy has quit [Ping timeout: 265 seconds]
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
proteus-guy has joined #nmigen
Stary- is now known as Stary
<awygle>
Morning
<ZirconiumX>
Afternoon
thinknok has quit [Ping timeout: 260 seconds]
thinknok has joined #nmigen
thinknok has quit [Ping timeout: 256 seconds]
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
ademski has joined #nmigen
thinknok has joined #nmigen
<awygle>
would it be better to bikeshed ILA design here or on github
<awygle>
also, does anyone want to bikeshed ILA design with me
thinknok has quit [Ping timeout: 256 seconds]
<whitequark>
here
<whitequark>
we can then do a GH RFC
<awygle>
ok cool
<awygle>
so here's where i am currently
<awygle>
it's fairly easy to add a "get ila" method to platform, add sampling ports in different clock domains, set up triggers, etc
<awygle>
i think this design might require flattening, which is not ideal but probably not a dealbreaker?
<whitequark>
flattening? why?
<whitequark>
you can't flatten in nmigen anyway, not with the current design
<whitequark>
(it looks like it'd work but it would break clock domains)
<awygle>
because (the way i have it prototyped) you end up with an ILA module as a submodule of the top module that has tentacles to all the other submodules
<awygle>
so i assumed it would get flattened by yosys
* ZirconiumX
's mind just read "tentacles" and got confused
<whitequark>
yosys always flattens but the whole point of nmigen is that it supports hierarchical designs
<whitequark>
if you had to flatten the design each time you use a signal deep in the hierarchy nmigen would have been useless for that
<awygle>
i think from the nmigen perspective it shouldn't be required
<whitequark>
why would it be required from synthesizer's perspective?
<awygle>
what is the warning about "driven from multiple submodules, flattening" about then?
<whitequark>
exactly what it says on the tin
<whitequark>
you can use a signal from howver many submodules you want if exactly one of them is driving the signal
thinknok has joined #nmigen
<awygle>
admittedly in this case we're not driving but i guess i assumed it would round to the same thing
<awygle>
ah ok
<awygle>
well nvm then
<whitequark>
no
<whitequark>
it's like processes in verilog
<awygle>
i see
<whitequark>
... it specifically says "driving" to make it unambiguous :/
<whitequark>
ah well
<awygle>
i think i was applying too muhch software intuition
<awygle>
sorry
<whitequark>
makes sense
<awygle>
anyway. there needs to be a way to deal with the _output_ of the ILA module
<whitequark>
anyway, a design where a toplevel module has its uhm, tentacles, all over the design is 100% OK
<awygle>
and idk how to handle that best, because you kind of have to let the user configure it
<awygle>
so it's not as transparent
<awygle>
maybe that's fine, idk
thinknok has quit [Remote host closed the connection]
<awygle>
but we could add a "default ila output" thingy to the platform a la "default clk"
<whitequark>
so there are two basic operations with an ILA
<whitequark>
first, you add probes
<whitequark>
second, you add a sink
thinknok has joined #nmigen
<whitequark>
without a sink the probes should be no-op so you don't have to rejig your design if you want a debug build
<awygle>
yes, i did that
<whitequark>
this means that when you're adding a sink (something like `platform.get_analyzer_sink()`?) you get an interface through which you can drive it
<whitequark>
and the code which requests a sink can use that interfac
<awygle>
right
<awygle>
so the way i have it right now, in platform.build, there's a new kw argument which is `use_ila` and defaults to False
<awygle>
and if it's set to False then the ILA probes do nothing
<awygle>
i was thinking of extending that to the sink as well
<awygle>
so you can enable/disable the whole ILA
<awygle>
(name bikeshedding TBD)
<whitequark>
no new kw arguments, I think
<whitequark>
if you request a sink you get an ILA, if you don't you don't
<whitequark>
there's no need for another moving part
<whitequark>
it's like with pins
<awygle>
hm, i feel like i often want to remove _all_ ILA stuff, without changing my source?
<whitequark>
sure
<awygle>
but maybe that's a holdover from tools like diamond
<whitequark>
if you don't request a sink, the probes won't be emitted at all
<awygle>
but the "request a sink" is in the source
<awygle>
isn't it?
<whitequark>
oh I see
<whitequark>
the difference as I see it is that probes are designed to be as noninvasive as possible (of course on real devices they can't be 100% noninvasive but we try to pretend they are)
<whitequark>
but a sink isn't because you hook it up to real pins
thinknok has quit [Ping timeout: 260 seconds]
<whitequark>
(or wherever else in your design you connect a sink to)
<awygle>
as a counterexample, imagine a sink which was accessed over JTAG
<tpw_rules>
um
<whitequark>
sure, that's a corner case where connecting a sink is almost completely noninvasive
<whitequark>
(it's not completely noninvasive because the JTAG internal port primitive is unique)
<whitequark>
but it seems to me that in general this isn't true, and a design with or without ILA has nontrivial differences in behavior
<whitequark>
on ice40 you don't even have JTAG
<whitequark>
anyway, what i'm trying to say is that I think it's better to make this choice explicit by the designer
<whitequark>
you can still have `use_ila`, but it'll be in the module that instantiates the sink, probably in the toplevel one
<awygle>
hm. i guess my opinion here is just different. ideally the ILA sink stuff won't (in most cases) connect to anything else in the design and can be removed wholesale. but i'm not married to that approach, i think an `enabled` kwarg on the sink-getter works fine
<awygle>
(it would default to true of course)
<whitequark>
why would you need an enabled kwarg? you just don't request a sink if you don't need it
<whitequark>
the design with an ILA sink is a different design, we shouldn't pretend it isn't
<awygle>
ok let me describe an example scenario
<awygle>
i am writing a DDR2 controller, and i want to introspect that module. i hook up the ILA. in my top module, i request the ILA sink. i only have a UART on this board, so i need to hook the ILA output up to something that frames it for transport over the UART. fortunately i have a nice formally-proven SLIP module to do just that, so i hook the sink up to it and the output of the SLIP module up to some pins.
<awygle>
now i want to check my DDR2 controller's resource usage, so i want to remove the ILA bits. in my scenario, i change `enabled = True` to `enabled = False`. in your scenario i comment out the `get_sink` call... but there's also the code that connects the sink to the SLIP module. so i have to change that code _as well_
<awygle>
does that make my concern clearer?
<whitequark>
yes
<whitequark>
my idea for that is that you'd always leave the probes in
<whitequark>
and unless a sink is requested at some point, there would be no code generated for them in the first place
<whitequark>
does that work for you?
<awygle>
that doesn't address what i described above though
<awygle>
i want to leave the sink in too, so i can easily toggle back and forth between "yes ila" and "no ila" versions
<awygle>
without having to remove all the sink-to-pin infrastructure
<whitequark>
i don't understand why is that desirable
<whitequark>
you want to have the probes, and the sink, but not the connections between them?
<whitequark>
why?
<awygle>
i want to have the probes and the sink _in the nmigen source code_, but _not_ in the synthesized netlist, if i pass `enabled=False`
<whitequark>
so you want to take one condition guarding `m.submodules += UARTAnalyzerSink(platform.request_analyzer_sink())` out of your own code and put it in the shared nmigen platform code
<whitequark>
why?
<awygle>
because i envision that line being multiple lines, i guess? i don't agree that making those changes in my own code will always be as simple as you seem to believe it is
<whitequark>
then does that point to some other problem that makes this functionality hard to implement in your own code?
<whitequark>
because it seems to me that it ought to be easy to disable parts of the design like that, and if it isn't, we're screwing up somewhere
<awygle>
not a problem per se, just that we don't know what the user will want between their analyzer sink and the pins
<awygle>
for example, maybe they want to multiplex it with some other data stream
<awygle>
the potential complexity is unbounded because it's user-controlled
<whitequark>
yes, that's exactly why i'm arguing that it should be decided by the user code, ultimately
<awygle>
i agree with that but want to preserve easily disabling it
<whitequark>
an `enable` kwarg brings nothing to the table fundamentally (it replicates functionality nmigen already provides by virtue of having metaprogramming) and it restricts user code to the simplest possible enable logic
<whitequark>
so it seems to me that it only has downsides
<awygle>
why does it restrict user code to the simplest possible enable logic?
<whitequark>
well, you get one boolean passed from platform, that's it
<whitequark>
and you have to decide with just that
<awygle>
i think we're talking about different designs. i think the best way to fix that is if i prototype what i'm describing and show it to you, because i'm not doing a good job explaining what's in my head.
<whitequark>
sure
<whitequark>
juts to be clear, my view on the platform ILA bits is that the platform should do exactly the things that can only be done by platform, and nothing more
<whitequark>
at least for the initial implementation
<whitequark>
we can always add features, but we can't easily remove them if it turns out that was a bad idea
<awygle>
i don't disagree with that at all. it's possible that i don't fully appreciate what powers the platform has that user code doesn't and vice versa, though.
<whitequark>
ah, okay
<whitequark>
so the thing the platform can do that user code can't is to do something after all of the user code has been elaborated
<whitequark>
it can collect the probes and the sink (if any) while it's elaborating and once that's done, make a judgement on whether it should emit the ILA interconnect or not
<awygle>
mhm
<awygle>
ok so i do understand then, mostly
<whitequark>
user code can't do that because you can always stuff an elaboratable into another and add a probe that won't end up hooked anywhere
<awygle>
mhm
<whitequark>
it can also let people leave probes in third party code so you don't need to e.g. modify nmigen-stdio sources to trace the cores in it
<whitequark>
(we should probably have some mechanism for selecting probes by hierarchy or even by glob)
<whitequark>
but sink insertion is fundamentally a job of first party code because a first party is debugging it
<whitequark>
so it doesn't need to be done by the platform
<awygle>
arright well i'll put something up that demonstrates the interfaces i have in mind in the next couple days (probably without any actual bones yet) and we can talk about that. i think there are still a few fundamental design questions - yes that is exacctly one of them (selecting probes) - to discuss but we should figure out this bit first i think
<whitequark>
we can add configurable sink insertion later if it turns out people do in fact reinvent the same thing over and over
<whitequark>
but i don't think we should add it at first
<whitequark>
the best argument in favor of your proposal I can think of is that it would let us have a more standardized toplevel interface, which is something emily was rightfully arguing in favor of
<whitequark>
toplevel interface as in CLI
<awygle>
ah, yes, that is true
<whitequark>
but we don't have that yet, so it's a bit design in the future tense
<awygle>
mhm
<whitequark>
anyway. i don't think we shouldn't use your suggestion. i just think we shouldn't use it yet
<whitequark>
let's ship an MVP then add it if it's handy
<awygle>
that's fair, i just want to make sure that my suggestion is properly communicated first
<whitequark>
sounds good
<awygle>
it's an easy removal from the prototype code if you still don't like it
Guest30583 has quit [Quit: Nettalk6 - www.ntalk.de]