azonenberg_work has quit [Ping timeout: 240 seconds]
gnufan has quit [Quit: Leaving.]
Tenacious-Techhu has quit [Ping timeout: 260 seconds]
m_t has quit [Quit: Leaving]
soylentyellow has joined ##openfpga
grantsmith has quit [Ping timeout: 255 seconds]
azonenberg_work has joined ##openfpga
balrog has quit [Ping timeout: 240 seconds]
grantsmith has joined ##openfpga
balrog has joined ##openfpga
[X-Scale] has joined ##openfpga
X-Scale has quit [Ping timeout: 240 seconds]
[X-Scale] is now known as X-Scale
m_w has quit [Quit: Leaving]
digshadow has quit [Ping timeout: 264 seconds]
digshadow has joined ##openfpga
monochroma has quit [Quit: bork bark blep mlem]
scrts has quit [Ping timeout: 272 seconds]
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
<rqou>
offtopic: i've been doing some reading about high vacuum systems and they're much less difficult than i thought
<rqou>
azonenberg_work: diy rie system?
<rqou>
also whitequark i guess?
<whitequark>
rqou: yes i want one
<whitequark>
but I need to restart my vacuum work
<whitequark>
I want to get solvespace into working order first since that's what I use for all my designs
<rqou>
why doesn't m-labs already have one? :P
<whitequark>
care to contribute there?
<rqou>
ENOTIME :P
<whitequark>
because m-labs is about quantum physics not silicon RE
<whitequark>
pfff -ENOTIME is for losers
<whitequark>
sleep less
<rqou>
that's not working out for me too well right now
inode has joined ##openfpga
<rqou>
btw azonenberg_work, balrog, whoever else asked about this: today i spent a few hours REing the xc9500 (non-xl) but didn't make very much progress
<rqou>
the ordering of _everything_ is permuted in some weird way
<rqou>
but i think i know which group of bits controls the PAL, macrocells, and interconnect
eduardo_ has joined ##openfpga
eduardo__ has quit [Ping timeout: 240 seconds]
eduardo_ has quit [Ping timeout: 268 seconds]
eduardo_ has joined ##openfpga
nicdev has quit [Remote host closed the connection]
asy has joined ##openfpga
scrts has joined ##openfpga
m_t has joined ##openfpga
mumptai has joined ##openfpga
<azonenberg_work>
rqou: diy rie is on the TODO after i move
azonenberg_work has quit [Ping timeout: 264 seconds]
mumptai has quit [Remote host closed the connection]
fitzsim has joined ##openfpga
promach__ has joined ##openfpga
promach__ has quit [Read error: Connection reset by peer]
promach__ has joined ##openfpga
promach__ has quit [Remote host closed the connection]
Bike has joined ##openfpga
azonenberg_work has joined ##openfpga
<azonenberg_work>
rqou: i have die shots
<azonenberg_work>
if they help any
<azonenberg_work>
So far i think just top metal but i could delayer if there was interest
<azonenberg_work>
i'm used to putting decoupling caps in via-in-pad right on top of BGA pads :p
<azonenberg_work>
lool
<azonenberg_work>
i mean the layout being done in EAGLE tells me all i need to know in general :P
<tnt>
Meh, I use eagle :p
<azonenberg_work>
all i can say is, almost all serious high speed board designs i've seen have used either kicad, altium, pads, or cadence
<azonenberg_work>
I saw one nice PCIe board done in geda
<tnt>
Well I tried kicad (because I don't want any of the new eagle licensing) but the inability to easily do via stiching was just annoying ... but it got fixed a couple month back apparently so I might retry.
<tnt>
I do mostly small boards, with speeds ... ~ 200-300 MHz digital or 2-3 GHz RF.
<azonenberg_work>
i'm using a couple months old kicad righ tnow
<azonenberg_work>
i should check and see if they can do stitching now
<azonenberg_work>
i saw discussion on the mailing list
<tnt>
Gotta go. I'll need to see if I can fix up the upduino board a bit with rework.
<azonenberg_work>
but i forget if they got it working
<tnt>
I saw a commit and the bug switched to 'Fixed' but didn't try.
<azonenberg_work>
ah o
<azonenberg_work>
i see*
<azonenberg_work>
i did a kicad design not too long ago doing 10 Gsps analog
scrts has quit [Ping timeout: 248 seconds]
s0n1cB00m has joined ##openfpga
s0n1cB00m has quit [Ping timeout: 256 seconds]
azonenberg_work has quit [Ping timeout: 248 seconds]
s0n1cB00m has joined ##openfpga
scrts has joined ##openfpga
jhol has quit [Quit: Coyote finally caught me]
jhol has joined ##openfpga
jhol has quit [Quit: Coyote finally caught me]
jhol has joined ##openfpga
s0n1cB00m has quit [Excess Flood]
s0n1cB00m has joined ##openfpga
user10032 has joined ##openfpga
digshadow has quit [Ping timeout: 248 seconds]
s0n1cB00m has quit [Ping timeout: 276 seconds]
s0n1cB00m has joined ##openfpga
digshadow has joined ##openfpga
s0n1cB00m has quit [Ping timeout: 268 seconds]
mumptai has joined ##openfpga
pie_ has quit [Ping timeout: 256 seconds]
<digshadow>
rqou: I have some rie equip if you want to play with it
<rqou>
why don't you use that for delayering?
<digshadow>
multiple reasons, but the main thing is that I got it and then had to move space
<digshadow>
and so got distracted and never played with it
<digshadow>
also I had someone that was supposed to get me proper process gas, and he flake dout
sgstair has quit [Read error: Connection reset by peer]
<jn>
let me introduce to you Bake.ly(tm)(R), a fabless baking company :P
<awygle>
broke: apple pie from universe. woke: universe from apple pie
<lain>
lol
<awygle>
cr1901_modern: I engaged on Twitter because I actually think these problems will lead to *more* CPU innovation, just at a higher level. Less "let's pretend that the von Neumann bottleneck doesn't exist", more "let's see if we can actually solve our fundamental problems"
<awygle>
Actually on further thought it's not really a von Neumann issue, but still.
<cr1901_modern>
awygle: I basically gave up on that when I realized Mill is vaporware, and learned the real reason Lisp Machines failed
<jn>
but MCST Elbrus is right around the corner! /s
user10032 has quit [Remote host closed the connection]
<cr1901_modern>
(Economies of scale basically ensure that general purpose CPU designers can take the size/money hit from making GPCPUs better Lisp Machines than well... Lisp Machines)
<awygle>
My hot take is "novel cpu architectures fail because of the economic climate, and massive security holes are semi-plausible reasons for the economic climate to change
<lain>
my 2 cents: novel architectures fail because we're N decades into this game already and write-once-run-everywhere is still a pipedream, so we're heavily tied to specific architectures in general
<lain>
I realize this isn't true in ALL industries, but ...
<awygle>
cr1901_modern: maybe "pretending everything is L1 cache" is a better way to say it
<lain>
though that is slowly changing, like how Win10 on ARM can run x86 apps with what I understand to be a rather sophisticated dynarec, basically doing what Transmeta tried to do forever ago
<lain>
it's not *fast*, but it's good enough for most things
<awygle>
Memory latency exists - there's no law of nature that says we have to pretend it doesn't
<cr1901_modern>
But compilers already know that
<awygle>
It was the easiest solution for a long time, and maybe now it isn't
<awygle>
I mean sort of. But just look at the effort it takes to write timing independent code
<awygle>
A hypothetical system where addresses with the high bit set are cache is easy to imagine
<awygle>
And the idea extends to arbitrary hierarchies
<cr1901_modern>
MIPS and lm32 do that (well, uncached vs cache anyway)
<cr1901_modern>
Though Idk if kseg0/1/2 is meaningful today
<cr1901_modern>
*insert MIPS and meaningful jokes here*
<awygle>
IIRC that's "this memory is or is not cached", not "by writing to this address you are writing to the L2 cache and not to RAM at all"
<lain>
hmm.. did we ever find out if AMD Zen architecture is vuln to the speculative execution attack? iirc it wasn't because it uses separate cache areas for different privilege levels
<cr1901_modern>
Ahhh right, that might be doable, but as Jan Gray said, you evicted something to write to that cache
<cr1901_modern>
you can still get info about stuff you shouldn't have access to based on what was evicted
<cr1901_modern>
Idk _how_ just that you can :P
<awygle>
See lain's comment about separate cache areas for different privilege levels (or different processes, or or or). There's a wider design space, is all I'm really saying
<awygle>
Anyway. Back to drawing triangles. Good discussion!
<qu1j0t3>
mmmm triangles
<cr1901_modern>
triangle strips are the best primitive don't @ me
azonenberg_work has joined ##openfpga
azonenberg_work has quit [Ping timeout: 248 seconds]
azonenberg_work has joined ##openfpga
<rqou>
anyone think any of these are exploitable on cortex-m?
<rqou>
afaict no because the pipeline on cortex-m isn't deep enough
<kc8apf>
rqou: would only matter if you are enabling MPU
<rqou>
i was thinking vendor-specific flash read protection
<rqou>
(although those have historically had a number of fun logic bugs of their own)
<azonenberg_work>
i dont think cortex-m speculates memory loads
<azonenberg_work>
cortex-A is probably affected
<rqou>
it does for branch targets
<rqou>
but afaict it won't speculate anything more than that
<kc8apf>
flash read-ahead might cause a similar effect
<kc8apf>
it would pollute the icache
<rqou>
the thing is that cortex-m afaik doesn't have its own caches
<rqou>
vendors added their own
<kc8apf>
I only now a few parts that do flash read-ahead
<kc8apf>
that would require caching
<rqou>
right, but afaik the caching is outside the cortex-m core and is in the vendor-customized part
<kc8apf>
it's still speculatively loading from the flash. The question is whether you can determine the content by looking at timing, etc.
<rqou>
yeah, but i don't think you can
<rqou>
at least not with the exact same technique
scrts has quit [Ping timeout: 248 seconds]
mumptai has quit [Quit: Verlassend]
azonenberg_work has quit [Remote host closed the connection]
azonenberg_work has joined ##openfpga
gnufan has quit [Quit: Leaving.]
azonenberg_work has quit [Remote host closed the connection]
<sorear>
lain: meltdown is a rather specific vulnerability and is only known to affect Intel's high end products and Cortex-A75; AMD said they weren't affected. the spectre stuff is much more general and is a problem on zen