<kc8apf>
that's common if you are writing local-time to RTC
<kc8apf>
instead of UTC
<awygle>
i suspect that for a while, things are assuming my hwclock is UTC and applying the offset, but then eventually it realizes that's dumb and catches up
<q3k>
Rationale: the Linux kernel needs to have some idea of time zone,
<q3k>
notably because some filesystems (e.g. FAT) store file
<q3k>
modification/access times in local time rather than UTC(=GMT)
<q3k>
(which Unix uses internally for all timestamps). This kernel
<q3k>
(system) time zone is set through the settimeofday() system call;
<kc8apf>
hwclock should be UTC
<q3k>
interesting
<awygle>
well yeah but it's clearly not
<kc8apf>
please don't set it to local time
<Prf_Jakob>
A friend had a mnemonic for the "Do you want to set the BIOS time to UTC?" question when installing linux as "Do you want to have trouble with Windows?"
<q3k>
RealTimeIsUniversal is your friend
<kc8apf>
Force everyone to switch to TAI
<kc8apf>
no more leap seconds
<awygle>
arright i'm definitely being an idiot someplace here.
<awygle>
kc8apf: how _should_ i call hwclock to say "please take the system time as returned by date, undo the time zone adjustment, and write the UTC equivalent to the hardware clock"? "hwclock -w --utc"?
<kc8apf>
who is reading it back from hwclock during boot?
<kc8apf>
what does that expect it to be in?
<awygle>
syslog is reading it, and is printing $CORRECT_TIME-7, until an init script runs which runs "hwclock -s", after which syslog prints $CORRECT_TIME
<awygle>
i would like syslog to always print $CORRECT_TIME, and i am empowered to remove "hwclock -s" from the init script if needed
steakpizza has quit [Remote host closed the connection]
<kc8apf>
hwclock(8) says kernel assumes UTC by default when reading hwclock during boot
<kc8apf>
hwclock -w will take into /etc/adjtime into consideration
<kc8apf>
make sure that says UTC
<awygle>
i don't have an /etc/adjtime. or a /var/lib/hwclock/adjtime either. awesome
steakpizza has joined ##openfpga
<kc8apf>
then it should be writing it as UTC
<kc8apf>
what does timedatectl say?
<awygle>
"command not found" lol
steakpizza has quit [Remote host closed the connection]
<awygle>
so whether i run "hwclock -w --utc" or "hwclock -w --local" it jumps on reboot, either forward or backward. i think i need to change "hwclock -s" in the init scripts but that requires rebuilding the image which is more work than i want to do at 6pm, so i'll figure this out tomorrow. thanks kc8apf
knielsen has quit [Ping timeout: 276 seconds]
steakpizza has joined ##openfpga
steakpizza has quit [Ping timeout: 265 seconds]
<reportingsjr>
free shipping on arrow right now fyi
oeuf has joined ##openfpga
cr1901_modern1 has joined ##openfpga
grantsmith has quit [Ping timeout: 256 seconds]
cr1901_modern has quit [Ping timeout: 256 seconds]
egg|z|egg has quit [Ping timeout: 256 seconds]
grantsmith has joined ##openfpga
grantsmith has joined ##openfpga
grantsmith has quit [Changing host]
GenTooMan has quit [Quit: Leaving]
knielsen has joined ##openfpga
steakpizza has joined ##openfpga
steakpizza has quit [Ping timeout: 260 seconds]
knielsen has quit [Ping timeout: 265 seconds]
digshadow has quit [Ping timeout: 256 seconds]
digshadow has joined ##openfpga
Bike has quit [Quit: Lost terminal]
rohitksingh_work has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
<rqou>
wtf quartus claims that this device has 704 total R4s
<rqou>
but that makes no sense
<rqou>
it's 11*64
<rqou>
but there's no 11 of anything
rohitksingh_work has joined ##openfpga
knielsen has joined ##openfpga
steakpizza has joined ##openfpga
steakpizza has quit [Ping timeout: 245 seconds]
steakpizza has joined ##openfpga
<rqou>
shapr: i'm writing the reference card you asked for since i'm currently a bit stuck for project chibi
<sorear>
thank you!
<sorear>
what's the scope here? presumably smaller than "all commercially sold programmable logic devices, ever"
<rqou>
also wtf everybody likes to have different terms for everything
rohitksingh has joined ##openfpga
<awygle>
Oh awesome, thanks rqou
<rqou>
not nearly complete though
<rqou>
but it's a wiki :P
<awygle>
Well, yes lol
rohitksingh has quit [Quit: Leaving.]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
<rqou>
hey, does anybody have any idea how exactly span4 wires are supposed to fill the routing channels in a part this small?
<rqou>
from various OSINT sources i've found that every horizontal channel should have 64 wires
<rqou>
but the whole thing is only 8 tiles across
<rqou>
and wires appear unidirectional
<rqou>
i have no idea how any of this is supposed to actually fit together
<rqou>
also, the numbering of wires is extremely confusing
<daveshah>
In the ecp5, span wires connect round to other span wires at the ends of the device
<rqou>
i'm pretty sure that doesn't happen here?
<rqou>
the internal numbering is totally screwed though
<rqou>
all tracks are numbered the vpr way from the bottom/left
<rqou>
but that's not where they originate from
<rqou>
and presumably the numbers switch around a lot
<daveshah>
Have you looked at a larger device?
<rqou>
all the devices are really smol
<daveshah>
It could be its more regular in the middle, which doesnt exist on the 6x4
<daveshah>
In the ECP5 the net naming is quite screwed up at the edges too
<rqou>
in ice40 the span wires just terminate short at the edges, right?
<daveshah>
Span4s go into the IO tiles, and terminate there
<daveshah>
Span12s just terminate
<rqou>
daveshah: can you give me a very brief overview how the ice40 routing was originally figured out?
<rqou>
e.g. the pairwise-crossings, etc
<daveshah>
rqou: that was way before my time
<rqou>
hrm
<daveshah>
Pretty sure a lot of stuff was just making bitstreams and looking at the routing
<rqou>
so basically trying designs that contain more than just a single lut? :P
<daveshah>
Because of the data we had access to from icecube, Clifford knew what each switch was doing
<daveshah>
rqou: yeah
<daveshah>
For the ECP5, I've just used Diamond's physical view and "Epic" FPGA editor
<rqou>
yeah, afaict altera's refuses to show me _all_ possible routes
<rqou>
just the ones my design has used
<rqou>
it's extra confusing because afaict from datasheets every track is unidirectional
<rqou>
*datasheets and OSINT
<rqou>
so there needs to be "left" tracks and "right tracks"
<rqou>
or "up" tracks and "down" tracks
<rqou>
but all of the "left" and "down" tracks have fucked up numbering
<rqou>
also, every track can be driven from three different tiles
<rqou>
which mixes with all the previous confusion
<daveshah>
That certainly sounds pretty icky
<rqou>
oh, and every logic cell has two outputs :P
<rqou>
(actually three, but one only goes into a local track)
<rqou>
well, actually five
<rqou>
but the extra two are only for chaining
<rqou>
yeah, this architecture is pretty cute but kinda messy
<daveshah>
I'm starting to think the ECP5 excluding DSPs is the simplest FPGA in the world
<daveshah>
Certainly compared to Max V and ice40
<rqou>
not this 4x6 tile thing?
<daveshah>
Well, by the sounds of the logic cells and routing architecture
<rqou>
there's an impressive amount of interconnect in this chip
<rqou>
hrm, so still thinking out loud...
<rqou>
the tool reports a total of 784 C4s in the entire chip
<rqou>
which is 2^4 * 7^2
<rqou>
i'm assuming there are 7 channels to put routing in
<rqou>
(there's also a flash memory interface that's weird)
<rqou>
which gives me 2^4 * 7 wires per channel
<rqou>
which is 112
<rqou>
but a particular OSINT source claimed the channel should only be 56 wires wide, so what's going on?
<rqou>
maybe it was supposed to be interpreted as 56 up and 56 down?
<rqou>
that's ludicrously big
<rqou>
one column has 6 tiles, 4 logic and 2 IO
<rqou>
i assume the C4s cannot be originated from the IO part?
<daveshah>
Depends on the structure
<daveshah>
Maybe this is an artefact of it being cut down from a big FPGA?
<daveshah>
112 channels does seem an awful lot
<daveshah>
*112 wide channels
<rqou>
not extending the C4s into the io tiles matches the assumption baked into vpr
<rqou>
looking at an active-layer die photo of a cyclone 1 that i unfortunately cannot show you, i also see nothing that looks even remotely similar
<rqou>
oh herp derp the channel isn't 112-wide
<rqou>
it contains 112 total wires
<rqou>
and the datasheet drawings also seem to imply that C4s don't stick into IOs
<rqou>
so working off of all of these assumptions, each logic tile originates 28 C4s
<rqou>
so possibly 14 up and 14 down
<rqou>
that sounds like a reasonable amount
<daveshah>
Yes, that sounds very plausible
<daveshah>
Comparable with ice40 and ecp5
<rqou>
so grepping through everything that i've fuzzed previously, the largest C4 index used going up from Y4 is 9
azonenberg has quit [Ping timeout: 260 seconds]
<rqou>
and not until i hit Y1/Y0 (which is where all of the "down" tracks ended up) do i see huge numbers
<rqou>
so 10 tracks, out of 14
<rqou>
it seems like this makes sense?
<rqou>
oh wait, no
<rqou>
there are tracks that originate from Y0
<rqou>
so everything i just said is possibly invalid
<rqou>
or maybe this is just the fucky numbering
azonenberg has joined ##openfpga
<rqou>
the largest index i see used in any of my fuzzing so far is 34
<rqou>
which is much less than 56
<rqou>
what really makes no sense to me is the tool reports 708 R4s
<rqou>
*704
<rqou>
there is no sensible way for that to happen
<rqou>
704 = 2^6 * 11 but there isn't 11 of _anything_
<rqou>
what
<rqou>
the tool reports 888 total local interconnects
<rqou>
that matches absolutely nothing that i expect
<azonenberg>
rqou: keep in mind that OSINT on FPGAs may not be super accurate especially if it's pre-release
<azonenberg>
iow there may have been arch changes
<azonenberg>
so con slides or early patent filings could be inaccurate
<rqou>
this is post-release for sure
<rqou>
either way, factoring 888 gives a nice prime of 37
<rqou>
there isn't 37 of anything either
<azonenberg>
What about 36 + 1?
<azonenberg>
could there be 36 plus a ground to terminate an unused pin or something?
<daveshah>
or vcc, as in the ecp5?
<rqou>
ok, there's definitely 36 of a lot of things
<rqou>
alright, so that gives 36*24
<rqou>
+24 more
<rqou>
oh right
<rqou>
herp derp
<rqou>
io cells
<rqou>
wait, that doesn't sound right
<rqou>
24 local tracks for all io cells?
<rqou>
now that's too few :P
<rqou>
alright, giving up on this part for now
<rqou>
wtf is going on with 704 R4s?
<rqou>
704 = 2^6 * 11
<rqou>
but there's supposed to be 5 row channels
<rqou>
huh
<rqou>
what if there's only 4?
<rqou>
there's still a problem that there isn't 11 of anything
<rqou>
azonenberg: can i get you to take a peek at the ep1c die photo on sipr0n?
<azonenberg>
whats the full part number?
<azonenberg>
ep1k10tc100?
<rqou>
so you see how the columns all have two "half-size" bits at the very top and bottom
<rqou>
and in the middle there's "some other pattern"
<rqou>
do you think that "some other pattern" is the row interconnect?
<rqou>
btw, the bits for max v have that gap in the middle too
<azonenberg>
let's see
<rqou>
luts 0-4 are above the gap and luts 4-9 are below the gap (and mirrored)
<azonenberg>
you mean 5-9?
<rqou>
yeah
<azonenberg>
yes, i think the basic tile is a ten-lut-high block with routing in the middle
<rqou>
so basically, is it plausible the row interconnect physically lives in the middle of the tile?
<azonenberg>
that makes the most sense
<rqou>
the datasheet draws it as if it were on the sides
<azonenberg>
That would mean the big pieces are not actually big pieces
<rqou>
exactly
<rqou>
they're not
<azonenberg>
They're two small pieces back to back, mirrored
<azonenberg>
From what i've seen in other ICs, this is almost 100% true
<rqou>
so there really are only <num logic rows> R4 channels
<azonenberg>
Datasheets use a lot of artistic license
<rqou>
not <num logic rows + 1>
<azonenberg>
They should be considered a good source of arch info
<azonenberg>
Not layout
<rqou>
unless the column IOs have R4s
<rqou>
oh wait they definitely do not
<rqou>
datasheet mentions column IOs can only go into C4s
<rqou>
so this means that 708 R4s divides up into 176 total wires each row
<rqou>
at least it's divisible now
<rqou>
but it's still not clear to me how to further divide this
<rqou>
this is 2^4*11
<rqou>
but i still can't see how to get 11 of anything
<rqou>
hmm azonenberg but this means that C4s really do exist in <num logic cols + 1> different channels
<azonenberg>
meaning?
<azonenberg>
i'm not familiar enough with their uarch to comment at that level
<rqou>
there appears to be one more column channel than logic rows (so column channels between all types of tiles)
<rqou>
unlike rows where there is exactly as many
<rqou>
so "columns on the sides" is actually accurate
<rqou>
"rows on the sides" appears to be artistic license
<azonenberg>
Makes sense
<rqou>
hmm yup, this matches the ep1c die actually
<rqou>
so if you go all the way to the right of the array on the ep1c die
<rqou>
you see that column that looks different?
<rqou>
(there's also one like it on the left)
<azonenberg>
with the dark block?
<rqou>
the two narrow columns that appear much darker than normal
<azonenberg>
yeah
steakpizza has quit [Remote host closed the connection]
<rqou>
anyways, immediately to the left of that there's a pattern that i recognize by the "weird square-ish shape" just left of center
<azonenberg>
This image is infuriating
<azonenberg>
it's *almost* but not quite enough resolution to do anything useful
<azonenberg>
i.e. see actual cells
<rqou>
yeah
<rqou>
anyways, the "weird square-ish shape" for now i might assume is column interconnect?
<azonenberg>
Plausible
<azonenberg>
What about the big boxy thing on the left of the whole array? PLL?
<rqou>
left of that is a "very-dense-looking area"
<rqou>
yes, that big box is PLL
<azonenberg>
With... two fractional-N and three integer outputs maybe?
<rqou>
anyways, i'm assuming the "very-dense-looking area" to the left of the "weird square-ish shape" is the LUT/FF/logic?
<rqou>
because it's so dense and doesn't have the weird lines and circle shapes
<rqou>
and further left of that i'm assuming is local interconnect for now
<rqou>
and then the pattern repeats
<azonenberg>
i cant make too many deductions at that level with an image of this level
<azonenberg>
if i could see sram bits i could tell you more accurately :p
<rqou>
but if you go to the very very left you can see the pattern with the "weird square-ish shape" one extra time
<rqou>
did that make any sense? :P
<azonenberg>
not really
<rqou>
goddammit
<azonenberg>
can you pm me an annotated image or something?
<rqou>
ok, i think i'll do that instead
<rqou>
why is this image restricted anyways? presumably copyright?
<azonenberg>
Yeah
<azonenberg>
The original source wanted you to register to download
<azonenberg>
presumably to gauge interest
<azonenberg>
This is mostly a mirror if that data goes down
<rqou>
ugh this is hard
<rqou>
apparently photo uploading sucks
<azonenberg>
And this is one of the reasons i self host my "random files for public consumption" server :p
<rqou>
yeah, i'll work on doing that eventually
<rqou>
anyways, PM'd
<rqou>
so do these guesses make sense?
bitd has joined ##openfpga
<azonenberg>
Plausible, yes
<azonenberg>
The darker areas are probably interconnect
<azonenberg>
which is going to be alternating sram cells and pass fets
<azonenberg>
But otoh, if it's solid sram
<azonenberg>
then lines coming out to muxes
<azonenberg>
it could be a lut
<azonenberg>
at this mag, no way ot tell
<azonenberg>
But does it matter for the analysis you're doing?
<rqou>
right, we should unwind the discussion stack :P
<rqou>
so cyclone 1 die photos do not rule out "one more C4 channel than expected"
<azonenberg>
You do not have any decaps of the actual chip you're working with?
<rqou>
which also makes sense from a dividing-and-factoring-numbers perspective
<rqou>
no
<azonenberg>
is it possible the additional channels are clock/reset/config or something?
<rqou>
which additional channels?
<rqou>
you mean the ones i pointed at?
<azonenberg>
yes
<rqou>
maybe
<azonenberg>
i.e. something other than general fabric
<rqou>
hence "do not rule out"
<rqou>
anyways, the die photo of the cyclone 1 seems to imply that there is _not_ one additional R4 channel
<rqou>
this is also implied by the fact that 704 is not divisible by 5
<rqou>
but it is divisible by 4
<rqou>
so now i just need to figure out how that makes sense
<rqou>
704/4 is 176 or 16*11
<rqou>
and what i'm struggling with is that *) there isn't 11 of anything
<rqou>
and 176 isn't divisible by 6
<rqou>
it's not divisible by 5, 6, or 7
<rqou>
hrm
<rqou>
it is divisible by 8
<rqou>
leaving 22
<rqou>
but then how the heck can the channel width be 64?
<rqou>
maybe the channel width isn't 64
<rqou>
no, but i see wires with index 63
<rqou>
so what the heck is going on?
<rqou>
maybe this whole "channel width" concept is bogus
<rqou>
and is a lie to make tools work better
<azonenberg>
lol
<azonenberg>
sounds plausible
<rqou>
wait
<rqou>
so if we ignore the whole channel width concept
<rqou>
and we assume that io tiles can "originate" wires
<rqou>
as well as logic tiles
<rqou>
then each tile originates presumably 11 left and 11 right wires
<rqou>
that seems... fewer than expected
<rqou>
actually yeah, there's far fewer R4s than expected
<azonenberg>
That sounds plausible
<rqou>
what's going on
<rqou>
oooooh
<rqou>
each tile also originates 10 span1s
<rqou>
which added together is.... 32
<azonenberg>
So then you have 32 possible inputs at the mux
<rqou>
and this (somewhat) matches the patent Marex linked earlier
<azonenberg>
(in other news i'm finally below 100 signals to route on the line card)
<rqou>
although that patent seemed to be talking about driving _into_ a tile, not out
<rqou>
so idk what's up with that
<azonenberg>
maybe the wires run in the opposite direction you thought?
<azonenberg>
Or you misread the patent?
<rqou>
or the patent is wrong?
<rqou>
the patent is clearly talking about lines to drive _into_ the lut
<rqou>
which definitely doesn't match
<rqou>
also, the patent is for stratix 1
<azonenberg>
So it might just not be applicable
<rqou>
well, afaict stratix 1 became cyclone 1
<rqou>
but cyclone 1 deleted all of the wires of lengths >4
<rqou>
and then cyclone 1 became a max ii
<rqou>
and then that got enhanced into a max v
<rqou>
so it's been a while :P
<rqou>
ok, Marex's cyclone iv docs claim that there are 12 up lines and 12 down lines in that part
<rqou>
cyclone iv is not in the <REDACTED>, and the cyclone/stratix iii docs don't talk about "channel width" at all
<rqou>
so it's seeming more and more likely that "channel width" is a bogus concept
steakpizza has joined ##openfpga
<rqou>
14 up and 14 down is the same order of magnitude as Marex's 12 up and 12 down
<rqou>
aaand Marex was also stuck on R4s :P
<azonenberg>
makes sense
<azonenberg>
and yes, its probably fictional to make par simpler
<azonenberg>
just like "80 inputs" to the zia
<rqou>
but i still need to figure out wtf is going on with the numbering
<rqou>
since i do see R4s with an index of 63
steakpizza has quit [Ping timeout: 260 seconds]
<rqou>
azonenberg: so, if you were to make a guess based on only what you know now, what would you target fuzzing first?
<rqou>
interconnect into LUT or LUT out to interconnect?
<rqou>
and rows first or columns first?
<azonenberg>
I havent studied the arch enough to make an informed suggestion
<rqou>
guess? :P
rohitksingh has joined ##openfpga
<rqou>
right know the only things known are LUT bits and LUT inputs
<rqou>
*LUT inputs from local tracks
<rqou>
i was thinking fuzzing "interconnect into LUT local tracks"
<azonenberg>
That would let you do a functional, though inefficient, design
<azonenberg>
using local routing only
<azonenberg>
right?
<rqou>
lol yes
<rqou>
well, not yet
<azonenberg>
or is "local" only within the slice
<azonenberg>
and not slice-to-slice?
<rqou>
i have no idea how to get anything out of the LUTs
<azonenberg>
ah ok
<rqou>
presumably there are at least enable bits
<rqou>
i also haven't fuzzed anything about the FF at all
<rqou>
because i assumed those would be easy
<rqou>
and i was trying to use clifford's technique of doing the hard parts first :P
<azonenberg>
I would target a "minimum viable product" bitstream that lets you do iob -> iob and then iob -> lut -> iob
<rqou>
nothing about IOBs has been fuzzed yet
<azonenberg>
so you can ground-truth verify everything you think you know about other stuff
<azonenberg>
by crafting a bitstream to test it in hardware
<azonenberg>
or are you trying to do this 100% black box?
<rqou>
i'm pretty certain about the lut inputs and lut values
<azonenberg>
no hardware?
<rqou>
right now i don't even have hardware lol :P
<rqou>
i should buy some 5M"40"s
<rqou>
which are _definitely_ software-defeatured btw
<rqou>
since i've exhaustively fuzzed every LUT bit
<rqou>
but yeah, sub-$1 nonvolatile FPGA with flexible io standards and distributed RAM?
<rqou>
very nice
<daveshah>
rqou: whatever edmund may say, I agree that's pretty awesome :D
<daveshah>
built in flash is advantageous over ice40 for small stuff
<rqou>
anyways, i was thinking about fuzzing the inputs into the local tracks because i should be able to somehow enumerate all choices much more easily
<rqou>
because the choices can only be "some combination of span1s, R4, and C4 nearby to me"
<daveshah>
yes, that sounds like a good place to start
<rqou>
whereas the outputs definitely mix together LUT->interconnect with interconnect->interconnect changing directions
<rqou>
daveshah: i mean, the ice40 also has the NVCM that afaik nobody has bothered to RE
<daveshah>
rqou: yeah, I don't think the NVCM is actually that complicated
<rqou>
probably because people don't enjoy the prospect of chucking the device in the bin every time they messed itup :P
rohitksingh has quit [Quit: Leaving.]
<daveshah>
icecube will generate a SVF file with the commands
<daveshah>
as "pseudo-JTAG" lol
<daveshah>
afaik you basically send an unlock command, then you use the de facto SPI flash programming commands
<rqou>
don't be me and manage to program in a mirrored bitstream into a coolrunner2 btw
<daveshah>
boom?
<rqou>
no actually
<azonenberg>
you probably overheated the zia a bit
<azonenberg>
maybe, depending on how it was set
<rqou>
it turns out that if you aren't using the global signals then everything just mirrors itself
<rqou>
no, the zia bits are interleaved with each other
<daveshah>
I definitely shorted some stuff when working out corner routing in the ice40, but it was only a few nets and didn't notice any heating
<azonenberg>
but everything else would be just mirrored
<rqou>
oh right, this design actually didn't use the ZIA
<rqou>
it just set 4 leds to "on"
<azonenberg>
daveshah: killing a coolrunner took 10 minutes of the entire routing fabric shorted
<azonenberg>
all dffs 50% high and 50% low
<rqou>
so no ZIA bits set, no PLA bits set
<rqou>
only macrocell bits get set
<rqou>
so mirroring it works just fine
<azonenberg>
power, ground, high, low logic
<azonenberg>
exactly half high and half low, maximum worst case bus fight
<rqou>
which got me extra confused because azonenberg's schematic symbol is labeled with the io bank number, not function block number
<azonenberg>
times 40 rows times 2 function blocks
<azonenberg>
rqou: i created the symbol before i started RE work
<daveshah>
azonenberg: I did hear from someone who thought a Xilinx FPGA would probably desolder itself before failing internally in that situation
<rqou>
and the official io bank number and function block numbers for the 32a just so happen to be opposites :P
<azonenberg>
i didnt care about FB numbers
<azonenberg>
daveshah: I cant comment on FPGAs, never tried
<azonenberg>
if anybody has a 7 series part they're willing to kill in the name of science, once your RE progresses more
<azonenberg>
i'm willing to run and film the test in my new lab :p
<daveshah>
I think there's enough data in prjxray to do that already
<azonenberg>
well it depends
<azonenberg>
do you want a *few* shorts?
<azonenberg>
Or do you want worst case every possible one? :D
<rqou>
anyways, since i'm not being very productive tonight, max v pricing on digikey is:
<rqou>
5M40 (actually 240) $0.90
<daveshah>
I think it's only the long lines that have multiple possible drivers with a "valid" bitstream, but you could cause many more shorts by not one-hotting the one-hot muxes
<daveshah>
rqou: nice
<rqou>
5M240Z**T144** (actually 570) $4.90
<azonenberg>
daveshah: yeah exactly
<rqou>
ironically the same price as 5M240Z**T100** which really is only 240
<azonenberg>
the challenge in making a max-power suicide bitstream is to find ALL the shorts
<daveshah>
it says everything about FPGAs that you can't even see any volume prices without signing an NDA
<azonenberg>
so you have to get half the one hot inputs high and half low
<azonenberg>
daveshah: are you sure that isnt just digikey?
<daveshah>
rqou: wtf? same device in different package is different silicon
<daveshah>
azonenberg: mouser too
<rqou>
afaict yes
* azonenberg
checks avnet
<daveshah>
interesting
<azonenberg>
whcih is xilinx's preferred distributor
<rqou>
5M1270ZF256 (really 1270) $13.70
<azonenberg>
huh yeah they dont have volume pricing either
<daveshah>
azonenberg: maybe a post-intel policy?
<daveshah>
they may have a standard policy on not publishing volume pricing
<azonenberg>
idk, it seems silly
<daveshah>
rqou: will be curious what the timing is like compared to ice40
<rqou>
and finally 5M1270Z**F324** (actually 2210) $15.7
<rqou>
(yes, they did this trick twice)
<daveshah>
rqou: do they limit area, or resource count?
<rqou>
afaict resource count
soylentyellow_ has quit [Ping timeout: 256 seconds]
<rqou>
i've used all 240 lut sites in the 40
<rqou>
it's so blatant they even have the same idcodes
<daveshah>
yeah, sounds like they are clearly fully tested
<rqou>
like i mentioned earlier, it's not really even possible to design a 40 LE tile-based FPGA
<rqou>
that'd only be 4 tiles
<rqou>
there was a doc somewhere that mentioned that these chips were designed by picking a die/padring size first and then seeing how much fabric could be put into it
<rqou>
oh also, the max ii is _only_ available in the "real" sizes
<rqou>
so afaict when they made max v they must have made the die smaller/yields better and then tried to satisfy the market demand for a "32-MC equivalent" part for cheap
<rqou>
yeah, the cheapest max ii is officially $7.50 on digikey
<rqou>
(but apparently significantly cheaper in shenzhen)
<rqou>
oh wut
<rqou>
the most expensive max ii (EPM2210F324C3N) is $90.50
<rqou>
what are they doing?!
<rqou>
the max v (5M2210ZF324C5N) is $22.50 but might not be exactly socket compatible
<daveshah>
rqou: programmable logic never goes obselete, it just becomes unaffordable :P
<daveshah>
clearly the customers with long product lifetimes are also the ones willing to pay the most
<daveshah>
no point making old devices with expensive/unwanted processes cheaper
<rqou>
um, both are 180nm :P
<daveshah>
thats a bit odder then
<rqou>
maybe still different processes
<daveshah>
altera's reliability report implies they are the same
<kc8apf>
huh. router's power supply died tonight
<kc8apf>
started dropping under load
<rqou>
huh max v is slower
<rqou>
the "240 die" timing parameters match the max iiz power-reduced timing parameters
<daveshah>
this is the ultraplus shenanigan all over again
<daveshah>
what is it with "newer/better" devices having crappy timing
<rqou>
the "larger" max v dies match the max ii not-power-reduced timing parameters
<rqou>
but no longer have the fastest bin
<daveshah>
suspect its demand related
<daveshah>
fast processors don't really need/use "cpld"s any more
<daveshah>
most applications are either low power glue or legacy
<daveshah>
high performance stuff is all fpga/soc
soylentyellow has joined ##openfpga
<rqou>
max v io is much slower
<rqou>
like 2x
<rqou>
er, no, not quite
<rqou>
some are faster
<rqou>
e.g. 1.8V is faster
<rqou>
er, faster for the smaller parts, _much_ slower for the larger parts
<rqou>
so basically totally new IO cell
<daveshah>
yeah, seems like they optimised for low voltages
<rqou>
interconnect is way slower
<rqou>
so probably a very similar (almost identical) architecture but redesigned layout
<rqou>
i mean, the bitstream layout even manages to match very closely to a _cyclone_ die shot
<rqou>
anyways, it's pretty late, i should sleep soon
<rqou>
probably too late to start writing a new fuzzer
<rqou>
azonenberg: if you're still awake, have you managed to finally get your house inspected yet?
<azonenberg>
Nope
<azonenberg>
Delays and more delays
<azonenberg>
we're finishing up the riser wires between the 1st and 2nd floor
<azonenberg>
Things keep going wrong
<rqou>
wtf
<rqou>
your entire house project has been just a huge comedy of errors
<azonenberg>
We found the drain pipe on the sump pump was leaking because the guy who installed it couldn't be bothered to glue one of the fittings
<rqou>
right
<azonenberg>
it was held in place by pressure from the pipes on either end
<rqou>
you mentioned that already
<rqou>
and then?
<azonenberg>
then today, we lost half an hour when the blade on my armored cable cutter broke
<azonenberg>
it just cracked right down the middle
<azonenberg>
nobody nearby sells spare blades
<pie__>
<azonenberg> We found the drain pipe on the sump pump was leaking because the guy who installed it couldn't be bothered to glue one of the fittings
<azonenberg>
So i had to drop $35 on a new cutter
<azonenberg>
The blades are $10 on amazon but i had already used my spare when the old one dulled
<pie__>
this is why i feel uncomfortable with ever contracting anyone to work on anything....but i cant learn how to build an entire goddamn house
<azonenberg>
I was expecting to have some warning when it got dull, not have the blade shatter :p
<azonenberg>
pie__: i'm basically doing that at this point :p
<azonenberg>
so, on the sump pump
<azonenberg>
i cut open the pipe that was leaking
<azonenberg>
To remove the defective joint
<azonenberg>
As soon as the saw started vibrating the pipe, the bad joint completely popped open
<azonenberg>
this should not be possible, a properly done solvent weld is as strong as the pipe or even stronger
<azonenberg>
if you torque it, the pipe often fails before the joint
<azonenberg>
since its thinner
<azonenberg>
When i looked at the failed surface, the entire surface of the fitting had dirt from the sump on it
<azonenberg>
meaning there was no joint at all
<azonenberg>
they were just press-fit
<pie__>
have you called the guy to tell him he did a shitty job
<azonenberg>
one better, i called my sales rep at the company (a team member from my SAR unit)
<azonenberg>
Sent him photos of the failure AND the bill for the cost of new pipe and fittings to fix it
digshadow has quit [Ping timeout: 264 seconds]
<pie__>
oh well thats too easy if you know a guy from sar team :P
<azonenberg>
I do not take kindly to substandard work
<azonenberg>
i found out after the fact they never pulled a plumbing permit for the discharge line so it was never inspected
<pie__>
do you have a "how to house" book or something
<pie__>
fml
<azonenberg>
I learned a lot of this when i was young
<azonenberg>
my parents had a second floor built that they could barely afford
<azonenberg>
So we did a lot of the finish work ourselves
<azonenberg>
Then renovated the first floor on our own time
<pie__>
lucky. :p (in a sense)
<azonenberg>
At this point about the only thing i havent done is load bearing framing / exterior walls and gas piping
<azonenberg>
and roofing
<azonenberg>
I've done interior (non load bearing) walls, copper and pvc plumbing, electrical power and data, sheetrock, tile, masonry for stairs
<azonenberg>
paint obviously
<azonenberg>
i've installed prehung doors, but not hung them myself
<azonenberg>
I've done a bit of insulation and will be doing a lot more soon
<azonenberg>
And i've spent enough time reading codes etc that every time i open something up in this house i find something not up to par :p
<pie__>
lul might as well go for the building inspector license
<azonenberg>
lol
<azonenberg>
well if i ever get tired of fpga stuff and security work
<pie__>
inb4 requires an architecture degree
<azonenberg>
i could probably get an electrician's license pretty quickly at this point :p
rohitksingh has joined ##openfpga
<rqou>
um... no
<rqou>
my housemate and i actually looked into that as a joke a while back
<rqou>
it actually requires real experience
<rqou>
not just a test and/or a fancy piece of paper
<azonenberg>
Yeah looks like they want ~3 years as a trainee to get licensed
<azonenberg>
And there doesnt seem to be any way around that
<rqou>
yeah
<azonenberg>
You can cut that in half if you want to be a "specialty electrician" though
<rqou>
hmm apparently max v has a new DPLL soft(?) IP
<rqou>
i wonder how they did that
<kc8apf>
what does BLIF's .area command actually do?
<rqou>
encodes an area? :P
<kc8apf>
the spec PDF says absolutely nothing about what value it should take
rohitksingh has quit [Quit: Leaving.]
<rqou>
have you considered using... json? :P
<azonenberg>
rqou: interesting that they had that requirement though, a lot of professions i've seen you can shortcut most (not all but a good chunk) of the work experience requirement
<kc8apf>
that would not help with reading BLIF from other tools
<azonenberg>
with a degree / more advanced degree
<azonenberg>
kc8apf: who uses blif really?
<rqou>
yeah, i find blif totally unreadable
<kc8apf>
lowest common denominator
<azonenberg>
i thought edif and gds were the de facto standard interchange formats
<rqou>
both for a human and for a program
<kc8apf>
edif is a monstrosity
<azonenberg>
rqou: for example, the PE license you can trade several years of work experience off against a grad degree
<rqou>
^
<azonenberg>
you still need SOME, but you need a lot less
<rqou>
seriously, if you really want to exchange a netlist, use yosys json
<azonenberg>
read_blif;write_json
<azonenberg>
?
<rqou>
or that
<kc8apf>
I want something that at least has a sepcification
<rqou>
yosys - the best blif to something sane converter ever written
<rqou>
why do you care so much?
<azonenberg>
kc8apf: my response would be to call on clifford to specify the json schema
<rqou>
^
<azonenberg>
and declare various portions of it to be a stable api
<azonenberg>
Not to use another format
<kc8apf>
this is just one of many I plan to support
<rqou>
btw the current schema doesn't include floats *cough* *cough* azonenberg
<kc8apf>
starting with BLIF because it's fairly simple
<rqou>
"simple"
<rqou>
if it were simple you wouldn't be asking :P
<kc8apf>
sure. one question from the last page of a 12 page spec
<rqou>
i would assume you just write something like `.area 1` (mm^2)
<azonenberg>
i'd assume um^2 as the unit since that seems more common
<azonenberg>
Alternatively, the spec is deliberately unclear
<rqou>
i mean, as long as everybody agrees it doesn't matter :P
<azonenberg>
and it's library dependent / some kind of relative unit where only comparisons between cell sizes matter
<rqou>
that would be my second guess
<rqou>
so `.area 1.2` (INVs)
<kc8apf>
they explicitly say cycle times are "a unitless number that is to be interpreted by the user"
<kc8apf>
so, float it is
<azonenberg>
Yeah that implies area is the same
<rqou>
anyways, yosys json parsing only requires 333 lines of rust, so i'm curious how much code blif will be :P
<azonenberg>
a unitless quantity used solely as a figure of merit when deciding which of two cells to place somewhere
<rqou>
(this is including tests btw)
<daveshah>
I think any hypothetical new tools of any kind would use Yosys JSON
<daveshah>
in terms of Symbiotic stuff
<rqou>
you can even use the code i wrote and debugged
<rqou>
and checked that it was as lax/strict as necessary
<kc8apf>
I'll gladly add it once there is a spec
<rqou>
spec: whatever yosys does
<kc8apf>
i've spent too much of my career chasing those "specs"
<daveshah>
needs a bit of work, sure, but its something to base a spec on
<azonenberg>
rqou: sounds like perl
<azonenberg>
:p
<rqou>
oh wait what
<rqou>
yosys can write out AIGs of cells?
<rqou>
i guess i don't support that feature
<daveshah>
yeah, I think that's primarily for formal type flows
<daveshah>
it's the only particularly complicated part of the spec
<rqou>
yeah i just ignore "models" in my crate
<daveshah>
in a fully techmapped design, I think they will be irrelevant as all the cells will be blackboxed
openfpga-github has joined ##openfpga
openfpga-github has left ##openfpga [##openfpga]
<openfpga-github>
[openfpga] rqou closed issue #117: this commit makes rust release builds suddenly take 20+GB https://git.io/vdA8g
<daveshah>
looks like project trellis now understands ~99% of set config bits in the NES test bitstream
<daveshah>
PIO and EBR config should make that approach 100%
<daveshah>
there are a few tiles we will probably never understand (like one called PVT_COUNT) that are internal stuff that stays the same always and we can just copy and paste
steakpizza has joined ##openfpga
steakpizza has quit [Ping timeout: 260 seconds]
<q3k>
daveshah: holy cow you're making great progress
<daveshah>
q3k: the number is not necessarily as impressive as it sounds - its obviously swamped by the fully known logic and interconnect tiles
<daveshah>
the remaining 1% will be the odd cases that each aren't many bits but quite a few things to consider
<daveshah>
also that excludes the garbage-fire dsps
rohitksingh_wor1 has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 260 seconds]
Ekho- is now known as Ekho
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
Bike has joined ##openfpga
rohitksingh has joined ##openfpga
genii has joined ##openfpga
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined ##openfpga
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined ##openfpga
rohitksingh has quit [Client Quit]
rohitksingh has joined ##openfpga
steakpizza has joined ##openfpga
steakpizza has quit [Ping timeout: 255 seconds]
rohitksingh has quit [Quit: Leaving.]
digshadow has joined ##openfpga
massi has quit [Remote host closed the connection]
<azonenberg>
daveshah: what chip is this again?
<azonenberg>
daveshah: conjecture: ptv sensor of some sort
<daveshah>
azonenberg: ecp5
<daveshah>
lfe5u-45f
<daveshah>
yeah, I think it is
<azonenberg>
used to calibrate the pll vco or something
<daveshah>
I'm not sure if it's for calibration or factory testing
<daveshah>
there are clearly a lot of blocks for testing shown in the Diamond physical view
<daveshah>
CLOCKTEST, CIBTEST, etc
<azonenberg>
i wonder if thats how they do speed grade binning
<daveshah>
yeah, could well be
<azonenberg>
poke a fixed block with an external clock through probe pads or some secret routing to the nearest IOB
<azonenberg>
see how many times the ring oscillator toggles
<azonenberg>
Then thats your speed number
<daveshah>
yep, the COUNT implies a ring oscillator definitely
<daveshah>
there's actually a block shown in the diamond physical view called "PVTTEST"
<daveshah>
it has a single input called TEST_IN
<azonenberg>
Wonder how stuff gets out
<azonenberg>
registers readable through the ICAP or equivalent? (does ecp5 have partial reconfig?)
<azonenberg>
JTAG?
mumptai has joined ##openfpga
<daveshah>
azonenberg: there's readback but no partial config
<daveshah>
and various JTAG stuff
<rqou>
azonenberg: you or i really need to get our labs set up again
<azonenberg>
rqou: well you know full well whats's in the way of mine
<azonenberg>
even once i'm moved there will be months before i'm fully set up
<rqou>
it seems it'd be much easier for every re project to start with a dash etch of the die :P
<azonenberg>
Yes, and as soon as i have my new roof put in, shelving in the lab, etc
<azonenberg>
the floor painted
<azonenberg>
the $500 eyewash, the $1700 sink, the $4K-ish fume hood
<azonenberg>
etc
<azonenberg>
i can start doing such things
<azonenberg>
but its a lot of time, work, and cash
<sorear>
You seem to have a lot of problems with image quality
<rqou>
me?
<rqou>
yeah, my imaging setup is no good
<rqou>
but anyways, azonenberg why don't i need anything of those things? :P :P
<rqou>
most expensive component is the respirator :P
Hamilton has joined ##openfpga
<azonenberg>
Because i dont want acid fumes all over my lab corroding things?
<azonenberg>
Because PPE is a last resort and not something you should ever use as your sole means of preventing harm?
<rqou>
hey, even my shitty fan "hasn't even shorted out yet" :P :P :P
<rqou>
and my hotplate hasn't overheated and died yet either
<azonenberg>
The only time i would ever use a respirator as my *intended* protection against harm is if i was responding to some kind of uncontrolled emergency situation
<azonenberg>
In which case I'd want a real SCBA and either turnout gear or a fully encapsulating suit depending on the situation
m_w has quit [Quit: leaving]
<rqou>
although i do kinda want to reduce the amount of hackiness in my lab at some point
<rqou>
treating $20 box fans as consumables isn't exactly a standard technique :P
bitd has quit [Quit: Leaving]
bitd has joined ##openfpga
digshadow has quit [Ping timeout: 260 seconds]
steakpizza has joined ##openfpga
steakpizza has quit [Ping timeout: 276 seconds]
mumptai has quit [Quit: Verlassend]
mumptai has joined ##openfpga
digshadow has joined ##openfpga
<azonenberg>
awygle: so fun idea just occurred to me
<azonenberg>
re the switch
<azonenberg>
So, after all of the line cards, a UART to the brain, boot flash, and a QDR-II+
<azonenberg>
we have, if my math is right
<azonenberg>
4x HP pins that i am considering write-offs (they're the only non-LVDS pins in the HP banks)
<azonenberg>
And 36x HR pins
<azonenberg>
We use 24 of those 36 pins to proxy the RGMII bus between the FPGA and the management LAN PHY
mumptai has quit [Quit: Verlassend]
<azonenberg>
This would allow alternative topologies in which the management port is bridged to the switch fabric instead of isolated
<azonenberg>
It would also allow the FPGA to implement layer 3/4 firewalling before the management engine
<azonenberg>
As an extra layer of security
<azonenberg>
This would leave a total of 12 HR pins unused, and i'm sure i'd find things to do with them :p
<azonenberg>
(this brain board is going to be FULL)
<rqou>
azonenberg: so I'm not sure exactly what you're talking about, but you almost certainly want to run the management interface through the fpga
<rqou>
when my father was doing this stuff, every time they didn't do this they eventually regretted it
<shapr>
rqou: what would happen?
<shapr>
running the pins through the FPGA means you could reroute them elsewhere? or what?
<rqou>
some customer would eventually ask for a feature that would be tricky or impossible to implement with the management interface connected only to a potato CPU
<rqou>
so e.g. iirc "dying gasp alarm" would be implemented in the fpga
<shapr>
watchdog that fires when the board has a fatal error?
<rqou>
and/or various issues with hot-failover (which i guess azonenberg doesn't care about)
<rqou>
alarm for when the board loses power
unixb0y has joined ##openfpga
<unixb0y>
Hi guys
<rqou>
hi unixb0y
<shapr>
gutentag
<unixb0y>
Moin 😁
<unixb0y>
I guess I need to set up my bnc again 🤔
<shapr>
Is bnc a fork of znc?
<shapr>
or short for bouncer?
<unixb0y>
Bouncer;)
<shapr>
jaså
<rqou>
hmm i just realized something (ping azonenberg)
<rqou>
there's even more evidence of "one extra column channel" in max v
<rqou>
one column of tiles is 0x380 bytes
<rqou>
but if you count the total bytes in the bitstream as well as look at the repeating patterns
<rqou>
you'll find that there are _7_ sets of 0x380 bytes
<rqou>
not 6
<rqou>
i.e. it's 0xC0 bytes (assuming this is an io column), 7x 0x380 bytes (this is mostly logic, possibly with the extra 7th one containing only column control bits), 0xC0 bytes
<azonenberg>
rqou: i'm going with the google failover approach
<rqou>
does this sound reasonable?
<azonenberg>
assume any one thing can fail, keep the system as a whole operational
<azonenberg>
Yes, that's plausible
<azonenberg>
rqou: well my thought was to do it for firewalling
<azonenberg>
i want to ensure that the linux tcp/ip stack never sees malformed packets
<rqou>
yeah
<rqou>
my father's design philosophy has always been "just add it just in case, at worst you don't take advantage of it"
<rqou>
this coupled with the fact that it was telco equipment (i.e. no cost constraints)
<azonenberg>
well in my case, i have the fpga, i have the soc, and i have the phy
<azonenberg>
its just a question of if i route directly or proxy
<azonenberg>
i probably will not proxy the mdio bus, i dont see THAT as being necessary
<azonenberg>
only rgmii
Hamilton2 has joined ##openfpga
<rqou>
my father likes to proxy everything through the fpga :P
Hamilton3 has joined ##openfpga
<azonenberg>
lol well proxying mdio requires that you do some fun tristate stuff
Hamilton3 has quit [Remote host closed the connection]
<azonenberg>
i.e. you have to actually understand the protocol
<azonenberg>
but screw it, i'll do it (and add a solder jumper to bypass)
<daveshah>
azonenberg: go overkill and use an analog switch to inject the fpga in/out of the path?
<daveshah>
Best of both worlds
<azonenberg>
lol
<azonenberg>
well the way i see it is, i'll start with the fpga bypassed so i dont have to deal with full protocol proxying
Hamilton has quit [Ping timeout: 276 seconds]
<azonenberg>
Then if i have a need i can move the solder jumper
<azonenberg>
Not having the bypass forces me to write that rtl to get the board to work at all
<azonenberg>
And i dont plan to mass produce these, certainly not at this stage of the design
<daveshah>
Makes sense
<azonenberg>
so moving two resistors on 2-3 boards is not a huge deal
<azonenberg>
soo um
<azonenberg>
hopefully i don't need too many more signals routed to this fpga...
<azonenberg>
this is a 484-ball chip
Hamilton2 has quit [Ping timeout: 276 seconds]
<azonenberg>
I'm going to have 4x HP and 8x HR unused and... i dont think i added a master clock source yet
<azonenberg>
so that's 2 more
<azonenberg>
So there will be ten unused pins on the whole fpga
unixb0y has quit [Quit: bye bye]
<azonenberg>
if this gets any worse i'm going to have to add a CPLD or smaller FPGA just to do io expansion
<azonenberg>
I do have a bunch of slow signals for stuff like the line card reset and power rail sequencing
<rqou>
heh
<rqou>
many of my father's designs had that
<rqou>
for bonus points, often an Altera CPLD (especially funny given that they were a Xilinx shop)
<rqou>
see: "no real cost constraints"
<rqou>
azonenberg: did i tell you the story about the board that had a heater on it? :p
<azonenberg>
um?
<rqou>
some of their boards had some big resistor heaters on it
<azonenberg>
why
<azonenberg>
space?
<rqou>
because Canada is very cold :P
<azonenberg>
outdoor deployment on phone poles?
<daveshah>
Couldnt you do that in the FPGA?
<azonenberg>
lol
<daveshah>
With some ring oscillators
<daveshah>
Close loop control based on oscillator frequency
<rqou>
fortunately, the temp range they needed to guarantee was only ~5 degrees lower than normal commercial temperature range
<rqou>
so instead of making the entire board with industrial temperature range, there was only one industrial temp range CPLD that would detect if it was too cold and turn on some heaters
<azonenberg>
lol
<azonenberg>
5C doesnt soudn like it would be TOO much more work
<rqou>
and once the board was on the heaters could be turned off
<azonenberg>
how about just using a slightly larger FPGA (no cost constraints)
<rqou>
because the waste heat kept it warm enough
<azonenberg>
And mining bitcoins on the unused gates
<daveshah>
lool
<rqou>
this is like a decade before Bitcoin
<azonenberg>
ok fine, folding@home
<rqou>
the problem is that the chip isn't guaranteed to properly power on if it's too cold
<azonenberg>
So this is only during boot
<azonenberg>
Not once it's operating? it produces enough heat to stay warm?
<rqou>
yeah
<azonenberg>
Side note
<azonenberg>
I'd be very curious to see any graphs of participation in major BOINC projects
<azonenberg>
plotted relative to the rise of cryptocurrency
<azonenberg>
Did Folding@Home or Seti@Home lose people when BTC mining took off?
<Bike>
there's a reason to dislike bitcoin i hadn't thought of before
<awygle>
azonenberg: yeah good idea, both the proxy and the jumpers to unproxy
<azonenberg>
Bike: besides being an ecological disaster? :p
<Bike>
yes
<awygle>
Also, I hate this decaying meat sack. ##openascensionintobeingsofpurelight when.
* awygle
is still sick
Hamilton has joined ##openfpga
<rqou>
lol awygle
<Bike>
the meat is more than just a sack, you know
<Bike>
more like a decaying suit of powered meat armor
<rqou>
can beings of pure light still have cat ears? :P
<azonenberg>
i need to get ally to draw me a "salad bar"
<awygle>
being ~meguca~ a meat sack is suffering
<azonenberg>
i'm thinking a seedy pub in a bad part of town with a bunch of guys in biker outfits munching on Caesar salads
<azonenberg>
maybe a platter of lettuce resting on the side of a pool table with a single bare light bulb hanging over it
<azonenberg>
etc
<rqou>
wtf?
<azonenberg>
Isn't that what a salad bar is?
<awygle>
I can't tell if my cat is sympathetic, just happy I'm home, or trying to finish me off
<azonenberg>
oh and behind the bartender there's like shelves of artfully displayed tomatoes, bottles of dressing, etc
<rqou>
oh daveshah: re your comment about a ring oscillator: the heaters were open-loop
<rqou>
it's literally just "above freezing yet?"
<daveshah>
you mean they didn't have a fine tuned model predictive control algorithm?
<rqou>
or whatever the threshold was
<daveshah>
This doesn't sound very over engineered
<rqou>
no, since bang-bang control is very very hard
<awygle>
Our satellite had a heater for the battery that ran directly off the solar panels when the low temperature cutoff disconnected the battery
<awygle>
Charging frozen batteries is very bad
<rqou>
i can imagine
<awygle>
Apparently
<awygle>
But charging heats them up too, so it's complicated lol
<rqou>
what about charging frozen (non-sealed) lead acid batteries?
<sorear>
##openradioisotopeheatingunits
<rqou>
just ask whitequark to steal one from an abandoned Siberian lighthouse
<rqou>
(do these still exist?)
<awygle>
I suggested Open literally-just-turn-on-the-radio heating unit. It dissipated 4W as heat.
<awygle>
But nasa regs made that impossible
<Bike>
i don't think it's certain whether there are any RTG lighthouses left, since they lost records
<Bike>
they used to put some in pacemakers, maybe you could go Temple of Doom on someone
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
steakpizza has joined ##openfpga
Hamilton has quit [Quit: Leaving]
<sorear>
Tiny ones though.
<Bike>
a little plutonium goes a long way
<rqou>
says North Korea :P
steakpizza has quit [Remote host closed the connection]
<sorear>
Sure but those are promethium
<sorear>
And the lighthouses are strontium
<sorear>
Both much worse W/kg than 238Pu
<azonenberg>
wait 238? i thought they normally used 239 for RTGs?
<azonenberg>
oh wait
<azonenberg>
239 is what's used in nukes
<azonenberg>
238 is the strong alpha emitter
<azonenberg>
But too unstable to use in a nuke because it'd detonate prematurely
<rqou>
fun challenge: machine a plutonium sphere (apparently this is very difficult)
<shapr>
toxicity? or what?
<rqou>
even "fun" challenge: make measurements of it with just a screwdriver that you hopefully won't ever let slip :P
<rqou>
iirc toxicity and the huge number of phases
<rqou>
hmm "The reasons for the complicated phase diagram are not entirely understood; recent research has focused on constructing accurate computer models of the phase transitions. "
steakpizza has joined ##openfpga
<awygle>
Apparently the toxicity is somewhat disputed? At least that's what came up when I Googled it.
Bike has quit [Ping timeout: 260 seconds]
tinyfpga has quit [Ping timeout: 245 seconds]
tinyfpga has joined ##openfpga
steakpizza has quit [Remote host closed the connection]
<sorear>
Toxicity is probably overstated, phase changes are a huge pain
<rqou>
random question: i just discovered that some of the stm32s have a different usb block that isn't the synopsys designware block
<sorear>
In any event it’s a heavy metal, do not eat
<rqou>
anybody know where it comes from?
steakpizza has joined ##openfpga
<rqou>
first registers are called CNTR, ISTR, FNR
<rqou>
sorear: can i eat polonium instead? i heard it's popular among Russian dissidents :P :P :P
<sorear>
wasn’t he roofied
<rqou>
Litvinenko was polonium
<rqou>
the recent one was allegedly a novichok agent
<sorear>
Can they go back to fancy umbrellas
<rqou>
lol
<rqou>
apparently Russia really likes to be showy
<rqou>
unlike Mossad that really likes to be subtle
<rqou>
hmm, we should build an open-source ricin umbrella :P :P :P :P :P
<rqou>
azonenberg: would such an item be ITAR-controlled?
<azonenberg>
almost certainly
* azonenberg
pulls up examples of silly itar items
<awygle>
yeah for sure
<rqou>
random rant: wtf is wrong with the gdb remote debug protocol?
<rqou>
why does every gnu project appear to superficially work pretty well but is always a trashfire internally?
<awygle>
yeah gdb remote debug is pretty bad
<awygle>
it's good that it exists, but it could be a lot better designed
Bike has joined ##openfpga
<rqou>
what about the overall "gnu code always manages to be a trashfire internally" part?
<rqou>
and yet it usually works for me
<balrog>
rqou: legacy
<lain>
organic growth is a curse
<balrog>
yup
bitd has quit [Ping timeout: 240 seconds]
unixb0y has joined ##openfpga
<unixb0y>
Test
<sorear>
ok 1 # message received
unixb0y_ has joined ##openfpga
<mithro>
The icestick has a tq144 chip right?
<mithro>
daveshah: ^ ?
unixb0y_ has quit [Client Quit]
<unixb0y>
Hi mithro :)
steakpizza has quit [Remote host closed the connection]
<mithro>
unixb0y: Want a task? :-P
<unixb0y>
😂😂😂
<unixb0y>
Maybe 😉
<mithro>
unixb0y: Need a little python script which translates an icebox .pcf file to a vpr io.place file
<unixb0y>
Okay i is
<unixb0y>
1 sec
<unixb0y>
My phone is acting weird
<unixb0y>
Yeah I’ll try to look into what Those file types are :) you can send me sample files to my github email address if you want.