<agg>
can I have an signal force my fsm to a given state without writing a check for it in every state?
<agg>
or, alternatively, does the mysterious `reset` parameter to Module.FSM() take a signal which is used to reset the FSM?
<Sarayan>
re
<Sarayan>
hmmm
<agg>
I think reset is the name of the reset state, not a signal
<agg>
perhaps I should just reset the clock domain that the fsm is in
<whitequark>
or use ResetInserter
<agg>
hmm, I guess elaborate() can create a module, and then resetinsert into it, and then tie one of the inputs to the reset signal, then return the result?
<agg>
in retrospect I think I'll probably just only accept this signal from a specific state instead of any state
<whitequark>
yeah
<Sarayan>
hmmmm, it's kinda unclear. Let's say I want to allow access to the interrupt hps module, which is a non-configurable thing with 42 named signals going from the hps to the core (can, dma, spi, i2c...) and 64 unnamed signals going the other way
<Sarayan>
fpga-wise, it's just fixed nodes in the routing
<Sarayan>
Should I do a HPS_Interrupt module with 42 outputs and 64 inputs, that instanciate an Instance with a predefined name with all of these?
<Sarayan>
Cat'ing the 64 together and leaving the named separate since that's pretty much how the hardware is documented?
<whitequark>
unnamed signals? all verilog ports are named
<Sarayan>
Unnamed as in a 64-bits wide output named "irq"
<Sarayan>
to compare to a 1-bit wide input named H2F_GPIO0_IRQ
<Sarayan>
also, I don't care about verilog there, the more I avoid verilog the better
<Sarayan>
and nmigen-yosys-nextpnr does not seem to need verilog at any point
<whitequark>
rtlil ports are also always named
<Lofty>
No, but unfortunately we have to care about verilog for everybody who doesn't use nmigen ^^;
<Sarayan>
makes sense
<EmilJ>
I'm confused, Lofty did you mean to say yosys instead of nmigen?
<Lofty>
No, I meant nmigen
<Lofty>
Yosys accepts Verilog after all
<EmilJ>
But we're in... #nmigen
<EmilJ>
discussing nmigen Instances propagating to hardware
<Lofty>
Sure, and Sarayan talks about #prjmistral stuff in #nmigen
<Sarayan>
Well, right now I'm talking how does one interface a cyclonev in nmigen
<EmilJ>
oh okay, I'm out of the loop, my bad
<Sarayan>
so while the cyclonev stuff is kinda prjmistral, the nmigen stuff is rather nmigen :-)
<Sarayan>
(at least for once I'm not fucking up the channels *too much*)
<Lofty>
You made it sound like you didn't want there to be a Verilog module at all :P
<Sarayan>
It's more like verilog is not my primary or even secondary motivation
<Lofty>
Aside from MiSTer.
<Lofty>
With all its Verilog code :P
<Sarayan>
Yeah, I'm not that interested by the existing mister code because verilog
<Sarayan>
I'm way more interested into doing fun stuff in nmigen and see how optimally it can go down to the bitstream
<Sarayan>
Yes NIH, so what :-)
<Sarayan>
mister users only want a rbf in any case
<Lofty>
I agree, but I also think this is basically a bugfix
<Lofty>
But I'm not sure I can fully understand the consequences of that
<whitequark>
I'm not sure I can call something adding a brand new API a bugfix
<whitequark>
but that's not very important
<Lofty>
The new API is obviously redundant
<Lofty>
My point is more the `as_signed` vs `to_signed` thing
<whitequark>
oh?
<whitequark>
I think I'm missing something
<Lofty>
So, to_signed takes an unsigned value, zero-extends it and then makes it signed, right?
<Lofty>
Whereas as_signed would sign-extend it, right?
<whitequark>
yes, no
<whitequark>
.as_signed is basically reinterpret_cast
<whitequark>
.. ok no
<whitequark>
it's basically bit_cast.
* whitequark
should not make C++ analogies, they just make things more confusing
<whitequark>
let me rephrase: .as_signed and .as_unsigned never change the width. they just alter the signedness. essentially, they change how the operations down the road interpret the value
<whitequark>
signed gt vs unsigned gt for example
<whitequark>
you would use .as_signed() if e.g. you had a register file (which gives you unsigned values) and you need to do signed math
<Sarayan>
so it's all in the integer promotion that happens afterwards, to continue to bad analogy
<Sarayan>
the
<whitequark>
basically
<Lofty>
My head's spinning here :P
<Lofty>
Anyway, in that case I think we just go back to discussing the general shape conversion operators
<whitequark>
okay, guess I just forgot to remove the label
<whitequark>
what's left are #377 and #510
<whitequark>
I think ktemkin is on vacation, not sure if awygle is present; it's a bit unfortunate as I'd prefer to have their input on both
<anuejn>
ah I se
<anuejn>
*see
<whitequark>
with #510, the inversion of connector pins and the inversion of resource pins is orthogonal, right?
<whitequark>
so we could merge the part that allows inversion of resource pins before the one with connector pins
<whitequark>
and I don't think there are any objections to individual inversion of resource pins
<anuejn>
yup
<anuejn>
connector pin inversion somehow depends (implementation wise) on resource pin inversion but otherwise yes
<whitequark>
so here's my concerns about connector pin inversion
<whitequark>
for single ended pins, it's straightforward, but also not particularly often needed; how often do you really have an inverter sitting somewhere in a connector?
<Lofty>
Actually, this reminds me. Sarayan brought up earlier the Cyclone V HPS, and *that* reminded me that Cyclone V (IIRC?) needs an Instance creating to talk to the ARM chip, rather than a pin assignment
<whitequark>
I can totally see it happening, but I'm not sure if it happens often enough to justify the cognitive overhead
<Lofty>
Which Platforms don't support right now
<Lofty>
(sorry to OT, but I wanted to get it down while I remembered it)
<whitequark>
if you feel like writing an RFC, here's your chance! I think it is very much a desirable feature and I have a rough sketch we can discuss (later)
* Lofty
mutes #nmigen in the 1b2 discord
<Lofty>
Sadly I'm a little preoccupied, but otherwise sure
<whitequark>
applies to anyone else too
<whitequark>
you can take a look at the [rfc] label to see the format, it's not a super formal process at the moment so don't let that scare you
<anuejn>
whitequark: but for diff pairs it is far mor common (i guess)
<whitequark>
yes
<whitequark>
for diff pairs there's another problem, which is mismatching inversion
<whitequark>
hmm, we already have that with normal diff pair definitions
<anuejn>
I would be okay to only handle that (I dont have the other problem)
<whitequark>
ok, I propose a compromise: only diff pairs can be inverted in connectors
<whitequark>
we can always extend it later to single ended signals
<whitequark>
but for now let's avoid it to make things more predictable
<anuejn>
sounds good to me
<_whitenotifier-f>
[nmigen] whitequark commented on issue #510: [RFC] Allow DiffPairs and Pins to be inverted individually - https://git.io/JT6ZD
<anuejn>
do we want to discuss syntax here?
<whitequark>
same as with resources?
<anuejn>
okay, fine for me
<anuejn>
should I go ahead and implement that or should I wait untill #510 is merged?
<whitequark>
latter
<whitequark>
er, 510?
<whitequark>
514 you mean?
<anuejn>
yup
<anuejn>
sorry
<whitequark>
ok, you're waiting on me for that
<anuejn>
yup
<whitequark>
my main concern was that there shouldn't be two inversion attributes
<whitequark>
alright, i'll try to get back to you on that soon
<anuejn>
that might break the repr and some other (internal?) code
<whitequark>
breaking the repr and internal code is 100% fine
<anuejn>
okay
<whitequark>
the only guarantee on the repr we might have is that it roundtrips
<whitequark>
but many of our reprs are purely human readable also
<whitequark>
eg the AST ones
<anuejn>
okay
<whitequark>
for Pins/DiffPairs I would prefer if the repr was in the same format as the DSL the user enters
<whitequark>
I don't recall what it has currently
<anuejn>
should everything change to an inversion tuple then?
<whitequark>
I think .invert becoming a tuple is OK; we'd probably also want a @property that converts it to an integer that can be XOR'd
<whitequark>
something like .invert_bits
<anuejn>
okay
<anuejn>
so .invert is nothing the user can rely on so it doesnt have to go trough a deprecation cycle?
<Sarayan>
Sorry if I'm waylaying, but how is one supposed to compile the nmigen docs?
<Sarayan>
oh, sphinx-build docs docs/_build
<whitequark>
yep
<whitequark>
to Sarayan
<Sarayan>
thanks
<awygle>
Ah shit sorry whitequark, I fell asleep
<whitequark>
anuejn: in this case I judge that the breakage will be nonexistent to minor, and the hassle of going through a deprecation cycle significant
<whitequark>
I mean, the semantics changes anyway
<anuejn>
okay :)
<whitequark>
i.e. if you have code that depends on .invert, and you add individual inverts *on top*, then that code breaks anyway
<whitequark>
so you can go through a deprecation cycle but it doesn't really fix any problem
<anuejn>
I was more concerned about having code that sets .invert
<anuejn>
as PinsN and DiffPairsN do (why btw?)
<anuejn>
but having that outside of nmigen is unlikly, right
<anuejn>
should those DSL classes be treated imutable by downstream code?
<whitequark>
they should, and PinsN is doing something weird
<whitequark>
it should just pass invert=True
<anuejn>
Okay, thought that too
<whitequark>
ahh I know what happened, it predates invert=
<anuejn>
should we bring invert= to DiffPairs too (for the sake of consistency?
<awygle>
I agree with the decision on 510, I find it a bit weird to not support SE signals and expect to be asked about it in approximately three month's time, but I understand the reason to take this approach
<whitequark>
awygle: I find it unlikely people will have inverters on connector lines often
<Sarayan>
the pdf version of the documentation looks rather good
<daveshah>
Lofty: > Actually, this reminds me. Sarayan brought up earlier the Cyclone V HPS, and *that* reminded me that Cyclone V (IIRC?) needs an Instance creating to talk to the ARM chip, rather than a pin assignment
<awygle>
I am now up to speed on 377 if you want to discuss it, or we can wait for ktemkin if you prefer, we're past an hour and I know it's getting late
<whitequark>
Sarayan: huh, never tried it
<daveshah>
Xilinx is the same too, fwiw
<whitequark>
awygle: let's bump it to next meeting
<awygle>
kk
<whitequark>
I'm getting tired as well
<awygle>
I don't disagree with you about not having inverters on connectors but I think someone will reach for that functionality for some esoteric reason and find the hole in the semantic matrix
<Sarayan>
og.kervella.org/nmigentoolchain.pdf
<awygle>
But we can just solve the problem then. And maybe I'm wrong.
<awygle>
I find connectors to be fairly unintuitive in any case, on a personal level, so I may be anticipating incorrectly
<Sarayan>
daveshah: it's for the arm, but also the hssi, the hmc, the jtag stuff, etc
chipmuenk has quit [Quit: chipmuenk]
<whitequark>
Sarayan: oh that's cool, even the platform selector ends up being semi-reasonable
<anuejn>
awygle: maybe we should solve that now then
<whitequark>
the problem is that then everyone who uses connectors will have to think about 2 inversion layers and not 1
<anuejn>
whitequark: ah I think having inverts on connectors for non diffpairs be a hard error doestnt work
<anuejn>
because sometimes one wants to use a crossed diffpair as single ended pins
<anuejn>
I think we can still disallow inversion through connectors on `Pins`
<anuejn>
but we cant make that a hard error
<anuejn>
and maybe we should come up with a less confusing syntax that says more specifically that the pin is not getting inverted when it is not used as a diff pair
<anuejn>
something like ?
* cr1901_modern
is here but in read-only mode
<cr1901_modern>
Looks like I have some backlog
<anuejn>
or even mark explicitly what polarity the connector entry is with something like +n and +p and then do the inversion based on that?
<Sarayan>
Doesn't the example >>> Signal(range(-8, 7)).shape()
<Sarayan>
want to be (-8, 8)?
<whitequark>
anuejn: hrm, if "sometimes one wants to use a crossed diffpair as single ended pins" then i think we should just allow inverting SE pins
<anuejn>
okay
<whitequark>
in that case what i think we should do (not as a blocker, in the future) is a detailed report of which pin gets which polarity and mapping
<anuejn>
but for my specific use case I need to be able to express "invert this if it is a diffpair but not if it is sigle ended"
<whitequark>
oh
<whitequark>
okay that's cursed
<whitequark>
i think we need to rethink the syntax :/
<anuejn>
maybe (or add not-very-nice elements like ? to the synax that express that very specific case)
<whitequark>
that just means people would get it wrong constantly
<whitequark>
as the case of inverting diffpairs is not that rare
<anuejn>
but isnt that most of the time my case?
<whitequark>
hmm?
<anuejn>
when you swapped polarity "invert this if it is a diffpair but not if it is sigle ended" is exactly what one needs
<whitequark>
i'm not actually sure about that?
<whitequark>
why are you using diffpairs as single ended anyway?
<anuejn>
because i have a generic extention connector
<anuejn>
and I can connect either boards with single ended or with differential ressources on them to that connector
<whitequark>
ok
<whitequark>
(unrelated: is your first language french?)
<anuejn>
no :D
<whitequark>
ha
<anuejn>
german, but I make similiar mistakes
<whitequark>
i thought "ressources" is very french specific
<whitequark>
guess not
<whitequark>
anyway, how about this approach...
<anuejn>
I guess that is a key repeat issue ;)
<whitequark>
so the root of the problem is that the diff IO primitive requires using the + pin of diffpair and the - pin of diffpair at specific ports
<anuejn>
agreed
<whitequark>
but nmigen does not know apriori which pin is + and which is -
<whitequark>
otherwise, it could invert everything completely on its own
<anuejn>
yup
<whitequark>
therefore, we could make it so that each time you specify a pin (either in DiffPairs or in Connector) you put a + or - next to it
<anuejn>
sounds good
<whitequark>
this is tricky to implement though
<whitequark>
hmmm
<cr1901_modern>
Why do single-ended signals need an invert attr if PinsN already exists?