egg|anbo|egg has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
<fest>
TomKeddie: thanks, looks exactly what I need
egg|anbo|egg has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
bvernoux has quit [Quit: Leaving]
egg|anbo|egg has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
jstein has joined #glasgow
egg|anbo|egg__ has joined #glasgow
egg|anbo|egg has quit [Ping timeout: 260 seconds]
egg|anbo|egg__ has quit [Read error: Connection reset by peer]
egg|anbo|egg has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
Eli2 has joined #glasgow
Eli2_ has quit [Ping timeout: 240 seconds]
egg|anbo|egg has quit [Remote host closed the connection]
Sarayan has joined #glasgow
* Sarayan
waves
egg|anbo|egg has joined #glasgow
<whitequark[m]>
hi Sarayan
<Sarayan>
hi you
<Sarayan>
I'm curious how possible it would be to build a glasgow variant with a cyclone v and more i/os
<whitequark>
it's possible but it will not be supported upstream per policy
<whitequark>
technically, should be fairly straightforward
<Sarayan>
is rhw policy "full open source toolchain"?
<whitequark>
"rhw"?
<Sarayan>
the
<Sarayan>
sorry, cat installing herself makes typing harder
<whitequark>
the policy is essentially that the upstream only supports the hardware that is produced by the upstream
<Sarayan>
oh ok
<whitequark>
this is not sustainable otherwise
<Sarayan>
of course
<Sarayan>
I hate when it completely makes sense :-)
<whitequark>
hehe
egg|anbo|egg has quit [Remote host closed the connection]
<Sarayan>
In fact I was wonderinf of hard/expensive it would be to go 64 or 128 (to make foone happy) i/os wiyh minimal changes
<Sarayan>
how
<Sarayan>
(cat deinstalled herself, that did not help either)
<whitequark>
you could do that with ecp5, i think, and retain the advantages of a FOSS toolchain
<whitequark>
there's a 384 ball ECP5 iirc?
<Sarayan>
and I was suspecting the number of i/os on the fpga was an issue
<Sarayan>
and possibly the number of LE in general
<whitequark[m]>
well
<whitequark[m]>
128 I/O is a large board with many components, expensive
<whitequark[m]>
the existing revC3 board is already not cheap to make
<Sarayan>
really? I actually have no idea
<whitequark[m]>
the market for a 128 I/O variant that's otherwise like revC3 is much smaller
<Sarayan>
yeah, I like 64 because it tends to cover anything nmos or close, time-wise
<whitequark[m]>
electronics is expensive to manufacture, especially in small batches, especially with as many BOM lines as in revC
<whitequark[m]>
... especially during a severe silicon shortage
<Sarayan>
you can put a 68000 or pretty much any processor of the same time with 64
<Sarayan>
oh sure, now is not a good time for pretty much anything
<Sarayan>
it's jsut that you hit 16 pretty damn fast
<whitequark[m]>
64 I/O is still 4 times more than the current board. it would be a much larger, much more complex board. probably more layers
<whitequark[m]>
revD will be 32 I/O for that reason
<Sarayan>
more complex really? It looked really module in 8-channels increments
<whitequark[m]>
revE will go much higher up, but that has daughterboards
<Sarayan>
modular
<whitequark[m]>
well
<whitequark[m]>
yeah, but there's a lot more components and routing
<whitequark[m]>
by no means it's not impossible, it's just making an already fairly expensive design more expensive
<whitequark[m]>
* by any means it's not impossible, it's just making an already fairly expensive design more expensive
<Sarayan>
yeah, I see, it's the "already fairly expensive" that's the issue I guess
<whitequark[m]>
it's possible to reduce the cost of the existing revC design somewhat by adhering to JLCPCB design rules, but probably that won't work for a 64 I/O design
<Sarayan>
Interestingly, I suspect BOM would stay the same, only with larger numbers
<Sarayan>
3 more i/o blocks can be problematic for routing the signals though
<whitequark[m]>
yes, also you'll need to redo the I2C stuff because there's a limited amount of addresses on the bus that can be used by Vreg related ICs
<Sarayan>
and the cost of the pcb is nothing to scoff at
<whitequark[m]>
yes
<Sarayan>
oh, you can't just extend nilly-willy then
<whitequark[m]>
you can make ports wider, i guess? like a 32-pin port A and 32-pin port B
<whitequark[m]>
that would result in no changes to firmware and only rudimentary changes to the host stack
<Sarayan>
fanout may be annoying, but otoh if you connect *one* chip you don't need 8 different voltages usually
jstein has quit [Quit: quit]
<Sarayan>
you have the fx2 so that you can boot the fpga from usb?
<whitequark>
multiple reasons
<whitequark>
fx2 is unbrickable
<Sarayan>
that's nice indeed
<whitequark[m]>
it also serves as a board management controller, doing all sorts of aux stuff
<whitequark[m]>
so that anything can be loaded into the FPGA without messing up the board
<whitequark[m]>
and yeah
<d1b2>
<theorbtwo> Hm, I was wondering kind of the oppisite: how hard would it be to make something like the glasgow, but without some of the fancier / BOM-harder bits, like current sensing, maybe some of the protection.
<whitequark[m]>
easy
<whitequark[m]>
just don't call it glasgow
<Sarayan>
a cyclone v with embedded arm would be the more epensive version of the same thing I guess
<d1b2>
<theorbtwo> Shawlands, I think.
<Sarayan>
(*way* more expensive I suspect)
<whitequark[m]>
because the fancier bits are why i made glasgow in first place. it's protected against accidental misuse
<Sarayan>
these fancier bits are the reason I'm very interested by glasgow too :-)
<d1b2>
<theorbtwo> (It's a suburb of glasgow, for a cut-down version.)
<Sarayan>
Can you connect multiple gg without using the 16 i/os?
<whitequark[m]>
"gg"?
<Sarayan>
glasgow, the lazy typist version
<whitequark[m]>
this was sort of planned, but it's not even clear if the original plan is viable
<d1b2>
<theorbtwo> Two reasons I see to do it. In normal times, you might want one after you've got a proven design -- you aren't planning on misusing it anymore -- but you don't want to redesign everything.
<Sarayan>
it's a swiss knife, if you odn't misuse it you don't need a swiss knife
<whitequark[m]>
it's a debug tool. you don't put it in your designs. the entire stack is built around assumptions that it's used as a debug tool
<whitequark[m]>
you can borrow pieces of the stack because it's built in a fairly modular way, though there are no explicit API boundaries at the moment, and you're expected to just grab the pieces you want individually
<d1b2>
<theorbtwo> In current times, you might want one because a full glasgow is unobtanium, so anything that you can actually get that scratches the same itch is much cheaper then infinite cost.
<whitequark[m]>
i believe one of the reasons it's unobtainium is the shortage of the iCE40 FPGAs
<whitequark[m]>
sure, you can cut down on the TI parts, but you still have that problem
<d1b2>
<theorbtwo> Damn. There goes that idea.
jstein has joined #glasgow
egg|anbo|egg has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]