<ktemkin>
I haven't told people about it because I'm hiding from everyone~
<ktemkin>
TiltMeSenpai: mostly on the usb-tools discord, but it's bridged to #luna-usb
<d1b2>
<TiltMeSenpai> I've been working on adding USB HID to ktemkin's LUNA project
<ktemkin>
I should probably start using the channel I made for LUNA instead of letting it fill up #nmigen, huh? >.>
<ktemkin>
I mean, the service was originally gamer-centric; I wouldn't be surprised if people used it with controllers in their hands and text-to-speech on
<ktemkin>
it doesn't affect the badges on servers
<ktemkin>
the "unread badge" is for the whole-app badge, like the win10/mac/iOS red dot on the app icon
<ktemkin>
I mean, I ignore IRC, too, most of the time
<ktemkin>
I just ignore everything
<ktemkin>
I was all prepared to be old and hate discord, but I actually appreciate a bunch of what it adds over IRC
<ktemkin>
yep; it's not just Siuan~
<ktemkin>
(and I didn't want to modify the base board)
<ktemkin>
I wanted an LED, and I can only assume it'll cost me my soul
<ktemkin>
there's an old spanish proverb that says "take what you want and pay for it"
<ktemkin>
well, this conversation's invoked in me... well, whatever the opposite of inspiration is
<ktemkin>
the best part is that you can convince yourself it was whomever made the thing that sinned, and not you -- you only plugged it in to the sodimm you're abusing, after all
<ktemkin>
it's perfect for if you want to yoink off the oversized battery socket, add one bodge, and then have terrible LEDs
<ktemkin>
I mean, you can see the traces, there -- one side on each LED is to a plane (ostensibly VBATT) and one side is to the the DDR signals
<ktemkin>
I'll find out when I get this thing
<ktemkin>
so either they expect you to jab a lithium cell in there or it's series'd with 1v8
<ktemkin>
lithium coin cells output like 3v, which is enough to turn on an LED
<ktemkin>
that's a good sentence, there
<ktemkin>
possibly the signaling forward voltage isn't enough for the LEDs and they use a coin cell to power the LEDs and then rely on the coin cell voltage to 0 being enough to turn the LEDs on, but the coin cell to 1 not being
<ktemkin>
whitequark: I have _no idea_
<ktemkin>
daveshah: I'm assuming they rely on the forward voltage of the LEDs being a bit higher than the signaling voltages
<ktemkin>
whitequark: it's LEDs tied to SODIMM pins for ambiguous testing
<ktemkin>
there are workarounds (all that good virutalenv-derived magic), but when problems do crop up, they tend to crop up in ways that are very difficult for end-users to diagnose
<ktemkin>
mm
<ktemkin>
python's package management (and its relevant way of handling versions) makes this very, very brittle
<ktemkin>
since it definitely motivates a more comprehensive stdlib than would be the case were it super easy to say "I want nmigen-crc"
<ktemkin>
it's interesting how much python's package management sucking drives us to pose these kinds of questions
<ktemkin>
mm
<ktemkin>
and thus am a slave to my calendar
<ktemkin>
into manager
<ktemkin>
I’ve multi classed
<ktemkin>
mm; yep
<ktemkin>
I remember you saying you were taking time off and cannot remember how long ago that was ^^
<ktemkin>
don’t mind me; I don’t remember what time is ^^
<ktemkin>
okays
<whitequark>
ktemkin: i'm on vacation, so i decided to postpone this one
<ktemkin>
or is this Vacation Week?
<ktemkin>
meeting?
2020-08-06
<ktemkin>
if you're still having issues tomorrow or so, let me know, and I can take a look
2020-07-31
<whitequark>
no, ktemkin also reported something similar
<ktemkin>
IIRC there are things with nice hardware implementations of USB/IP that are essentially "remote hubs"
<ktemkin>
well, not for FPGA dev, anyways
<ktemkin>
I don't use Windows; so usbip's a lot more reasonable
<ktemkin>
it's not perfect, but it's been good enough for a lot of what I'm doing
<ktemkin>
yep
<d1b2>
<edbordin> ktemkin ooh neat, so you can plug a board in at your desk and the remote machine can talk to it?
<ktemkin>
I use vscode's remote dev extensions on my build machine plus usbip, and it's been pretty decent for FPGA stuffs
2020-07-29
<ktemkin>
miek: Amalthea was a good choice; it's apparently only two spaces from the Jupiter Space Dock~
<ktemkin>
awygle: re: Amalthea's name: we're naming all the LUNA-derived boards after moons :)
<zignig>
ktemkin: ping
<whitequark>
DaKnig: to add to what ktemkin said, there are a few implicit protocols that python will check your objects against
2020-07-28
<ktemkin>
DaKnig: also: generically, python lets you stick whatever you want to into its indexing operator [] (see e.g. __getitem__); though individual types like list impose their own meanings and thus requirements
<ktemkin>
if you're using nMigen Arrays, yes, that's the point
<ktemkin>
that said, I now have several PCIe analyzers and interposers, which based on past expeirence means I eventually will wind up designing my own PCIe tooling
<ktemkin>
awygle: I'm not doing anything with a structured end-goal with it, but I've been mentoring Degi in implementing it, and I can't look at anything sufficiently complicated without getting drawn into it
<ktemkin>
which I mean as semantically distinct from "I'm working on PCIe"
<ktemkin>
I'm not not-working on PCIe, currently
<awygle>
ktemkin: on a totally other note, are you working on PCIe now?
<ktemkin>
8051's sour
<ktemkin>
it does kind of hurt, but in the end of the day there's still something about the capsaicin
<ktemkin>
intel technologies are the 'pointlessly spicy food' of computer architecture
<whitequark>
ktemkin: this is how i feel re: just about anything made by intel
<ktemkin>
as well as bad coding styles
<ktemkin>
I think I feel the same way about bad code, at this point
<ktemkin>
there came a point in my life where I started enjoying eating foods I dislike, because there was a certain level of interest in experiencing the adverse flavor itself
<awygle>
ktemkin: i genuinely think it is not unlikely that i will end up working on a GANTT chart during therapy today.
<ktemkin>
~~I assume your therapist will understand if you take out a pen and paper and start solving utility calculus~~
<ktemkin>
awygle: it's a net-happiness thing; you get more happy overall by accepting that lots of coding styles will make you unhappy and rolling with them anyways~
<awygle>
ktemkin: i have therapy in 20 minutes, i wonder what would happen if i said "i've just learned to accept unhappiness" to my shrink :p
<ktemkin>
I've just learned to accept unhappiness~
<ktemkin>
I figured out an elegant solution to this problem years ago
<cr1901_modern>
ktemkin: wq has been talking about eprom hacking in ##yamahasynths, which is my channel where I really don't enforce on-topic (basically derails into any obsolete computer tech)
<ktemkin>
mm; I guess that goes unused enough to host specific-project discussions without blocking general FPGA conversation (and serdes stuff is relevant)
<ktemkin>
whitequark: btw, is there a place to talk about things like Yumewatari/related PCIe things and things like your eeprom hacking without taking up the nMigen or similar channels?
2020-07-27
<ktemkin>
*tfw you're bikeshedding yourself in your PRs~
<ktemkin>
tfw upi
<ktemkin>
emeb: make sure you grabbed the right nmigen
<ktemkin>
it just uses master
<ktemkin>
ohey, meeting
<ktemkin>
you could, yes
<lkcl__>
as ktemkin points out, nmigen AST "fragments" are data structures specific to nmigen.
<ktemkin>
pysim can only operate on designs that explicitly follow those constraints
<ktemkin>
in particular, the way clocking is handled (e.g. statements belonging to single clock domains)
<ktemkin>
nMigen places a number of constraints on what it can construct / represent internally in order to remove a lot of common gateware footguns
2020-07-26
<lkcl>
ktemkin: lol
<ktemkin>
(anyways, I should actually nap; I’m pretty sure $girlfriend is rolling her eyes at me for doing the whole “Kate checks her phone repeatedly in bed” thing)
<ktemkin>
*out
<ktemkin>
dunno if they’d be smoothed our enough, but if the setup is the one I saw on twitter a bit ago it looked very capacitive and inductive =P
<ktemkin>
I mean, chances are the oscillations you’re seeing are getting smoothed out a bit by the mass of wiring on their way over to the glasgow
<ktemkin>
you’re probing at the Glasgow side?
<ktemkin>
huh
<ktemkin>
I’m guessing that your single-signal oscillation stays around without settling as well as it does because the threshold of the signal itself is being modulated
<ktemkin>
I’d think
<ktemkin>
I’m going to guess the supply input impedance is significant enough that you’d still see appreciable internal VCC swings when the buffer’s pull-up and pull-down transistors are on
<ktemkin>
(typing slowly from phone)
<ktemkin>
but it strikes me as likely coupling via the supplies; since during the astable states you’re effectively turning on both logic network partially, drawing more than typical stable-state current; this in turn would cause threshold oscillations for the other signals
<whitequark>
ktemkin: oh, i have two possible reasons
<ktemkin>
oh, by the way, I don’t know if you postulated a good theory for why the outputs wound up oscillating in lockstep during your astable reads
<ktemkin>
I should never check IRC from my phone; it’s the enemy of sleep and the source of stupid ideas
<ktemkin>
tired brain vaguely wonders if leakage currents result in trapped carriers over a long period of disuse
<ktemkin>
when I’m not supposed to be napping, I totally will
<ktemkin>
now you’re tempting me to babble about flash and EPROMs
<ktemkin>
;)
<trabucayre>
ktemkin: I like your PR, especially the first point in the message and toolchain_program :)
<ktemkin>
whitequark: I have a handful of board definitions to dump into nmigen_boards; I'm going to PR the first couple one-at-a-time before I PR the rest so if there are things wrong with the first ones, I can change the rest before making them your problem =P
2020-07-20
<whitequark>
awygle? ktemkin?
<Yehowshua>
ktemkin, I'm perusing Luna - how might set the device class in the descriptor packets?
2020-07-19
<Yehowshua>
ktemkin, I programed TinFPGABX with the serial acm example. It shows up under `lsusb` with the vendor id and all, but does not enumerate in the device tree as an acm device. Checking the raw usb packets, I see that it send `bDeviceClass: Device (0x00)` in its descriptor packet. When restting to the default TinyFPGA ACM USB boot loader, that field
<Yehowshua>
ktemkin, just curious, why not have the requirements in requirements in `setup.py`?
<ktemkin>
[anyways, I’ll be back later if you have more questions :)]
<ktemkin>
LUNA_PLATFORM will take a filename for the section before the “:” too; so you can use an out-of-tree platform file as you dev, as well :)
<ktemkin>
(check out the Fomu or iCEBreaker platforms; those are up5k based)
<ktemkin>
\o/
<ktemkin>
Yehowshua: but yes, the platform definition local to LUNA, in addition to the I/O resources and typical platform things, provide a teensy bit of platform abstraction in the form of indicating which module should be used by the examples for e.g. PLL/clock-domain config & which I/O resource provides the USB connections
<ktemkin>
in the environment? it just sets which platform the examples (and other things that use the built-in main function) try to use
<Yehowshua>
ktemkin, so I'm guessing the reason you have to set the platform is to enable LUNA to generate the PLL in the `platform.clock_domain_generator()`?
<emeb>
ktemkin: Yeah - not looking at wide bandwidth stuff ATM. Full speed should suffice for audio bandwidths.
<ktemkin>
emeb: it’s worth noting that the orangecrab is a full-speed USB platform, so if you want to do something like SDR, LUNA/USB may not have enough throughput for your application
<ktemkin>
run one of the examples to test running on the OrangeCrab (I suggest examples/usb/simple_device.py)
<ktemkin>
the docs need to be clarified: that test script is only for LUNA hardware
<emeb>
ktemkin: tried the post-install test dry run and it's complaining: ModuleNotFoundError: No module named 'prompt_toolkit'
<ktemkin>
the failure is less on the part of the individual install command and more on python package management as a whole~ =P
<ktemkin>
whitequark: yeah, but without the strict need to re-run the command that “error”’d / “retry”
<ktemkin>
*install
<ktemkin>
those “errors” aren’t indications that the process has failed, as much as python makes it look like it — they’re it letting you know that you have conflicting local requirements post-instal, so things might be broken
<ktemkin>
(you can ignore the lambdasoc soft-error; the setup.py on their side is overly strict about version and it’s a soft requirement)
<ktemkin>
(LUNA’s examples are often provided-platform agnostic; so the existing examples work on the orangecrab if you set the LUNA_PLATFORM environment variable correctly)
<ktemkin>
cool beans; with that merged I can start PR'ing all the platform definitions I've been lazily collecting over here >.>
<ktemkin>
might be a couple of hours until I get around to it, though
<ktemkin>
if you want I can update the PR accordingly
<ktemkin>
mm, fair
<ktemkin>
just sharing thought process
<ktemkin>
but again, I don't -really- see an issue with changing it
<ktemkin>
I see quite a few omigen designs that use things like i_blah and o_blah
<ktemkin>
mm, yeah -- I just worry the prefixes will seem to have semantic meaning
<ktemkin>
mm, I'm fine with that
<ktemkin>
all the options suck, so I'm completely ambivalent
<ktemkin>
since generically A+/A- translate to a_p and a_n
<ktemkin>
my main concern with dp/dm is that D+/D- are named as if the lines were differential on the USB side; and I feel like when guessing how those'd be written in nmigen I/O, folks might assume d_p/d_n
<ktemkin>
mm
<ktemkin>
I am honestly okay with pretty much any of the options; and there's nothing super wrong with e.g. just using dp/dm or d_p/d_n
<ktemkin>
(I omitted underscores in the kwargs because underscores in kwargs are semantically overloaded in other places, such as Instance)
<ktemkin>
I've seen d_p and d_n in a variety of FPGA designs, and wound up using it for LUNA in order to keep in line with that convention
<ktemkin>
*but use differential naming
<ktemkin>
I mean, lots of things aren't _really_ differential but use the differential naming
<whitequark>
ktemkin: so what i was wondering about is the pin naming for USB
<whitequark>
ktemkin: ping
<ktemkin>
[by the way, expect a bunch of PRs from me to nmigen-boards as I try squish all the LUNA supported boards into there]
<cr1901_modern>
ktemkin: I have about 10,000 days worth of scrollback... hang on
<ktemkin>
I feel like I missed something that was @'d at me in here, but I'm not seeing it immediately in the scroolback
2020-07-13
<MadHacker>
ktemkin: Have you tried out LUNA's ACM serial stuff on Windows at all yet? I'm seeing two devices created, and no drivers. I'm thinking I should work a bit on the descriptors and add in the WCID magic to make it use the standard usbser.sys?
<ktemkin>
actually, hell, I'll accept the change as is and then take the more work later; it's easier than getting my brain to articular a complex thought at the moment >.>
2020-07-12
<ktemkin>
(I need to get to my computer before I can comment in more depth, will be a bit)
<agg>
ktemkin: I think the sync ones are the problem in that case, i.e. if you use Rose/Fell/Past with domain=None (default), it gets turned in to "sync" _after_ renaming, so can't be renamed, so incorrectly uses the sync domain when every other use of sync has been changed
<ktemkin>
so, basically: skipping the SPI code section
<ktemkin>
*to instances of
<ktemkin>
if you get rid of the changes adding domain=“sync” instance of Rose/Fell, I’d gladly merge the rest of the PR :)
<ktemkin>
thanks for trying that out and poking around
<ktemkin>
MadHacker: just catching up now
<MadHacker>
ktemkin: I've submitted a pull request for changing those rose/fell bits. Works On My Machine(TM). :)
<MadHacker>
ktemkin: LUNA's yours, yes? I think those Rose() and Past() bits might need tweaked if you have a non-USB-related system-wide sync.
2020-07-10
<ktemkin>
https://twitter.com/ktemkin/status/1281083448816361473 <-- btw, whitequark: when you have a minute, want to talk over this with me to see if we can make what I'm going to do as reusable for general-nMigen as I currently can?
2020-07-09
<ktemkin>
(I’ve been asked to replace Fomu’s foboot bootloader)
<ktemkin>
I’ll have a sample DFU application at some point probably not too far in the future
<ktemkin>
np
<ktemkin>
:)
<ktemkin>
it’s a little status FSM and then some simple vendor requests, plus the complexity of whatever flashing process you want to use
<ktemkin>
so just add whatever the complexity / resource usage is of the SCSI pieces you want to implement, essentially
<ktemkin>
well, bulk-only storage is pretty much just sticking SCSI-ish commands over pretty much the same design
<ktemkin>
luckily USB2 isn’t *that* complicated, especially if you’re trying to use it rather than implement all the low-level stuff; it’s just a bit of an odd half-duplex protocol
<ktemkin>
I’ll try to re-prioritize those, I’ve been putting them off for too long
<ktemkin>
awygle: I have some training materials that I think explain the USB stuff well, but they need to be recorded and/or translated into prose, still
<ktemkin>
USB Promoter Group is the more expansive one that does high-level stuff and tries to squish USB into every use case
<ktemkin>
that’s my fault for the architecture docs not being more prominent / complete
<ktemkin>
LUNA’s is a rewrite of a rewrite of Luke’s code >.>
<ktemkin>
but the PHY code is very, very similar to the one in usbserial (they both inherit architecture from Luke Valenty’s usb stack at some point)
<ktemkin>
awygle: I’m on my phone and just woke up, so I have no idea
<ktemkin>
since that’s what I thought the most likely use case would be
<ktemkin>
it has a small amount of block ram; I just grabbed it to simulate having a CPU there
<ktemkin>
distributed ram instead of block ram
<ktemkin>
(And that’s using distram since the Bx was asked for, so some of those LEs are just fancy FFs)
<ktemkin>
strict USB compliance and throughput make things bigger
<ktemkin>
you can get the LUNA ACM one smaller than the Verilog usbserial if you remove “unnecessary” descriptors and usb request / pull out the double buffering
<ktemkin>
compared to 1.1k base for the tinyfpga_bx_usbserial
<ktemkin>
Faltecks: the ACM example is about 1.5k-2k LEs all nicely double buffered for throughput and fully spec compliant
<zignig>
ktemkin: luna acm ran second go on my tiny bx , had to update the usb_protocol package to get it to build.
2020-07-07
<ktemkin>
and when it's treated like a Value, you get all its bits
<ktemkin>
a Record behaves like a packed struct
<ktemkin>
You shouldn't need to do the copy
2020-07-06
<ktemkin>
if we run into a problem with too many boards supported, that's a good thing, and we can figure things out then :)
<ktemkin>
so "hardware's not quite finalized"
<ktemkin>
because until very recently, only like ~5 people have had boards
<ktemkin>
in nmigen_boards? nope
<ktemkin>
*stop my
<ktemkin>
and I'd like to stop by terrible habit of carrying around my own platforms >.>
<ktemkin>
at least, I imagine
<ktemkin>
no, but having it in core nMigen would also solve the "I need to replicate I/O during simulation" case
<ktemkin>
that'd give an immediate solution (e.g. I can grab a correctly-shaped record for now), and then later there can be proper interface-specs that are squished in there
<ktemkin>
another simple solution might be just to have something like a default= argument for something like `request_optional` -- it's what you get instead of the pin's not there
<ktemkin>
mm
<ktemkin>
I just created it quickly as a scaffold for a Correct solution
<ktemkin>
mm; I'm not recommending this one
<ktemkin>
I was actually thinking it might be something that just creates a "black-hole" proxy
<ktemkin>
yep
<ktemkin>
but ideally it'd be something that generates stand-ins for subsignals, yes
<ktemkin>
right now, in that quick convenience on my side, it just spits out an equivalent Signal() if the I/O's not there
<ktemkin>
In LUNA, I have a little bit of syntactic sugar in `request_optional`
<ktemkin>
here's a minor "would be nice" feature before I have to run: some conveniences for running code examples on multiple platforms with varying I/O resources
<ktemkin>
anyways, did we want to move on?
<ktemkin>
mm
<ktemkin>
mm
<ktemkin>
the other I think is now too esotetic to bother with, so mostly yeah: debuggers
<ktemkin>
debuggers were one of them
<ktemkin>
I was thinking of two things
<ktemkin>
mhm
<ktemkin>
dunno; this might be overly bikeshedding at this point, and maybe we should just go ahead and run into issues during implementation
<ktemkin>
for a generic constant, we might want to have something like `bits(0x01, 3)`, and then the BSP just goes "oh, yeah, that's a u8"
<ktemkin>
*u8
<ktemkin>
whitequark: yeah -- my thought was for something like that, we'd say N bits and let the BSP generator select u*
<ktemkin>
ah, okay, it was someone else who was Eastern
<whitequark>
ktemkin: so in Rust that enum would have to be represented by u8
<ktemkin>
awygle: wait, are you Eastern time?
<ktemkin>
https://paste.debian.net/1155401/ <-- here's an example of the information we might provide for a general register field in an SVD
<whitequark>
ktemkin: ah that's good to know, so maybe we shouldn't have an enum but something more precise for the types
<ktemkin>
(it also likes to know exact widths for things)
<ktemkin>
yep
<whitequark>
ktemkin: indeed that is also what I'd like to have
<ktemkin>
(and one that'd be desirable due to how many different tools accept SVDs)
<ktemkin>
that seems like a good example BSP generator to consider when imagining something that's going to run into all the PITA cases
<ktemkin>
whitequark: one case I'm thinking of immediately is having a BSP that generates an SVD itself
<ktemkin>
and sometimes, those constants may be things that need to be fed back into e.g. a CSR, in which case we'll have to specify a way to provide an exact binary representation, like bits+width
<ktemkin>
mm
<ktemkin>
the BSP generator needs to know type information to do that
<ktemkin>
that'll also curtail the amount of "junk drawer" clutter that can be accumulated on the peripheral
<ktemkin>
+1
<ktemkin>
mm; I see the requirements here (having a collection of little tidbits of type-annotated data) as being close to the same between the peripherals and their registers; and that leads me to believe it might be a good idea to share code between both cases
<ktemkin>
in the end, you have little bits of metadata that can be attached to registers; e.g. you have a counter register with a synthesis-time limit and want to communicate that range via your BSP generator
<ktemkin>
that seems to me like a very similar problem to tying these little bits of metadata to the peripheral
<ktemkin>
mm
<ktemkin>
if I have a register that has modes foo (0), bar(1), and baz(2), ideally the relevant constants could be attached to the register in a similar way
<ktemkin>
here's another question: is this only specifically for constants global to the peripehral?
<ktemkin>
one simple way is to better document intention while adding it
<ktemkin>
specifically, I'm concerned that we're going to wind up with unintended uses of this becoming part of the required API to Not Break Things