<esden[m]>
So the PCB cost is ~$2000 to replace them with new ones. As for the level shifters, I will have to check the inventory to make sure how many I have, but it is roughly $2000 per 1k boards. So if memory serves I have about $4k-$6k worth of those parts here. All that data needs to be verified, this is of the top of my head.
<whitequark[cis]>
I didn't realize you've ordered that many PCBs
Attie[m] has joined #glasgow
<Attie[m]>
<whitequark[cis]> "this means that every pin..." <- I saw something like this recently, but didn't investigate... 🙈
<whitequark[cis]>
it's been with us since revC0
<esden[m]>
Yeah well... I ordered them recently as we had so many of the boards already in the field, and I need to fulfill the campaign and have inventory after. And it was a cutoff to get a decent price. It is more expensive to order smaller batches.
<whitequark[cis]>
true
<esden[m]>
They just got delivered _TODAY_ >_<
<whitequark[cis]>
it's rather unfortunate that no one who noticed this behavior brought it up before today
<esden[m]>
yeah...
<Attie[m]>
(I only noticed if while playing with those Ethernet PHYs last week or whenever it was... recently though)
<esden[m]>
I think the software mitigation solution should be implemented. As well as work on revC4 initiated. In the mean time I have no choice but to continue fulfilling the campaign though. I hope that the slowdown and downsides of the software fix won't be a show stopper for most use cases. When the revC4 hardware is implemented and tested we can evaluate what to do and how to switch over to that design.
<whitequark[cis]>
sgtm
<Attie[m]>
s/if/it/
<esden[m]>
But let me say one other thing too. The pullup default mode on the ice40 is extremely dumb and annoying.
<whitequark[cis]>
100%
<Darius>
what do you think of publishing an ECO if people want to mod theirs?
<Darius>
eg tack on a pulldown
<Darius>
I haven't looked at the PCB to see how horrible that would be though
<whitequark[cis]>
infeasible
<Darius>
bummer
<esden[m]>
@darius that is a lot of pulldowns to bodge in 😬 ... and even more bodging to swap level shifters.
<Darius>
yeah I was thinking it was only 1 pull down but of course not..
<whitequark[cis]>
it's sixteen
jslcom[m] has quit [Quit: Idle timeout reached: 172800s]
josHua[m] has quit [Quit: Idle timeout reached: 172800s]
M87910[m] has quit [Quit: Idle timeout reached: 172800s]
omnitechnomancer has quit [Quit: Idle timeout reached: 172800s]
esden[cis] has quit [Quit: Idle timeout reached: 172800s]
notgull has joined #glasgow
Wanda[cis] has quit [Quit: Idle timeout reached: 172800s]
andymandias has quit [Remote host closed the connection]
andymandias has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
notgull has quit [Ping timeout: 252 seconds]
notgull has joined #glasgow
bvernoux has joined #glasgow
redstarcomrade has joined #glasgow
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has quit [Read error: Connection reset by peer]
q3k[cis] has joined #glasgow
<q3k[cis]>
Catherine: is that behaviour documented somewhere by lattice, or is this something you've only observed?
gatecat[m] has joined #glasgow
<gatecat[m]>
it's in the datasheet - "The default configuration of the I/O pins in a device prior to configuration is tri-stated with a weak pull-up to VCCIO"
alen6060[m] has joined #glasgow
<alen6060[m]>
If I want another glasgow I have to consider waiting for revC4?
<q3k[cis]>
gatecat: 'tristated with a weak pull-up' uh-uh
galibert[m] has joined #glasgow
<galibert[m]>
tristated but not really
<q3k[cis]>
well that sucks (and not just for the glasgow usecase, it generally sounds like a terrible default state to be in)
M246tnt[m] has quit [Quit: Idle timeout reached: 172800s]
<gatecat[m]>
it's definitely more normal for FPGAs (certainly ECP5, and I think Xilinx too) to have a weak pull-down by default
<gatecat[m]>
although, iCE40 doesn't have pull-downs at all, so I guess it kind of makes sense