wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
scrts has quit [Ping timeout: 248 seconds]
scrts has joined ##openfpga
lexano_ has joined ##openfpga
lexano has quit [Ping timeout: 248 seconds]
azonenberg_work has joined ##openfpga
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
<azonenberg>
whitequark: also as a FYI
<azonenberg>
i played with my peltier more, took it out to 3.5A (single stage)
<azonenberg>
Got it from 25C down to -16C
<azonenberg>
So a 41C gradient
<azonenberg>
(measured with an IR thermometer on the surface of the plate)
<azonenberg>
With a second stage i should have no trouble at all hitting -40
<Zorix>
stacked?
<azonenberg>
Yes
<azonenberg>
just gonna stack two of this same unit
<azonenberg>
i have a second one on order
<azonenberg>
but i wanted to see how far i could push this one first
<Zorix>
neat idea, never considered that as a possibility
<azonenberg>
its a pretty standard technique for large gradients
<Zorix>
i have thought about playing with one for the reverse thermoelectric properties
<azonenberg>
As a thermocouple you mean?
<azonenberg>
My interest is in characterizing greenpak devices across the full operating temperature/voltage range
<Zorix>
yep
<Zorix>
ah
<azonenberg>
So i need to be able to get a tiny (2x3 mm, few mW heat output) chip
<azonenberg>
from ambient up to +85 or down to -40
<azonenberg>
And a few points in between
<Zorix>
yea peltier is best for that
<Zorix>
but each chip isnt the same, so your testing is not going to be the same for all of them, they will differ somewhat
<azonenberg>
You mean each die, or each peltier?
<azonenberg>
My test breakout is a board with one greenpak and one I2C thermal sensor, that will both be in contact with the peltier to do closed-loop feedback control
<Zorix>
each die in this case..
<azonenberg>
That is the point :p
<azonenberg>
i'm going to be testing a few dozen samples from several different wafer lots
<Zorix>
ah so you are individually rating them
<azonenberg>
Not exactly
<azonenberg>
i mean i am collecting data on single dies
<azonenberg>
But the goal is to find min/max process corners
<azonenberg>
So i can say, for any un-tested die
<azonenberg>
its performance is likely to be somewhere in this range
<azonenberg>
I'll try to do some statistical magic to add a safety margin for extreme tolerance variations beyond the samples i've tested
<Zorix>
have to go with the worst of each extreme to know what the safe tolerances are going to be
<azonenberg>
but as a minimum i'll be testing several samples from wafer lots 5P501 and P6001
<azonenberg>
at -40C, +85C, and a few points in between
<azonenberg>
at 1.8 +/- 5%, 3.3 +/- 10%, and 5V +/- 10%
<azonenberg>
every die at all temp/voltage conditions
<Zorix>
have a specific application in mind?
<azonenberg>
then plot both the spread and min/max
<azonenberg>
Writing a static timing analyzer :p
<Zorix>
ah
<azonenberg>
Hard to do that without setup/hold/propagation delays
<azonenberg>
The vendor only publishes typical delay at 1.8, 3.3, 5V
<azonenberg>
not min/max
<azonenberg>
and no setup/hold
<azonenberg>
So i'm fixing this :p
<Zorix>
nice hehe
<azonenberg>
Once i have the setup done, it should be fairly easy to port to other devices
<azonenberg>
I need to optimize my measurement setup, it takes way too long to measure a single die right now
<Zorix>
how many are you going to measure?
<azonenberg>
Depends on how big the spread i see is
<jn__>
i don't have a mastodon/*social account, but that & should be an |
<lain>
the & should be a |
<jn__>
timing :D
<lain>
:D
* cr1901_modern
throws out virtual cookies for all
<cr1901_modern>
I didn't notice it for a week T_T
<cr1901_modern>
(on and off)
<jn__>
i've spent a few weeks on a bare metal project where i loaded a few megabytes of signed code on one processor, and used it on a different processor which isn't cache-coherent with the first one
<jn__>
the signature check always failed and i didn't know why. turns out i had to flush the cache first
<pie__>
sure i figured latex but i dont really get it
<rqou>
overfull hbox is some kind of error that latex likes to give
<rqou>
i don't know what it actually means though
digshadow has joined ##openfpga
<pie__>
ok so basically the joke is that the stuff looks a lot like a latex "rendering" log?
<pie__>
(which is what i figured i guess)
ZipCPU|Laptop has joined ##openfpga
<qu1j0t3>
rqou: it means that it couldn't fit the contents of a horizontal "box" to the desired width, within the prevailign tolerances. Most commonly a line of a justified paragraph. (and often caused by a long word that can't be hyphenated in a good place)
<qu1j0t3>
it's much like a compiler warning; you can then go and reword or insert discretionary breaks or take other manual action to resolve.
digshadow has left ##openfpga [##openfpga]
ZipCPU|Laptop has quit [Ping timeout: 260 seconds]