<whitequark[cis]>
so i've been thinking about improving the "toplevel" situation for applets: adding support for multiple simultaneous applets, allowing specifying options in something that is not argparse, etc
<whitequark[cis]>
the main challenge is that there is a bit that gets turned into a bitstream and loaded into the device, and also there is a bit that runs on the host system, and you have to make them match at runtime even though there's no "port numbers" or "IP addresses" or anything like that assigned for the USB comms
<whitequark[cis]>
so what i'm thinking is that we need a top-level object that would track resource allocation and know that "this specific Amaranth stream interface corresponds to this specific USB FIFO number". this wouldn't persist over more than a single run but that's fine, I don't care to support those use cases anyway
<whitequark[cis]>
it was on my mind for unrelated reasons
<whitequark[cis]>
the design above concentrates surface-level concerns (i.e. using the applet as it was designed) in the toplevel *Applet class, like today, while defining an easy way for people to interpose the process
<whitequark[cis]>
like if you want to have a JTAGInterface that's talking to something that isn't a JTAGComponent but is interface-compatible with that FIFO
<whitequark[cis]>
or if you want to connect something else to the component
<Wanda[cis]>
hmmmm
<whitequark[cis]>
like if you want a mux between bitbanging JTAG and having a high-speed ARM-specific debugger use it
<Wanda[cis]>
and the components would of course be stackable
<whitequark[cis]>
naturally
<whitequark[cis]>
right now this is done using incredibly cursed inheritance patterns around *Applet and they basically just don't scale and are incomprehensible (see run_lower())
<whitequark[cis]>
tests are also... painful
<whitequark[cis]>
oh. i guess you'll also have host_obj = orchi.add_register(gateware_thing.reg) with the semantics of like... await host_obj.get(), await host_obj.set(...)
<whitequark[cis]>
this avoids the current situation where you have to juggle register addresses for no clear reason
<whitequark[cis]>
most importantly this hides the transport mechanism for registers. right now they can only be on I2C
<Wanda[cis]>
what does the register look like from the gateware side?
<Wanda[cis]>
another Signature?
<whitequark[cis]>
you give add_register a Signal or a view
<whitequark[cis]>
you could conceivably make it a pair of streams or something but why
<Wanda[cis]>
you'd also have to select directionality, right?
<whitequark[cis]>
we might also consider using the CSR bus from amaranth-soc
<Wanda[cis]>
would there be like read strobes? write strobes?
<whitequark[cis]>
in fact that's almost certainly a good idea
<Wanda[cis]>
mhm
<whitequark[cis]>
then it's just orchi.add_csr and then it builds a big CSR multiplexer somewhere
<Wanda[cis]>
right
<Wanda[cis]>
and if we have some weird thing like ethernet transport in the future we can just multiplex all that stuff (CSRs and FIFOs) over a single bytestream
<whitequark[cis]>
i want to do this already tbh, for synchronization reasons
<Wanda[cis]>
mhmm
<whitequark[cis]>
but we can't until there's a better transport over USB
<whitequark[cis]>
which might be a good idea to upgrade first
<whitequark[cis]>
but there's no real dependency between the two
<Wanda[cis]>
yeah that old router plan we have somewhere
<whitequark[cis]>
yes
meklort has joined #glasgow
meklort has quit [Ping timeout: 252 seconds]
redstarcomrade has quit [Read error: Connection reset by peer]
meklort has joined #glasgow
meklort has quit [Quit: ZNC 1.9.0+deb2build3 - https://znc.in]
meklort has joined #glasgow
redstarcomrade has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
figushki has joined #glasgow
figushki has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
figushki has joined #glasgow
figushki has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Eli2| has quit [Ping timeout: 248 seconds]
Eli2 has joined #glasgow
figushki has joined #glasgow
figushki has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
figushki has joined #glasgow
figushki has quit [Ping timeout: 276 seconds]
FFY00 has quit [Ping timeout: 276 seconds]
figushki has joined #glasgow
figushki has quit [Client Quit]
figushki has joined #glasgow
figushki has quit [Client Quit]
figushki has joined #glasgow
figushki has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
galibert[m] has joined #glasgow
<galibert[m]>
Given you’re on usb, can you use separate endpoints by applet?
<galibert[m]>
It’s in a way the port of usb
purdeaandrei[m] has joined #glasgow
<purdeaandrei[m]>
I want to build some ram-paks. I have found esden mentioning that his ram-paks would have 0.5mm thickness. But as far as I can tell, perillamint built 0.8mm thick ram-paks (based on their comment that they used JLC04081H-1080 stackup). I wonder if I built a 0.6mm thick PCB, with 1080 prepreg, if that would be good enough...
<purdeaandrei[m]>
jlcpcb only supports 0.6mm 4-layer PCBs, while pcbway supports 0.4mm and 0.6mm, but not 0.5mm
figushki has joined #glasgow
figushki has quit [Ping timeout: 244 seconds]
<whitequark[cis]>
<galibert[m]> "Given you’re on usb, can you use..." <- no, since i only have two IN and two OUT
<whitequark[cis]>
that was the original idea and it's a failure
<purdeaandrei[m]>
is this silkscreen acceptable if I build rampaks with 0.6mm PCB, with a slightly adjusted trace clearance?
<whitequark[cis]>
galibert[m]: yeah, the FX2 only has 2x2 endpoints at most
<galibert[m]>
Yeah so no, indeed
<whitequark[cis]>
the FX3 (new) has 16x16 but i still think scheduling packets on the FPGA is a better call
<galibert[m]>
so you need packetization and destination "addresses"
<whitequark[cis]>
yeah
<galibert[m]>
is your packet size limit 8 or 32?
<whitequark[cis]>
neither
<whitequark[cis]>
it can be anything i want
<galibert[m]>
ah, the fx2 makes it transparent?
<whitequark[cis]>
huh?
<galibert[m]>
packets on the wire have very limited sizes, but there's things in the setup to tell a global packet size. I suspect the fx2 handles the headers, retries, etc automatically
<whitequark[cis]>
USB BULK packets always have a 512 byte size in HS but this is irrelevant because flow control requires you treat those like a TCP stream
vegard_e[m] has joined #glasgow
<vegard_e[m]>
I think you're confused
<vegard_e[m]>
it's also fairly irrelevant in other contexts since they can be joined into larger transfers
<whitequark[cis]>
yeah, that's sorta what i mean
<galibert[m]>
I’m probably confused. I’ve needed a LA to make any sense of the usb docs
<whitequark[cis]>
you almost never care about the 512, except in some performance evaluations
<vegard_e[m]>
a USB transfer is the normal framing boundary for framed USB stuff, a transfer consists of any number of full packets followed by a single non-full packet
<vegard_e[m]>
so if you wanna send 1200B on HS bulk, it gets packetized as 512B+512B+176B
<galibert[m]>
control is smaller frame size, right?
<vegard_e[m]>
no
<vegard_e[m]>
control is framed the same way as bulk
<whitequark[cis]>
and ending a transfer early incurs a latency penalty, so you dont want e.g. glasgow level packets to have their address in the first byte of a transfer
figushki has joined #glasgow
<vegard_e[m]>
interrupt is limited to a single packet per transfer, and isochronous is limited to max three IIRC
<whitequark[cis]>
i thought control packet size is 64B on HS?
<vegard_e[m]>
yeah, but the mechanism works the same
<whitequark[cis]>
sorta, i think it's limited to 4K of data at a time
<whitequark[cis]>
and then there's the additional ACK
cr1901 has quit [Read error: Connection reset by peer]
<vegard_e[m]>
hmm, I thought you could do the full 64k-1 that you can fit in wLength
<galibert[m]>
ok, for HS is 512 max for bulk, not for control though
<vegard_e[m]>
65535B control transfers works for me
<whitequark[cis]>
thanks, useful to know
<vegard_e[m]>
(except my test setup seems somewhat broken and unreliable when I turn up the request size, but that's unrelated to what the protocol supports)