revolve has quit [Read error: Connection reset by peer]
revolve has joined #nmigen
<FL4SHK>
I think I'll be able to get everything I need to do done in nMigen
<FL4SHK>
but I'll also continue developing the custom HDL I had in mind
<whitequark[m]>
neat!
<FL4SHK>
I think SV interfaces are one of the best features in an HDL I've ever seen
<whitequark[m]>
nmigen is a fairly conservative language, and i'm always excited to see HDLs exploring new areas
<whitequark[m]>
yes, nmigen really needs something like SV interfaces
<whitequark[m]>
it'll happen eventually
<FL4SHK>
can you include things like arrays of interfaces?
<FL4SHK>
that's one thign that apparently Vivado didn't support in synthesis for a long time
<FL4SHK>
they do support it now IIRC
<FL4SHK>
Oh, yeah
<FL4SHK>
and I'd really like something like VHDL variables in nMigen
<FL4SHK>
as well as the ability to do something like a VHDL function
<FL4SHK>
you can currently do stuff like VHDL procedures with a Python function
<d1b2>
<4o> vhdl variable = a signal in async domain
<FL4SHK>
you can't assign new values to a signal within the same clock cycle though
<FL4SHK>
variables have that property
<FL4SHK>
and it's a useful one
<whitequark[m]>
let's talk about specifics during the design cycle for interfaces
<FL4SHK>
cool
<whitequark[m]>
regarding variables, i think those would be best solved with a (probably quite small) DSL on top of nmigen, though they might eventually find their way into the core
<whitequark[m]>
i've encountered the need for them, too
<FL4SHK>
I see
<FL4SHK>
glad to hear that I'm not alone in wanting those
<whitequark[m]>
it's not clear how to best integrate them, and it's also not clear whether they would fit in nmigen's execution model at all
<whitequark[m]>
but i acknowledge the need entirely
<d1b2>
<4o> nmigen doesn't have processes so variable = gets value immediately = async signal. ... ?
<whitequark[m]>
nmigen does have processes, in a way, they're just implicit
<FL4SHK>
it's mainly like, one process per clock domain plus another for m.d.comb
<whitequark[m]>
i mean, nmigen's If/Case/eq are equivalent to processes, and are lowered to them in RTLIL
<FL4SHK>
oh
<FL4SHK>
Okay, that's different from what I was expecting
<whitequark[m]>
(the exact mapping from nmigen statements to RTLIL processes is subtle and unimportant for this comparison)
<whitequark[m]>
(you have to fiddle with things a bit to get both verilator and iverilog happy, basically)
<d1b2>
<4o> ok, really interested in the answer. variable /= async signal on the python lvl of nmigen?
<whitequark[m]>
FL4SHK: do you think you can explain the difference to 4o? since we're on the same page
<FL4SHK>
4o, do you understand blocking assignments in SV?
<FL4SHK>
I don't think variables are async signals at all
<FL4SHK>
they're not even really supposed to be treated like signals exactly in VHDL
<FL4SHK>
you can assign to a variable within one process
<FL4SHK>
then assign to it again with a completely new value
<d1b2>
<4o> i'm not talking about sv. what's your definition for variables in nmigen?
<FL4SHK>
the same as in VHDL
<FL4SHK>
I want to do more than one `.eq()` of the same signal within the same clock cycle
<FL4SHK>
with the signal having the old value before I do the .eq()
<FL4SHK>
mainly useful for `m.d.comb`
<FL4SHK>
at least in nMigen's model
<FL4SHK>
since nMigen basically does the two process thing, m.d.comb and m.d.sync
<FL4SHK>
but if you could have a new scope within an `m.If()`
<FL4SHK>
that'd be even better
<tpw_rules>
is this like m.d.comb += my_var.eq(1) m.d.comb += out1.eq(my_var) m.d.comb += my_var.eq(2) m.d.comb += out2.eq(my_var) and have out1 be 1 and out2 be 2?
<FL4SHK>
VHDL doesn't have new scopes like that besides `block`, which is only for the top level of a module
<FL4SHK>
yes
<FL4SHK>
that's the feature I'm looking for
<FL4SHK>
and I want to be able to use nMigen's "control flow" (for lack of a better term) with this
<d1b2>
<4o> do i get you right that you want an intermediate "container" to split a mile long equation into comprehansible pieces?
<tpw_rules>
ok, so a python variable wouldn't work
<FL4SHK>
yes
<FL4SHK>
Python variables don't work
<FL4SHK>
that only handles simple cases
<FL4SHK>
generally, nMigen handles so much of what I wanted in an HDL
<FL4SHK>
there just a few sticking points for me in nMigen
<FL4SHK>
and the lack of variables is one of those
<FL4SHK>
I really wanted type generics with respect to records in VHDL 2008
<FL4SHK>
but that feature doesn't exist
<FL4SHK>
I like my code generation features that you see in nMigen a whole lot
<FL4SHK>
*that you can do in nMigen
<FL4SHK>
I generate an `m.Switch` in nMigen as part of my long divider
<FL4SHK>
it's something where the structure depends on the value of what I'd call a generic
_whitelogger has joined #nmigen
<FL4SHK>
this was already covered earlier by tpw_rules
<FL4SHK>
and I
<FL4SHK>
I'll reiterate
<FL4SHK>
Or well
<tpw_rules>
i see what he means lemme rewrite the paste
<FL4SHK>
I'll try to explain why a Python variable doens't work
<tpw_rules>
actually i will listen first
<FL4SHK>
a Python variable does not know the actual value of a signal
<FL4SHK>
it doesn't have any knowledge of nMigen's control structures
<FL4SHK>
in an elaborate() function
<FL4SHK>
you don't know any actual signal values until you're outside the elaborate() function
<FL4SHK>
and you can't overwrite a Signal's value
<d1b2>
<4o> imagine that this paste would work. would you say that tmp is a variable?
<FL4SHK>
you can only assign to it once
<FL4SHK>
I wouldn't
<FL4SHK>
because you can't reassign to the value of a signal
<tpw_rules>
but you can?
<tpw_rules>
or do you mean as in the signal can never refer to two values in two places?
<tpw_rules>
(in the same clock cycle)
<FL4SHK>
it needs to be reassigned within the same clock cycle
<FL4SHK>
i.e. it needs to have one value at one time within the clock cycle and another value later
<FL4SHK>
this is a useful feature of both VHDL and SV
<FL4SHK>
and it's not in nMigen
<d1b2>
<4o> ok, i finally understand what you mean:)
<FL4SHK>
I may have explained poorly but I did finally reach my point
<FL4SHK>
you basically only have SV `<=` assignments in nMigen
<d1b2>
<4o> do you havea suggestion for syntax for the feature in nmigen?
<whitequark[m]>
it's not entirely clear to me what the semantics would be, to begin with
<whitequark[m]>
at a first glance, it would require something SSA-ish to happen at one of the lowering steps
<whitequark[m]>
this is more complex than any of the transforms that currently exist in nmigen
<lkcl>
4o: basically a python variable, if assigned to some nmigen constructs, effectively stores the entire Abstract Syntax Tree in that python variable
<lkcl>
therefore if you use that in another nmigen statement, the *entire Abstract Syntax Tree* is substituted into the (new) expression
<lkcl>
that gets particularly bad (understatement) if you use python variables to store slices that index a reference into an array
<lkcl>
and it gets completely and utterly insane if you reference a 2D array
<whitequark[m]>
however, i don't think this is the culprit here
<whitequark[m]>
i suspect something goes wrong in the yosys `proc_arst` machinery, which is one of the sketchier parts of yosys, for unfortunate but historically unavoidable reasons
<whitequark[m]>
mwk: do you happen to have a guess as to why this happens?
<lkcl>
whitequark: ack. no, no rush - fortunately we have ghdl working with cocotb, it's excruciatingly slow but functional
<lkcl>
so there's a way forward: cxxsim isn't a critical path blocker
<d1b2>
<4o> i'll fix the code and update the issue. can't see past "invalid rtlil" as a reason. can try to poke yosys community for the particular reason what goes wrong there. makes sense?
<whitequark[m]>
lkcl: ftr you're currently just using cxxrtl; cxxsim is the nmigen component
<whitequark[m]>
the naming might not be the best thing i came up with
<Lofty>
There's a lot of Yosys community here already, 4o :P
<lkcl>
yes, cxxrtl.
<d1b2>
<4o> @Lofty got this feeling
<d1b2>
<4o> i'm kind of worried if the issue could have a potential fix in like 4 months from now, or it's so low on priority list that no way i'll happen. we are using nmigen to generate rtl for async active-low reset asyn lib
<d1b2>
<4o> *asic
<Lofty>
You're trying to work in asynchronous logic?
<d1b2>
<4o> async reset
<mwk>
whitequark[m]: ugh
<Lofty>
mwk: I agree with this sentiment
<mwk>
so yeah, you're basically emitting code that proc_arst cannot handle
<mwk>
the general problem is that proc_arst can only handle processes with one (1) top level switch (because that's what verilog frontend emits for IEEE 1364.1 patterns), and since this one has two of them, it's skipped by proc_arst
<mwk>
and then proc_dff chokes on it because the async reset hasn't been handled
<Lofty>
I mean, there's always the fallback of making some small Verilog file which implements the right behaviour and then using an nMigen Instance() of it
<mwk>
what
<Lofty>
Maybe we're interpreting the behaviour of this code differently
<whitequark[m]>
mwk: that is probably fixable, though it seems like it would be kind of hacky
<mwk>
whitequark[m]: there are two options
<whitequark[m]>
i think redoing the exact pattern ResetInserter uses might fix it?
<mwk>
one is to throw everything other than the reset into the default case of the rst switch
<mwk>
which would probably be easier
<mwk>
second is to just admit that processes, and in particular sync rules, are an ugly hack that protrudes from verilog frontend into RTLIL proper and shouldn't be used for other purposes
<mwk>
and emit $adff directly
<whitequark[m]>
i don't agree with that
<whitequark[m]>
in fact, if yosys got rid of processes, i would get rid of yosys in nmigen
<whitequark[m]>
to put it bluntly
<whitequark[m]>
i do see your point on sync rules though
<d1b2>
<4o> ok. so moving the multilayer ifs to async is the official fix for the code :) i'll check if it fixes the code that was downgraded to the snippet in question
<whitequark[m]>
4o: no
<whitequark[m]>
the "official" fix would be to change the pattern that ResetInserter emits
<d1b2>
<4o> i mean workaround i can use
<whitequark[m]>
that's feasible and would probably even result in slightly more idiomatic verilog being emitted
<whitequark[m]>
mwk: to continue that thought, "RTLIL-with-processes" and "RTLIL-without-processes" are two different languages that use the same representation
<whitequark[m]>
it is tempting to kick one of them out (and make it second-class, essentially. stuff processes into the AST "frontend" or something), but I'm no longer convinced this is a good idea after looking at MLIR
<whitequark[m]>
all of the tooling would work on RTLIL proper and there would be almost nothing to debug the complexity that lives in AST (let's call it that for the moment). LLVM had that happen with normal IR and machine IR. machine IR has a good chunk of the complexity but until recently also had none of the tools
Bertl_zZ is now known as Bertl
<mwk>
you've missed some of our discussions on new IRs and pass architectures...
<whitequark[m]>
are there meeting minutes I can read?
<mwk>
either way, the thing here is that sync rules, for better or worse, are verilog specific
<mwk>
proc_arst is literally an implementation of that particular IEEE 1364.1 chapter, and nmigen isn't following the patterns
<whitequark[m]>
yes, I agree
<whitequark[m]>
I could emit `$dff` and `$adff` directly and avoid sync rules entirely
<whitequark[m]>
while still emitting decision trees as processes
<whitequark[m]>
this actually wouldn't even be hard to implement
<mwk>
that'd be how I'd do this tbh
<whitequark[m]>
then let it be so
<_whitenotifier-5>
[nmigen] whitequark edited issue #603: RTLIL sync rules are Verilog-specific and should not be emitted - https://git.io/JYE9N
<_whitenotifier-5>
[nmigen] whitequark commented on issue #603: RTLIL sync rules are Verilog-specific and should not be emitted - https://git.io/JOUB7
<whitequark[m]>
mwk: thanks!
chipmuenk has joined #nmigen
<d1b2>
<4o> trying to understand the solution. you want to split generated code into async logic and explicit ff cell?
<whitequark[m]>
this is what already happens before emission of verilog, but in a roundabout way that as mwk describes is not really correct in first place
<whitequark[m]>
it just happens to work most of the time
<d1b2>
<4o> ok
<d1b2>
<4o> aaand another question. https://paste.debian.net/1193100/ i got the feeling that this is not the recommended practice, right?
<whitequark[m]>
I suggest using \_\_init__ to assign ports and parameters only, and then creating a Module inside `elaborate`
<whitequark[m]>
basically, `__init__` defines the interface, and `elaborate` defines the implementation
<d1b2>
<4o> what's the motivation behind it?
<whitequark[m]>
there are several reasons this is useful
<whitequark[m]>
first, this is just a useful distinction to make explicit. in migen, it was conventional to use `###` to separate the two, which served to aid the reader but nothing else
<whitequark[m]>
second, in complex designs, the interface and configuration of a module might be constructed part by part
<whitequark[m]>
* second, in complex designs, the interface and configuration of a design component might be constructed part by part
<whitequark[m]>
sometimes it is necessary to get a reference to the component before it has been fully constructed (and therefore, before its implementation can be emitted)
<whitequark[m]>
third, the implementation can be platform-specific, and you only have the platform in `elaborate`
<whitequark[m]>
fourth (this is similar to the second), some components can be modified after they are created, e.g. to initialize some memory inside or change some parameters that aren't exposed in the constructor for some reason
<whitequark[m]>
once again, delaying emission of the implementation helps with that
<whitequark[m]>
that should be about it.
<d1b2>
<4o> what do you think about turning the bug into a feature? https://paste.debian.net/1193101/ use it for passing stuff b/n modules. provided elab sequence is magically sorts itself right
<d1b2>
<4o> is
<whitequark[m]>
I don't understand what you're talking about
<whitequark[m]>
fwiw, setting properties on signals is explicitly unsupported
<whitequark[m]>
as is inheriting from signals and such
<whitequark[m]>
(this is because i might later choose to add a property with the name you picked, breaking your code)
<d1b2>
<4o> let's leave my_property aside for a bit. if i could get my hands on the .shape of an external port connected to current module port, i could configure the module accordingly
<whitequark[m]>
* (this is because i might later choose to add a property with the name you picked, breaking your code; there's a similar but worse problem with inheritance)
<whitequark[m]>
you're asking more from nmigen than it was ever intended to do. it doesn't (and, likely, will not) provide introspection of netlists
<whitequark[m]>
if you encounter a need for that often, i suggest building something on top of nmigen
<d1b2>
<4o> ok, understandable
<whitequark[m]>
it is likely that there will be a limited form of netlist introspection for clocking analysis, but it's still unclear what form that should have, and it's unlikely that it will be exposed in the API in a reusable way
<whitequark[m]>
implying the current syntax is ugly, are you? :p
<whitequark[m]>
i'm not fond of such wrappers around languages as they split the ecosystem
<whitequark[m]>
the most stark example i can think of is OCaml's "revised" syntax
<d1b2>
<4o> sadly, no. i have some problems with typing so the little i have to type the better. as for ecosystem, that ... thing is compatible with nmigen. at least i could use it inside pure nmigen in 2 structural blocks
<whitequark[m]>
my view here is that issues with the syntax (or semantics, for that matter) that fall within the scope of the underlying project ought to be fixed in that project so that everyone can enjoy them. the rest can be built on top in a way that doesn't overlap with the scope of the underlying project.
<whitequark[m]>
"compatible" in the sense of being interoperable code-wise, right?
<whitequark[m]>
that's only a part of the story
<whitequark[m]>
however, it seems like you've mostly built it for yourself. in that case, none of my concerns apply as it doesn't really influence language evolution as a whole
<d1b2>
<4o> compatible as in i can instaniate "nyanMigen" instance in nmigen code cause the former ast is replaced by propper nmigen ast and compiled back to python source
<whitequark[m]>
sure. but programming languages aren't just about working code. working code is necessary, yes, but it's only the first step
<whitequark[m]>
programming language implementations are about error messages, and API design, and documentation, and learnability
<d1b2>
<4o> heh, 1.5/4
<whitequark[m]>
it's, generally, easy to put an alternative frontend on an existing language implementation, which will let you interoperate with all of the existing code. but that's stopping after solving the easiest part
<whitequark[m]>
if you were aiming to get your project adopted widely, i would have actually preferred it if you forked nmigen completely and changed it to suit your needs, because this would in the long run benefit both of us
<d1b2>
<4o> ok, i'll make an issue in some time. but some things can't be fixed just cause nmigen code is meant to be executed directly rather then used as input for code generation
<whitequark[m]>
sure. i would suggest anyone generating nmigen code (that is, generating python text intended to be executed) to... well, do anything else instead? it's going to lead to sadness the very moment an error message references generated code rather than human-written source
<whitequark[m]>
it is not feasible to support foreign source locations in nmigen (or on verilog, unfortunately for nmigen itself), so i don't see any approach to generating nmigen code that would be comfortable to end users other than "don't"
<whitequark[m]>
honestly, generating plain python code is bad enough without having to care about another DSL embedded in it. i do that in pysim, and it's very challenging to debug
proteusguy has quit [*.net *.split]
kbeckmann has quit [*.net *.split]
anuejn has quit [*.net *.split]
trabucayre has quit [*.net *.split]
kbeckmann has joined #nmigen
anuejn has joined #nmigen
trabucayre has joined #nmigen
proteusguy has joined #nmigen
nelgau_ has quit [Remote host closed the connection]
cr1901_modern has quit [Read error: Connection reset by peer]
nelgau has joined #nmigen
cr1901_modern has joined #nmigen
pftbest has quit [Remote host closed the connection]
<FL4SHK>
I have an idea for my HDL
<FL4SHK>
just make a library for generating VHDL code
<FL4SHK>
or maybe SV code
<FL4SHK>
SV code so I can put arrays with an arbitrary number of dimensions on ports
<FL4SHK>
I think I can just make the DSL in Python
<FL4SHK>
I can overload `<<=`
<FL4SHK>
that can be my assignment operator
<FL4SHK>
though maybe it should be `%=`
pftbest has joined #nmigen
<FL4SHK>
I like `<<=` better
<FL4SHK>
though I think it'd be best if I could just do `<=`
<FL4SHK>
only problem with that is you can't do a less than comparison
<FL4SHK>
so I'm kind of interested in doing `.eq()` again
<FL4SHK>
really it'd be best if you could have an overload-only `:=` operator in Python
<FL4SHK>
ooh, ooh
<FL4SHK>
I can overload `__setattr__`
<FL4SHK>
`module.a = b` for a VHDL combinatorial assignment
<whitequark[m]>
<FL4SHK "really it'd be best if you could"> there's `@=` which might be fitting
<FL4SHK>
wait
<FL4SHK>
there's `@=`?
<FL4SHK>
how do I overload that?
<FL4SHK>
`__iat__`?
<whitequark[m]>
wait
<whitequark[m]>
there's @
<FL4SHK>
`@=` seems to be a real thing
<whitequark[m]>
but not @= ?
<whitequark[m]>
hm
<FL4SHK>
where do you see these operators?
<FL4SHK>
I've never even heard of this operator
<FL4SHK>
`@=` exists
<FL4SHK>
I just don't know how to overload it
<whitequark[m]>
@ is \_\_matmul__
<FL4SHK>
`imatmul`
<whitequark[m]>
pep465
<whitequark[m]>
yeah imatmul is a thing too.
<FL4SHK>
that'll work
<FL4SHK>
maybe add that to nMigen?
DaKnig has joined #nmigen
DaKnig has quit [Changing host]
DaKnig has joined #nmigen
<whitequark[m]>
what for?
<FL4SHK>
instead of `.eq()`
<FL4SHK>
or as an alternative to it
<whitequark[m]>
i don't see .eq as something that needs replacement, personally
<FL4SHK>
I see
<FL4SHK>
Yeah, probably not
<FL4SHK>
some people seem to think it's ugly
<whitequark[m]>
and i'm not sure how @ would be better
<whitequark[m]>
i mean, you still need to specify the module and the domain, right?
<FL4SHK>
m.d.comb += (a @= b)
<FL4SHK>
or
<FL4SHK>
m.d.comb += (a @ b)
<whitequark[m]>
this actually looks worse to me
<FL4SHK>
cool
<whitequark[m]>
also
<FL4SHK>
I'll stick to `.eq()`
<whitequark[m]>
wait
<whitequark[m]>
the first one is illegal
<FL4SHK>
that's true
<whitequark[m]>
the second one depends on precedence of @
<FL4SHK>
I like `.eq()` better also...
<FL4SHK>
yeah, you're right
<whitequark[m]>
in cases like a @ b + c
<d1b2>
<zyp> yeah, was about to say, it's just gonna turn into a mess with precedence
<FL4SHK>
right, `.eq()` for me it is
<FL4SHK>
I'm going to start working on a VHDL code generator thing
<FL4SHK>
then bring it to work..
<FL4SHK>
actually, I guess I'm happy with VHDL plus my macro pack thing I made at work
<d1b2>
<dub_dub_11> apparently nmigen has generated an invalid constraint Annotating constraints to design from ucf file "top.ucf" ... ERROR:ConstraintSystem:300 - In file: top.ucf(9): Constraint 'PERIOD' has a value 'TSclocks/clk12' which is invalid. Use the following: Text that matches the regular expression: *i:ts[a-z_0-9\\]+ Please see the Constraints Guide for more information on this constraint. from platform.add_clock_constraint(clk12, 12e6)
<whitequark[m]>
are you using ISE?
<d1b2>
<dub_dub_11> yeah
<whitequark[m]>
that looks like it's using invalid character in hierarchical nams
<whitequark[m]>
* that looks like it's using invalid character in hierarchical names
<whitequark[m]>
the issue is that the patch won't apply
<whitequark[m]>
(I misunderstood which of mwk's forks you had in mind)
<d1b2>
<dub_dub_11> no need to apologise I'm using an unusual setup soo
<d1b2>
<dub_dub_11> I see the same line though
<d1b2>
<dub_dub_11> I will make a PR to mwks fork
revolve has quit [Read error: Connection reset by peer]
revolve has joined #nmigen
<mwk>
wait what fork
<d1b2>
<dub_dub_11> mwk/XilinxPlatform
<d1b2>
<dub_dub_11> sorry mwk/xilinx-platform
<mwk>
that's not a fork, that's a PR
<mwk>
or at least that's what it was supposed to be
<d1b2>
<dub_dub_11> oh
<d1b2>
<dub_dub_11> hmm
<mwk>
whitequark[m]: any news on that one? I'd rather avoid the situation where I have a PR to my PR
<d1b2>
<dub_dub_11> I suppose github creates it as a fork
<d1b2>
<dub_dub_11> > I'd rather avoid the situation where I have a PR to my PR that is understandable...
<whitequark[m]>
mwk: no news. as you may have noticed, i haven't attended meetings either, and that's because i've had things more important than code going on
<whitequark[m]>
i'll take care of it in due time.
<d1b2>
<dub_dub_11> > https://paste.debian.net/1193126/ this did the trick, thanks. I can make a PR to your branch mwk, or if it's too messy I can just leave it
<mwk>
whitequark[m]: yeah, understandable
<whitequark[m]>
you can expect me to merge it within a few weeks
<whitequark[m]>
not sure exactly which
<whitequark[m]>
probably sometime in april
<FL4SHK>
whitequark[m], do you have any ideas how I might be able to have the features I was after for my `Packarr`?
<whitequark[m]>
I would prefer to discuss that during the design cycle for PackedStruct
<FL4SHK>
mainly such that I could do both records containing `Packarr`s and `Packarr`s of records
<mwk>
dub_dub_11: I'm not sure if making a PR to a branch that is a PR itself is a good idea
<FL4SHK>
okay
<FL4SHK>
sounds good to me
<FL4SHK>
I'll wait
<whitequark[m]>
mwk: technically speaking, that works just fine
<whitequark[m]>
now if you just don't want to deal with it, that's of course reasonable
<whitequark[m]>
but the functionality is there and it'll do what you'd expect it to do
<mwk>
that said... this looks like an obvious fix and IMO it wouldn't be a problem if I rolled that commit into the same branch
<d1b2>
<dub_dub_11> (in the end the PR consists of 3 characters worth of changes anyway)
<mwk>
then it'd get merged as one unit to upstream, I suppose
<mwk>
yeah
<d1b2>
<dub_dub_11> so should I make the pr or just leave it to you?