DocScrutinizer05 has quit [Remote host closed the connection]
DocScrutinizer05 has joined ##openfpga
m_w has quit [Quit: Leaving]
<DocScrutinizer05>
DAMN! SEGV
<DocScrutinizer05>
btw azonenberg lain: the chipquick dadashit says "12 months warranty no matter if fridge or not"
<DocScrutinizer05>
and they clearly suggest to not discard product after the EOL of 2 months without fridge, 6 with. Rather inspect it and expect it to be still good when not looking strange
<azonenberg>
i used SMD291SNL
<azonenberg>
fwiw
<DocScrutinizer05>
yeah, I'm targeting a particular issue: OMAP warp. I pondered to solder the flimsy SoC with its ring of warping "flex PCB" around the fie to the PCB with SMD291SNL (so the molten solder would pull the flex down to PCB), only then place the PoP on top with SMDLTLFP and reflow again with temperature well below melting point of SMD291SNL
<DocScrutinizer05>
s/fie/die/
<DocScrutinizer05>
I'd hope the SoC/RAM doesn't reach 138°C during operation X-P
<DocScrutinizer05>
I also wonder what happens when you solder 'standard' SMD291SNL-compliant BGA solder balls with SMDLTLFP. Will they mix? will the 'normal' solder balls even melt and connect to the low temp solder paste?
<azonenberg>
That i dont know
<azonenberg>
as a general rule mixing solder alloys is bad juju
<DocScrutinizer05>
yeah
<DocScrutinizer05>
but which chip has pins/balls with SMDLTLFP on it?
<azonenberg>
Nothing :p
<DocScrutinizer05>
Sn42/Bi57.6/Ag0.4 vs Sn96.5/Ag3.0/Cu0.5
<DocScrutinizer05>
except for the Bi they look as if htey'd form alloys happily, aka 'mix'
<azonenberg>
yeah but how strong is that alloy?
<azonenberg>
compared to the others
<azonenberg>
will it disintegrate on two thermal cycles? :p
<DocScrutinizer05>
BFC :-)
<DocScrutinizer05>
"No"* even
* DocScrutinizer05
wonders if the effect will be similar to Sn96.5/Ag3.0/Cu0.5 on Cu100
<DocScrutinizer05>
or Bronze, or brass
<DocScrutinizer05>
odds are there won't be much mixing, except for a thin layer where one material blends into the other
<DocScrutinizer05>
since bronze is made from copper amd bismut, I don't think the resulting alloy from 'mixing' (or soldering) Sn96.5/Ag3.0/Cu0.5 with Sn42/Bi57.6/Ag0.4 will be particularly brittle or weak in any way
<DocScrutinizer05>
metallurgy, a black art of its own
<DocScrutinizer05>
Shouldn't quickchip know about such things?
<davidc___>
heh, that "get attachment" path seems secure
<davidc___>
(not that I plan to try)
<DocScrutinizer05>
hm?
<davidc___>
never mind :P
GreeningGalaxy has quit [Quit: WeeChat 1.6]
<DocScrutinizer05>
a very interesting question is activation temperarure of the flux
<DocScrutinizer05>
you probably don't want to try and solder a SMD291SNL flux contaminated solder point with lowtemp solderpaste, unless you carefully removed all flux residues
<azonenberg>
you mean b/c the other flux wouldnt have activated yet?
digshadow1 has joined ##openfpga
digshadow has quit [Ping timeout: 246 seconds]
<DocScrutinizer05>
well, because the residue might not even get liquid maybe, at such low temperatures
Hootch has joined ##openfpga
<DocScrutinizer05>
I'd generally think the flux is composed for a certain taget temperature matching the solder melting point minus some offset
<DocScrutinizer05>
so maybe a "general purpose" flux is not always exactly helpful for lowtemp solder
<DocScrutinizer05>
not sure, just musing
<azonenberg>
no idea
<azonenberg>
my only low-temp work was LEDs on aluminum core pcb
<azonenberg>
using low temp paste
<azonenberg>
and no high temp anywhere in the system
<DocScrutinizer05>
why lowtemp?
<DocScrutinizer05>
LED max temperature?
<azonenberg>
Yeah
* DocScrutinizer05
wishes he knew the abs max temp of "PHY" (whatever it is) in EdgeRouter Pro8
<rqou>
broadcom? max temp is a bajillion degrees because that's the natural state :P
<rqou>
more seriously, they've gotten A LOT better at this on the recent parts
<rqou>
PHYs still get really hot though
<digshadow1>
rqou: max temp is competitor's spec +5C?
<rqou>
i have no idea if they do that or not :P
X-Scale has quit [Read error: Connection reset by peer]
<rqou>
egg|egg: does ada have aliases?
<rqou>
i might have found an interesting ghdl bug (via language lawyering)
<rqou>
i really need to build a new ghdl to see if any of these bugs are fixed
<egg|egg>
rqou: mooo?
<rqou>
entity test is signal a : bit; alias a is a; begin end;
<rqou>
i believe this is legal but ghdl rejects it
<egg|egg>
rqou: what do you mean? aliased is a keyword, which means you can take the address of the thing
<egg|egg>
alias isn't, what does it mean?
<egg|egg>
s/address/Access/
<rqou>
ok this is a vhdl-specific feature then
<rqou>
it basically defines a new name for an existing "named entity"
<egg|egg>
rqou: ah, renames?
<egg|egg>
as in π : constant renames Pi;
<rqou>
yeah
<egg|egg>
well in Ada that's called a renaming
<egg|egg>
not an alias
<rqou>
so normally in vhdl you cannot declare two different things with the same name
<rqou>
the spec uses the term "homograph" to describe when this happens
<egg|egg>
(works only for functions or procedures or variables or constants btw, not types; there you'd use a subtype)
<egg|egg>
rqou: Ada has overloading, a lot of it
<rqou>
but the spec says "Each of two declarations is said to be a homograph of the other if and only if both declarations have the same designator, **and they denote different named entities**"
<egg|egg>
(though you can't have two variables with the same name)
<rqou>
so via language lawyering, since i'm renaming a to a, it is not a different named entity
<egg|egg>
(unless they're at different scopes, usual business)
<egg|egg>
rqou: note 9: Renaming with a different identifier or operator_symbol does not hide the old name; the new name and the old name need not be visible at the same places.
<egg|egg>
also 7.a: The second sentence of RM83-8.5(3), “At any point where a renaming declaration is visible, the identifier, or operator symbol of this declaration denotes the renamed entity.” is incorrect. It doesn't say directly visible. Also, such an identifier might resolve to something else.
<rqou>
sure
<rqou>
in this case i'm doing a useless rename from a to a though
<rqou>
i believe that should be just ignored
<egg|egg>
rqou: static semantics, aa-8.5.1 6/2: An object_renaming_declaration declares a new view [of the renamed object] whose properties are identical to those of the renamed view. [Thus, the properties of the renamed object are not affected by the renaming_declaration.
<egg|egg>
if it's [normatively] a new view, it can't be the existing one?
<rqou>
VHDL just says "An alias declaration declares an alternate name for an existing named entity."
<egg|egg>
hm
<egg|egg>
rqou: is there something in the RM about the rules about declaring a name in general?
<egg|egg>
(also, blarg, they don't have the concept of view?)
<rqou>
"Two declarations that occur immediately within the same declarative region, other than [not relevant], shall not be homographs, unless [not relevant]"
<rqou>
"Each of two declarations is said to be a homograph of the other if and only if both declarations have the same designator, **and they denote different named entities**, and [not relevant]"
<rqou>
they don't denote different named entities here
<egg|egg>
rqou: so it all hinges on the interpretation of "alternate"
<egg|egg>
can the same name be said to be an alternate name?
<egg|egg>
I'd tend towards no
<egg|egg>
but that standard is badly written
<egg|egg>
so that's a US sense of alternate, doesn't appear in the Oxford dictionaries
<rqou>
there's always the answer of "wtf r u doin?" :P
<egg|egg>
rqou: since it's US english, in Merriam-Webster, 4: constituting an alternative took the alternate route home; alternative: 2
<egg|egg>
: different from the usual or conventional: such as [examples]
<egg|egg>
rqou: so I would say that 1. it's written in US english; 2. the "alternate" implies that; 3. it's really badly written if you can't even read it by the OED and understand it :-p
<rqou>
hrm, maybe
<rqou>
i just realized that it's actually more important than a silly "alias a is a" because aliases may contain a subtype_indication
<rqou>
and can be used to coerce types
<egg|egg>
.... blaaargh
scrts has quit [Ping timeout: 260 seconds]
<egg|egg>
(did I mention this language sounds ugly :-p)
<rqou>
so are you saying i might be in the 1c state? :P
Bike has quit [Quit: leaving]
scrts has joined ##openfpga
<rqou>
hrm, so my old ghdl problem has been fixed
<rqou>
egg|egg: back to language lawyering
<nats`>
setup for metastability is running !
<rqou>
if you use merriam-webster's definition 1 for alternative, "offering or expressing a choice"
<rqou>
you can argue that two names that are the same still offers a choice, it's just that there is only one thing to choose from
<rqou>
i'm inclined to go with "no, that's dumb" though :P
<rqou>
especially the part where you can coerce types with it
<egg|egg>
rqou: yes, but see that's probably just Merriam-Webster being bad
<egg|egg>
rqou: if you define alternate by alternative, maybe you should say *which meaning* is meant >_>
<egg|egg>
I think in this case it has to be 2
<egg|egg>
rqou: ah, we can use Oxford actually
<egg|egg>
rqou: alternate: North American ‘a novel set in an alternate universe’ another term for alternative; BUT alternative: 1. [attributive] (of one or more things) available as another possibility or choice. 2. Relating to activities that depart from or challenge traditional norms.
<rqou>
i'm just going to make it "you can't do that, that's silly"
<rqou>
:P
<egg|egg>
rqou: that seems consistent with the Oxford reading of that as american
<egg|egg>
rqou: also yes it would be daft, but the standard is daft; you implement the standard, not reason :-p
<rqou>
ghdl also doesn't let you do it
<egg|egg>
rqou: the g-something compilers have nothing to do with standards though
* egg|egg
stabs gnat
<rqou>
i wonder if there is an errata/clarification for this?
<rqou>
also, ghdl doesn't belong to the gnu compiler suite
<egg|egg>
gnat didn't initially I think?
qu1j0t3 has quit [Ping timeout: 240 seconds]
seu has quit [Remote host closed the connection]
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
qu1j0t3 has joined ##openfpga
pie_ has quit [Ping timeout: 268 seconds]
scrts has quit [Ping timeout: 260 seconds]
m_t has joined ##openfpga
seu has joined ##openfpga
scrts has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
scrts has quit [Ping timeout: 260 seconds]
pie_ has joined ##openfpga
scrts has joined ##openfpga
pie_ has quit [Ping timeout: 256 seconds]
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 268 seconds]
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
m_t has quit [Quit: Leaving]
Zarutian has joined ##openfpga
Zarutian has quit [Read error: Connection reset by peer]
Zarutian has joined ##openfpga
scrts has quit [Ping timeout: 246 seconds]
digshadow1 has quit [Ping timeout: 260 seconds]
digshadow has joined ##openfpga
promach has quit [Ping timeout: 258 seconds]
Zarutian has quit [Quit: Zarutian]
promach has joined ##openfpga
Bike has joined ##openfpga
amclain has joined ##openfpga
m_w has joined ##openfpga
talsit has left ##openfpga [##openfpga]
digshadow has quit [Ping timeout: 240 seconds]
promach has quit [Ping timeout: 258 seconds]
pie_ has joined ##openfpga
Zarutian has joined ##openfpga
X-Scale has joined ##openfpga
scrts has joined ##openfpga
digshadow has joined ##openfpga
pie_ has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 268 seconds]
m_w has quit [Quit: leaving]
m_t has joined ##openfpga
m_w has joined ##openfpga
pie_ has joined ##openfpga
qu1j0t3 has quit [Ping timeout: 256 seconds]
m_w has quit [Quit: Leaving]
Hootch has quit [Quit: Leaving]
GreeningGalaxy has joined ##openfpga
qu1j0t3 has joined ##openfpga
GreeningGalaxy has quit [Ping timeout: 240 seconds]
digshadow1 has joined ##openfpga
digshadow has quit [Read error: Connection reset by peer]