<whitequark[cis]>
i've hit this issue multiple times and thought about this a bunch and concluded that it's basically impossible to resolve without introducing something like "host_to_device_stream" ("h2d_stream"?) which i find fantastically ugly
<whitequark[cis]>
it's also not even true if you compose parts of applets, which you are very much supposed to do now
<whitequark[cis]>
we could make the pipes adopt the direction in reference to the applet, but... we have USB to live with, which does the opposite
<whitequark[cis]>
unlike in migen, we have a robust multiple-driver / wrong-direction checks on several layers of the stack, so it's not like you will be able to silently get it wrong
<isabelburgos[m]>
whitequark[cis]: can you give an example?
<whitequark[cis]>
have you looked at the ARM7TDMI debugger applet?
<whitequark[cis]>
actually, ignore that
<whitequark[cis]>
there's existing examples in-tree: for example we have memory-25x building on top of qspi-controller
<whitequark[cis]>
but in the existing design, memory-25x needs to know about implementation details of qspi-controller instead of simply instantiating the latter as a black box
<whitequark[cis]>
memory-25x is just fine instantiating qspi-controller's Python frontend, but imagine an applet that requires precise timing when programming memories. such an applet would use QSPIControllerComponent (i am renaming "subtargets" which is a silly term to "components", within glasgow) and send it commands much the same way QSPIControllerInterface would, but on the FPGA
<whitequark[cis]>
so if QSPIControllerComponent had a h2d_stream and d2h_stream instead of like, i_stream and o_stream, the h2d/d2h designations would be wrong
<isabelburgos[m]>
That makes sense. i_stream and o_stream are Amaranth stream interfaces and could be connected to any other components. I was thinking more about the syntax around connecting pipes to assemblies, like for example if add_in_pipe was called add_device_to_host_pipe, that would always be true albeit ugly
<isabelburgos[m]>
q3k[cis]: hi
<q3k[cis]>
hello!
<q3k[cis]>
i actually have a backlog of people who also want an OBI and to which i've promised to sell some at cost - so expect even more users in the near future
<whitequark[cis]>
this was a big update that may have introduced some kind of subtle issue i wasn't able to test for
<whitequark[cis]>
should be fine though since i reused code wherever i could, only moving it around, and not really changing the interface exposed to applets
<whitequark[cis]>
but also, now that i've turned over a big stone, i'm feeling like turning up more stones, this time with immediate user impact
<whitequark[cis]>
in short: --port needs to die
<whitequark[cis]>
back in the before times (pre-pandemic!) i thought up a use model for glasgow that would split the device in half: 2 EPs, 8 pins, 1 Vio per applet. then you would address pins as 0..7
<whitequark[cis]>
but then it was obviously useful to have one applet control 16 pins. that's how --port was born: it conceptually glued two 8-pin ports together into one virtual 16-pin port
<whitequark[cis]>
so you can do --port BA to do it in the opposite order, and even --port ABS which makes the sync port available as pin 16
<whitequark[cis]>
i want to do the following things.
<whitequark[cis]>
(a) make --keep-voltage the default and remove --mirror-voltage; (b) make --voltage configure it per-port, e.g. -V A=3.3,B=1.8 or -V A=SA (sense S input of A and repeat); (c) if the port is not specified, make -V apply to "every pin requested by the applet"
<whitequark[cis]>
(d) make all --pin-x or --pins-xs arguments accept not bare integers but rather A1, B0, etc; (d) kill --pin- or --pins- prefix and have e.g. UART applet be just glasgow run uart -V 3.3 --rx A0 --tx B1, or glasgow run uart -V A=3.3,B=5.0 --rx A0 --tx A if you're powering the device from port B
<whitequark[cis]>
* (d) make all --pin-x or --pins-xs arguments accept not bare integers but rather A1, B0, etc; (e) kill --pin- or --pins- prefix and have e.g. UART applet be just glasgow run uart -V 3.3 --rx A0 --tx B1, or glasgow run uart -V A=3.3,B=5.0 --rx A0 --tx A if you're powering the device from port B
<whitequark[cis]>
this will be a breaking change to everyone's muscle memory
<whitequark[cis]>
somewhere in the future, applets should have power domains where some pins could be at one voltage and some at another
<whitequark[cis]>
so, let's talk about exposing the new "assembly" API to applets, so we can all write applets that are much nicer to use
<whitequark[cis]>
the "build arguments" / "run arguments" separation is almost completely artificial. the only time it matters is for glasgow build... which i really want to deprecate, together with allowing prebuilt bitstreams to be used
josHua[m] has quit [Quit: Idle timeout reached: 172800s]
<whitequark[cis]>
the intended use model is "you construct a bitstream on the fly, immediately load it, then start sending it commands"
<whitequark[cis]>
but, we still need to separate "build" and "run" stages somehow, precisely for the sake of multiple applets: you have to build them first, then run them all
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
<whitequark[cis]>
all of the assembly.add_something methods return objects that can be used only after assembly.start(), but there's no like... wait_for_start() or on_start(fn) or something
<whitequark[cis]>
so i'm thinking... we could have a async def add_setup_arguments(cls) + async def setup(self, assembly, args)
jfsimon has quit [Remote host closed the connection]
<whitequark[cis]>
all of the setup() functions are called concurrently when you do glasgow run; most of them will just run sequentially since there's going to be nothing async in there. but if your setup function requires talking to the applet, you would do await assembly.wait_for_start() and then do the thing you want
redstarcomrade has quit [Read error: Connection reset by peer]
<whitequark[cis]>
i think right now the primary thing applets do in run() is setting up pull resistors
<whitequark[cis]>
which should be an argument on add_port in first place
jfsimon has joined #glasgow
jfsimon has quit [Remote host closed the connection]
<whitequark[cis]>
okay, first breaking change about to be merged
<whitequark[cis]>
glasgow run uart: error: argument --pin-rx: applet 'uart': use --rx 1 instead
<threeflour[m]>
Re assembly API: I like it. Why is `add_setup_arguments` `async` through? Is there something special about it vs the other `add_foo_arguments` methods?
<threeflour[m]>
Re `glasgow build`: I sometimes like using it to check fmax/resource consumption without having my glasgow plugged in. If it's deprecated, would it be reasonable to add a "dry run" option to run?
<whitequark[cis]>
re: add_setup_arguments being async: that's just a typo
<whitequark[cis]>
re: glasgow build: yes, if it's removed there will be a --dry-run option for sure
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #glasgow
jfsimon has quit [Max SendQ exceeded]
jfsimon has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
galibert[m] has quit [Quit: Idle timeout reached: 172800s]
dne has quit [Remote host closed the connection]
dne has joined #glasgow
Foxyloxy has quit [Read error: Connection reset by peer]
Foxyloxy has joined #glasgow
<isabelburgos[m]>
Is the new assembly.add_port() function intended to support inverted pin arguments? Will the # notation be maintained with the new pin naming convention, ie --rx A0#?
<isabelburgos[m]>
Afaik setting pins to pull up/pull down still happens in claim_interface() and is yet to be replaced
FFY00_ has joined #glasgow
<whitequark[cis]>
<isabelburgos[m]> "Is the new assembly.add_port()..." <- the # notation stays with the new naming convention
FFY00 has quit [Ping timeout: 248 seconds]
<whitequark[cis]>
the inversion could be handled by accepting a PinArgument directly in add_port and passing PinArgument through when creating a port group; this part is a bit unpolished
<whitequark[cis]>
<isabelburgos[m]> "Afaik setting pins to pull up/..." <- yes, haven't got around to doing that
<whitequark[cis]>
it should be a method on the object returned by add_port maybe
<isabelburgos[m]>
<whitequark[cis]> "it should be a method on the..." <- maybe `await ports.setup()`?
<isabelburgos[m]>
<whitequark[cis]> "the inversion could be handled..." <- add_port accepting a PinArgument directly seems intuitive to me because `add_port_group()` would take the same arguments as the legacy `get_port_group()`, it is also convenient to just be able to use a string like `"A1"`
<whitequark[cis]>
no, pulls being set up at the beginning should just be automated; it's modifying it after that should require a method
<isabelburgos[m]>
I forgot you can set ports to pull up/ pull down without reloading the bitstream... very convenient
<isabelburgos[m]>
re: just using strings to name pins without going through PinArgument, self._platform.glasgow_pins.pop(pin_name) seems like an equivalent or better way of validating pin names than a regex, although it would be nice to be able to distinguish from an error message whether the pin doesn't exist or the pin has already been used
<whitequark[cis]>
you need the regex to parse the inversion, ranges, etc
<whitequark[cis]>
and then on top of it you check for existence
<isabelburgos[m]>
oh, right. if you're not using the CLI but scripting directly, like in the demo, you don't have to worry about argument parsing, but in that context it makes sense to me to declare a PinArgument directly and then use the same .add_port_group() interface as CLI applets. the PinArgument struct still uses a bare integer as the main identifier, is that something that will need to change along with the new pin naming scheme?
<whitequark[cis]>
yeah, PinArgument needs to be reworked
<isabelburgos[m]>
yeah and probably something more complex than just changing number: int to name:str, since directly declaring a PinArgument doesn't validate the pin number/name
<whitequark[cis]>
it's intended to be an internal thing really