<ZirconiumX>
whitequark: I think it'd be nice to annotate Signals as inputs or outputs so nMigen can warn if you connect two inputs or outputs together.
<ZirconiumX>
At the moment it seems to rely on naming conventions to prevent that
<whitequark>
ZirconiumX: it would be nice
<whitequark>
unfortunately, I don't really see a way to do this
<ZirconiumX>
Is it an undecidable problem or something?
<whitequark>
no, it just doesn't fit well into nmigen's existing design
<whitequark>
I mean, maybe I'm just missing something!
<whitequark>
you can try coming up with a specific design for this and we can discuss it; it's just that I wasn't able to
<whitequark>
so far
<ZirconiumX>
Constructors can take keyword arguments in Python, right?
<whitequark>
sure
<ZirconiumX>
So then how about an enum-like kwarg of Signal(..., type=connection.INPUT)?
<whitequark>
and what semantics would that have?
<ZirconiumX>
I'm wary of linking this to Verilog, so I won't
<ZirconiumX>
It'd need to default to an in/out type because of backcompat
<whitequark>
no, that's irrelevant
<whitequark>
signals are not tied to fragments in nmigen
<whitequark>
you can use any signal in any fragment
<ZirconiumX>
Would you mind defining fragment here in terms of nMigen?
<whitequark>
well
<whitequark>
a fragment is nmigen's internal representation
<ZirconiumX>
Would that have been the F in Migen's FHDL?
<whitequark>
yeah
<whitequark>
a fragment in nmigen has (a) ports and (b) tree of switch and assign statements
<whitequark>
it's essentially equivalent to an RTLIL module
<ZirconiumX>
Okay, I think I get it
<ZirconiumX>
My main aim for something like this is as a lint
<ZirconiumX>
If an annotated output connects to another annotated output, there's probably something wrong
<whitequark>
you already get a warning in this case
<whitequark>
(hierarchy being flattened)
<whitequark>
well, if those are outputs of different modules
<whitequark>
if those are the outputs of the same module, then that's perfectly reasonable
* ZirconiumX
is scanning through the nMigen source, and may be a little while
<whitequark>
defining the exact semantics of what does it mean to have an "input signal" or "output signal" is hard
<whitequark>
i'm not sure if it makes sense at all
<whitequark>
in fact, i wonder if the right approach here is to define a dataflow language on top of nmigen that distinguishes between input, output, and control signals, and natively supports pipelining
<ZirconiumX>
I think the main purpose of it would be as a lint.
<whitequark>
a lint has to have very few false positives or it's worse than useless
<whitequark>
so this doesn't change much
<ZirconiumX>
"you say this is an input signal; okay, fine, but you haven't connected it to anything"
<ZirconiumX>
I don't think I understand enough about nMigen to really appreciate the problems involved here
<whitequark>
unconnected inputs in nmigen are defined to go to their reset value, so leaving them unconnected is perfectly sound
<ZirconiumX>
Doesn't that require you to define a reset value, though?
<whitequark>
if you don't explicitly specify a reset value, it's 0
<ZirconiumX>
Personally I feel like this would be a good time for "errors should not pass silently; unless explicitly silenced"
<ZirconiumX>
To quote Tim Peters
<whitequark>
but it's not an error
<whitequark>
not having 'x is a deliberate, explicit choice
<whitequark>
and so is having signals reset to 0 by default
<ZirconiumX>
It's possible to not have 'x and still require it to be given a value
<whitequark>
sure
<whitequark>
you're a few years late to suggest doing that though
<whitequark>
about eight, i think
<ZirconiumX>
I'll get my DeLorean then
<whitequark>
I'm also not actually convinced that sprinkling "reset=0" everywhere is beneficial
<ZirconiumX>
That's not what I mean; zero as a default seems sane to me
<whitequark>
okay
<whitequark>
then I don't understand what you are suggesting
<ZirconiumX>
When module X adds module Y as a submodule, module Y has an annotation that marks signals as public or whatever. While elaborating module X, nMigen checks if X references all public signals of Y and warns if not.
<whitequark>
sure. lots of existing migen/nmigen code rely on disconnected signals having their reset value
<whitequark>
for example, if you don't use some feature, you never set the signal that enables it to 1. what's wrong with that?
<whitequark>
you can't do this in verilog (without a lot of effort) because of 'x, but in nmigen it's natural
<whitequark>
also, if you were writing such a lint, it's not necessary to extend nmigen at all
<ZirconiumX>
To me as a beginner it might as well be 'x unless I know what the reset value of something is
<whitequark>
there's already a pass that sets all unused signals to their reset value. it'd be relatively easy to make it emit a diagnostic instead.
<whitequark>
*unassigned signals
<whitequark>
hm
<whitequark>
so thinking more about it
<whitequark>
wouldn't it make more sense to have something like Rust's #[must_use] annotation on the signals without which a module is pointless?
<ZirconiumX>
Yes, it would
<whitequark>
this wouldn't apply to inputs only; if you instantiate a FIFO and never use dout, that's bad
<ZirconiumX>
Or memory
<ZirconiumX>
I think something like must_read and must_write would be helpful
<whitequark>
I don't see why is the distinction needed
<whitequark>
the semantics of must_use would be, "this signal needs to be referenced from an outer fragment"
<ZirconiumX>
Is writing to a FIFO output a particularly useful thing to do?
<whitequark>
hmm.
<whitequark>
ok, true
<ZirconiumX>
Sure, you get a warning about the hierarchy being flattened
<ZirconiumX>
But it counts as a "reference"
<whitequark>
yes, you have a point
<whitequark>
now the syntax I'd like to use for this is Python's type annotations
<kernlbob>
File "/Users/kbob/Documents/Code/Python/Envs/nmigen/lib/python3.7/site-packages/nmigen/vendor/lattice_ice40.py", line 138, in create_missing_domain
<kernlbob>
File "/Users/kbob/Documents/Code/Python/Envs/nmigen/lib/python3.7/site-packages/nmigen/build/res.py", line 65, in request
<kernlbob>
.format(name, number))
<kernlbob>
nmigen.build.res.ResourceError: Resource clk12#0 has already been requested
<kernlbob>
```
<kernlbob>
I must missing something basic, because I don't know how to start
<kernlbob>
debugging this. What am I doing wrong?
cr1901_modern has joined #m-labs
<davidc__>
uh... this isn't slack :P
<kernlbob>
@davidc__: Yes it isn't. What would be a better question format?
<tpw_rules>
pastebin
rohitksingh has quit [Ping timeout: 264 seconds]
zng has quit [*.net *.split]
<cr1901_modern>
Can Arrays be used as ranges?
zng has joined #m-labs
rohitksingh has joined #m-labs
kernlbob has quit [*.net *.split]
<vup>
kernlbob: so what happens is, that the `'sync'` clock domain referenced by the ResetSynchronizer is different from the `cd_pll` `ClockDomain`, so the platform creates the default `'sync'` clock domain (by using the 'clk12' pin) and you use the 'clk12' pin in the pll instance, which explains why the 'clk12' pin is requested twice
<_whitenotifier>
[nmigen] RobertBaruch opened issue #199: Documentation: 'domain' in Past et al is a string - https://git.io/JevZm
<vup>
to fix it you need to specify that `cd_pll` should be the 'sync' ClockDomain, by giving it the 'sync` name: `cd_pll = ClockDomain(jsync')`
rohitksingh has quit [Ping timeout: 276 seconds]
<ZirconiumX>
[21:18:56] * kernlbob has disconnected (*.net *.split)
<ZirconiumX>
vup: you'll probably need to copy paste it when they get back
<vup>
well i hope they read the log
<emily>
after pasting an entire program? sounds a little optimistic >.>