<whitequark[cis]>
> Used for Parallel Ports which were incorporated on to Video Cards - Doesn't support ECP addresses
<whitequark[cis]>
cursed
<whitequark[cis]>
supersat: okay, so, i reviewed this mess
<whitequark[cis]>
basically, the IBM parallel port is 8 general purpose outputs or sometimes I/O (data lines); 5 general purpose inputs (status lines); and 4 general purpose outputs (control lines) that people kinda sorta use as open collector but really shouldn't be
<whitequark[cis]>
this just barely fits on the Glasgow, requiring the use of the SYNC port for one of the lines (one of the control lines fits best)
<whitequark[cis]>
but other than that this could basically be 8 GPIO bank + 5 GPI bank + 4 GPO bank, or just a 8+9 GPIO bank for simplicity
brolin has joined #glasgow
brolin has quit [Read error: Connection reset by peer]
<adaisdead[m]>
wierdly I have an early bird case, but not early bird glasgow - will that mess things up?
esden[m] has joined #glasgow
<esden[m]>
If you ordered them together in one order you will receive the case when the glasgow becomes available. They will keep it one shipment.
trh has quit [Quit: weg]
trh has joined #glasgow
joerg has quit [Ping timeout: 255 seconds]
joerg has joined #glasgow
brolin has quit [Ping timeout: 248 seconds]
ar-jan has joined #glasgow
notgull has quit [Ping timeout: 252 seconds]
notgull has joined #glasgow
bvernoux has joined #glasgow
<dav_818[m]>
fully understand. about applet-count/streams of data, what are the current limitations when it comes to streaming data from several serial ports/IC's
<whitequark[cis]>
dav_818: there are two limitations in the way of having an arbitrary number of applets connected in parallel
<whitequark[cis]>
the first one is the UI, which I assume is not very relevant to you. this is largely a matter of defining a syntax for argparse or another CLI option parser (or a configuration file format) that is a bunch of effort tied to other things that isn't really viable to invest in right now
<whitequark[cis]>
the second one is the USB transport layer, which at the moment supports at most 4 unidirectional pipes (two IN and two OUT), so any combination of applets you put on the device must fit into those four pipes. in practice this means you can use at most two UART or SPI applets simultaneously
<nemanjan00[m]>
It just means it does not have enough memory for more time?
<whitequark[cis]>
the logic analyzer, despite being one of the more obvious applets, actually doesn't work all that well
<whitequark[cis]>
aside from selftest it's probably the worst designed/implemented applet
<nemanjan00[m]>
I went for it first, just to confirm I wired everything up correctly
_whitelogger has joined #glasgow
brolin has quit [Ping timeout: 255 seconds]
cyborg_ar has joined #glasgow
brolin has joined #glasgow
<dav_818[m]>
thx! read #354 and that looks like a great idea, minimal framing pci style.
<dav_818[m]>
I know the hardware is done and locked for the moment, but has alternative usb phy's been on the table? super-speed!?
<dav_818[m]>
good to have python parsing overhead in mind, perhaps multiple endpoints could solve some when used with async libs or running as separate processes
<nemanjan00[m]>
Is there any kind of help regarding starting implementing applet? I am already confused with concept of pads
<nemanjan00[m]>
I do understand I need to define _pins, but I do not know how those pins will be mapped to actual hardware pins
brolin has quit [Ping timeout: 272 seconds]
brolin has joined #glasgow
<Attie[m]>
nemanjan00: from a basic "applet" point of view, the pins are in two banks, A0-7 and B0-7. when port `AB` is used, they are exposed as pins 0 through 15 (A0, A1, ... B6, B7), otherwise (e.g: port `A` or `B`) they are just 0 through 7 corresponding to that port
<Attie[m]>
there is more to it behind the scenes, but if you're writing an first-time applet, I suspect that's all you need to know for the moment
<nemanjan00[m]>
My confusion is about what --pin-whatever will be if I do not pass it
<nemanjan00[m]>
if my _pins = ('whatever')
<Attie[m]>
they are just mapped in order, from zero
<Attie[m]>
e.g: take a look at the UART applet, which defines __pins = ("rx", "tx"), and ends up with --pin-rx (default: 0) and --pin-tx (default: 1)
<Attie[m]>
this is an area that may recieve some attention in the near-ish future, but this should cover you for today
<Attie[m]>
there are also other ways to define pins - see AccessArguments.add_pin_argument() and/or AccessArguments.add_pin_set_argument()
<Attie[m]>
the HUB75 output applet is probably a reasonable example for them, as it uses both
<Attie[m]>
[these are great questions for the "my first applet" docs that I'd like to write.......]
<Attie[m]>
* to write....... thank you]
<whitequark[cis]>
except of course the doc would have to be rewritten whenever we update the API
<whitequark[cis]>
FT600 is out of question, the more popular Chinese PHYs don't seem viable, the only option seems to be the FX3
<whitequark[cis]>
the FX3 has a really outdated FPGA core but is otherwise fit for our purposes
<whitequark[cis]>
there will be significant work needed on the USB side (both software and gateware) before we can migrate to something like an FX3 because I want the SuperSpeed capable device to also work via Ethernet, with the same protocol
<whitequark[cis]>
s/FPGA/ARM/
<tpw_rules>
how about the stuff using ecp5? is that too much yak shaving or too unreliable still?
<whitequark[cis]>
do you mean LUNA?
<tpw_rules>
i thought so but i looked that up and it didn't mention usb3
<whitequark[cis]>
it does implement an experimental USB3 stack
<whitequark[cis]>
so... after Maya was contracted by GSG to go over that code with a fine toothed comb and rewrite most of it, I have some baseline degree of faith in its viability at all which I previously (rightfully, as it turned out) did not
vegard_e[m] has joined #glasgow
<vegard_e[m]>
lifcl-33u looks interesting, but might end up too expensive to use as just a USB3 bridge
<tpw_rules>
it might also not be desireable to mix the usb3 engine and the user design
<whitequark[cis]>
however using LUNA means placing two FX3's on the board
<tpw_rules>
was just sort of thinking out loud bringing it back up
<whitequark[cis]>
err, two ECP5's
<tpw_rules>
so you wouldn't mix things
<whitequark[cis]>
and the FX3 is actually cheaper than the cheapest USB3-capable ECP5
<tpw_rules>
i see
<whitequark[cis]>
how else would I achieve unbrickability, keeing the desire for remote access in mind?
<tpw_rules>
watchdog?
<whitequark[cis]>
watchdog that checks what?
<vegard_e[m]>
fed by the host side software, so it resets if it can't connect to host?
<tpw_rules>
that the usb3 core is still on the fpga and alive.
<whitequark[cis]>
vegard_e[m]: if it's on par with the FX3 it could be a viable option
<whitequark[cis]>
tpw_rules: define "still on the FPGA and alive"
<whitequark[cis]>
I don't know how to reliably check that this holds if e.g. the end user downloaded a bitstream with a timing violation to the FPGA
<tpw_rules>
like it just toggles an i/o pin. i'm not immediately sure of a failure mode where a user design could do that
<tpw_rules>
i guess that's a good point. that could mess up your part of the design
<whitequark[cis]>
what you get is basically "fail short"
<whitequark[cis]>
ie where it keeps toggling the i/o pin but the actual management functions are dead
<whitequark[cis]>
and because all of the design is mashed together there's no way to separate the management functions from the user functions
<tpw_rules>
i guess yosys doesn't do partitioning at all?
<vegard_e[m]>
you could have a little mcu acting as the watchdog, checking for a specific sequence that's fed from the host
<whitequark[cis]>
nextpnr does not, no
<tpw_rules>
(i don't remember if the ecp5 hardware supports partial reconfig either)
<vegard_e[m]>
but that's a lot more complicated than just separating usb bridge from fpga
<whitequark[cis]>
vegard_e: the idea was to use the Ethernet wake-on-lan sequence to make this happen for Ethernet remoting
<vegard_e[m]>
IIRC there's some proof of concept doing partial reconfig on ecp5 even though it's not officially supported
<whitequark[cis]>
and for USB remoting we just say that USB has less of a reliability guarantee
<whitequark[cis]>
vegard_e: yes, I am the reason that proof of concept exists
<whitequark[cis]>
it's severely limiting, you can't use LUTRAM for example
<nemanjan00[m]>
Thanks
<whitequark[cis]>
we could potentially still use it but it's incredibly immature
<whitequark[cis]>
none of these things are ones that I'm willing to ship in a commercial product
bvernoux has quit [Read error: Connection reset by peer]
<whitequark[cis]>
especially given that FX3 works reasonably well and isn't that expensive