<wpwrak>
behaviour is very inconsistent. i wouldn't trust kicad when handling that
<wpwrak>
i saw too many bugs already (mentioned them on #kicad). this is really really treacherous ground
<wpwrak>
i'm just happy that i never tried to fix anything in the modem so far (i.e., before knowing about this problem). else, all hell would have broken loose
<wpwrak>
yup :) and you already hit a lot of bugs even below 64
<wpwrak>
so the only safe number of units is <= 26
<wpwrak>
anyway, PHS8 is now safe. down to 13 units. and the modem sheet basically looks identical
<wpwrak>
well, PHS8-CLEAN is. PHS8 still is the same nightmare it always was :)
<wpwrak>
ah, and i found some more problem parts: the FH23 connectors. they also consists of individual pins
<wpwrak>
they're in the BB section. i guess i'll just kill them and use my generic connectors. it's not as if there was anything special about them
<wpwrak>
after that, we have the TLV320AIC34ZAS with 24 units. close but no trouble.
<wpwrak>
and of course, good old OMAP, with 40
<DocScrutinizer05>
this 64 limit looks _very_ randomly chosen
<wpwrak>
clearly in need of a good haircut
<DocScrutinizer05>
please pstpone OMAP
<wpwrak>
could be sizeof(uint64_t) * 8
<wpwrak>
(OMAP) yup, definitely not for today :)
<DocScrutinizer05>
not even needed for proto_v2
<DocScrutinizer05>
and we don't know what exactly we'll need for OMAP when we use it, e.g. we might want footprint already with in-pad vias, or whatever
<wpwrak>
but i want to use it sometime soon. the idea is that i connect signals to the omap, to make sure everything has its place. that will also tell me about any pin type conflicts (which the connector to BB wouldn't)
<DocScrutinizer05>
ohmy
<wpwrak>
(footprint) that's unrelated. i'm not changing the pin "numbers". it's the pin numbers that define what goes where on the footprint
<DocScrutinizer05>
that's a job for pinmux!
<wpwrak>
in other words, all this cleanup has no effect on the footprints
<wpwrak>
luckily, kicad doesn't allow you to split a footprint into "units" ;-)
<DocScrutinizer05>
the idea was to keep OMAP out of design for proto_v2, not only regarding PCB and layout but also schematics
<wpwrak>
(pinmux) pinmux doesn't know the pin types in our schematics
<wpwrak>
yes, i just want to use it temporarily. we can then just remove the sub-sheet, and it's gone
<DocScrutinizer05>
definiteve nope @ using OMAP for proto_v2 schematics
<wpwrak>
(gone) until we put it back. so, it goes into hiding, not permadeath
<wpwrak>
as i said, temporarily, to help detect problems early
<DocScrutinizer05>
nope, too much overhead
<wpwrak>
not really. fixing problems we failed to detect will have much more overhead
<DocScrutinizer05>
no
<wpwrak>
just trust me on this :)
<DocScrutinizer05>
no
<DocScrutinizer05>
we have not the time nor the funds for doing it this way
<wpwrak>
der boese geist, der stets verneint
<DocScrutinizer05>
review of pin types in OMAP alone takes days if not weeks
<DocScrutinizer05>
and in the end it's totally meaningless for proto_v2 since we do not have any omap in proto_v2
<wpwrak>
and just a few weeks ago, you wanted the OMAP in there yourself, and even operational, not just for checking. amazing, how quickly how something can change from "let's just do it" to "oh, even a tenth of it would be prohibitively expensive to do" :)
<DocScrutinizer05>
don't twist my words!
<wpwrak>
i would assume that nik got the pin types mostly right
<wpwrak>
especially on the omap
<DocScrutinizer05>
not going to happen
<DocScrutinizer05>
this sort of "ERC" is 100% pointless for proto_v2
<wpwrak>
i've seen quite a number of his choices so far, and most are reasonable. there are areas of sloppiness, but they tend to announce themselves by other issues as well
<wpwrak>
so you say we do v2 without ERC ?
<DocScrutinizer05>
I say there won't be any OMAP getting used in proto_v2
<DocScrutinizer05>
period
<wpwrak>
sigh, there will of course be no omap for v2. merely as a transitional design aid, it will appear in the schematics. i mean, it already does at a number of places
<DocScrutinizer05>
adding the omap gives us zilch validation or check for the BB interface, plus it will defimnitely add a bazillion new bogus ERC errors and warnings
<DocScrutinizer05>
honestly, I totally fail to see the point of that maneuvre
<wpwrak>
it gives us indirect validation: the next step is then a transfer from omap to equivalent (i.e., also omap) pins on the BB interface
<DocScrutinizer05>
heck, then how do you check that the pins on BB interface are equivalent to those on OMAP, and what is the end benefit of that whole exercise??
<wpwrak>
and then deal with what remains (after disappearing the transient omap)
<DocScrutinizer05>
no
<wpwrak>
we have to check BB-OMAP equivalence anyway
<DocScrutinizer05>
exactly, so forget about that omap
<wpwrak>
we don't have a magical solution for BB. this will be a fair bit of work.
<DocScrutinizer05>
it only adds a week of useless overhead, if not more
<wpwrak>
more like a day, or half that
<DocScrutinizer05>
whatever it is, it's useless overhead
<wpwrak>
well, it's your project ...
<DocScrutinizer05>
you need to manually validate against the BB interface anyway
<wpwrak>
in any case, i'm done with editing for a bit. probably won't have time tomorrow. so in case you want to work on the two analog circuits (CABC and GSM comparator) you proposed, please feel free. though there are probably better ways to spend a sunday ;-)
<DocScrutinizer05>
and that manual evaluation and validation need to be waaay more in depth and high level than what a DRC can do. In the end the workflow with OMAP would be: here's a IRQ that needs to be fast and has wake capability, what do we have on BB interfaces? aaah here is pin ZZ34 GPIO, with pinmux alternative functrions not conflicting, so we can use that. [<now cruft starts>} So do we have a similar GPIO on our virtual OMAP? hmm, yes, let's take
<DocScrutinizer05>
this YX45. I connect it now. Oh, gives ERC error. Wait I found in virtual OMAP that pin is incorrectly clasified as POWER. I fix it. HOORAY http://wstaw.org/m/2016/10/02/plasma-desktopOx2309.png is happy now, connecting Output to BIDIR
<DocScrutinizer05>
but we already knew we're connecting output to bidir, we searched for exactly such thing on the available pins of BB interface
<DocScrutinizer05>
for signals like e.g. video bus it's even more bizarre, since we know we only can connect it to the video pins, and the pin type of those is pretty rigidly defined, we will learn exactly zilch from connecting them to a virtual OMAP before we connect them to the real BB video interface
<DocScrutinizer05>
same for I2C, SPI, PCM, you name it
<DocScrutinizer05>
s/DRC/ERC/g
qws-user-1229 has joined #neo900
qws-user-1228 has quit [Ping timeout: 272 seconds]
<DocScrutinizer05>
it makes way more sense to for example redefine pin types of the BB-xM interface connector according to the purpose we want to use that pin for. So OUTPUT even for a GPIO we want to use in output pinmux config
<DocScrutinizer05>
it's a manual task either way to make sure that OMAP pin on BB-xM's OMAP is compatible with that usage we specified for it. No local virtual transient OMAP chip will help on that