ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting October 12th
emeb has quit [Quit: Leaving.]
Asuu has quit [Remote host closed the connection]
smkz has quit [Quit: smkz]
smkz has joined #nmigen
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #nmigen
electronic_eel_ has joined #nmigen
electronic_eel has quit [Ping timeout: 272 seconds]
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter_ is now known as PyroPeter
chipmuenk has joined #nmigen
samlittlewood_ has joined #nmigen
samlittlewood has quit [Ping timeout: 240 seconds]
samlittlewood_ is now known as samlittlewood
emeb_mac has quit [Quit: Leaving.]
jeanthom has joined #nmigen
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 260 seconds]
chipmuenk1 is now known as chipmuenk
jeanthom has quit [Ping timeout: 258 seconds]
chipmuenk1 has joined #nmigen
jeanthom has joined #nmigen
chipmuenk has quit [Ping timeout: 260 seconds]
chipmuenk1 is now known as chipmuenk
jeanthom has quit [Ping timeout: 260 seconds]
Asu has joined #nmigen
samlittlewood has quit [Read error: Connection reset by peer]
samlittlewood has joined #nmigen
electronic_eel_ is now known as electronic_eel
Chips4Makers has quit [Remote host closed the connection]
Chips4Makers has joined #nmigen
Chips4Makers has quit [Remote host closed the connection]
Chips4Makers has joined #nmigen
<_whitenotifier-f> [nmigen] anuejn opened issue #515: Provide public api to add build commands -
DaKnig has quit [Ping timeout: 240 seconds]
DaKnig has joined #nmigen
DaKnig has quit [Changing host]
DaKnig has joined #nmigen
emeb has joined #nmigen
Asu has quit [Quit: Konversation terminated!]
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 258 seconds]
<anuejn> will there be a meeting today?
Asu has joined #nmigen
<whitequark> anuejn: yes
ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting October 26th
<Sarayan> What's the nmigen way to connect to a fpga specialized block, and if there a way to configure it when that makes sense?
<Sarayan> is
<_whitenotifier-f> [nmigen] whitequark commented on issue #515: Provide public api to add build commands -
<Sarayan> (I'll have the same question fir the yosys step afterwards :-)
<Sarayan> for
<Lofty> Sarayan: Instance
<Sarayan> Interesting, thanks
<Sarayan> I'll have to look at it a little more in-depth, wife nmi though
<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> That's depressingly true
<EmilJ> anyway, this seems to be how RTLIL is emitted from an Instance:
<Sarayan> I love the "seems to be", I must say :-)
<Sarayan> "We got this code from aliens"
<Sarayan> To which whitequark is probably gonna answer "if only"
Asu has quit [Remote host closed the connection]
Asu has joined #nmigen
electronic_eel has quit [Ping timeout: 264 seconds]
electronic_eel has joined #nmigen
<_whitenotifier-f> [nmigen] anuejn commented on issue #515: Provide public api to add build commands -
<_whitenotifier-f> [nmigen] whitequark commented on issue #515: Provide public api to add build commands -
<_whitenotifier-f> [nmigen] anuejn commented on issue #515: Provide public api to add build commands -
<_whitenotifier-f> [nmigen] anuejn commented on issue #515: Provide public api to add build commands -
<whitequark> okay, meeting time
<whitequark> let's start with I think this one mostly just slipped through the cracks in the past months
<Lofty> ...It's weird having the meetings be 6pm now
<whitequark> this is kind of why we have the time set in UTC...
<_whitenotifier-f> [nmigen] whitequark reviewed pull request #449 commit -
<_whitenotifier-f> [nmigen] whitequark reviewed pull request #449 commit -
<_whitenotifier-f> [nmigen] whitequark reviewed pull request #449 commit -
<whitequark> okay, reviwed that one
<_whitenotifier-f> [nmigen] Ravenslofty reviewed pull request #449 commit -
<Lofty> Also spotted a typo :P
<whitequark> unless someone has further comments on #449 (which I think nobody does?) let's move on to
<Lofty> #481 doesn't feel like the right approach
<whitequark> I remember someone else from IRC having opinions on that one... pepijndevos_? anuejn? vup?
<whitequark> Lofty: yeah, I'm not sure how I feel about it either
<Lofty> This feels like a bug report in the same way unary - needed to extend the result by one bit
<anuejn> i think i dont
<Lofty> Wait.
<Lofty> So, the text mentions `to_unsigned()`, but the commit adds a `to_signed()` function
<Lofty> What?
<whitequark> I remember now I think, we actually fixed a super similar bug in ArrayProxy
<whitequark> > So, the text mentions `to_unsigned()`
<whitequark> the text mentions *as*_unsigned
<Lofty> > a.to_unsigned() - b # correct
<whitequark> ohh
<Lofty> ^^;
<whitequark> so my main concern is this is redundant with
<whitequark> or *might* be redundant
<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> yes
<whitequark> let me respond as such
<_whitenotifier-f> [nmigen] whitequark commented on pull request #481: hdl.ast.Value: Add .to_signed() method -
<_whitenotifier-f> [nmigen] whitequark closed pull request #481: hdl.ast.Value: Add .to_signed() method -
<_whitenotifier-f> [nmigen] whitequark commented on issue #464: [RFC] Shape Conversion Operators Round 2 -
<_whitenotifier-f> [nmigen] whitequark edited a comment on issue #464: [RFC] Shape Conversion Operators Round 2 -
<whitequark> okay, does anyone remember why is nominated?
<whitequark> didn't we already discuss that?
<anuejn> I think so
<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 -
<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> Sarayan: yeah, not pushed yet
<whitequark> anuejn: yes
<anuejn> k
<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
<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?
<_whitenotifier-f> [nmigen] anuejn reviewed pull request #512 commit -
<_whitenotifier-f> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-f> [nmigen/nmigen] whitequark e3207b7 - build.dsl: clean up inversion logic.
<whitequark> PinsN sets the invert attr
<_whitenotifier-f> [nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13]
<_whitenotifier-f> [nmigen/nmigen] whitequark dc93b1c - Deploying to gh-pages from @ e3207b74f45be1939ee5c52c251f7145a451cae9 🚀
<cr1901_modern> So why does the invert attr need to be exposed to user code for single-ended pins if PinsN already exists*?
<cr1901_modern> Sounds like two different ways to do the almost-same-but-not-quite thing
<_whitenotifier-f> [nmigen] whitequark reviewed pull request #512 commit -
<whitequark> cr1901_modern: ah yeah, so the thing is that diffpairs should be possible to individually invert in a group within a single DiffPairs()
<whitequark> which means invert=True|False is not sufficient
<_whitenotifier-f> [nmigen] anuejn reviewed pull request #512 commit -
<cr1901_modern> Okay that makes sense... I need to reread; sounded like the idea was to expose invert to Pins() as well
<cr1901_modern> (since Pins() is well, a single-ended pin)
<anuejn> whitequark: why would that be difficult to implement?
<anuejn> cr1901_modern: I think that exposing than can be usefull if you want to dynamically decide that (based on a variable)
jeanthom has joined #nmigen
<whitequark> cr1901_modern: Pins() already has invert exposed...
<cr1901_modern> Then PinsN is sugar for Pins(invert=False)?
<cr1901_modern> err True
<whitequark> yes
<whitequark> as of the commit i just pushed, it literally calls that
<whitequark> but it was sugar before
<whitequark> what anuejn said about dynamically deciding is correct, this was necessary in nmigen-boards
<cr1901_modern> Ahhh okay... I don't seem to remember ever using invert in Pins. So I must've missed it.
<cr1901_modern> Hmmm, just for my own understanding: Aren't all the HDMI pins in the examples outputs? Why would you use an IBUFDS for an output?
<cr1901_modern> the anuejn's example*
peepsalot has quit [Ping timeout: 240 seconds]
<anuejn> i think that is wrong
peeps[zen] has joined #nmigen
emeb_mac has joined #nmigen
<cr1901_modern> Okay, me too. I wanted a second opinion
<anuejn> whitequark: is the meeting more or less concluded?
<whitequark> a long time ago yes
moony has quit [*.net *.split]
lambda has quit [*.net *.split]
alanvgreen has quit [*.net *.split]
ktemkin has quit [*.net *.split]
RaYmAn has quit [*.net *.split]
TD-Linux has quit [*.net *.split]
RaYmAn has joined #nmigen
alanvgreen has joined #nmigen
ktemkin has joined #nmigen
TD-Linux has joined #nmigen
moony has joined #nmigen
lambda has joined #nmigen
<anuejn> oh somehow i thought that you were still thinking :see_no_evil:
<Sarayan> she's always thinking
<awygle> just realizing i am confused at how the meeting time did not get fucked up by daylight savings
<awygle> (in that i was the same late/unprepared i always am for a meeting starting 11am local)
<whitequark> don't worry, i also woke up just before a meeting starting 9pm local
<awygle> yeah but i should have either been 2 hours late for a 10am meeting or right on time for a 12pm meeting because our time changed on sunday
<whitequark> oh!
Asu has quit [Ping timeout: 246 seconds]
samlittlewood has quit [Ping timeout: 256 seconds]
samlittlewood_ has joined #nmigen
emeb has quit [Quit: Leaving.]