<stary[m]>
i have a custom ice40 board here with only spi cipo/copi brought out for the flash - i don't seem to be able to use `program-ice40-flash` for this, if i pass `--pins-io 2,3` i get an error that `set 2,3 includes 2 pins, but 4 pins are required`
<stary[m]>
would be nice if this is supported
<whitequark[cis]>
this is a known issue with the memory-25x applet
<whitequark[cis]>
the workaround at the time is to pick some unused pins
<stary[m]>
right, that seems to work
<stary[m]>
thanks
<whitequark[cis]>
(the reason this issue exists is because QSPIController uses IOStreamer which is difficult to make generic over sets of pins)
<whitequark[cis]>
the solution here is perhaps to allow specifying something like ? as a pin, in which case it just goes into nowhere
<fridtjof[m]>
(it totally makes sense why this exists, same reason as maintaining some DOS/3.11 system for old CNC equipment i would guess)
<whitequark[cis]>
why not Ethernet over 40 Gbps over USB-C?
<whitequark[cis]>
(that is more or less the plan)
WilfriedWonkaKla has joined #glasgow
<WilfriedWonkaKla>
<asjackson> "well, when glasgow has ethernet..." <- I'd prefer 40Gbps over USB-C.
<WilfriedWonkaKla>
"whatever works" over 40 Gbps.
<WilfriedWonkaKla>
Ethernet would be a bottleneck.
<whitequark[cis]>
I think this is frankly a bit unrealistic
<WilfriedWonkaKla>
I mean *BASE-T Ethernet would be.
<whitequark[cis]>
for one, this only works if we have a Xilinx FPGA, because ECP5 isn't gonna be able to process 40 Gbps of anything
<whitequark[cis]>
I don't think it even has 40 Gbps of IO in any meaningful way
<whitequark[cis]>
you'll also need a lot of buffering, and most importantly, there's no way you're processing that much data in Python
<whitequark[cis]>
I wouldn't expect any Glasgow rev any time soon to advertise more than 10 Gbps of IO
<whitequark[cis]>
(this is notwithstanding the complexity of gateware needed to process that much data)
icb has quit [Ping timeout: 244 seconds]
icb has joined #glasgow
<WilfriedWonkaKla>
My point was that there is no need for Ethernet on Glasgow because USB-C can already do faster communication than any SOHO Ethernet.
<whitequark[cis]>
but now you need a USB host
<whitequark[cis]>
i would very much like to be able to plop a glasgow in a test fixture somewhere remote and not worry about the USB falling off or the attached rpi killing its microsd card in half a year or something
<asjackson>
i wonder how far I could get trying to add a wiznet
<asjackson>
have to disable three lines because they both think they are controllers, but it does the thing
<whitequark[cis]>
very nice
<whitequark[cis]>
i do remember about the simulation bug, it's in my queue
<asjackson>
it's all good, i opened the PR because I thought it _was_ in fact working and it's a nice test case, but then i realised it wasn't
<asjackson>
and also i was off work for a couple of weeks, and now im back in work.. so :'(
<whitequark[cis]>
oh, it was broken on your side?
<asjackson>
the ordering of how you read and write to fifo in simulation seems to matter
<whitequark[cis]>
yes, that's expected to some degree
<asjackson>
but it should be bidirectional
<asjackson>
basically i got it working writing in one direction and reading from the other, but when i added a write / read in the opposite direction after, it gets stuck :D
jfsimon has quit [Quit: Leaving]
jfsimon has joined #glasgow
l0rds474n[m] has quit [Quit: Idle timeout reached: 172800s]