<ktemkin>
there's some stuff in `nmigen-soc` paralleling the old misoc stuff that'll get you a bit of the way there
<ktemkin>
lemme grab a log with an explanation in it
<ktemkin>
the instantiation is done with Instance
<ktemkin>
yep
2020-12-10
<Bertl_oO>
whitequark: ktemkin: what's the current state of the art for an USB 2.0 sniffer/tool which can optionally also alter the communication (PITM)?
<ktemkin>
the exercise game I'm playing while my toes are broken?
<ktemkin>
oh
<ktemkin>
I am really going to need context
<ktemkin>
is it meeting-ish time?
<ktemkin>
I have no idea how time works anymore
2020-11-14
<key2>
ktemkin: what is the status of isochronious in Luna ? I see some code in the repo but the readthedoc doesn't say much
2020-11-13
<mithro>
@whitequark / @ktemkin - Do you know if there is a diagram somewhere which shows where the various bits in the PCIe stack map to things like LitePCIe / ECP5-PCIe / Yumewatari ?
2020-11-10
<ktemkin>
there’s already some hacks (.request_optional) in place that make that work that you may not want to take to extremes outside of the examples
<ktemkin>
I mean, top-level modules maybe shouldn’t be considered necessarily generic; I just have them genericized in LUNA to make it easy to run the examples on whatever platform :)
<ktemkin>
but it’ll require you to tweak each example you want to use
<ktemkin>
the latter is what you want for real usage on a platform like that
<ktemkin>
and then drive the signal yourself
<ktemkin>
otherwise, add handle_clocking=False to the USBDevice instantiation, and then use xdr={‘clk’: 2} in your .request to create the DDR buffer
<ktemkin>
I suspect you can use that construct to split the clock domain in a way that works with the examples
<ktemkin>
check out the Genesys2 platform in LUNA for an example of custom clocking that works with the default examples
<Shari2_>
ktemkin: I need the ulpi clock to be and output my platform (Spartan6) and to output a BUFG clock a ODRR is needed. So the question is how and where to set the xdr attribute for ulpi clk.
<ktemkin>
oh, I might see
<ktemkin>
what’s the question?
<agg>
maybe ktemkin will have ideas when she's around
2020-11-09
<lkcl>
ktemkin: regarding use-cases if nmigen was its own language: yyep, i hear you. hilariously quite a lot of libre-soc is like this:
<ktemkin>
I owe y'all that at some point
<ktemkin>
incidentally, I feel bad that I haven't made more of a meaningful contribution to nMigen thus far
<ktemkin>
you're pretty far from the Jerk Bin
<ktemkin>
awygle: we've had way more purely-positive conversations than I've ever had critiques
<ktemkin>
was just hoping to provide context; I really don't want to make you feel bad
<ktemkin>
awygle: apologies from over here, too, for being critical/argumentative. I'm sure I was projecting a fair amount through the discussion. >.>
<ktemkin>
mm
<ktemkin>
awygle: it didn't feel like "fucked up badly" territory; I just recognized "I don't know if I like <thing you happen to be doing>" as something that would have triggered my guilt-reflex
<whitequark>
i agree with ktemkin
<ktemkin>
awygle: but generally, I like to keep my philosophical conversations like that nice and distant from any actual implementation
<ktemkin>
awygle: I think a lot of this theory is super fun to discuss, and would be great for conversation-over-a-beer-style-discussion
<ktemkin>
yeah, this conversation seems closer to what I meant, there
<ktemkin>
personally, I think nMigen does a pretty damned awesome job of being elegant within the constraints of practicality
<ktemkin>
I mean, I'm referring to an label derived from observation of myself, rather than anything tied to identity
<whitequark>
ktemkin: i kind of generally stopped considering myself... anything in particular. i try to discuss traits and their consequences while tying them as little as possible to identity
<ktemkin>
at this point, I don't really know if I'd consider myself a perfectionist, anymore
<ktemkin>
personally, I read you as staring wistfully out a window at the beauty hovering out of reach =P
<ktemkin>
I think it may be the only way to survive in tech without having your soul crushed =P
<ktemkin>
awygle: I've learned to find beauty in the inelegance that emerges when you actualize things
<awygle>
ktemkin: i both agree with that statement and will fight against it until my death
<ktemkin>
and once you pull things out of theory and into the usable, you wind up leaving little bits of elegance behind
<ktemkin>
elegance lives in theory
<ktemkin>
my point is, there are costs to loose coupling
<ktemkin>
awygle: I'll often modify my design / APIs as I implement, as challenges become apparent and/or I have better ideas
<Sarayan>
ktemkin: we shall know later then :-)
<awygle>
ktemkin: it really depends how you define those terms. i change my architecture between development cycles all the time, but rarely make major shifts within development cycles
<ktemkin>
Sarayan: haven't done any USB stuff yet; been in meetings
<Sarayan>
ktemkin: so, was it your code or was it usb being usb?
<ktemkin>
awygle: I mean, how often have you changed your architecture upon realizing something while developing?
<ktemkin>
but development is as often exploratory as it is implementative
<ktemkin>
"microservices are brutalism for API design, since you _must_ draw clear boundaries and all that" <-- this is a *lot* easier to do if the boundaries are already known, rather than something that becomes apparent over the course of development
<awygle>
which, mine or ktemkin's? i think ktemkin's is a bad thing
<ktemkin>
a lot of the development on that side shifted from "come up with a common interop" to "modify all of our _languages_ to behave closer to the same"
<ktemkin>
look at what happened after COM, though
<ktemkin>
awygle: the thing is, you can't just throw good developers at e.g. whitequark and expect that'd make things more productive
<awygle>
ktemkin: that's true and kinda falls into the "first step" category, because i don't think that's a fundamental state of being so much as a fucked-up industry
<ktemkin>
the more compatibility and abstraction you add, the more you spread those people out across things
<ktemkin>
there's a huge problem in that there's a limited number of People Who Can Do The Thing
<ktemkin>
I have _lots_ of things that have python functionality (GNURadio, FaceDancer, etc), and being able to use the existing code to orchestrate gateware construction *is* what I need
<whitequark>
ktemkin: agg: there are metaprogramming languages better suited to embedding a HDL than Python!
<ktemkin>
the thing is, if nmigen was its own metaprogramming language, it wouldn't support like 70% of my use cases
<ktemkin>
I thought "broken vendor tool" was saying the same thing twice
<Shari2>
@ktemkin target_ulpi.data.oe .eq(~target_ulpi.dir) TypeError: bad operand type for unary ~: 'Pin'. Is this a know issue? Currently trying to build master 70db91ced with python3 applets/interactive-test.py --dry-run.
<ktemkin>
pretty sure the initial research was a SBIR, one of those Small Business Innovation grants from the military
<ktemkin>
friendship ended with synchronous logic; null-convention-logic is my new best friend
2020-10-26
<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>
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
2020-10-25
<ktemkin>
but I’ll have to explain later, the thing Qyriad and I are watching is paused while I’m nerd sniped =P
<ktemkin>
you can abuse geared inputs though by phase-staggering your sample points
<ktemkin>
SerDes are expensive, PHYs are cheap
<ktemkin>
but again
<ktemkin>
it’d be interesting to explore 4/8 times oversampling + the SerDes link FSM/aligners to try and minimize CDR logic
<ktemkin>
rather than anything that’s controlling frontend sample points
<ktemkin>
ideally you set up your CDR so it’s just selecting bits from your input stream
<ktemkin>
it can be; but it’s more phase noise that’s your issue when you’re not given enough transitions to do CDR easily
<ktemkin>
and I’m actually thinking oversampling *more* might help reduce CDR logic
<ktemkin>
Degi: there’s actually a trade-off between the amount of oversampling and the amount of phase/etc noise you tolerate
<ktemkin>
apparently I can't type one half of a input/<whatever> without my brain trying to complete the other half to output =P
<ktemkin>
*IDELAY/internal-granular-delays
<ktemkin>
if you want to start being really clever about it, you can do a similar thing by bringing D+ and D- to multiple DDR pins and then using the IDELAY/ODELAY to oversample with phase offset
<ktemkin>
I just don't see any compelling reason to waste the resources on it when a USB2 PHY is so cheap and SerDes stuff is so expensive
<ktemkin>
CDR in fabric's not -too- terrible using the USB2 sync pulses if you've massively oversampled and then geared down enough
<ktemkin>
the most straightforward/reliable way to do it is to put the SerDes in 10BSER mode, bypass clock recovery, set your clock rate to ~2.4GHz so you're oversampling enough and then do a mix between clock recovery in logic and cheating (by abusing individual serdes' behaviors)
<ktemkin>
it’s just very silly
<ktemkin>
I’ve looked into it a bit
<ktemkin>
you *can* use these serdes for USB2, if you really want to
2020-10-23
<ktemkin>
AFAIK, the purpose of tagging a class with Elaboratable is pretty much entirely to make sure that class is used, so it'd have made sense to be able to not subclass Elaboratable to not get that tracking, but it's a bit damned-if-you-do, damned-if-you-don't
<ktemkin>
bit of a catch-22 there
<ktemkin>
oh, actually, strike that -- that generates a different stray warning
<ktemkin>
I mean, I'd imagine you can also just not mark your class Elaboratable, but define Elaborate() anyway
<ktemkin>
if you don't care about dirtying yourself by reaching into the nMigen innards, you can also just `my_elaborable._MustUse__used = True
<ktemkin>
you can suppress it for a whole file by sticking "# nmigen: UnusedElaboratable=no" at the top of your file
<ktemkin>
cr1901_modern1: depending on how hacky you want to be and what scope you want, you have at least a few options
<ktemkin>
not sure there's currently a use-case that makes 10Gbps worth it, yet, either as 5Gx2 or 10Gx1
<ktemkin>
anuejn: doesn't currently, could in the future
<anuejn>
ktemkin: does / will luna support multi lane usb?
<ktemkin>
I need a long break before I touch any more complex protocols / physical layers =P
<ktemkin>
key2: theoretically, eventually
<ktemkin>
it’s NRND, though
<ktemkin>
the TUSB1310A works okay-ish
<ktemkin>
I haven’t found a hard PHY other than that that’s acquirable
<lkcl>
ktemkin: nice
<ktemkin>
and ideally that'll include more than just the USB3 flavor of PIPE, eventually
<ktemkin>
going to pull the SerDes drivers from LUNA into a soft-PIPE library, so I should have PIPE interfaces for the ECP5, the GTPs, and the GTX that can be be used in place of a hardware PIPE PHY
<ktemkin>
I'm on vacation for the next week and a half, but when I get back I'm going to implement a bit more stack (bulk) and then work on figuring out if fixing clocking is good enough to solve the eye closure / bit error rate issues I was having with the ECP5s
<ktemkin>
I've been working on the gateware stack using PHYs
<ktemkin>
I need to retry everything now that the USB3 stack's core is done
<ktemkin>
she seems to be doing good well on it
<ktemkin>
key2: Degi is the one to ping re: ECP5-PCIe status
2020-10-20
<key2>
ktemkin: hi. did you manage to get Luna to work on ECP5 serdes finally ? ?
<whitequark>
the last time this happened was with ktemkin, i think awygle hit it before that
2020-10-17
<key2>
ktemkin: ahhahaha yeah so how do you handle that ?
<ktemkin>
well, assuming you still have input left to do that with =P
<ktemkin>
you can just disable and re-enable the driver for the root hub
<ktemkin>
key2: on windows?
<key2>
ktemkin: what happens if you use thunderbolt<>usb_host adapter or something like that ? you think it could save you from rebooting ?
<ktemkin>
so, for example, on Surface Pro 3, the USB port stops working and also the keyboard and mouse, since the keyboard/mouse cover for it is connected via USB
<ktemkin>
cr1901_modern: on USB3 it's a little worse, because instead of just taking down the device, Windows decides the problem is with the root hub
<lkcl>
whitequark, ktemkin: we have someone else interested in learning nmigen and HDL, i am referring people to robert baruch's tutorial for now, is there anything better available? (happy to link to "planned" tutorials as well)
<whitequark>
ktemkin: yeah
<ktemkin>
words have more than one meaning, it turns out
<ktemkin>
re-reading the backlog, I realize I should say Python-module-level
<ktemkin>
it is the worst and I hate it and it's probably the least keystrokes to getting quick debug output I've found
<ktemkin>
I don't know why I never thought of this before -- probably because it's incredibly cursed -- but creating module-level Signals is a really easy way to yoink a signal from like seven levels deep so you can shove it into an ILA
2020-10-14
<lkcl>
ktemkin: that's absolutely fantastic news about the nmigen+FPGAs workshop. very cool.
<key2>
@ktemkin is USB3 full or half duplex ?
2020-10-13
<ktemkin>
thanks
<ktemkin>
which would work well if there was time left over to actually produce the damned materials
<ktemkin>
so then I wind up building the tools I need
<ktemkin>
theoretically, I'm an educator first, and an engineer second; but every time I go to produce good educational materials, I find there aren't enough good tools to teach the way I want to
<ktemkin>
I find them fairly easy to make; I just find there's always a more pressing technical objective that prevents me from really sitting down and getting to make them
<ktemkin>
and hopefully I'll actually get around to producing all the educational resources I owe everyone
<ktemkin>
assuming it's ever safe to have people outside in the same space again
<ktemkin>
it sounds like there's going to be a good chunk of people taking FPGA workshops
<ktemkin>
considering Lattice is sponsoring making 5000 FPGA badges for a forthcoming hackercamp; and the Python-heavy badge team is leaning towards favoring nMigen
<ktemkin>
incidentally, it looks like I'm implicitly going to be drafted to create a "getting started with FPGAs using nMigen" workshop sometime in the next year or so
2020-10-12
<carlomaragno>
Lofty, lkcl, ktemkin it works
<ktemkin>
specifically, I found myself doing something similar, and only realized afterwards that it was likely the time I spent writing Ruby that left me with the feeling that I should be able to design APIs that get the host language the hell out of the way
<ktemkin>
whitequark: I think I only realized recently how much nMigen's use of context-managers feels Ruby-inspired
<ktemkin>
generically, avoiding multiple clock domains whenever you can avoids a lot of footguns
<ktemkin>
that's pretty reasonable, typically
<ktemkin>
nope
<ktemkin>
and then work with it like any other domain; e.g. `m.d.clk12 += a.eq(b)`
<ktemkin>
so if you have a domain called clk48, and you want to create a clk12 domain, you can do something akin to `m.domains.clk12 = ClockDomain()` / `m.d.comb += ClockSignal("clk12").eq(my_12mhz_divided_clk)`
<ktemkin>
carlomaragno: ClockSignal("<domain name>") gets a reference to the clock signal for a given domain; you can assign to it like any other signal
<whitequark>
ktemkin: oh i do that too
<Qyriad>
ktemkin: I lose the mental picture without a reference. If I delete the code I'll have to figure out how I did it all over again lol
<ktemkin>
I dunno; for me it's less about refining the code and more about refining my mental picture
<ktemkin>
I'll write several paragraphs of code, ponder for a second, and then just delete them all
<ktemkin>
I refactor constantly; it freaks Qyriad out
<lkcl>
ktemkin: interesting to hear that the primary intent behind what you do is not to "code" but to "communicate"
<Qyriad>
ktemkin: your comments aren't the stereotypical `int x = 5; // assign 5 to x` or anything. Yeah there's a lot of them, but they're all _meaningful_
<ktemkin>
Qyriad: if anything, I comment overmuch; I just write everything as if they were examples I was going to give to students
<Qyriad>
The last PR I submitted to ktemkin I was like "…are you sure it doesn't need more comments. maybe I should put more comments."
<ktemkin>
mm, scaffolding is good
<ktemkin>
aww; thanks ^^
<ktemkin>
what
<whitequark>
ktemkin writes phenomenally good code
<ktemkin>
>.>
<ktemkin>
at least as much as something can look like itself
<ktemkin>
it'll be there with SuperSpeed soon too, hopefully
<ktemkin>
miek: I try ^^
<miek>
ktemkin: *someone* made it so easy that you just hook up a fifo to it and it works :)
<carlomaragno>
ktemkin: it is
<ktemkin>
usually everyone runs from USB~ =P
<ktemkin>
it's still weird to see LUNA being actually useful for other people
<ktemkin>
IIRC, if they're not declared with local=True, yep
<ktemkin>
nothing urgent over here
<vup>
ktemkin: thank you :)
<ktemkin>
and yes, the int() isn't necessary, there
<lkcl>
ktemkin: interesting, thank you, that makes a lot of sense
<ktemkin>
which I assume was a decision made to avoid semantic ambiguity in cases like my_func(yield a, b)
<ktemkin>
(yield) marks yield as an expression rather than a statement
<ktemkin>
whitequark: is it in violation of your aesthetic to add a parenthetical, like `assert <...>, f"unexpected use of {sig.name} [possible assignment to input]?"`
<ktemkin>
but again, my preferences aren't strong at all, so that's mostly an aesthetic/theoretical comment =P
<ktemkin>
considering my go-to action when I see that and don't immediately realize the issue is to open ir.py and add a print
<ktemkin>
I mean, personally, I think I'd prefer a more useful AssertionError("Internal error processing `<signal name>`") just to give a breadcrumb for the time being
<ktemkin>
I mean, I'd think an exception as intermediary scaffolding wouldn't hurt; but my preference about it is so weak that I'll 100% defer to whatever seems best to you
<whitequark>
ktemkin: i can do some nmigen work in near future, so what do you say about just fixing it properly?
<ktemkin>
(which immediately becomes obvious if it even prints out prints out "TypeError: something bad happened with 'hitech_fmc_pipe_0__rx_termination__i' )
<ktemkin>
and experientially, I pretty much only see that assertion if I've done something stupid, like forgotten a .o on an inout signal
<ktemkin>
but even having a very ambiguous/not-detailed message that contains the signal name seems a lot more useful than just an AssertionError
<ktemkin>
mm; that's part of why I asked instead of PR'ing
<whitequark>
ktemkin: that part of the code is tricky and i never spent time to figure out if something like your patch would work well
<ktemkin>
(I don't know what that message should read, really; I'll admit I didn't stare at the codebase for long enough to get a good feeling for what it should say)
<ktemkin>
I finally got bitten by the "assert defs[sig] is self" one too many times and decided maybe it was worth replacing that assert
<ktemkin>
(the Memory however, winds up directly outputting a `memrd`, which is more or less Yosys for "hey! I'm describing the read half of a memory, here!")
<ktemkin>
s/in the memory backend/in the synthesis backend
<ktemkin>
strictly speaking, the Array of Consts might infer an equivalent structure in the memory backend; that's pretty much how you do it in e.g. Verilog
<ktemkin>
you can set the read port's domain to "comb"
<ktemkin>
for your LUT, once you have sufficient elements, you might be better off using a Memory without a write port
<ktemkin>
just like you provided
<ktemkin>
you can use comb-driven signals as inputs to other comb assignments
2020-09-24
<agg>
Suryo/ ktemkin: you can use just use the connector numbers directly and then put conn="name" inside Pins which saves a lot of typing when you have multiple pins
<ktemkin>
the bot is just the IRC bridge
<ktemkin>
ah, okay
<ktemkin>
including for the OrangeCrab and Mimas (not sure if it's the v1 or v2)
<ktemkin>
Suryo: if you're looking for how to come up with a platform file, there are quite a few examples in `nmigen_boards`: https://github.com/nmigen/nmigen-boards
2020-09-18
<ktemkin>
hardware? not until after I start selling the inexpensive USB2 design and start designing a much-more-expensive-but-USB3-and-friends one
<ktemkin>
awygle: gateware? yes; especially once the USB3 work is done
<ktemkin>
oh, nice; I accidentally typo'd "m.next =" as "m.next +=", and the infinite recursion that resulted was gnarly ^^
2020-09-02
<lkcl_>
convention "device under ..." lol beat me to it, ktemkin :)
<ktemkin>
Device Under Test
2020-08-31
<ktemkin>
awygle: decoder?
<ktemkin>
things that don't wind up connected in that graph wind up not translating into logic as a necessary consequence of routing
<ktemkin>
building and optimizing the nets that fan into a final signal (the whole structure of which is often called the "logic cone")
<ktemkin>
TiltMeSenpai: imagine yourself netlisting / routing -- in a very simplified sense, you'd be traversing a graph from output to input
<ktemkin>
TiltMeSenpai: I wouldn't even necessarily call "removed because unused" an optimization, strictly
2020-08-29
<ktemkin>
jeez, every time I go to port code from oMigen I find yet another collection of undocumented grab-bag style miscellanea in it >.>
2020-08-28
<awygle>
the contributor was ktemkin I believe
2020-08-27
<whitequark>
ktemkin: yep and yep
<ktemkin>
if you want to spread that role out, you need to have other people with the same sense of “what nMigen should be”
<ktemkin>
whitequark: tbh, one of the reasons nMigen works is because you‘re filling the role of “vision-haver & decider”
<ktemkin>
especially for others who want to do things but haven’t borne the burden of steering something like this
<ktemkin>
the hard part is conveying the general vision to others
<ktemkin>
dunno; maybe the answer is just to not be me =P
<ktemkin>
I’ve never found one.
<ktemkin>
I don’t know if there’s a good way to have maintainership be a shared/not-crushing burden.
2020-08-26
<Yehowshua>
ktemkin, been having a bit of trouble with Luna's ACM-serial valid ready interface
2020-08-23
<ktemkin>
I’ll swap that on Monday, unless someone wants to PR it first
<ktemkin>
imagined that subclasses might want FHDLTestCase methods
<ktemkin>
er
<ktemkin>
yeah, that’s the right fix; I think I just imagined that
<miek>
ktemkin: yeah, it's just as a base class. also it looks like you're not using anything from it, all the tests still pass after changing LunaGatewareTestCase to base off unittest.TestCase
<ktemkin>
... can’t properly seem to ignore github chatter, though >.>
<ktemkin>
(I‘m self-restrained from using my computer for these kinds of Work Things on Fri/Sat/Sun)
<ktemkin>
I’d be fine just implementing an equivalent in LUNA.
<ktemkin>
I can’t remember: do I use FHDLTestCase, really, or do I mostly use it as a base class?
2020-08-22
<Yehowshua>
ktemkin, heads up, I copied FHDLTestcase into luna.gateware.utils... Will attempt a pull request to get your thoughts
2020-08-18
<ktemkin>
TiltMeSenpai: you can, with current record semantics
<moony>
ktemkin: seems to add to it
<ktemkin>
I don't remember if it adds to or sets the list of displayed traces
<ktemkin>
moony: write_vcd takes a `traces` kwarg
2020-08-17
<ktemkin>
I've gone past that into running the hell away from (or heavily disclaimer'ing) most things
2020-08-12
<tannewt>
ktemkin: what is in your diamond environment file?
<tpw_rules>
ktemkin: augh
<ktemkin>
or a multi-FPGA HLS engine that targets being able to compile half of the C standard
<ktemkin>
pandemicc sounds like it’s a frontend for about half of many languages
<tannewt>
ktemkin: I got it working if I switched from pnmainc to diamondc. I don't have any environment variables. I just copied the license to the default path
<zignig_>
ktemkin: I finally have luna_acm and a boneless running at 12Mhz on my tinybx.
<ktemkin>
I can help with that when I’m awake if you run into more troubles
<ktemkin>
it works out of the box as long as you have the right environment file source’ing
<ktemkin>
for reference, Arch is where I run Diamond; both with nMigen and otherwise
2020-08-11
<ktemkin>
and yes, RFCs are Very Good
<ktemkin>
TiltMeSenpai: off the top of my head, I can imagine that as having a function like .add_report_item(), which takes both metadata that describes the type of the report item, and the signal that carries the relevant report chunk -- and then the module might Cat together the various report chunks appropriately and squish 'em in a SignalInEndpoint
<ktemkin>
TiltMeSenpai: in the same style that many of the LUNA modules are builders
<ktemkin>
TiltMeSenpai: for a generic HID IN endpoint, I was thinking of a builder around SignalInEndpoint