<tnt>
mm, that patch might be a bit too restrictive actually. If the global output of the PLL has no connection (and only the CORE output is used), then I think the global network remains free to use for any other purpose.
<marcan>
hm, so. OnSemi NCP718/NCP705 and TI TLV733/755 have compatible packages and pinouts
<marcan>
whitequark: ^^
<marcan>
same as the the TLV757P that daveshah mentioned
<marcan>
(but we don't need 1A)
<marcan>
they're reasonably cheap (<$1 in singles) and seem to have decent availability
<marcan>
2x2mm package, so pretty tiny
<marcan>
and since they offer several currents in the same package, that gives some flexibility if we wind up with availability issues (though they all have 4-digit stock at digikey, so it looks good)
<marcan>
5-digit factory stock for some of them
<tnt>
TLV733 i don't see it in qfn6 ?
<marcan>
DFN6
<tnt>
yeah, same, I only see it in sot23 and xson4
<electronic_eel>
It is a cheap chinese companion crimp tool
<electronic_eel>
YTH-202B, like 8 dollars on Aliexpress
<whitequark>
ooh, nice
* whitequark
opens aliexpress
* whitequark
stares at the placeholder text
<whitequark>
it autodetected my language as russian using geoip and translated all the UI
<electronic_eel>
yeah, they "improve" their ui all the time
<electronic_eel>
like when they removed the "price per piece" option from the search window
<whitequark>
now that would be reasonably bad but the search placeholder text says, and i had to do a double take, "for your twat"
<whitequark>
oh wait, that's not their ui text
<whitequark>
that's search queries
<whitequark>
from random other people
<electronic_eel>
and you can't use quotes, AND OR keywords and so on
Jasjar has quit [Ping timeout: 250 seconds]
<tnt>
whitequark: did you get a chance to test the fix ?
<whitequark>
not yet, let me try
<whitequark>
tnt: yes, works
<whitequark>
and without even removing the SB_IO with the same GBs
<tnt>
whitequark: yeah, the input path isn't used turns out, so it can detect that.
<tnt>
actually you don't even use the global outputs of the PLL so it shouldn't use any global buffer but ATM they get assigned irrespectively if the global outputs are used or not.
<whitequark>
ahh
<whitequark>
so the fix for input path being unused is upstream?
<tnt>
yes
<whitequark>
sweet, thank you
<whitequark>
PLLs have always been a kind of sore spot
<tnt>
yeah, they're definitely a bit weird and so handling all that in nextpnr hasn't been trivial.
electronic_eel has quit [Quit: Konversation terminated!]
bgamari has quit [Ping timeout: 264 seconds]
bgamari has joined #glasgow
<eddyb>
does Lattice have any FPGA with integrated level shifters (comparable to what Glasgow does with external chips)?
<tnt>
eddyb: well you can choose the Vio per bank ... within some limits.
<eddyb>
although I guess that could increase the cost of a chip anyway, so it'd be mostly about reducing total board area
<eddyb>
tnt: hmm can you pick something other than the several LV options?
<eddyb>
that are listed in the datasheet
<tnt>
eddyb: sure anything between the min and max will work fine.
<tnt>
it's just not "specifieD" (i.e. they didn't test the theshold etc ...)
<eddyb>
huh, I had the impression you had to pick something like 3.3V, 2.5V or one of the other ones
<eddyb>
tnt: why does the max frequency differ with voltage then?
<whitequark>
the capacitance stays the same
<eddyb>
or are there several ranges within which you can pick any value?
<whitequark>
the swing is different
<tnt>
the max frequency of a level shifter also depends on the voltage ...
<eddyb>
oh fuck wow
<whitequark>
also yes
<eddyb>
so the values they give are what they tested and guarantee?
<tnt>
mm, they might just be "typical" values, not sure what the datasheet says.
<eddyb>
okay so what an iCE40 is missing is more like 5V, ESD protection, etc. right?
<eddyb>
tnt: I guess, and it probably depends on what you connect to that pin externally
<whitequark>
the iCE40 drivers are also fairly weak
<eddyb>
that I expected, heh. maybe MachXO3 is slightly better? anyway, I couldn't find much about Lattice
<whitequark>
you get 8 mA per pin
<whitequark>
well, i guess it's not that weak...
<eddyb>
but it sounds like some Altera FPGAs have fancier IO
<whitequark>
but the shifters can drive like 100 mA without apparent harm to them
<eddyb>
whitequark: well, all the FPGA has to drive is an LED :P
<eddyb>
(does this count as an optocoupler joke?)
<whitequark>
optocouplers are extremely slow
<eddyb>
dammit
<whitequark>
you'd be hard pressed to find one that works at >1 MHz
<whitequark>
people use microscopic inductors, see the ADuM series
<eddyb>
I'm surprised, given what I've heard fiber being used for. or is it a latency thing?
<whitequark>
fiber does not use optocouplers.
<eddyb>
sorry, I deleted a thing about not being sure how close the technology is, since I couldn't figure out how to phrase it
<eddyb>
anyway,,, it does seem safer to not get higher current and/or voltage on the same die as the precious logic blocks
<whitequark>
what do you want anyway
<eddyb>
I should study STARSHIPRAIDER, it probably explains how you make the big daddy of Glasgow
<eddyb>
or at least points in the right direction (idk how much of it is done)
<whitequark>
STARSHIPRAIDER is less flexible, actually
<eddyb>
hah!
<whitequark>
it uses a huge mux
<eddyb>
whitequark: okay, more to the point: I'm curious what you could do if you needed more channels: are there wider level shifters, or do you need to keep adding chips?
<whitequark>
nope, one chip and two capacitors per bit.
<eddyb>
wait how did I miss that jeeez
<whitequark>
there are wider level shifters, with one OE signal per group
<eddyb>
actually, you could have an expansion board for Glasgow with the same hardware as on the main board, and that plugs into the big LV header, couldn't you?
<eddyb>
anyway I'd be glad to use Glasgow for one I2C or JTAG port rn, and leave any wider stuff for later :D
<eddyb>
(and rn I should sleep instead of getting hyped)
<whitequark>
eddyb: do you have a glasgow already?
<eddyb>
no, patiently waiting to place an order :D
<eddyb>
considering assembling myself but unsure if wise as a first attempt at surface-mount (and I've barely done any soldering period, and it was long ago)
<whitequark>
nope
<whitequark>
it's quite fine pitch
<eddyb>
and I'm the opposite of pitch-perfect :P
<eddyb>
whitequark: fwiw if I buy one or two on the company, I wouldn't mind them being overpriced
<eddyb>
to help with further development and stuff
<eddyb>
(I mean, I'd buy ten but idk what I'd do with them,,,)
<whitequark>
esden keeps what people pay esden for glasgows
<eddyb>
oh I wasn't sure who would sell assembled glasgows
<esden>
whitequark: and sends free hardware to core developers :D ... when he eventually finally builds them... :/
bgamari has quit [Ping timeout: 240 seconds]
<esden>
(trying to wrap up all the needed information to order preassembled Pmods from PCBWay ... *grind*)
bgamari has joined #glasgow
<davidc__>
esden: heh.. you should get around to that, or I might have to get into the business!
<davidc__>
esden: (I mean, not that I want to, but if I have to do my own prod run to get myself a board, I'm going to build enough to sell to cover the NREs!)
<gruetzkopf>
It's not like I don't have a company that deals with assembly houses all day .
<davidc__>
esden: (and TBH, I'd much rather just pay someone else for a completed unit.....)
<gruetzkopf>
I could have some made at a rail-certified assembler or three
<esden>
davidc__: I know I know... I want to work on reviewing revC1 as soon as I am done with this step here. And then order a pile of prototype boards. I did that for revC0 and that one became obsolete before I came around to assemble them. :(
<esden>
marcan and whitequark are just moving too fast with their changes and improvoments...
<esden>
I hope C1 is stable enough now and will not require too many bodge wires. :D
Jasjar has joined #glasgow
Jasjar has quit [Remote host closed the connection]
Jasjar has joined #glasgow
<_whitenotifier-1>
[Glasgow] esden created branch 1b2-keys - https://git.io/fhhGp
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] esden pushed 1 commit to 1b2-keys [+0/-0/±4] https://git.io/fjY2w
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] esden 7f0f774 - revC1: Added BOM management keys to the schematic.
<_whitenotifier-1>
[Glasgow] esden opened pull request #129: revC1: Added BOM management keys to the schematic. - https://git.io/fjY2r
<esden>
whitequark: looking at the issues you are probably correct. (maybe we should have a badge for issues that imply "board layout change" so we can just filter them out?)
<esden>
or not even layout change, hardware change in general?
<whitequark>
esden: that's what "revC" generally means
<whitequark>
hrm
<whitequark>
wait
<whitequark>
yeah i'm going to add a tag for "hardware"
<_whitenotifier-1>
[Glasgow] whitequark unassigned issue #34: Use a dedicated USB protection IC instead of a regular fast-blow fuse - https://git.io/fjYak
<_whitenotifier-1>
[Glasgow] whitequark unassigned issue #34: Use a dedicated USB protection IC instead of a regular fast-blow fuse - https://git.io/fjYak