ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at https://github.com/nmigen · logs at https://freenode.irclog.whitequark.org/nmigen
Degi_ has joined #nmigen
Degi has quit [Ping timeout: 265 seconds]
Degi_ is now known as Degi
SpaceCoaster has joined #nmigen
<awygle> python doesn't have multiline lambdas :(
<awygle> python can't tell the difference between a method and a field :(
<awygle> if i have a bunch of m.If in an FSM state, each of which assigns the same signal, does that generate different RTLIL than a long m.If()/m.ElIf/m.Else chain? they're both effectively priority encoders, right/
<awygle> and if the guards on those Ifs are actually mutually exclusive, will some element of the toolchain (presumably Yosys) figure that out and remove the priority bits?
<cr1901_modern> >python doesn't have multiline lambdas
<cr1901_modern> Boils down to "it's too difficult to add" :/
<awygle> 'because we love syntactic whitespace'
<whitequark> awygle: it does
<whitequark> lambda foo: (foo +
<whitequark> foo)
<awygle> yeah but you can't assign stuff, right? i wanted to do `lambda x: x.a = "test"; x.b = "continue"`
<whitequark> that's a separate problem
<whitequark> it doesn't let you put statements in lambdas, no matter how long
<awygle> oh really? even `lambda x: x.a = "test"` doesn't work?
<whitequark> yep, try it
<whitequark> guido quit over this
<whitequark> not the change itself
<whitequark> people tried to get the change in the language and the process was so painful he gave up and quit
<awygle> wow
<awygle> ~*~open source~*~
<_whitenotifier-3> [nmigen] alanvgreen opened pull request #349: setup.py: add "wheel" to setup_requires - https://git.io/JvpX1
<whitequark> i don't think it's necessarily OSS itself
<whitequark> or rather, not any particular bad aspects of OSS
<whitequark> my understanding is that it's just one of the situations where being in charge burns out everyone who isn't a total sociopath, the question is when, not if
<awygle> honestly i may not like python much but guido seems like a real solid person. every time i've read something from them i've been impressed. i should learn more about them.
<whitequark> see also: all the resignations in the rust project, starting with graydon himself
<awygle> (if only to pre-discover whether they're secretly evil in case i say something like that in a more public forum someday)
<awygle> yeah. i, too, read that elm thing today, so i've been thinking about this kinda thing anyway
<whitequark> PEP572 got accepted btw
<whitequark> the elm thing is kind of a counterexample.
<awygle> mhm
<awygle> or at least an example on the other end of the spectrum
<whitequark> yeah, that's what i meant, wasn't clear
<awygle> someday maybe i'll be in charge enough of something to experience this. currently i'm squarely in the position of "this doesn't sound like something that would be that difficult for me to handle, but also the odds against me being special here are extremely long, so maybe i'll just keep my damn mouth shut"
<awygle> but i find it an extremely interesting ... area of study? sociological circumstance? whatever it is it's a very interesting one
<whitequark> making decisions that you know come with near-permanent consequences and will definitely negatively impact someone is draining
<whitequark> (if it isn't, consider running for political office)
<awygle> this is maybe part of a larger thesis but i think this is a hugely underestimated consequence of rust's backwards compatibility stance (which i'm on record as saying is bad for other reasons)
<awygle> every discussion has this immense weight of finality to it
<awygle> it has to be incredibly taxing on the people with decision-making power
<awygle> and it motivates the worst kinds of open source entitlement
SpaceCoaster has quit [Quit: ZNC 1.6.5+deb1+deb9u2 - http://znc.in]
<whitequark> this has very little to do with backward compatibility
<whitequark> do you think python is any more free to break backwards compat? after the 2-to-3 migration?
<awygle> heh
<whitequark> there are actually people calling for a literal coup in the python developer team because they think that team no longer represents the interest of the majority of python users
<sorear> how much better is python doing than rust on this front? I seem to recall guido quitting
<awygle> yeah that's approx. what started this discussion
<awygle> isn't a coup on the python developer team a fork?
<whitequark> sort of, i'm trying to find the post i've read about it and failing
<whitequark> it struck me as even more radical than calling for a hostile fork when i've read it
<whitequark> but yes, more or less
<awygle> that is _definitely_ part of a larger thesis then. i would write down how i feel about all this if i thought anybody was interested in reading it, but like i said above, i've never been in the position so i'm not sure my thoughts are valuable here
<_whitenotifier-3> [nmigen] whitequark commented on pull request #349: setup.py: add "wheel" to setup_requires - https://git.io/Jvp1U
<awygle> trying not to give my innate techie arrogance too much leash :p
<whitequark> i think this is called "being young"
<whitequark> as in "young and foolish", not necessarily literally
<awygle> i was gonna say i've never had the impression we're that far apart in age
<awygle> but i take your point
<whitequark> i know people almost a decade younger than me but much wiser than me today
<whitequark> so it's not about age
<awygle> brb, gonna go invent a programming language for The Experience (TM)
<whitequark> absolutely do it imo
<awygle> i do intend to
<whitequark> you might spend the rest of your life writing the same compiler over an over
<whitequark> i wrote *basically* the same compiler, what, three times already?
<awygle> if only because it does seem quite intimidating and that probably means i should do it
<whitequark> i hope i never implement a dynlang again because i swear that might be the worth
<whitequark> oh
<whitequark> yeah
<whitequark> i don't find it intimidating except in one aspect
<whitequark> languages are anti-composable. the smallest change you make affects the entire rest of the thing
<awygle> an interesting way to put it
<awygle> mmm gotta get to work. thanks for the discussion, always a pleasure :) and thanks for teaching me about python
<_whitenotifier-3> [nmigen] Success. Coverage not affected when comparing 0e40dc0...8acb27b - https://codecov.io/gh/nmigen/nmigen/compare/0e40dc0a2d336945dfe0669207fe160cafff50dc...8acb27bf155db6c3e89e7bfd705c7bac89400528
<_whitenotifier-3> [nmigen] codecov[bot] commented on pull request #349: setup.py: add "wheel" to setup_requires - https://git.io/Jvp1g
<_whitenotifier-3> [nmigen] codecov[bot] edited a comment on pull request #349: setup.py: add "wheel" to setup_requires - https://git.io/Jvp1g
<_whitenotifier-3> [nmigen] codecov[bot] edited a comment on pull request #349: setup.py: add "wheel" to setup_requires - https://git.io/Jvp1g
<_whitenotifier-3> [nmigen] codecov[bot] edited a comment on pull request #349: setup.py: add "wheel" to setup_requires - https://git.io/Jvp1g
<Vinalon> speaking of languages, I've always liked the idea of flow-based ones like node-red. But it seems like "schematic capture" kind of came and went with digital circuit design
<whitequark> you can't put schematics in version control
<whitequark> or rather, you can, but you can't merge them
<Vinalon> ohhh...yeah, that's a pretty big downside
<whitequark> the other problem is generic code
<whitequark> imagine you're making a reusable power supply module
<whitequark> in a PCB EDA tool
<whitequark> first, you'll need to make values follow some sort of variables and formulas. that's pretty easy (however for some reason no EDA tool i know of implements it anyway)
<whitequark> then, you'll need to optionally populate some parts of the circuit and some not, say if you have a 5 channel buck converter but you need 3 channels
<whitequark> that's doable too
<whitequark> but the moment you need to change the netlist, especially change in ways that aren't expressible by something like a simple mux--say, if you're repeating a part of the circuit a number of times derived from a formula--you're pretty screwed
<whitequark> azonenberg used SystemVerilog instead of schematic capture to design some of his boards bescaue of this, and I tried to evolve that idea into a Migen-like PCB design tool
<whitequark> which never materialized unfortunately
<Vinalon> I was going to say you could probably make a 'node' for that sort of thing, like I use the same symbols for generic 3-pin regulators a lot...but guess I don't ever try to make that part of some sort of automated toolchain
peepsalot has quit [Read error: Connection reset by peer]
<cr1901_modern> whitequark: I still have PCBHDL stuff in my todoist lmao
<whitequark> I've largely given up on the concept, and here's why
<Vinalon> one of my dreams is to make a zachtronics-style EDA game where your solutions could actually work in the real world...but that's probably up there with writing a language in terms of pipe dreams
<whitequark> when you debug an FPGA netlist, how do you do it? well, you have formal verification, and you have simulators
<whitequark> when you debug a PCB netlist, how do you do it? you trace wires by hand, like a caveman
<whitequark> schematic capture tools are almost misnamed. their primary purpose is not schematic /capture/, in the sense of turning your ideas into computer readable netlists
<Vinalon> I've always wanted to try topo-r...but don't FPGAs have a predictable set of input/output connections?
<whitequark> their primary purpose is to produce human readable documentation you can debug your design with, and they also happen to produce a machine readable netlist
<whitequark> so by throwing away the ever-so-inconvenient graphical part we're chopping off not a secondary but a primary purpose of a tool
peepsalot has joined #nmigen
<whitequark> i think azonenberg's systemverilog PCB hack is extremely cool, but i'm not sure if it scales beyond a single person who wrote it
<cr1901_modern> And for some threshold of complexity, good luck getting to the machine-readable netlist when you only have the "human readable documentation". >>
<cr1901_modern> There's a reason people say "schematics only" isn't FOSS hardware
<whitequark> i thought they say that because layout is as important as schematics
<whitequark> for old designs, because you need the mechanical specs too. for less old designs, because of decoupling, signal integrity, etc
<cr1901_modern> I'm putting layout under that too. What I mean is without conversion to a computer format, your ability to quickly and incrementally modify a design is much more difficult.
<Vinalon> it probably would be hard to modify something if you only had like, a PDF schematic and a set of gerber files, huh?
<cr1901_modern> I think it's morally equivalent to supplying obfuscated code as source
<whitequark> there is a lot of open source software you cannot "quickly and incrementally modify" even though you have all the source code lmao
<cr1901_modern> and calling it FOSS
<cr1901_modern> it's deliberately making the task more difficult
<whitequark> yeah, i get what you mean
<Vinalon> I dunno if it's always deliberate, though; organization is hard.
<Vinalon> sounds like a pretty common open source problem, huh? :P
<awygle> what i want from PCB EDA (yeah hi i'm not working but we all knew that was a lie right?) is simultaneous scripting and manual editing. i'm picturing a Visual Studio-like interface, with a central area where the schematic/layout is kept and a lower console pane where you have an interactive e.g. python session.
<awygle> then add some (imo) fairly basic features like constraint-driven layout on top of that
<whitequark> doesn't kicad actually have that?
<whitequark> the python console
<awygle> yeah but it's kinda... secondary-feeling. and it works inconsistently between schematic and layout.
<whitequark> right
<Vinalon> it would be cool to see that as a first-class feature
<whitequark> kicad is kind of inconsistent between schematic and layout
<whitequark> in general
<awygle> or at least it did, idk if they've improved it. kicad's biggest problems are mostly "it's very old"
<Vinalon> I think it's seen a lot of active development lately tho
<whitequark> it's pretty nice no
<whitequark> *now
<whitequark> it still has a ton of legacy unfortunately, often not very good kind of legacy
<awygle> it's definitely better
<awygle> call me when it has fonts in eeschema >_>
<awygle> i think maybe PCB EDA is one of those things like todo list apps where there's an infinite market because everyone's brains are shaped slightly differently on the topic
<awygle> for example i hate the way kicad manages components, but every attempt to replace kicad, many of which list "the way it handles components" as what they want to change, has somehow made it worse in my opinion
proteus-guy has quit [Ping timeout: 264 seconds]
proteus-guy has joined #nmigen
____ has joined #nmigen
rohitksingh has quit [Remote host closed the connection]
rohitksingh has joined #nmigen
Asu has joined #nmigen
<anuejn> I found horizon eda to work rather nice for me
<anuejn> It is a bit like kicad (uses their interacive router) with a different part management system and less legacy
<anuejn> And good usability on notebooks :)
Sarayan has quit [Remote host closed the connection]
Sarayan has joined #nmigen
pinknok has quit [Remote host closed the connection]
hhmmnn has joined #nmigen
Vinalon has quit [Ping timeout: 256 seconds]
proteus-guy has quit [Ping timeout: 256 seconds]
_franck_ has quit [Ping timeout: 250 seconds]
hhmmnn has left #nmigen ["ERC (IRC client for Emacs 26.1)"]
_franck_ has joined #nmigen
<_whitenotifier-3> [nmigen] whitequark commented on issue #291: Need a way to attach attributes to memories - https://git.io/JvhTi
<_whitenotifier-3> [nmigen] whitequark closed issue #291: Need a way to attach attributes to memories - https://git.io/JvZVK
proteus-guy has joined #nmigen
proteus-guy has quit [Ping timeout: 256 seconds]
peepsalot has quit [Ping timeout: 240 seconds]
<whitequark> anuejn: horizon eda is good for people who make their own bespoke footprints for every passive
<whitequark> libraries in general
peepsalot has joined #nmigen
<anuejn> whitequark: well, almost
<anuejn> it is not _that_ bad but i get what you mean
<whitequark> i refuse to use a EDA tool without a proper standard library, like what kicad has
<whitequark> yes, kicad's is flawed, in ways some of which are significant
<whitequark> that should inspire you to do do better. EDA is a pile of garbage stuck in the 80s. make it not so.
<MadHacker> I think that's the minimum entry price to the market, frankly. You've got to have at least a reasonable library.
<whitequark> this is like having a HDL without an async FIFO in the standard library
<MadHacker> (I confess, I use evil not-open-source tools for EDA - DipTrace)
<MadHacker> Nowadays I'm not even sure not having a 3D library for STEP output etc. is OK.
<vup> whitequark: what do you think isn't proper about the horizon library? My main complaint would be that it is rather small, but that doesn't seem like a fundamental flaw and more due to its low number of users
<whitequark> vup: hm, looks like it grew a bit since I last looked
<whitequark> but yes, that's the general problem. I really don't like making footprints, and having a community of people who review them as well as reasonable guidelines (KLC) is super valuable
<vup> ok, i see
<vup> if your main problem is the footprints, horizon eda can import kicad footprints, which could help, but of course is not perfect, because of different guidelines regarding silkscreen and such
proteus-guy has joined #nmigen
<whitequark> oh, hm
<whitequark> okay, i should check it out then
Vinalon has joined #nmigen
<tpw_rules> is there such a thing as a pipelined state machine? like suppose mine goes WAIT -> START -> BUSY -> FINISH -> WAIT -> START -> BUSY -> FINISH. i can make it faster by checking in FINISH if the conditions for WAIT->START are satisfied and going directly to START. or i can check in BUSY and then have FINISH do the work of START and go right back to BUSY. but this involves lots of duplication and a weird state machine
<Degi> Hmm you can choose which state it changes to
<Degi> Like "with m.If(A):\n m.next="START"\n with m.Else():\n m.next="WAIT"
<tpw_rules> sure. but then i have A in both FINISH and WAIT
<Degi> So you have the logic for A in FINISH as well as WAIT with the code I posted?
<tpw_rules> yes
<Degi> I mean you could make a python function with that code and then use it in both states of the FSM
<tpw_rules> how else does WAIT know to go to START?
<Degi> Hm I'm not sure what wait does
<whitequark> this is something i've been thinking about in regards to the new FSM mechanism
<tpw_rules> sure, or even make it a comb Signal. but is there some sort of conceptual framework to make that easier?
<whitequark> a few people noticed it's quite underpowered, awygle for example
<whitequark> there currently isn't
<tpw_rules> even completely outside of nmigen?
<whitequark> not that I'm aware of
<whitequark> but note that my knowledge of the topic is limite
<tpw_rules> i wonder what other people do in that case
<whitequark> i write awfully large FSMs
<whitequark> with a lot of copy paste
<whitequark> which is obviously not ideal but it does work
<Degi> Hm cant you reuse python code by putting it into a function and calling that from the states?
<whitequark> you can
<whitequark> you couldn't really do it in Migen, and the FSMs I wrote (like the I2C one) date back to Migen
<Degi> Ah okay
<Vinalon> sometimes I do that with small stuff, like a 'trigger_interrupt' function that saves and changes a CPU's PC, updates flags, etc. But I kind of worry that it obscures the marginal complexity that you add by calling the function
<Degi> Hm I mean putting it inside of a function shouldn't change the gateware as long as the same calls to nmigen are made, right?
<Vinalon> yeah, just conceptually; maybe it's because I don't have a good handle on how expensive different kinds of logic are
<Degi> Kinda same, I'm pretty new to FPGAs...
<Degi> At least it tells you after compilation how much of what has been used...
<Vinalon> sometimes I also put the most 'common' logic outside of the FSM/switch case/etc, and only override it in the special cases. Is that less efficient than copy/pasting the 'common' logic only in the places that it is required?
<Degi> Hm you could try it out and then look at the output... Add 'import os os.environ["NMIGEN_verbose"] = "Yes"' somewhere into your code for the output
<Vinalon> I guess for that to be relevant to tpw_rules' question, you'd have to be able to set 'm.next' from outside the FSM, and it looks like you can't
<Degi> Hm you can change the m.next based on a signal and set that signal from outside the FSM I think
<whitequark> making it possible to set m.next outside the FSM is one of the things that are much easier to fix
<Vinalon> I'm not actually sure if having 'default' logic which gets overridden later in the design is a good pattern, though; it seemed to slightly improve my design when I replaced it with more verbose and specific logic.
<Vinalon> but that's a sample size of like, three, and it could just be my design
<whitequark> improve how? readability?
<Vinalon> slightly better timing and fewer LUTs, but iirc the differences were small enough that it could just be down to the toolchain's mood at the time
<Vinalon> Personally I think having 'default' logic is a little easier to read because there's less duplication, and it does seem useful for FSM logic.
<Vinalon> like, to what tpw_rules was saying, I have a CPU's 'execute' stage with `m.d.sync += self.pc.eq( self.pc + 4 ) \ m.next = "IFETCH"` right at the top, because that's what most instructions end up doing
<Sarayan> wq: Did you see how Kate writes her code? It's very interesting
<whitequark> Vinalon: I would not put too much into minor differences in LUT count, unless you use -abc9 the LUT counts tend to be fairly random anyway
<Vinalon> oooh, I didn't know you could go higher than -abc2. Yay, thanks
<daveshah> They aren't really related
<whitequark> Sarayan: a bit, any specific highlights?
<daveshah> abc2 is a horrible hack that runs abc twice but usually makes things worse
<daveshah> abc9 is a new interface with abc that enables timing driven mapping
<Degi> lol
<daveshah> (said interface started from version 9 of ABC)
<Vinalon> haha, shows how much I know; thanks for the context
<Degi> is --abc a yosys option?
<_whitenotifier-3> [nmigen-soc] whitequark reviewed pull request #12 commit - https://git.io/Jvhqo
<Sarayan> wq: I lost my history, lemme see if I can find it again
<daveshah> No, there is no -abc because that is the default
<Sarayan> endpoint.py for instance is intriguing
<tpw_rules> uh i wish i knew Past/Rose/Fell existed before
<tpw_rules> is nmigen even docgenned anywhere?
____ has quit [Quit: Nettalk6 - www.ntalk.de]
<whitequark> no, this is something i should be fixing right now
<ktemkin> tpw_rules: took me a bit to realize those existed, too :)
<Vinalon> Sphinx's default setting seems to work okay for making some local searchable HTML docs, fwiw
<tpw_rules> something i keep making (in addition to those) which may exist but should if it doesn't: a set/reset signal. a set input and a reset input. if either set is asserted or reset is asserted, the output becomes asserted or deasserted respectively. if both are, which one depends on if it was instantiated with set priority or reset priority
chipmuenk has joined #nmigen
<Degi> Oh neat, so Past is the signal from 1 clock ago, Rose when it just rised and Fell when it just fell? That's really nice
emily has quit [*.net *.split]
awygle has quit [*.net *.split]
awygle has joined #nmigen
emily has joined #nmigen
<whitequark> these are actually inherited from SVA
<whitequark> but you can use them in normal logic too
<whitequark> they'll be appropriately deduplicated into optimal chains of FFs and gates
<awygle> Wow that was a huge net split, wonder if I missed anything
* awygle checks log
<MadHacker> Not here you didn't.
<MadHacker> Four whole minutes of silence. :)
<awygle> Oh yeah, past/rose/fell are great. I should file an issue proposing moving them out of the formal stuff so they're more discoverable. Not sure where they want to go though...
<awygle> "conditional = m.If" is either brilliant or horrific and I'm not sure which
<awygle> Maybe both
<tpw_rules> y th
<tpw_rules> o
<Degi> Hm you could make a python script reading a python script and replacing ordinary python if then stuff with m.If and m.Else lol
<Vinalon> wow, that is cool; I just tried using Past to replace a 'previous program counter' signal, and it shortened the critical path by like 500ns.
<Degi> Wow
<awygle> As for fsm stuff I'm playing with an implementation of hierarchical state machines I hacked together right now. It's fun, we'll see if it actually works out
<Vinalon> and that does look like a cool way to generate If/Elif chains with a for loop - it seems nicer than something like choosing between m.If/m.Elif based on a boolean
<tpw_rules> oh. i solved that problem by leading with m.If(False)
<tpw_rules> then for x in whatever: with m.Elif(some_deal == x):
<Degi> Why not use cases?
<awygle> why not emit multiplexers
<awygle> that's what i was planning to do/am currently doing
<ktemkin> Degi: they're not semantically equivalent
<tpw_rules> mine was a big fat priority encoder
<Degi> Hm dont the muxes only allow for selecting between two values?
<ktemkin> an m.If/M.Elif chain generates priority encoders
<ktemkin> (which then drive mux selects)
<tpw_rules> i'm not sure if my approach is more brilliant/horrifying though
<Degi> Oh
<Degi> And cases doesnt do that?
<tpw_rules> no because they can only look at one variable
<awygle> i mean it'll eventually emit muxes like ktemkin said, so idk why we wouldn't drop to that level personally. but maybe there's a good reason i'm not aware of?
<Degi> Hm right, the cases only work on constants...
<tpw_rules> i guess you could just be like scary_large_mux = Mux(False, 0, <default>); for xi, x in enumerate(whatever)[::-1]: scary_large_mux = Mux(x, xi, scary_large_mux)
<ktemkin> awygle: for cases like with m.If(condition_A) / m.Elif(condition_B), why not have the language generate the priority logic for you?
<awygle> i guess that's convenient. idk i'm running into mental conflicts viz "is nmigen a gate description language or a higher-level hardware design language"
<awygle> feel mentally like i'm reaching for nmigen.lib.priority_encoder
<awygle> which i don't think exists and anyway it'd be called PriorityEncoder because this is python not rust
<ZirconiumX> I converted some code from C to nMigen (it uses mostly masking) and I'm wondering how/if I can make it more idiomatic...
<ZirconiumX> Like, because it's designed to be branchless there's no real room for m.If etc
<ZirconiumX> I dunno, I'm rambling to myself a bit
<ktemkin> awygle: you can adopt structural -or- behavioral paradigms in nmigen; so it's as possible to say <generate the select logic> --> <build your mux with it>
<ktemkin> I suspect the case of my code mentioned above is a bad example for this particular discussion, anyway
<ktemkin> my priority encoders there are stand-ins that'll eventually be replaced, in many cases, with good ol' or-the-signals-together bussing; the priority encoders just make it more obvious what's going on in simulation
<ktemkin> or "I'll optimize once things are functionally correct"; however you want to phrase that~
<cr1901_modern> "The unoptimized version is the specification"
<ktemkin> also: "I thought you said it was functionally correct, now" / "sure, but it could be functionally correcter"
<MadHacker> Correctificationed.
<awygle> lol
<awygle> i feel like i spend a lot of time in this channel in sort of undirected confusion
<tpw_rules> s/in this channel //
<awygle> well, yes :p but it's more obvious and more public here
<cr1901_modern> Confession: I actually have not written anything substantial in nmigen.
<cr1901_modern> But that's also true about HDL in general for over a year.
<awygle> my immediate confusion is "wait, didn't we all agree like two days ago in this channel that the distinction between nmigen and verilog was that nmigen didn't try to do behavioral stuff because python exists"
<ktemkin> are you confused specifically by me saying "you can adopt structural or behavioral paradigms"?
<ktemkin> I can see how that'd be confusing
<ktemkin> in Verilog, you often describe "abstract behaviors", and let the synthesis tool figure out what the logic is that implements your behavior - you let the tools "infer down" from your description
<ktemkin> in nMigen, you start with a collection of concrete transforms on netlists; and build your way up from there
<ktemkin> you can reach behavioral levels by taking those concrete transforms and using them to build abstractions
<ktemkin> it's like you're building a "vocabulary" out of those concrete pieces, and then using that to express your ideas
<awygle> right, but "why not let the language generate the priority logic for you" doesn't sound like "a collection of concrete transforms on netlists", particularly
<awygle> i have that foggy "we're having slightly different conversations" feeling
<awygle> possible that i'm just taking things too literally/extremely
<ktemkin> "why not let the language generate" <-- yeah, I mean "why not use python to strum along nMigen in such a way that it does this"
<ktemkin> or, in the simple case of m.If(a) / m.Elif(b), I mean "why not just use the nMigen constructs that do this?"
<awygle> think i'm just getting hung up on philosophy
<whitequark> awygle: lemme try this from another angle
<whitequark> verilog gives you a few primitives to describe time evolution of abstract fully asynchronous systems, and that's it. it's down to you to use a specific subset of everything expressible with these primitives to describe a "synthesizable
<whitequark> " system, and if you don't? well, all bets are off. you might get an error, you might not
<whitequark> then you get a very similar situation in a fractal-ish way with memories
<whitequark> in both cases, the synthesizable subset is, either going by the spec, in practice, or both, not actually consistent with simulation behavior anyway
<whitequark> nmigen gives you a few primitives to describe time evolution of synchronous systems, plus a few explicit ways to connect them to the asynchronous world and between each other
<whitequark> in verilog, what does an "if" translate to? it could be a priority encoder. it could be a D-latch. it could be a D-flipflop with async set/reset. it could be an SR latch (in which case 1364.1 semantics does not match 1364 semantics, oops). it could be a memory port enable signal.
<whitequark> in nmigen, m.If translates to a priority encoder. that's it.
<whitequark> if you want a DFF, you name it explicitly. if you want a latch, you use an instance. if you want a memory port with particular control signals, you say that
<Degi> How would you instance a latch? Is that FPGA specific?
<whitequark> a goal of nMigen I have is to make sure that any code you can write without using instances would be (a) synthesizable and (b) deterministic insofar as the inputs are
<whitequark> this isn't *quite* what we have right now. there's no CDC checker. you can write a logic loop. there is memory-related weirdness on Xilinx platforms, etc. but this is how it *should* eventually look like
Asuu has joined #nmigen
Asu has quit [Ping timeout: 250 seconds]
<whitequark> awygle: does this make sense?
<whitequark> Degi: you can instantiate a $dlatch Yosys cell, for example
<awygle> It does, but it doesn't really connect to what we're talking about, for me. I get that unifying synthesis and simulation is a desirable thing to do, but I don't see how it relates to whether nmigen design is structural, behavioral, or both
<whitequark> awygle: can you describe the nature of "structural" and "behavioral" approaches in your own words?
<awygle> I guess the simplest distillation would be "in structural design you instantiate an Adder (or more specifically a KoggeStoneAdder or whatever). In behavioral design, you type '+'"
<whitequark> right, okay
<awygle> In behavioral design you specify a behavior (add these two numbers). In structural design you describe a structure (a Kogge-Stone adder)
<whitequark> this is a completely different definition of "behavioral" that i think ktemkin is using here
<awygle> that would certainly explain the confusion
<ZirconiumX> Am I the only one who misses the combined &=/|= operators in synchronous nMigen code?
<ZirconiumX> So I have to write, say, foo.eq(foo & ~bar), instead of foo.and_eq(~bar)
<awygle> i miss ++ tbh
<Degi> Same
<ZirconiumX> I've built the mother of all priority encoders, I think...
<ZirconiumX> I need to select one of 17 outcomes...
<tpw_rules> sorry but i built it last week. 65 outcomes, switching 4 bits
<ZirconiumX> You have me beat there, then
<ZirconiumX> But I'm switching 128 bits :P
<ZirconiumX> Well, that's not strictly right
<tpw_rules> also i put that comment specifically on it
<ZirconiumX> "128 bits at a time", but in total like 2*16*64 = 2048 bits :P
<ZirconiumX> And these are fed from 16 64-bit combinational subtractors
<ZirconiumX> I'm sure the synthesis tools will *hate* this
<tpw_rules> yours may be worse then. but i'm still mad you stole my comment :P
<ZirconiumX> (I think I can break up the 64-bit subtractors by manually informing the synthesis tooling of don't care inputs)
<ZirconiumX> But yeah :P
<ZirconiumX> My code is bad enough that WQ herself called it cursed, but it runs at 90MHz on an iCE40, 120MHz on ECP5 (with Diamond; it won't route under nextpnr), and 200MHz on a Cyclone V
<tpw_rules> what does it do
<awygle> "if it routes, it's very fast"
<ZirconiumX> Play chess
<tpw_rules> oh
<tpw_rules> is that why you were searching for tips on the chess wiki
<ZirconiumX> That and the chess programming wiki is my general bible when it comes to bit twiddling
<tpw_rules> i figured it was the second
<tpw_rules> and unrelated to the first
<ZirconiumX> I hate the chess programming community, but the tips on the wiki are great
<ZirconiumX> "toxic" doesn't begin to cover it
<ZirconiumX> Anyway, in general when you're working in 64-bit blocks, you end up with stupidly high fanout
<ZirconiumX> Which nextpnr no likey
<awygle> router2
<ZirconiumX> Last time I tried router2 it broke badly enough that daveshah upstreamed a fix because it had caused an integer overflow inside the codebase
<awygle> nice
<awygle> you should start counting
<ZirconiumX> I have quite the collection already
<ZirconiumX> https://github.com/YosysHQ/yosys/issues/1798 is still my favourite though
<Degi> I find it kinda funny how a 32 bit counter can run at 800 MHz lol. Like everything can run approx twice as fast as datasheet says, even the DDR interfaces
<ZirconiumX> Which chip?
<Degi> LFE5UM-5G-8
<ZirconiumX> ECP5 is not bad, although I've never practically pushed it much harder than 200MHz
<awygle> dave keeps telling me bad things about the serializers :(
<awygle> (to the point that i keep committing the cardinal sin of doubting him because it makes no fukkin sense to me)
<Degi> The high speed SERDESs?
<awygle> no, the 7:1 and 4:1
<awygle> i want to use them to do relatively-device-independent DDR2 stuff but apparently you can't have both a 7:1 and a 1:7 on the same pin
<Degi> Hm I've only used the 4:1 till now
<Degi> Oh
<Degi> I didnt try having them on the same pin heh
<awygle> i swear it seems like it should work by reading the docs. i'm gonna run diamond and actually try some stuff someday soon.
<Degi> Hm I think the DDRDLL or the other part for that thing for edge aligned stuff doesnt compile because it isnt implemented in yosys or nextpnr
<awygle> the DDR shit works
<awygle> but it's very chip-specific
<awygle> which makes me sad
<awygle> because it makes it hard to re-use
<awygle> whereas lots of FPGAs have a 7:1 serdes
<Degi> Hm why do you need 7:1 for DDR2? (I assume DDR2 RAM?)
<awygle> you don't necessarily
<awygle> but you aren't supposed to run the IDDR/ODDR too fast
<awygle> i think like 200 MHz?
<Degi> They work at 400 too
<awygle> sure but they're not rated for it :p
<Degi> But I cant make more than 900 MHz with the PLL so it is limited to 1.6 Gbit/s for now
<daveshah> A quick test a few days ago did suggest that 4:1 and 1:4 on the same pin works in hardware, at least to a basic degree
<daveshah> I expect the same for 7:1 but didn't test it
<daveshah> Diamond doesn't support 4:1 and 1:4 on the same pin though
chipmuenk has quit [Quit: chipmuenk]
chipmuenk has joined #nmigen
<awygle> it seems like actually the DDRX2 could max my particular DDR2 chip on the -8
chipmuenk has quit [Client Quit]
<awygle> but if i use the 7:1 i can max it on the -6
<awygle> i actually can't even find the "how fast can i run the 4:1" bit in the datasheet, odd
<Degi> It says more than 400 Mb/s
<Degi> So I guess up to 800? idk
<Degi> It work to 1600+
<awygle> oh
<awygle> no
<awygle> ddrX2 is the 4:1
<awygle> i was confused
<daveshah> 800Mbps is the official maximum
<Degi> Is it stated anywhere though?
<Degi> And is that speed higher for 5G variants?
<awygle> it's state on page 65 of the datasheet
<awygle> no distinction is made between regular and 5G
<daveshah> According the qualification summary, which is for non 5G (1.1V -6)
<daveshah> Generic DDRX2 modes were tested for error-free operation at 750, 1000, and 1300 Mb/s. No devices failed at 750 Mb/s, ~50% of devices/conditions failed at 1000 Mb/s, ~75% of
<daveshah> devices/conditions failed at 1300Mb/s
<daveshah> The regular DDR mode is actually faster
<daveshah> Generic DDRX1 modes were tested for error-free operation at 750, 1000, and 1300 Mb/s. No devices failed at any condition.
<awygle> that's odd considering the spec says 500 Mbps max
<Degi> huhh weird
<awygle> wait a minute. i'm confused by this table.
<awygle> GDDRX1 output: 500 Mb/s max, 250 MHz max
<awygle> GDDRX2 output: 800 Mb/s max, 400 MHz max
<Degi> Hm for a project I need a 1 Gb/s interface on a ECP5-5G... Maybe I could try using a x1 if the x2 has too high bit error rate...
<Degi> Where did you find the qualification summary?
<daveshah> It was linked from another Lattice pcn
<awygle> i love internally inconsistent datasheets... sigh...
<tpw_rules> i would figure they say 500mbps max so even the worst devices always pass
<tpw_rules> at the worst temperatures and voltages
<daveshah> Yes, and it's possible when they wrote that spec they were less sure of yields etc
<awygle> i am going to assume that my -6 12F with 25 kLUTs can also run at 800 Mbps :p
<Degi> Huh it says MLDS measured to 240.5 but spec is 400.0 on page 26 of what you linkd
<Degi> I mean try it out xD
<awygle> i'll need to do some kind of stressing test as part of board bringup but that shouldn't be too costly
<daveshah> The conclusion of some ring oscillator testing by tnt is that there is unlikely to be any difference between the grades
<awygle> my lattice contact implied that there used to be actual downchecking going on but then they figured out their process so now it's pure market segmentation
<Degi> downchecking?
<Degi> And couldnt they sell all devices as -8 now lol
<daveshah> That makes sense
<awygle> like for a while -6s were actually parts that failed the -8 testing
<awygle> but now nothing fails
<awygle> or it's very rare
<awygle> will be interesting to see what happens with the crosslink-nx parts actually
<awygle> wonder if we have sufficient depth of resource to track that over time :p
<Degi> Hm are all 5G parts -8
<daveshah> Yes
<awygle> yes. or more like -9
<daveshah> You can of course make any part a -9 by upping Vcc to the 5G 1.2V
<awygle> i was gonna ask you whether that was safe
<awygle> because currently the need for 1.1V is making me run a whole extra regulator on one board
<Degi> Huh is CrossLink next gen? They have 10G transceivers... neat
<daveshah> Absolute max is 1.32V
<awygle> goddamn do i want an ECP6
<daveshah> so it's safe
<daveshah> ECP6 is supposed to be later this year iirc
<Degi> Something like an ECP5 but wiht 16 SERDES at 8 Gbit
<awygle> yeah but that rumor is from the Before Times :p
<daveshah> or ECP NX or whatever they device to call it
<daveshah> It was planned to have a 6G serdes from what I've seen
<Degi> Hm wonder how long the toolchain will take to port...
<awygle> 6G is pretty lame tbh
<Degi> Yeah
<awygle> i was hoping for 10G
<Degi> At least more of them?
<daveshah> The CrossLink NX doesn't have a 10G transceiver it has 10G aggregate dphy bandwidth
<awygle> right, which is even lamer :p
<daveshah> ie 4x 2.5G lanes
<Degi> Thats worse than the ECP 5G
<daveshah> And a dedicated 5G serdes connected to a PCIe IP core
<awygle> what's even between 5 and 6 Gbps in terms of protocols?
<daveshah> But the regular IO can at least do 1.2-1.5Gbit/s officially
<Degi> A hard IP? How many channels?
<Degi> awygle: Maybe some more ADCs?
<daveshah> awygle: DisplayPort 5.4G
<daveshah> Degi: only 1
<awygle> oh, right, people care about video :p
<Degi> How many SERDESs will it have in total?
<daveshah> "ECP6"? No idea
Asuu has quit [Quit: Konversation terminated!]
<Degi> I kinda wonder if its possible to spread PCIe lanes over multiple devices and somehow glue them together with some logic... I mean the cheapest 5G is 13 € in bulk
<awygle> regular I/O at >1.25 Gbps is very useful to me though, so there's that at least
<daveshah> The only reason I'm guessing 6Gbps is a few references to "PCS6" in Radiant
<daveshah> The CrossLink NX only supports regular IO at 1.5Gbps in one package iirc
<daveshah> Otherwise it is 1.25Gbps max
<awygle> still fine. i just want to run SGMII
<awygle> and 1000BASE-X
<Degi> Hm is it possible to decode 8b10b without using physical serdes's?
<awygle> sure, why not?
<Degi> I guess as long as you can somehow feed that to a PLL...
<daveshah> The NX has hard SGMII CDR
<awygle> you probably don't even need that, you can just tweak an IDELAY until you get the training sequence without errors
<daveshah> If you have a reference clock then it is very easy
<daveshah> Otherwise you have drift to worry about
<Degi> Huh there's variable IDELAY primitives?
<awygle> that's true
<awygle> oh yeah f'sho
<daveshah> Yes, DELAYF for ECP5
<awygle> don't SGMII PHYs respond to the host with a clock derived from the transmit clock?
<awygle> so shouldn't it be fairly phase-locked?
<awygle> or do they have separate reference oscillators?
<Degi> Ooh DELAYF looks useful
<Degi> Do you know how many steps it has and what 1 step size is?
<awygle> the total sweep is about 2.5 ns
<awygle> or no
<awygle> that's the artix
<awygle> nvm
<daveshah> Each step is nominally 25ps
<daveshah> 128 steps in total
<awygle> nothing in this phy datasheet indicates whether the SGMII RX embedded clock would be based on the TX embedded clock, bummer
<awygle> oh well
<Degi> How many DELAYFs does the ECP5 have? Nextpnr doesnt seem to state that (or is it DCCA?)
<ZirconiumX> daveshah: ^
<awygle> I think every pin has one
<awygle> Or maybe two
<Degi> Oh neato, is it possible to route the output of the DELAYF back into fabric too?
<Degi> *input and output at the same tim
<ktemkin> there's one per IOLOGIC tile, IIRC
<Vinalon> can you toggle iCE40 pins between high-impedance and output modes at runtime?
<awygle> yes
<Vinalon> how d'you do it in nMigen? Can you set the 'dir' property of a 'Pins' object?