<vipqualitypost[m>
so if I write a module with it's own clock (I want to clock the module at like 100kHz but my device clock is 100MHz) I was thinking to make this sub-clock as an input to the module, but now I am struggling to find a way to simulate it. how should I handle this?
urja has quit [Read error: Connection reset by peer]
<cr1901>
(I'm guessing mutating the name fields after signal creation is an affront to nature, but I'll fix it tomorrow)
nak has quit [Quit: Bye]
GenTooMan has quit [Read error: Connection reset by peer]
GenTooMan has joined #amaranth-lang
<whitequark[cis]>
galibert: yeah. it's unclear when the warning should be raised and what to do if you do it intentionally in generated code
<whitequark[cis]>
and the general case isn't quite intractable but it's rough
<whitequark[cis]>
cr1901: what were they assigned by default? and no, mutating names is explicitly supported for cases such as this
<galibert[m]>
Yeah, I'm trying to document mu fuckups when the compiler could possibly have said something
<galibert[m]>
s/mu/my/
<galibert[m]>
Surviving the friend's move?
<whitequark[cis]>
ye
Bluefoxicy has quit [Ping timeout: 255 seconds]
<_whitenotifier>
[amaranth] cr1901 opened issue #882: Unfriendly "recursion depth exceeded" error message when forgetting `In` and `Out` on a `Component`'s signature - https://github.com/amaranth-lang/amaranth/issues/882
<cr1901>
whitequark[cis]: Give me a sec, am multitasking (badly) right now
Wolfvak has quit [Remote host closed the connection]
<cr1901>
Can you force push from GH's online Markdown editor?
<cr1901>
s/you/one/
<whitequark[cis]>
nope
<cr1901>
Okay very good, I'll check out locally. Gimme a few secs
<cr1901>
Force pushed
<cr1901>
whitequark[cis]: You asked: >what were they assigned by default? They are assigned the names "i, ack, rdy, data, \ack$1 , \rdy$2 , \data$3 , clk, rst, o"
<whitequark[cis]>
okay that's terrible
<whitequark[cis]>
this will be fixed once stdio is actually using interfaces
<cr1901>
I get "rand__addr, rand__read_en, rand__flush, rand__valid, seq__data, seq__addr, seq__ready, seq__valid, rand__data" as the ports (no clk, rst yet b/c the module is a stub)
<cr1901>
these are much better, although the double underscore bothers me
<whitequark[cis]>
consider rand__read_en
<whitequark[cis]>
without the double underscore the hierarchy represented would be ambiguous
<cr1901>
that's fair
<cr1901>
I'll get used to it :)
<galibert[m]>
those are verilog-level identifiers?
<whitequark[cis]>
yeah
<whitequark[cis]>
by the way, i want to have a CLI upstream that would replace whatever it is amgen is
<galibert[m]>
ok, that constraints the charset qui a bit
<galibert[m]>
quite a bit
<cr1901>
whitequark[cis]: amgen is a base class for generating a fusesoc core on-the-fly. It'll be a while before I rip fusesoc out.
<whitequark[cis]>
I'm thinking of eventually using mangled names, actually
<whitequark[cis]>
C++ style
<whitequark[cis]>
(maybe even literally C++?)
<whitequark[cis]>
cr1901: we actually want to have fusesoc core generation upstream
<whitequark[cis]>
it would make Amaranth cores potentially a lot more popular
<galibert[m]>
Catherine: As long as it's not dns-style :-)
<whitequark[cis]>
dns-style?
<galibert[m]>
yeah, the insane encoding to have full unicode in the legacy all-ascii dns
<whitequark[cis]>
yeah, so, the idea is to have an amaranth CLI command that lets you parameterize and generate Verilog from an arbitrary Amaranth componen
<josuah>
which does not require any bit of SpinalHDL on the host using it
<whitequark[cis]>
sorta?
<cr1901>
Would the user have to deal with mangled names when importing a Verilog-generated amaranth core into their design?
<whitequark[cis]>
I'm thinking of installing the requirements for the core in any way you like (they're described using the standard pyproject.toml file) and then running amaranth generate my_design.MyCore --width 16 or something like that
<whitequark[cis]>
* I'm thinking of installing the requirements for the core in any way you like (they're described using the standard pyproject.toml file) and then running amaranth generate my_design.MyCore --param width 16 or something like that
<cr1901>
(Right now I'm replacing every Verilog module to Amaranth one-at-a-time. If the demo still works after each replacement, move on to the next component. Otherwise, debug :).)
V has quit [Ping timeout: 240 seconds]
<cr1901>
Oh and lastly, is "ios = [m.rand.data, m.rand.addr, m.rand.read_en,...]" currently the correct way to construct a list of ios for verilog.convert, or is there a way to extract a flattened list of signals all at once from an interface object?
<whitequark[cis]>
hm.
<whitequark[cis]>
so this was a part of the RFC that got cut
<cr1901>
That's fine. Just wanted to make sure I wasn't missing anything
<whitequark[cis]>
oh, no, wait, it was a slightly different one
<whitequark[cis]>
but I agree anyway, this would be valuable
<whitequark[cis]>
I'm not sure how to expose it or even if we should
<whitequark[cis]>
here's an idea: we make interfaces legal in ports=[...]
<cr1901>
So you'd pass the Module() twice into verilog.convert()? (i.e. verilog.convert(m, ports=m))
<cr1901>
PageBuffer meets the requirements of an interface object
<whitequark[cis]>
oh yeah you're right, this is weirdly redundant
<whitequark[cis]>
PageBuffer is a component or has a signature, right?
<cr1901>
yes, it's a component
<whitequark[cis]>
then how about verilog.convert(m)?
<whitequark[cis]>
that seems sufficient
<whitequark[cis]>
and then we deprecate ports
<cr1901>
That works fine for me if you can get it to work
<whitequark[cis]>
it's straightforward
<cr1901>
yes, I'm fine w/ deprecating ports too
<galibert[m]>
deprecating ports essentially means making interfaces mandatory, no?
<whitequark[cis]>
can you file an issue for that?
<galibert[m]>
(not that I would have an issue with that)
<whitequark[cis]>
galibert[m]: sorta?
<cr1901>
Will do. And I'd rather hear from others re: deprecating ports. I'm fine with that.
<whitequark[cis]>
the reason i'm happy to do it in the backend is because the backend is its own thing
<whitequark[cis]>
if you really hate lib.wiring you can make a wrapper that makes up a signature based on whatever you want
<whitequark[cis]>
but if we mandated that for every Elaboratable you couldn't
V has joined #amaranth-lang
<cr1901>
If other ppl have their reasons to not use lib.wiring I'd also be okay with if (psuedocode) isinstance(Elaboratable): "look at the ports argument", ifinstance(Component) or getattr(signature): "make sure ports argument is None/unused".
<cr1901>
(psuedocode) if isinstance(...*
<cr1901>
Will file issue in a second
<whitequark[cis]>
for the time being ports=[] will remain in existence, just deprecated
<cr1901>
ack
<whitequark[cis]>
not sure if this needs an RFC. adding an optional introspection for the component if it's used doesn't
<whitequark[cis]>
a deprecation? i think it's fine, considering how the meetings re: lib.wiring went
<cr1901>
should I still file an issue then (writing it up now)?
<whitequark[cis]>
yes please
<whitequark[cis]>
I'll bring it up on the meeting (Monday after tomorrow)
<cr1901>
Ack. This code base is small enough that it can evolve w/ Amaranth (once porting all the components is done). I'm glad the Verilog works, but I've had too many "holy hell, I hate this" moments while extending it. So time to port.