07:01 <d1b2> <Hardkrash> I can't recall if there was consensus on the signaling for addon standardization. The BOM calls out a 3 pin header for the AUX header J10. Using pins pointing up and SMT sockets on the attached board facing down. The aux would be good to do a UART chain with loop back at the end, this allows for addon board intercommunication if more than one addon is attached. If the board cannot be stacked then it need not have the upward facing

07:01 <d1b2> pin. If it can have additional addons stacked then it can have a simple shunt attached to terminate the loopback. This alleviates the need for I2C address discovery and addressing collisions.

07:02 <d1b2> <Hardkrash> Ugh, meant to edit this more... accidentally sent.

07:02 <d1b2> <Hardkrash> Resent with edits.

07:04 <d1b2> <Hardkrash> I can't recall if there was consensus on the signaling for addon standardization. The BOM calls out a 3 pin header for the AUX header J10. Using pins pointing up and SMT sockets on the attached board facing down. If the board is not intended be stacked on top of; then it need not have the upward facing pins. The aux would be good to do a UART chain with loop back at the end, this allows for addon board intercommunication if more than one

07:04 <d1b2> addon is attached. If pins are present and no additional stacked addons, then a simple shunt makes the loop back complete. This alleviates the need for I2C address discovery and addressing collisions while providing the position attached addons.

07:10 <d1b2> <Hardkrash> An example addon I was thinking of having would be an industrial voltage level shifting IO board 0-60VDC or 0-240VAC, and would use the aux to configure and monitor the voltages and IO directions. It would have 2 UARTs. one upstream and one downstream. the UART going towards the top addon would interface with any other addon stacked on top and provide control if needed.

09:25 <electronic_eel> @Hardkrash: the idea of an addon header was discussed in depth in the past. the conclusion was to postpone it to revD and maybe to a later redesigned enhanced version of revC. main point was to not delay revC any further.

09:26 <electronic_eel> the idea was to use i2c to allow very simple addons where you just need to stick an eeprom on and that allows the software to properly detect it

09:27 <electronic_eel> we also thought about stacking multiple addons and rerouting the address pins to prevent address collision

09:29 <electronic_eel> but since the i2c bus would be shared with the main system bus that is used to control the pullups, vreg-dacs and so on, we came to the conclusion that a proper bridge would be necessary to isolate the busses (the fx2 just has one i2c bus)

11:50 <whitequark> Kate Temkin suggested moving to ECP5 while doing the revD design, which I think makes a lot of sense; this lets us approach revE step by step

11:50 <whitequark> in the same vein we could treat revD as an evolution step in IO capability rather than just a 2xrevC

11:51 <whitequark> with the amount of time it takes (and will take) to ship these things this is the only reasonable approach anyways

12:31 <electronic_eel> yes, using ecp5 for revD looks reasonable. i think in the past the arguments against it was mostly price and that the open toolchain wasn't as refined as the one for ice40

14:03 <d1b2> <davoid> has super speed usb been on the list?

14:22 <whitequark> yes, for revE

14:28 <d1b2> <sierra (she/her)> where will glasgow development be taking place in future? In the same github repo or elsewhere?

14:31 <d1b2> <Attie> not sure why it would be moving from the existing git repo?

14:32 <d1b2> <sierra (she/her)> yeah reasonable it's late early I ain't thinking straight (well, less than usual)

14:57 <d1b2> <davoid> maybe discussed already, but I think it would be nice with higher density/"speed" headers like https://www.i-pex.com/product/novastack-35-hdp (except that no of mate cycles isn't the best), some larger more robust board2boards out there that might be better for a dev platform like this

14:58 <whitequark> revE will use SYZYGY-compatible Samtec daughterboards, I think

14:58 <whitequark> or something similar, reusing SYZYGY seems vaguely useful though

15:37 <d1b2> <bartios> Is there any sort of timeline for new revs?

15:40 <whitequark> it's about the same as the timeline vendors have for shipping semiconductors

15:40 <whitequark> i could give you a date and it would be a lie

15:51 <d1b2> <bartios> I guess this is a good channel to watch if I want to stay up to date?

16:07 <whitequark> yes