redstarcomrade has quit [Quit: Connection closed for inactivity]
sm2n_ has joined #glasgow
davidc___ has quit [Ping timeout: 245 seconds]
sm2n has quit [Ping timeout: 256 seconds]
davidc__ has joined #glasgow
egg|anbo|egg_ has joined #glasgow
GNUmoon2 has quit [Remote host closed the connection]
egg|anbo|egg__ has joined #glasgow
egg|anbo|egg___ has joined #glasgow
egg|anbo|egg has quit [Ping timeout: 258 seconds]
egg|anbo|egg__ has quit [Ping timeout: 245 seconds]
samlittlewood has quit [Ping timeout: 272 seconds]
samlittlewood has joined #glasgow
redstarcomrade has joined #glasgow
Eli2 has quit [Remote host closed the connection]
Eli2 has joined #glasgow
<d1b2>
<davoid> I'm a bit curious on the hardware design around the VIO1/2 banks
<d1b2>
<davoid> the INA233 serves as both a voltmeter for sensing the external IO-reference
<d1b2>
<davoid> as well as acting as an over current protection via it's programmable alert pin (to cut the LDO feeding the B side of the SN47LVx buffers
<d1b2>
<davoid> I haven't looked at the code reading the voltage, updating the DAC that in turn will control the Feedback pin of the LDO powering the buffers.
<d1b2>
<davoid> isn't there a risk that this loop isn't fast enough? i.e. what if the rail on the outside has ripple or suddenly drops (here you might want to ensure you get an immediate Hi-Z on pins driven from the glasgow to the outside board/IC)
<d1b2>
<davoid> was an LDO with tracking-input or some op-amp refeence tracking circuit ever considered? i.e. getting an analog control from the wanted VIN-reference to the LDO's output voltage!?
<d1b2>
<Attie> @davoid could you clarify? are you looking for all these interfaces at once, or one "dual UART" use-case, one "dual I2C", etc...
<d1b2>
<davoid> my hardware question is purely out of interest how the design decision came about
<electronic_eel>
@davoid this is not designed as live feedback loop
<d1b2>
<davoid> and if it's solved in terms of speed
<d1b2>
<davoid> I mean there are LDO's with track input to avoid the need for software control + the DAC
<electronic_eel>
you can read in the sense voltage once, and then the vio output is set to that. that is the "track" mode. it does not change the vio voltage when sense changes
<electronic_eel>
but when sense goes out of a defined window, it shuts the port down
<d1b2>
<davoid> ah, got it! so if the board on the outside has say a regulator that shuts down, then it's up to you to sense it and quickly shut off serial pins driven from the glasgow
<d1b2>
<davoid> would you mind pointing me to the code-part where this is handled
<electronic_eel>
and the adjacent files for the adc or ina233
<electronic_eel>
when you program a allowed voltage / current window into the ina233, it will pull the interrupt line. that triggers the irq in the fx2
<electronic_eel>
also on the newer versions with the ina233, pulling the interrupt line will automatically switch off the ldo, without needing intervention from the fx2
<electronic_eel>
oh, wait, the whole code isn't merged into main yet. take a look at the wip-revC2-firmware branch
<d1b2>
<davoid> thanks! checking
<d1b2>
<davoid> it's good if the INA233 can do it directly as the roundtrip latency host and back is unknown
<electronic_eel>
yes, also the firmware could hang because of some kind of firmware bug or similar
<d1b2>
<davoid> or hold on, main.c here runs on the FX2?? i'm not familiar with those usb-bridges
<electronic_eel>
yes, that is the firmware that runs on the 8051 core within the fx2
<electronic_eel>
(you need an 8051, otherwise it wouldn't be true usb)
<d1b2>
<davoid> curious why you decided to have some logic running there instead of letting the ice40 take care of it?
<electronic_eel>
how would you initialize the ice40 and load gateware into it? also you want an easy way to unbrick the whole thing in case you upload bad firmware/gateware during development
<d1b2>
<davoid> true true, especially the second one
<electronic_eel>
the fx2 has a mode where you can upload the whole firmware via usb
<d1b2>
<davoid> thats nice, so unbrickable rom-loader, that's nice
<electronic_eel>
yeah. so in normal cases you can just force-upload the firmware from the host with this mode and you are good again
<electronic_eel>
when you messed up the eeprom contents in a bad way you may have to short the resecue pins on the glasgow, then you can also rewrite the eeprom
<electronic_eel>
so unless you fried the hardware, the glasgow is unbrickable. really neat design from wq
<electronic_eel>
another point is that although the fx2 an older design, it is one of the fastest usb 2 hs interface ics around. you'd need quite a lot of fpga resources to match that in gateware
<ebb>
Also it's not an FTDI part
<ebb>
I had to look at FT232H documentation yesterday for work and it just kinda sucked
<d1b2>
<davoid> true! and a modern M7 or similar might be able to do it but probably far more complex to get the same feature set
<d1b2>
<davoid> my hope was all at once. 2x uart, 2x i2c, 2x spi. I have no feel for how much that is reasonable to cram in.
ali-as has joined #glasgow
ali_as has quit [Remote host closed the connection]
<d1b2>
<Attie> that may be more difficult... i know wq has mentioned wanting to use COBS before - you will likely need to look into something for framing & muxing (not impossible, but afaik, doesn't exist in the project yet)
<d1b2>
<Attie> in terms of utilisation, that's another thing to watch out for, but i don't have a good handle on what those components / that setup would require off-hand
<d1b2>
<davoid> so framing of data is not multiplexed today?
<d1b2>
<davoid> i.e. any ways to handle say 8 different channels of async 2-way data to-from the host?
<d1b2>
<Attie> [for context, one UART applet will take two USB endpoints - one for Tx and one for Rx... same for I2C and SPI... running two of these at once totals 4x endpoints, running more (i.e: 6x as you're requesting) isn't going to be possible as of now]
<d1b2>
<Attie> re "handle 8x channels" ... theoretically, yes - but that will require the framing / multiplexing i mentioned above, which doesn't exist today
<d1b2>
<davoid> got you, I thought there was already a multiplexer+demultiplexer in place to overcome (hide) the USB endpoints
<d1b2>
<davoid> any plans to implement a generic one? in a way usb endpoints is already doing this under the hood, but with the limit of the fx2 of course
<d1b2>
<Attie> in the sense that the content of the 4x FIFOs are transferred over a single parallel interface (at the physical level), yes there is a mux...
<d1b2>
<Attie> but in the sense that you're after (looking for more than the hardware supported 4x FIFOs), there isn't support for that
<d1b2>
<davoid> re: COBS, we always use it in other projects specifically for creating a simple way of handling framing over UART. i.e. SOF + max lenght of package + COBS. can be very low overhead. but would be nice with something more intelligent when dealing with multiple streams resulting in small packages and framing overhead
<d1b2>
<Attie> relevant slide from my fosdem talk:
<d1b2>
<davoid> I actually saw that one, thanks for reminding
<d1b2>
<Attie> np!
<d1b2>
<davoid> still not sure how the overall design vs. use-cases are meant to map to the internal fifos vs endpoints
<d1b2>
<Attie> currently, if an applet requests a FIFO, it'll get allocated one of those 4x physical FIFOs in the FX2, and a counterpart in the FPGA
<d1b2>
<davoid> does it always have to be one applet tied to a specific fifo
<d1b2>
<Attie> these are limited (to 4x), etc... thus 2x UART (1x Rx FIFO, 1x Tx FIFO) would equal 4x FIFOs and be possible
<d1b2>
<davoid> so basically max applet count is 8
<d1b2>
<Attie> if you want to go beyond that, we need to look at pushing data for multiple FIFOs through a single "USB endpoint"
<d1b2>
<davoid> assuming data in only one dir in each
<d1b2>
<Attie> ... and thus deal with framing, muxing, etc...
<d1b2>
<davoid> I'd love that flexibility. not having to worry about the 1:1 usb transport connection
<d1b2>
<Attie> re: "max applet count is 8" ... if a hypothetical applet took 1x FIFO, then the maximum would be 4 (i.e: 1 x 4 = 4)
<d1b2>
<davoid> I guess there will be lots of air on the wire regardless
<d1b2>
<Attie> (as of today)
<d1b2>
<davoid> a bunch of "fast" uart's of 5mbit could be multiplexed into one EP
<d1b2>
<davoid> so let's say I need to do this 🙂
<d1b2>
<davoid> would the best way be to try make a "composite applet", i.e. an applet that runs two uarts and handles it's own framing?
<d1b2>
<davoid> vs. "wait" until you guys figured out a generic way to mux/demux data from multiple applets
<d1b2>
<davoid> (I wouldn't dare to look at the latter one myself)
<d1b2>
<Attie> that's certainly an option... but I don't think it'll be the preferred approach, so wouldn't be accepted into the main repo - you'd have to maintain it alongside
<d1b2>
<Attie> depending on your budget and timelines (you mentioned consultancy - I presume paid)... getting the preferred implementation done might be something that someone here could help with......
<d1b2>
<davoid> any reasons not to re-use the same mux/demux that you have in place fo the EP's befoe it hits the python host side?
<d1b2>
<davoid> or do you rely on the framing of a regular USB EP?
<d1b2>
<Attie> it's just a very different design - that relies on the USB endpoints, yep
<d1b2>
<davoid> my original idea was to find someone to help out setup an initial project that can stream say one UART, one i2c, and one SPI master. Regarding the SPI it's more about best practise what to run where, say if you wanna stream data from a fast 8ch ADC as a start (then adding multiple IC's/chip-selects, again needing some framing or multiplexing if data-readout needs to be flexible/reconfigurable = not continous fixed len)
<d1b2>
<davoid> but the number of "applets" I want to be able to run will hit the EP limitation, so this will be a dependent task to solve.
<d1b2>
<davoid> I guess it would be smart with COBS and some sort of predictable stream-bundles (like in AVB) where you can allocate your bw needs and the protocol would ensure it gets packaget in an optimal way, ensuring each EP packet can get filled to 100% when needed
<d1b2>
<Attie> ... don't forget, with your "wish list" set of interfaces, you'll be completely out of pins with only 1x #CS per SPI interface
<d1b2>
<Attie> (unless you look at using the LVDS header, another bit of somewhat-uncharted territory)
egg|anbo|egg_ has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
<d1b2>
<davoid> the plan is to make a custom board with the peripheral (header) pin-outs hard-coded. this removes the need fo some direction pins, but I could also add two extra banks of buffered IOs where the LVDS sits today
redstarcomrade has quit [Quit: Connection closed for inactivity]
<whitequark>
a custom board with custom FPGA pinout will be a completely unsupported fork
<d1b2>
<davoid> I think we can survive managing that extra effort here
<d1b2>
<davoid> idea is that the implementation would be done on the official hardware first
<d1b2>
<davoid> does anyone have time to review what it would take to support more than 4x FIFO's?
<whitequark>
not any time soon
<whitequark>
unless you're paying for it
<whitequark>
it's not entirely clear whether COBS is what we need for more than four FIFOs, fwiw
<whitequark>
we do need a COBS implementation for things like protocol monitors
<whitequark>
where you don't know packet payload sizes beforehand
<whitequark>
and may not be able to buffer the entire packet
<whitequark>
but the packetization on the USB layer is entirely under our control, so COBS is not strictly necessary there; and speed of decoding COBS in Python might be an issue
<whitequark>
or encoding
<d1b2>
<davoid> happy to pay/sponsor the work!
<d1b2>
<davoid> would be nice with a variable lenght feature like you describe above, perhaps useful for tunneling things like IRQ -> reg reads from some peripheral IC hooked up to a specific applet
<whitequark>
okay. that will be possible in a few weeks; I have a few things in life I need to handle urgently before I'm going to spend significant time on FOSS maintenance
<whitequark>
"IRQ -> reg reads"?
<d1b2>
<davoid> performance is of course important, so happy with any implementation being able to run more applets in parallel. to me, latency is more important than bandwidth
<whitequark>
I believe the right approach here is to rewrite the FX2 crossbar to be more flexible about the way it routes packet bytes
<whitequark>
one thing this should enable is e.g. having four IN EPs
<d1b2>
<davoid> sorry, I mean, take the example of adding a 8ch ADC to an applet (not sure if it's generic spi and the rest in python, or have moe logic in the applet itself), usually those IC's might have a few signals to trigger when new data is ready, overflow, errors etc. these could either be sent 24/7 as part of the payload, or only as events as they happen (like I understood a protocol monitor could work)
<whitequark>
it probably requires splitting the crossbar into the front end (FX2 facing) and the back end (FIFO facing), with some bits of state on the front end that record which FIFO are the bytes destined for
<d1b2>
<davoid> there is no stress, first thing would be to see if the general concept of what I want to fit in the ice works or not
<whitequark>
re events from ADC: that doesn't need COBS, you can send fixed size packets on events