<tem01[m]>
esden (@_discord_269693955338141697:catircservices.org) we get kapton /cirlex sheets cut by someone local to you, I can try to get their name for you Monday if you like?
<esden[m]>
tem01 (@_discord_190648969318236160:catircservices.org) ohh! If you can share that with me that would be most excellent. 🙂
<tem01[m]>
I'll set a reminder!
<esden[m]>
TYVM! 🙂
miek__[m] has quit [Quit: Idle timeout reached: 172800s]
redstarcomrade has quit [Read error: Connection reset by peer]
joerg has quit [Ping timeout: 255 seconds]
joerg has joined #glasgow
trh has quit [Quit: weg]
trh has joined #glasgow
axiesmoothie[m] has joined #glasgow
<axiesmoothie[m]>
hi, what is the advantage of an aluminium case? So much that it warrants going through the hassle of ensuring the absence of shorts, even though alternative non conductive materials exist and are also reasonably robust and suited to purpose, acrylic, various types of plastic, ..
<Darius>
you can machine aluminium and it looks nicer
<Darius>
also would have better EMI characteristics
pg12 has quit [Remote host closed the connection]
pg12 has joined #glasgow
duderonomy has joined #glasgow
duderonomy has quit [Ping timeout: 264 seconds]
duderonomy_ has joined #glasgow
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
notgull has quit [Ping timeout: 240 seconds]
notgull has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
supersat[m] has quit [Quit: Idle timeout reached: 172800s]
<whitequark[cis]>
*way* lower setup costs than injection molding
<_whitenotifier-f>
[glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-458-05c44bd0ff7fc051c08a942ed6c18cf0b0f8de20 - https://github.com/GlasgowEmbedded/glasgow
<Wanda[cis]>
Catherine: so am I now *the* <del>person</del>angel girl to call when there's a need for a large-scale refactoring
<whitequark[cis]>
well,
<whitequark[cis]>
i suppose so ^^;
<whitequark[cis]>
do you mind it?
<Wanda[cis]>
heh
<Wanda[cis]>
no
<Wanda[cis]>
absolutely no
<Wanda[cis]>
ok, speaking of XC9500XL for now
<Wanda[cis]>
.bit is to go and .jed should be natively used, that part is clear
<Wanda[cis]>
first: I understand you want the .jed output by the applet to be readable by impact as well? it requires a non-standard comment to be present in the file for successful programming (specifically, target part selection)
<Wanda[cis]>
second: I vaguely seem to recall getting rid of the "applet tool" concept as one of the reasons for this change. in addition to jed-bit conversion, the applet tool currently also has a non-trivial function of "extract the USERCODE from the bitstream". do you wish to keep this functionality in some way?
<whitequark[cis]>
<Wanda[cis]> "first: I understand you want the..." <- yep! so the JESD unparser should have a provision for adding comments; that's very common
<whitequark[cis]>
<Wanda[cis]> "second: I vaguely seem to recall..." <- I think "applet tools" should probably stay in some form or capacity, but the *current implementation* is bad, and if we don't have any tools remaining it is all that easier to redo the functionality
<whitequark[cis]>
like, i think applet tools should maybe be a part of the applet lifecycle or something?..
<whitequark[cis]>
like how we have build, run, interact, maybe there should be add_tool_arguments or sth
<whitequark[cis]>
the main reason not to do it was because most applets don't have tools and so they shouldn't be shown in the list
<whitequark[cis]>
rolls around like cat
<whitequark[cis]>
i dont know
<galibert[m]>
Then go take a nap, you cat ;-)
<Wanda[cis]>
hm
<Wanda[cis]>
I don't really feel qualified to comment on that atm
<Wanda[cis]>
but, okay, the USERCODE tool stays, fine
<Wanda[cis]>
actually about add_tool_arguments
<Wanda[cis]>
the relationship between applets and tools would be one-to-many, wouldn't it?
<Wanda[cis]>
like, the XC9500XL applet doesn't really have a tool, it has two tools atm
<whitequark[cis]>
sorry, I missed a statement
<whitequark[cis]>
I was going to say we can ditch the USERCODE tool, I think
<whitequark[cis]>
it was just something i did for RE purposes
<whitequark[cis]>
it's not hugely important or whatever. maybe put the USERCODE into the JED?
<whitequark[cis]>
doesn't Xilinx?
<Wanda[cis]>
I don't remember
<Wanda[cis]>
hm
<Wanda[cis]>
I should have some jeds laying around
<whitequark[cis]>
well, whatever, I think having that as a method that someone can import and call is more than sufficien
<whitequark[cis]>
s/sufficien/sufficient/
<whitequark[cis]>
Wanda[cis]: yeah that's a part of uncertainty
<whitequark[cis]>
namespacing of tools, I guess
<whitequark[cis]>
I can easily add plugin registration for tools the way we do for applets
<ar>
(not many-to-many? wouldn't surprise me if there were applets that worked with different enough end pieces of hardware to warrant being separate applets, but output data in compatible formats for the user)
<whitequark[cis]>
also, right now, we effectively have add_tool_arguments no? there is only one toplevel argument parser for each applet with tools
<Wanda[cis]>
yes
<whitequark[cis]>
basically my proposal here is to not touch this mess for now, but remove one tool where we can get rid of it
<whitequark[cis]>
and then deal with it later
<whitequark[cis]>
```
<whitequark[cis]>
memory-floppy manipulate raw disk images captured from IBM/Shugart floppy drives (PREVIEW QUALITY APPLET) (revC0+)
<whitequark[cis]>
memory-prom display statistics of parallel EPROMs, EEPROMs, and Flash memories
<whitequark[cis]>
right
<whitequark[cis]>
memory-prom is ... a weird thing
<whitequark[cis]>
it's a part of a research article i never wrote
<whitequark[cis]>
i still have the hardware and the chip
<whitequark[cis]>
so i can finish it, I think it might be genuinely novel
<whitequark[cis]>
maybe then the tool will make more sense
<whitequark[cis]>
idk
<Wanda[cis]>
oh, that
<Wanda[cis]>
yeah that was interesting
<Wanda[cis]>
seems Xilinx doesn't keep usercodes in .jed
<Wanda[cis]>
... I suppose I could also just go and obsolete the tool properly by writing a disassembler for XC9500 .jed, I do have more than enough RE
<Wanda[cis]>
I could literally just output the netlist in some custom unnamed format or whatever
<whitequark[cis]>
<_< heh
<whitequark[cis]>
I mean, why not tbh
<Wanda[cis]>
<del>because then I'd be compelled to write a full CPLD toolchain</del>
<galibert[m]>
That’s the danger right there indeed
<Wanda[cis]>
how does one write a CPLD fitter anyway
<Wanda[cis]>
somehow I've never studied that
<whitequark[cis]>
ok if we're talking about CPLD fitters i want prjbureau to serve as a source for one
<Wanda[cis]>
whoops that escalated quickly
<whitequark[cis]>
can that be imported into prjcombine btw?
<galibert[m]>
How different is it from a fpga one?
<Wanda[cis]>
very different
<whitequark[cis]>
galibert: very
<whitequark[cis]>
almost entirely unrelated
<galibert[m]>
How come ?
<Wanda[cis]>
whitequark[cis]: I think you already did a complete RE so it'd be largely pointless, no?
<Wanda[cis]>
unless you're thinking of making a common layer for bitstream format information and data structures, in which case... yeah, that's on the TODO
<whitequark[cis]>
yeah I was thinking the latter
<Wanda[cis]>
yes
<Wanda[cis]>
I actually wanted to do this... soon
<galibert[m]>
Soon[tm]
<whitequark[cis]>
the only things sorta missing are features that AFAICT are not possible to expose thru the fitter in any reliable way, and only on larger devices
<Wanda[cis]>
sounds interesting
<whitequark[cis]>
it's a few routing fuses, and on one device it's a few fuses in special cells like uh
<whitequark[cis]>
iirc something like
<whitequark[cis]>
pullup fuse for open drain only cell or whatever
<whitequark[cis]>
you could definitely use the database as-is for most of the lineup already
<Wanda[cis]>
mhm.
<whitequark[cis]>
it's just that other than for ATF1502AS, it's not quite 100%'d
<Wanda[cis]>
so for xilinx, I do have basically everything reversed, but I'm unhappy with my current database format
<Wanda[cis]>
ad-hoc mess
<Wanda[cis]>
and I still need to do a de-duplication pass
<galibert[m]>
there's a fucklot of bits in a fpga bitstream that are not actually used, I guess a cpld could have a smattering, right?
<whitequark[cis]>
no, it's an artifact of my RE process
<whitequark[cis]>
uh, let me look up what specifically breaks it
<whitequark[cis]>
it's VREFB
<whitequark[cis]>
that probably why it weird
<Wanda[cis]>
I have... 100%'d XC9500* except for one (1) bit, I'm missing 2 bits per MC in XPLA3 which are never used by the fitter, and I've 100%'d Coolrunner II except for one useless mux input per mux (the const-0 one)
<whitequark[cis]>
32242 should be d_mux
<Wanda[cis]>
and I wouldn't be surprised at all if the missing XC9500 bit turned out to do nothing at all, and just stayed in the data files for no good reason
<sven>
w.r.t. reliability and the quiet despite those 200 units: I think I already mentioned it in here some days ago but the software installation on macOS was extremely pleasant and just worked the first try
<sven>
it’s rare to see that in both proprietary and open source projects
<whitequark[cis]>
so i've been thinking about how to do out-of-tree applets
<whitequark[cis]>
and i think i know a solution that i would find acceptable maintenance-wise
<_whitenotifier-f>
[glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-461-0a5ec898e6ca4513939ed6dd35d0f0124462d85c - https://github.com/GlasgowEmbedded/glasgow
<whitequark[cis]>
the "major" version of glasgow (the core software) is essentially the API level/version, what the applets are written against
<whitequark[cis]>
I could add some code that gets the metadata for each out-of-tree plugin, checks that it has an exact version constraint for glasgow itself (i.e. glasgow==0.* for the moment), and refuse to load any plugin that does not fit that requirement
<whitequark[cis]>
this would still require defining an API surface that we are versioning, but it gives me a bit of a better feeling about it meaning something
<whitequark[cis]>
we would need to split the current package in two: glasgow-core (or glasgow-api or something), containing the API everything else is written against (but no applets), and then glasgow, containing everything else in our package currently
<whitequark[cis]>
i'm not sure if we can keep our current good installation/upgrade ergonomics if we do that, though :s
<whitequark[cis]>
why in the fuck does github merge shit into main that doesn't pass tests in the merge queue again?
<Wanda[cis]>
it may be a race?
<Wanda[cis]>
fails on installing a package version that got released 20 minutes ago
<whitequark[cis]>
no, that's not the question I'm asking
<bob_twinkles[m]>
oh it considers "skipped" jobs as succeeding, presumably because the test is "!= 'failed'"?
<bob_twinkles[m]>
that's certainly one way to implement the check
<whitequark[cis]>
bob_twinkles: except in *normal* pull requests, where it considers "skipped" as failing
<whitequark[cis]>
it's completely nuts
<whitequark[cis]>
s/*normal*/_normal_/, s/pull/branch/, s/requests/builds (PR and not merge queue)/
<bob_twinkles[m]>
?_?
<galibert[m]>
Note that the semantics of skipped are complicated
<bob_twinkles[m]>
actions is so close to being good
<bob_twinkles[m]>
yeah i've fought with job skipping to try and get some efficiency out of CI pipelines and it always ends in just throwing random garbage at the wall until something seems to work
<whitequark[cis]>
this legitimately seems like a python bug?
<Wanda[cis]>
good question
<Wanda[cis]>
I'm currently trying to find documentation for indices
brolin has quit [Ping timeout: 246 seconds]
<galibert[m]>
This method takes a single integer argument length and computes information about the slice that the slice object would describe if applied to a sequence of length items. It returns a tuple of three integers; respectively these are the start and stop indices and the step or stride length of the slice. Missing or out-of-bounds indices are handled in a manner consistent with regular slices.
<Wanda[cis]>
... oh, it's documented in entirely different place of the documentation than the slice constructor
<galibert[m]>
s/This/his/
<galibert[m]>
s/complicated/complicatedT/
<galibert[m]>
* This method takes a single integer argument length and computes information about the slice that the slice object would describe if applied to a sequence of length items. It returns a tuple of three integers; respectively these are the start and stop indices and the step or stride length of the slice. Missing or out-of-bounds indices are handled in a manner consistent with regular slices.
<Wanda[cis]>
the thing is
<Wanda[cis]>
there... isn't really anything better for it to return
<whitequark[cis]>
hold on
<whitequark[cis]>
```
<whitequark[cis]>
>>> x=[1,2,3]; [x[i] for i in range(2, -1, -1)]
<whitequark[cis]>
[3, 2, 1]
<Wanda[cis]>
it's just a really bad papercut
<whitequark[cis]>
this works
<Wanda[cis]>
yes
<whitequark[cis]>
and is how you're supposed to use it I think
<whitequark[cis]>
turns out bitarray now publishes binary wheels after all
<whitequark[cis]>
but that doesn't matter; I very much want a consistent API (something bitarray was really not good about) that is based on pure Python primitives and can be easily vendored
<whitequark[cis]>
your PR ticks all the boxes, and I'm a happy cat =^___^=
<_whitenotifier-f>
[glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-376-5c79669807fc1b9c051efd3a098c1ee4ca9346a7 - https://github.com/GlasgowEmbedded/glasgow
<whitequark[cis]>
I've been thinking about our plan to make Glasgow network-transparent by turning all the USB-style control requests into bulk requests on EP1IN/OUT
<whitequark[cis]>
I think that is probably not the right approach because EP1IN/OUT on FX2 is limited to 64 bytes only (and having an HS bulk endpoint on those violates the spec), so the software would have to artificially chop everything into 64-byte-sized chunks and submit them separately. also, again, violates the spec
<whitequark[cis]>
but there is the allure of being able to receive notifications from the firmware without polling it, or having long-running (or even hung) requests to firmware not block in libusb
<whitequark[cis]>
that's on top of the network transparency
<whitequark[cis]>
I think a good approach there is to continue using EP0 reads/writes, with wIndex/wValue ignored, and set up EP1IN as an interrupt endpoint with the smallest bMaxPacketSize we can and have it submit no data, just the indication that there is something to read from EP0
<whitequark[cis]>
then the firmware would have only one control request, over which datagrams of up to 4K at a time can be exchanged, and the whole thing becomes essentially asynchronous in the same sense our main USB pipe is
<whitequark[cis]>
specifically on EP1IN/OUT
vegard_e[m] has joined #glasgow
<vegard_e[m]>
what, fx2 can't do 512B packets?
<whitequark[cis]>
EP2468 all can, obviously
<vegard_e[m]>
so why not use those?
<whitequark[cis]>
because we're using them for the FPGA
<whitequark[cis]>
and we need to use all of the underlying memory resources to bottom out the USB2 bandwidth
<vegard_e[m]>
ah, right
<vegard_e[m]>
sounds reasonable enough then
<whitequark[cis]>
our ideal configuration (Windows-compatible) is enabling only EP2/EP6 (as EP2IN/EP6OUT) and quad-buffering both
<whitequark[cis]>
but this would be pending some changes to how we are doing buffering on the FPGA, and would honestly benefit from streams
<whitequark[cis]>
all of this is actually considerably simplifying the firmware and the gateware, so it's clear moving in that direction is a good idea
<whitequark[cis]>
especially as we're about 90 code bytes away from not being able to have any more firmware functionality, lol
<whitequark[cis]>
or, no, it's closer to 150 iirc
<whitequark[cis]>
same diff
<whitequark[cis]>
on the Python side, the FIFO interfaces could see some improvements, too
brolin has quit [Ping timeout: 258 seconds]
redstarcomrade has quit [Read error: Connection reset by peer]
<whitequark[cis]>
the current ones aren't particularly bad but we need an abstraction for "a queue where one end is a Python buffer and the other end is a task performing a USB request"
<whitequark[cis]>
and maybe some way to glue two simplex channels into one duplex channel, with logic added to handle pipelined request/response communications
<whitequark[cis]>
like... have x = await bidi_channel.write(buf) return a thing you can await x.read(10) from, which works basically like the normal read half of the channel but only starts reading after all the previous writes finish
<whitequark[cis]>
does this make sense?
<whitequark[cis]>
this way it would be possible to do lots of writes to e.g. JTAG applet, and only once they are all queued, start awaiting on the reads
<whitequark[cis]>
anyway, once network transparency on USB protocol level becomes a thing, it would be potentially nice to yeet all the USB handling code into a tiny Rust library slash daemon and entirely end our reliance on python-libusb1
<whitequark[cis]>
not only does this enable the "connect to Glasgow that is attached to a networked machine somewhere else" use case, but also, while python-libusb1 is a very nice library it has a number of architectural issues that aren't really solvable while still using Python and ctypes
<whitequark[cis]>
unfortunately that would mean that installing Glasgow now requires rustc, which is suboptimal
<whitequark[cis]>
so I don't really know
<whitequark[cis]>
<whitequark[cis]> "like... have x = await bidi_cha..." <- really this would have to be something more like... `async with bidi_channel.pipeline(): await bidi_channel.write(1); await bidi_channel.read(1)` where each read within a pipeline block blocks until the previous pipeline block completes, or something like that
<whitequark[cis]>
this is kind of tricky to design if you want to allow non-fixed-length reads
<whitequark[cis]>
like internally the read 'just' needs to wait until all the preceding reads complete
<whitequark[cis]>
but in a concurrent environment where reads can be piecemeal it's hard to exactly define "all the preceding reads complete" as a condition
<whitequark[cis]>
it might be rational to say "we have a fixed TLV framing and it only works with that framing"
<whitequark[cis]>
well, LV framing in this case
<whitequark[cis]>
cursed observation: the Glasgow USB interface and HTTP/2 share the design space
<whitequark[cis]>
we have the same problems: bufferbloat, head-of-line blocking, needing to multiplex streams, having to work over TCP
<whitequark[cis]>
maybe I should just take inspiration from the HTTP/2 spec lmfao