<whitequark>
it's not automatic because you might not need it and it takes a reset line.
<TD-Linux>
yeah but that doesn't include the 36 cycle wait
<whitequark>
sure?
<whitequark>
i don't understand what do you want
<TD-Linux>
I mean, if you're targeting ice40 wouldn't it make sense to automatically always generate a delayed reset line to work around the bram bug? given that yosys infers brams I don't think there would be many cases you wouldn't want the delay
<whitequark>
how many cycles of delay using what clock?
<TD-Linux>
I was just thinking using default_clk (and its period to figure out how many cycles)
<whitequark>
mmhm
<whitequark>
still, it adds a reset to your design
<whitequark>
i'm not sure
<TD-Linux>
yeah and I guess it's not 100% foolproof, especially if you have multiple clocks that start at different times.
<whitequark>
yep
<whitequark>
i might add a warning in nmigen...
OmniMancer has joined ##openfpga
<SolraBizna>
hey, I suddenly exist again, with *questions*
<SolraBizna>
(gasp)
<SolraBizna>
say I'm making a CPU out of an iCE40 LP8k, and say I'm using the PLL (with an external oscillator) to generate an IO clock, and say the IO device requires a differential clock signal
<SolraBizna>
...can I do that?
<whitequark>
if you use the bank 3, i think?
<whitequark>
either that or use DDR in regular registered IOs
<whitequark>
but that will give you a different phase
<SolraBizna>
well, I can
<SolraBizna>
so :D
unixb0y has quit [Ping timeout: 268 seconds]
flea86 has joined ##openfpga
unixb0y has joined ##openfpga
noobineer has joined ##openfpga
dj_pi has joined ##openfpga
dj_pi has quit [Ping timeout: 268 seconds]
gsi__ has joined ##openfpga
gsi_ has quit [Ping timeout: 255 seconds]
Bike has quit [Quit: Lost terminal]
genii has joined ##openfpga
genii has quit [Remote host closed the connection]
emeb has left ##openfpga [##openfpga]
StCypher has joined ##openfpga
StCypher has quit [Client Quit]
_whitelogger has joined ##openfpga
noobineer has quit [Ping timeout: 250 seconds]
m_w has quit [Quit: Leaving]
<mithro>
Anyone have recommendation for a desktop soldering station I should get? It will probably only get very light usage....
<cr1901_modern>
Weller wes51 is what I've used for the past 4 years to great effect
<whitequark>
mithro: depends on what kind of things you need to do
<whitequark>
but in general I would go for a T12 cartridge iron and the cheapest controller you're comfortable with. the chinese ones get *really* cheap these days; i have one for $20
<mithro>
whitequark: Soldering ICs every now and then, tinning wires, etc -- things like little pmods and stuff...
<whitequark>
mithro: I mean how miniature
<mithro>
0402 space...
<whitequark>
like i routinely have to solder to 0.3 mm pitch TQFPs and stuff
<azonenberg>
whitequark: what about a metcal or similar?
<azonenberg>
how does that fit your analogy
<mithro>
I find bash scripts always seem to evolve from "I just need to run a couple of commands" to "OMG how did I get into this mess" while you are not looking...
<azonenberg>
lol
<azonenberg>
mithro: see, i made a point of not learning bash beyond the && and || combination operators
<azonenberg>
if you need anything more than "run these commands in order and abort if something goes wrong"
<azonenberg>
IMO it shouldnt' be written in bash
<whitequark>
azonenberg: metcals are rf, right?
<mithro>
azonenberg: no matter how much I try and do that - I still seem to end up with giant messes. I'm pretty sure if you just did a "touch a.sh" and came back a couple of months later it would be a 1000 line monstrosity....
<cr1901_modern>
mithro: In the case of hdmi2usb you could probably replace all the bash stuff w/ shutil without loss of generality :D
<mithro>
cr1901_modern: problem is finding the time...
* cr1901_modern
nods
<azonenberg>
whitequark: yes, i have a hakko that works on the same principle
<whitequark>
azonenberg: those are haskell then
<azonenberg>
i've done 0201 up to giant sma
<whitequark>
immensely powerful but you're constrained by purity (of design that's not adjustable temp) :P
<whitequark>
they are great but not so afforable
<azonenberg>
yeah i use it for work so i have both budget and an excuse
<whitequark>
maybe in 5 years the chinese vendors of t12 will pick up that design, too, and it will be dirt cheap
<whitequark>
i mean
<whitequark>
i have a t12 hakko
<whitequark>
i could have got a metcal but i kinda like adjustable temp
<whitequark>
but i can't really recommend metcals to anyone
<whitequark>
people who can afford them, already know they can get those
<azonenberg>
i find adjusting temp is a crutch for poor heat transfer or poor tip temp control
<azonenberg>
unless you work with lots of alloys one temp is fine
<whitequark>
i work with extremely old pcbs that delaminate at lead free temps
<whitequark>
for example
<azonenberg>
yeah niche case
<whitequark>
i probably use temp control more as a crutch for poor heat transfer
<azonenberg>
but then i'd get a metcal and low temp tip :p
<whitequark>
i am not made of cash
<whitequark>
although, tips shouldn't be so bad, should they?
<whitequark>
i haven't realized you can effectively adjust the metcal by swapping cartridges too.
<azonenberg>
tips are 30-40 usd i think?
<whitequark>
that's actually less bad than what i thought
<whitequark>
mm, so like good t12? maybe a bit more
<whitequark>
it's not awful
<azonenberg>
base is literally 13.56 mhz (or 125 kHz) into handpiece
<azonenberg>
and adjust for reflected power
<whitequark>
yeah, i haven't realized the handpieces are cartridge based
<azonenberg>
thermoregulation is all done by tip curie point
<whitequark>
yep i know
<azonenberg>
i have one temp but several tips
<azonenberg>
for large vs small parts
<TD-Linux>
metcal is great in the US because ebay is full of cheap used ones
<TD-Linux>
with the newer cartridge based stuff (T12) the rf has less of an advantage
<TD-Linux>
absolutely in no circumstances buy a new metcal :)
zem has quit [Ping timeout: 255 seconds]
zem has joined ##openfpga
emeb_mac has quit [Ping timeout: 255 seconds]
Zorix has quit [Ping timeout: 250 seconds]
Zorix has joined ##openfpga
wren6991 has joined ##openfpga
<wren6991>
We have metcals at work and they're awesome, but if you do fine-pitch stuff on cheap chinese pcbs, pads seem to just evaporate
<wren6991>
Has anyone tried TS100? Not sure how practical they are, but look cute
<wren6991>
and being able to modify firmware of my soldering iron just... speaks to me
<wren6991>
Also fun fact: metcals will illuminate LEDs. Unsure of exact mechanism!
<sorear>
is this some kind of tesla coil
<Sprite_tm>
Oooh, I have a 2nd hand metcal as well, love the thing to bits.
<wren6991>
More like a really tiny induction cooker, and the tip is a tiny frying pan
<Sprite_tm>
Btw, fpga-related: I know the Ice40 tools have a quick way to replace the contents of a block ram in a bitstream; useful if you want to change a program without re-synthesizing the entire thing.
<Sprite_tm>
Do the ECP5 tools also have something like this?
<flea86>
Not officially :(
<flea86>
No way to partially reconfigure afaik
<flea86>
I also remember dave confirming that
<Sprite_tm>
Ah, I don't care about partial reconfigurability, I'm willing to send the entire bitstream to the fpga all over again.
<Sprite_tm>
I just want have something that can mod the bram initialization contents in a bitfile without resynthesizing everything.
<flea86>
Well, your FPGA will be in no-man's land for a few brief milliseconds at least :)
<wren6991>
flea86 I think he just wants to avoid synth + PnR, not trying to avoid flashing bitstream
<Sprite_tm>
Indeed.
<flea86>
I couldn't tell you for certain... all I know is Lattice tools don't allow it
<wren6991>
I don't think that tool exists for ECP5 yet, but the icebram tool for iCE40 is fairly simple
<Sprite_tm>
The Icestorm toolchain has icebram for this, but I'm not sure if ecp5 also has something.
<wren6991>
you just generate a random bit vector which goes into the BRAM init during synthesis
<wren6991>
and then after the fact, search for that random pattern to figure out how things got mapped to BRAMs
<wren6991>
and overlay your new contents
<wren6991>
the complex part is that the random bitstream can get swizzled and folded due to use of different port widths on the BRAMs, so it's not just a straightforward search
<Sprite_tm>
Yah, I imagined it wouldn't be a simple find&replace...
<wren6991>
I was concerned by the use of randomness but I did a quick calculation on probability of collision, and python gave me a probability of 0, with double-precision maths :)
<flea86>
I've been rejigging the FleaFPGA Ohm's JTAG utility to move away from FTDI and use a micro
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<wren6991>
Sprite_tm: icebram is only about 400 SLOC so you could reasonably roll your own, depending on how keen you are :)
<Sprite_tm>
Hm, you
<Sprite_tm>
're right... it may even be adaptable.
<wren6991>
flea86: oooh that's a cool board, can you solder it on top of a pi?
<flea86>
yes, yes you can... as long as you don't tie the 3.3v rails together at least :)
<flea86>
that's covered in the related UM
<flea86>
wren6991: also thanks :)
<wren6991>
I feel ya on FTDI, they're crazy overpriced for the functionality they offer
<wren6991>
but then I try to write some USB code and I'm like oh... this is why they're popular
<flea86>
Sprite_tm: Not gonna lie, that FTDI you noted is pretty nifty chip
<wren6991>
Sprite_tm: I'm interested, have you managed to use the speed? Seems like most people are doing ~few Mbps serial
<whitequark>
you can use FTDI at maximum USB line rate in parallel mode
<wren6991>
oh yeah that is pretty awesome
<wren6991>
Ok so they justify the HS PHY :) Just maybe not needed for programming an SPI flash
<flea86>
yeah
<wren6991>
and also not ideal because you end up polling over a piece of string instead of moving the polling up to the flash, with a micro
<flea86>
My Ohm1 uses FT230x in bitbang mode for JTAG programming
<wren6991>
FT2232H is nifty but I designed one into an FPGA board and was like "it costs HOW much"
<flea86>
Which is admittedly not the fastest thing around but definitely passable relative to synthesis time
<Sprite_tm>
wren6991: Agreed :) but I like to have a jtag board or two around which I can just hook up to something.
<flea86>
my new JTAG solution will be much faster
<wren6991>
Lol I'm currently programming my FPGA over a UART so can't complain
<Sprite_tm>
I mean, it's got my '45F reconfigured in 1.3 seconds.
<Sprite_tm>
Also the reason why I'm looking into the block ram thing.
<flea86>
That's pretty quick in anyone's language... that's with or without header compression?
<wren6991>
aaah cool
<flea86>
@Sprite_tm
<Sprite_tm>
flea86: I think without.
<Sprite_tm>
Bitstream itself is 1.1MiB if that matters.
<flea86>
Cool. Best I can do right now is ~8 seconds average for SRAM config of LFE5U-45
<flea86>
For Ohm2 board
<flea86>
but I am not doing bulk transfers or anything like that
<tnt>
Anyone tried writting a glasgow applet for it yet ?
<Sprite_tm>
Gotcha. I'll likely put an uC in the final incarnation of the board as well, but I'm waiting until that uC is actually manufactured ;)
<daveshah>
With the FT2232H and OpenOCD for the Versa board also with the 45k, no compression, I see <1s program time
<flea86>
Sprite_tm: oh? RISCV? :)
<Sprite_tm>
daveshah: I'm not surprised, I probably could tweak my openocd config for moar speed.
<Sprite_tm>
flea86: Erm... main proc of that chip is going to be Xtensa, no comments otherwise. Although I cannot guarantee that it'll be entirely RiscV-free.
<flea86>
I should try getting my solution to work with OpenOCD as well as ispVME
<flea86>
I see
<sorear>
if anyone manages to find out the # of cycles required to configure an ecp5 in "slave parallel mode", lmk
<Sprite_tm>
The RiscV bit is what the FPGA is for ;)
<flea86>
heh fair enough
<sorear>
the slave serial mode has no backpressure, so you can calculate the maximum time as (bitstream size in bits / max cCLK)
<sorear>
but the parallel mode has a /BUSY and the datasheet gives no hints for how long and how often it will be asserted
<flea86>
Sprite_tm: I've already got an extensa on my Ohm2, so far my impressions are mixed
<Sprite_tm>
Ahrg, something is wrong with my firmware and the synthesis cycle takes too long. Pulling the trigger here; I'm gonna whip up a bram replacement thingamajig.
<Sprite_tm>
flea86: How so?
<sorear>
max clock is ~ 50 MHz; it should be well under a second in any case
<whitequark>
xtensa is not very open, is it?
<whitequark>
is there even an isa manual?
<Sprite_tm>
whitequark: No :/ there is an isa manual out there, but it's leaked rather than official :/
<flea86>
Sprite_tm: Well, so far most of the example firmwares (that I'd like to see working) are all rather buggy :(
<sorear>
is the leaked isa manual what espressif used for the recent 3rd party llvm port?
<whitequark>
i'm pretty sure espressif has access to real manuals
<whitequark>
as... an xtensa licensee..
<Sprite_tm>
sorear: No, Espressif has an NDA, so the manual access is official.
<sorear>
yes but legally can the people writing open-source code look at the NDA manuals?
<Sprite_tm>
As long as the NDA allows it; it's effectively a contract. No idea what the NDA between Cadence and Espressif says, but I'd think it should be ok.
<Sprite_tm>
Also flea86, which examples in particular do you mean?
<flea86>
Sprite_tm: Oh, just some random examples.. like the SLIP modem router example (for retro computing projects etc.). as well as the web-based BASIC editor stuff
<Sprite_tm>
Ah, gotcha, I thought you meant the examples that came with the SDK.
<Sprite_tm>
If those were buggy, I could go kick some people :P
<flea86>
lol
<flea86>
I would too
<flea86>
I realize my Ohm2 is somewhat redundant in lieu of boards like ULX3s. Just doing it for myself for now I suppose heh.
Asu has joined ##openfpga
<Sprite_tm>
Eh, I took up this as a good excuse to get into SoCs and to see if I could hand-solder a BGA.
<flea86>
I found my answer to that, it was "With great difficulty"
<Sprite_tm>
Eh, it actually went easier than I thought. Got it first time right as well.
<tnt>
Sprite_tm: did you use an oven, skillet, or hot air ?
<flea86>
Sprite_tm: I suspect you did your homework first heh
<Sprite_tm>
Hot air. Plus some Louis Rossman-levels of flux.
<flea86>
That dude's got some mad skillz
<wren6991>
Watching a Rossman video now
<wren6991>
apparently TS100 can take T12 tips?
<Sprite_tm>
flea86: Don't underestimate how much better you get when you have a decent stereomicroscope at your disposal. Those things are like magic.
<flea86>
Sprite_tm: Oh I believe it. Didn't have a hope in hell until I got *something* resembling a good magnifier
<flea86>
stereo optics would be awesome tho
<wren6991>
"yeah this solders just as well as the normal hakko" -- louis rossman. has anyone tried these lil irons? T12 tip compatibility is an extra plus :) I'm not sure how the ergonomics are with the long reach though
<wren6991>
the problem with stereo microscopes is you realise how messy your soldering actually is
<wren6991>
nothing looks good under them
rohitksingh has joined ##openfpga
<whitequark>
my $20 T12 controller solders almost as well as the $500 hakko
<whitequark>
it's got a few glitches, but not $480 of them
<wren6991>
lol
<wren6991>
what is the conversion rate of dollars to watts
<flea86>
I still miss my trusty old Hakko 936 station. I loaned it and it got trashed. RIP.
<flea86>
*loaned it out
<wren6991>
my home iron is still something involving a lightbulb dimmer circuit that I got off ebay when I was 16
<whitequark>
that's brutal
<whitequark>
wooden toys, nailed to the ceiling
<wren6991>
what do you mean?
<wren6991>
It makes a weird 50 Hz sound at medium temperatures
<wren6991>
but other than that it's ok, and I can usually find tips for it
<wren6991>
it's temp controlled in the sense of "more" or "less"
<whitequark>
it's like "we were going uphill both ways", an exaggerated statement about a barren childhood
<wren6991>
ahhhh
<whitequark>
i think "wooden toys, nailed to the floor" is some kind of traditional thing, i'm not sure
<whitequark>
and "nailed to the ceiling" is parodying it
<whitequark>
anyway, i can't imagine using that setup, other than as a party trick :p
<flea86>
wren6991: Still, that sounds more sophisticated than an open fire and copper cattle-prod :)
<wren6991>
I originally learned to solder by just rubbing my hands together until the PCB was hot enough
<flea86>
Problem is, you don't want the PCB to be hot enough to melt solder :P
<wren6991>
Yes this was one of the many practical issues with this scheme
<flea86>
lol
<sorear>
pure Ga solder
<daveshah>
Taking the chipquik concept a bit far
<whitequark>
lol
<whitequark>
just amalgamate your components onto the PCB traces.
<whitequark>
what could go wrong.
<whitequark>
you could market it as a connection more reliable than a weld.
<parport0>
nice
<sorear>
live on the south pole, use neat mercury
<azonenberg>
wren6991: your metcal is probably set too hot for the cheap chinese boards
<azonenberg>
guessing the work iron is calibrated for SAC305 and the cheap boards are meant for lead solder
<whitequark>
see, not so niche :P
<azonenberg>
whitequark: well its not something i have ever had to deal with because all of my boards are 370HR or FR408
<azonenberg>
or, in the future, rogers
<azonenberg>
i dont normally deal with ultra-cheap stuff
<azonenberg>
i also dont use non-rohs solder
<flea86>
Oh man, I hate reworking boards that were previously done using SAC305
<whitequark>
azonenberg: thats why you ought to correct your advice imo
<whitequark>
your main use case is everyone else's niche use case
<whitequark>
and vice versa
<azonenberg>
i dont get the obsession with lead solder
<azonenberg>
sac is what the industry uses, it's easy to find
<azonenberg>
pretty much all bga parts are sac by default and you either can't find lead balls, or you can only get them in the $$$ space/medical/defense grade ones
<flea86>
and automotive grade too
<azonenberg>
just use rohs solder and boards meant for it, and you wont have problems
<sorear>
abbreviating chemical symbols to 1 latin letter each is vaguely cursed
<flea86>
since they're also exempt
<azonenberg>
sorear: well scandium-gold-chromium solder is unlikely to become mainstream so...
<azonenberg>
flea86: i keep one small spool of lead solder around
<azonenberg>
for the sole purpose of reworking non-rohs boards
<azonenberg>
i dont think i have touched it in the past year
<flea86>
azonenberg: I see. My station doesn't go high enough in temp to rework rohs.. so I am forced to cheat and apply pb :/
<flea86>
Ultimately, I need a new station
<sorear>
roughly what fraction of new commercial electronics are non-rohs?
<flea86>
Good question. Maybe 10%?
gsi__ is now known as gsi_
<azonenberg>
i dont think i've ever seen a soldering iron that cant get hot enough to melt sac o_O
<azonenberg>
the $40 aoyue i used for 8 years before buying the hakko went up to like 450C
<azonenberg>
sac305 melts at 219
<azonenberg>
(maybe it went past 450, i never ran it nearly that hot)
<flea86>
azonenberg: Well, it probably was hot enough, thirteen years ago :)
<flea86>
it's one of those early shitty hakko knockoffs.. a genuine combined station was going to set me back over a grand back then
s_frit has quit [Ping timeout: 244 seconds]
<azonenberg>
o_O
<azonenberg>
i wanna say i got my metcal-esque hakko for like 500
<azonenberg>
then another 150-200 for the super fine pitch handpiece and a range of tips
<whitequark>
just the soldering iron is 500, their iron plus hot air ones are more expensive
s_frit has joined ##openfpga
wren6991_ has joined ##openfpga
wren6991 has quit [Ping timeout: 256 seconds]
<wren6991_>
azonenberg: you're right :) those irons are normally used for RoHS multilayer boards. I just also happen to use them for my hobby projects
<wren6991_>
Having to change the tip to change the temperature is annoying though
futarisIRCcloud has joined ##openfpga
<sorear>
I'm still wondering if wren6991_'s complaint about *vaporizing* pads on chinese pcbs was meant literally
<wren6991_>
No
<wren6991_>
just delaminate with very little pressure + contact time
<wren6991_>
huh where did the underscore come from
<wren6991_>
typo probably
wren6991_ has quit [Quit: Page closed]
wren6991 has joined ##openfpga
<sorear>
wren6991: most clients, if you try to connect with user name asdf and there's already a user asdf, you get assigned asdf_ instead
<sorear>
this is up to the client and other conventions exist, but "add trailing underscores" is common
<whitequark>
whitequa1k
<sorear>
this can either be another person using the name or (more often) your old connection still looking open on the server's end, even though your end is obviously dropped
<sorear>
~ distributed systems ~
<wren6991>
Ah interesting! Thank you
<wren6991>
whitequark: And the larger whitequa8k, and whitequa4k which is the same thing but in a different package
<whitequark>
lmao
<whitequark>
and a whitequaup5k which is slightly larger than 4k but drunk.
<sorear>
very low static energy dissipation, though
<whitequark>
so that's why i constantly get shocked on random metal object
ZombieChicken has quit [Remote host closed the connection]
<cr1901_modern>
B/c my mind is weird, I've always managed to pronounce whitequa1k as "white caulk" (like the sealant)
<whitequark>
please donot use me on bathroom furniture
* cr1901_modern
snickers
<cr1901_modern>
or window frames?
<wren6991>
*notices your DSP primitives* owo what's this
<wren6991>
agh I had plans but I'm just watching louis rossmann soldering
<cr1901_modern>
wren6991: Well if we're discussing what we're doing right now, I just prepared a snack of cheese and crackers and I can barely taste the cheese. The packaging said "extra sharp" ffs
Bike has joined ##openfpga
s_frit has quit [Read error: Connection reset by peer]
s_frit has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
_whitelogger has joined ##openfpga
<Sprite_tm>
Well, that was simpler than I thought. Whipped up a quick something that only works on 32-bit BRAMs but it seems to do the job.
<tnt>
ecpbram ?
<Sprite_tm>
More-or-less yeah. The code is a quick hack so I haven't called it that, but that's what it does.
rohitksingh has quit [Ping timeout: 250 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<flea86>
Sprite_tm: Nice. So basically you're able to mod the BRAM contents in a ROM bitstream?
<Sprite_tm>
Yep.
<Sprite_tm>
Well actually, the config file that ecppack converts to the bitstream and svf file, but the ecppack step takes only a second or so extra.
dj_pi has joined ##openfpga
Bike has quit [Quit: Lost terminal]
<flea86>
Still cool :D
<flea86>
ok gtg
flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
rohitksingh has joined ##openfpga
emeb has joined ##openfpga
wren6991 has quit [Ping timeout: 256 seconds]
emeb_mac has joined ##openfpga
Laksen has joined ##openfpga
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 245 seconds]
X-Scale` is now known as X-Scale
rohitksingh has quit [Ping timeout: 255 seconds]
gnufan_home has joined ##openfpga
emeb has quit [Quit: Leaving.]
dj_pi has quit [Ping timeout: 244 seconds]
emeb_mac has quit [Ping timeout: 245 seconds]
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 268 seconds]
<eddyb>
12:44 <azonenberg> i dont get the obsession with lead solder
<eddyb>
azonenberg: this is great news for my brother, who is quite (un)healthily terrified of lead :P
<azonenberg>
i mean realistically solder is among the least harmful forms of lead
<azonenberg>
it's not finely powderered or in any kind of organic compound
<azonenberg>
So bioavailability is super low
<eddyb>
azonenberg: thanks (but I suspect that won't comfort him as much as it does me)
<azonenberg>
i mean i still dont like using neurotoxic materials when i can avoid it
<azonenberg>
But it's not as nasty as a lot of other ways you can be exposed to lead
<azonenberg>
(fwiw i still use rohs solder for everything, but it's mostly for convenience rather than safety)
<eddyb>
yeah if I can ensure everything I touch is RoHS, I'll just do that, but I'm less sure about older boards I just happened to find
<SolraBizna>
lead solder may be theoretically toxic, sure, but that just makes it easier for my project to outlive me :P
<tnt>
I still use leaded solder ... I tried lead free once like 8y ago and found it just wasn't working as well for me and really haven't retried since. I just found the roll I still had it's a Sn99Cu1.
<azonenberg>
well the way i see i see it is, the industry has moved to sac305 (Sn + 3% Ag + 0.5% Cu)
<azonenberg>
all of the bgas etc are made with it
<TD-Linux>
paste is more finely powdered so eh
<eddyb>
e.g. I have an old WD Blue control board here that I thought could be useful for SMT desoldering/(re)soldering practice
<TD-Linux>
but yeah sac305 is fine. joints won't be shiny but that's ok
<eddyb>
actually, I think it might have at least one BGA chip, so now I'm curious what kind of solder it's actually using
<tnt>
For small components it might not make a difference, but when I need to solder a giant lead to a giant ground plane, having to get it 30C higher temp is not reassuring.
<azonenberg>
i mean older bgas were snpcb
<azonenberg>
snpb*
<azonenberg>
tnt: just means you need a decent iron
<TD-Linux>
pretty sure the wd blue branding is new enough to be sac
<tnt>
azonenberg: yeah :/ Still using a weller.
<eddyb>
TD-Linux: this is... date code 46 12
<TD-Linux>
yeah easily :)
<eddyb>
I am assuming week 46, 2012
<azonenberg>
yeah thats waaaay after rohs
<azonenberg>
almost certainly sac
<azonenberg>
tnt: i mean weller does make good stuff
<azonenberg>
But they have cheaper stuff too
<tnt>
azonenberg: I have a WD-1 base and WP-80 pencil.
<eddyb>
azonenberg: would I be able to tell (just by melting point) with a good (de)soldering station? but not hot air, I'm guessing
<eddyb>
wait, so it being sold in the EU after a certain year is enough for it to be guaranteed RoHS?
<SolraBizna>
if GNDPLLx/VCCPLLx are unconnected, and PLLx is unused, that won't release the magic smoke, right?
<eddyb>
that almost sounds too good to be true :P
<azonenberg>
SolraBizna: it might
<azonenberg>
more likely it will use high power and oscillate or do nasty things
<azonenberg>
since gnd/vcc are likely connected in package
<azonenberg>
but not super directly
<azonenberg>
eddyb: unless it has one of a handful of exemptions
<azonenberg>
medical, space, etc
<SolraBizna>
I want to put them on a connector that won't necessarily be populated, especially during board programming
<eddyb>
azonenberg: I'm an idiot, all the right logos are on the HDD label itself, just not on the board
<eddyb>
so I can just assume any board is lead-free
<SolraBizna>
oh, I guess if it always has to be 1.2V, there's no point doing that
<SolraBizna>
never mind!
<eddyb>
hmm, so the main hazard is consumer electronics before the 2000s, like, say, an old Pentium II PC (that's probably the oldest thing I have; I've been wondering if I can run that CPU with an FPGA acting as the chipset :D)
<azonenberg>
pwnage from ##openfpga was trying to do exactly that with a pentium... 4? i forget which gen
<azonenberg>
it was the last intel cpu compatible with oshpark design rules, which was his reasoning
<azonenberg>
i dont think he ever had time to make it happen
<azonenberg>
from #oshpark i mean
<eddyb>
lol oshpark :D
<eddyb>
I wouldn't touch a pentium 4, jeez
<azonenberg>
but he was planning on making a spartan6 based northbridge
* eddyb
didn't realize Intel had put caches outside the main die in that thing
<eddyb>
does that mean that I can snoop CPU<->cache communication if I open the case?
<eddyb>
but also, it's card edge, so this might be easier to work with than a socket :D
<TD-Linux>
intel had caches outside the main die for everything before that too
<eddyb>
TD-Linux: yeah I just had no idea
<TD-Linux>
486 has external upgradeable cache cards
rohitksingh has joined ##openfpga
ZombieChicken has joined ##openfpga
<SolraBizna>
because I like trying to do things that are way more complicated than I can handle... I'm trying to make my core able to switch between a 32KHz clock for low power and a some-MHz clock for high speed
<SolraBizna>
I vaguely remember people talking about the iCE40 PLLs being cursed, and I know clock routing is both important and hard
<SolraBizna>
it seems to me that I can't safely switch between one and the other without some kind of magic
<azonenberg>
SolraBizna: look up glitchless clock muxing
<azonenberg>
xilinx parts include hard IP for this (BUFGMUX)
<azonenberg>
don't know about the siliconblue stuff
<SolraBizna>
thanks
<azonenberg>
in general unless you have weird dynamic logic
<azonenberg>
running slower than your fmax is not a problem
<azonenberg>
the problem is just the transition itself
<SolraBizna>
indeed
<SolraBizna>
thankfully, apart from the oscillators themselves, the freakiest dynamic aspect of this system is HyperRAM, which (I believe) is strictly synchronous
<azonenberg>
Does it have a fmin constraint though?
<azonenberg>
hyperram is DRAM internally, but i think it handles refreshes automatically for you
<azonenberg>
and just randomly spikes latency
<azonenberg>
i never got that far with my controller for it
<azonenberg>
i have it on a few boards and have been too busy to fully bring it up
<SolraBizna>
no fmin in the datasheet, only fmaxes that are well above what an iCE40 could hope to do anyway
<SolraBizna>
the "random" latency spiking matches what I remember, there's some mild spookiness around RWDS
<SolraBizna>
(again) because I like making things overly complicated, I'm actually intending to use a pair of HyperRAM+HyperFlash MCPs
<SolraBizna>
because they're on a common clock, I get to have extra logic for when one part wants an extra wait state for refresh and the other doesn't
<SolraBizna>
:D
<SolraBizna>
(I at least have separate CS# for each part for when that inevitably turns out to be too hard to implement)
<SolraBizna>
now I have just one clock question left, and that's how the heck do I pick a crystal
<SolraBizna>
I "know" that my real fmax is going to be somewhere in the 15-40MHz range, but I don't know exactly where in that range, and I won't even have a better upper bound until well after the boards are assembled
<SolraBizna>
I know that I can multiply the "output frequency" of the PLL blocks by certain fractions, but that's about all I know, and the official documentation is pretty handwavy on the details
<SolraBizna>
and I know that choosing an excessively fast oscillator will mean unavoidable power consumption
<azonenberg>
Cant help you there as i don't know the SB_PLL block at all. If you were using a xilinx part i could help...
<SolraBizna>
having an answer for Xilinx parts would probably be better than nothing
<azonenberg>
So, for an Artix-7 PLL the input signal needs to be 10 - 800 MHz
<azonenberg>
After the input divider, the PFD frequency needs to be 10 - (450-550 depending on speed grade) MHz
<azonenberg>
The VCO frequency needs to be 600 - (1200 - 1600 depending on speed grade)
<azonenberg>
Each output has a divider from the VCO that can range from 1 to 128
<azonenberg>
The VCO must be 2-64 times the PFD frequency
<azonenberg>
The input divider range is 1 to 106
<azonenberg>
All of these numbers are IP-specific, so what's true for a 7-series PLL won't be true for a spartan6 PLL or certainly any lattice part
* SolraBizna
nods
<azonenberg>
but this is the kind of data that you need in order to figure out how fast your input and output clock can be, what relationships they can have, etc
<eddyb>
looks like 33 address lines, 64 data lines, plus loads of other stuff
<eddyb>
128 IOs is a good guess, I think
<eddyb>
azonenberg: how dumb would it be to try to build a PCIe chipset for a CPU that never had an official chipset that natively supported it :P
<felix_>
the metcal soldering stations are awesome. got 3 used 40w base stations for 100 euros in total and new handpieces from another manufacturer for 80 euros each. totally worth the money
<eddyb>
I'm guessing there is an ECP5 that can do all this