azonenberg_work has quit [Ping timeout: 246 seconds]
m_t has quit [Quit: Leaving]
digshadow has quit [Quit: Leaving.]
wolfspraul has quit [*.net *.split]
reportingsjr has quit [*.net *.split]
dx has quit [*.net *.split]
wolfspraul has joined ##openfpga
dx has joined ##openfpga
reportingsjr has joined ##openfpga
kuldeep has quit [Read error: Connection reset by peer]
kuldeep has joined ##openfpga
digshadow has joined ##openfpga
jhol has quit [Quit: Coyote finally caught me]
dalias has quit [Ping timeout: 260 seconds]
pie_ has joined ##openfpga
pie__ has joined ##openfpga
pie__ has quit [Remote host closed the connection]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
balrog has quit [Ping timeout: 265 seconds]
amclain has quit [Quit: Leaving]
balrog has joined ##openfpga
massi has joined ##openfpga
Tanfrieze has quit [Ping timeout: 248 seconds]
Tanfrieze has joined ##openfpga
vls has joined ##openfpga
Bike has quit [Quit: mimsy were]
m_t has joined ##openfpga
vls has quit [Quit: Konversation terminated!]
cr1901_modern has quit [*.net *.split]
zino has quit [*.net *.split]
zino has joined ##openfpga
cr1901_modern has joined ##openfpga
Tanfrieze has quit [Ping timeout: 245 seconds]
<marex-cloud>
It finally struck me how awesome this statistical approach is. If we figure out the LE and LAB bits, we can use that to map that knowledge onto larger FPGAs with ease
<pie_>
statistical approach?
<azonenberg>
marex-cloud: so it sounds like there's progress going on the altera front now?
<azonenberg>
Have you guys put anything on the wiki yet?
<marex-cloud>
azonenberg: what wiki? :-)
<marex-cloud>
azonenberg: there's always progress on Altera ;-)
azonenberg_work has joined ##openfpga
<marex-cloud>
I'm just too busy, so the progress is slow
<azonenberg>
marex-cloud: do you not have github wiki access yet?
<openfpga-github>
yosys/master dfb461f Clifford Wolf: Added Verilog $rtoi and $itor support
<openfpga-github>
yosys/master 81bb952 Clifford Wolf: Handle "always 1" like "always -1" in .smtc files
JvD__ has joined ##openfpga
<marex-cloud>
azonenberg: I don't think so ...
<marex-cloud>
azonenberg: I disagree with github TOS
eduardo_ has joined ##openfpga
jrernst has joined ##openfpga
eduardo__ has quit [Ping timeout: 248 seconds]
<azonenberg>
marex-cloud: oh?
<azonenberg>
what about it?
JvD__ is now known as JvD
<Marex>
azonenberg: for starters, you have no control over the repo, it's owned by github basically
<Marex>
if they decide to put something else there, they can
<azonenberg>
marex: that's true of any third party hosting, and that's why i'd never use a third party host for anything but git
<azonenberg>
with git you have hashes that chain back to your working copy
<azonenberg>
so if they totally trash the repo you can at least detect it
<Marex>
azonenberg: but you'll have the entire internet pointing to that repo , which you cannot fix
<azonenberg>
What makes github any worse than any other host for that, though?
<azonenberg>
i got burned by google code in the past
<azonenberg>
the only way to 100% be sure it's good is if you host things yourself on your own server with a domain you own
<Marex>
azonenberg: they are all the wurst :)
<azonenberg>
But then you have to play sysadmin all the time
<azonenberg>
Better question
<Marex>
azonenberg: jupp, host it yourself
<azonenberg>
I used to do that, too much work
<azonenberg>
I always want to have my own copy of the code so if the host goes down i can push it back somewhere else
<azonenberg>
i never *rely* on the host, i consider it a convenience
<azonenberg>
FPGA devs are not stupid
<azonenberg>
if github magically disappears some day
<azonenberg>
they're going to google or whatever a bit
<azonenberg>
and find our new location
<azonenberg>
As long as the code survives and can be re-uploaded elsewhere i really don't care
<azonenberg>
github's job IMO is to eat my bandwidth and hosting costs, and be an attack magnet so i dont have to worry about people messing with my own servers
<azonenberg>
And if they fail at that, i go somewhere else
<Marex>
azonenberg: how is hosting git server too much work ?
<azonenberg>
It's not just a git server, it's a wiki plus issue tracker etc
<azonenberg>
i used to use redmine for this
<azonenberg>
and i still have it up but i dont use it anymore, and am in the process of shutting it down
<azonenberg>
redmine was too unstable, it'd corrupt the db randomly when i tried to update to the latest release
<azonenberg>
and i'd have to reinstall and lose my saved issues etc
<Marex>
well, it's ruby, no ?
<Marex>
aka. newfangled stuff
<azonenberg>
It's all i could find
<azonenberg>
i hate ruby :p
<Marex>
azonenberg: hate is a strong word, but I'm not a fan either
<Marex>
jrernst: Hi!
<azonenberg>
it routinely fails to do the job
<Marex>
jrernst: 14:01 < marex-cloud> It finally struck me how awesome this statistical approach is. If we figure out the LE and LAB bits, we can use that to map that knowledge onto larger FPGAs with ease
<azonenberg>
that better? :P
<jrernst>
hi
<jrernst>
Marex: there is still much work to be done
kristianpaul has quit [Quit: leaving]
kristianpaul has joined ##openfpga
kristianpaul has joined ##openfpga
kristianpaul has quit [Changing host]
<Marex>
jrernst: what I'd like to do is rewrite the tool to dump the bitstream content and make it capable of generating either RCF or annotated HDL
<Marex>
jrernst: then we'd be able to generate random designs, compile them with quartus and read back using the tool, and check the RCFs against one another to fill in the missing bits
<jrernst>
that would be great. I don't understand it 100% what's in the RCF. Hope this can be done.
<jrernst>
I had another idea. Instead of choosing a signal or whatever in the RCF and then looking for the bits we can maybe do it the other way around.
<Marex>
jrernst: I saw your email, didn't read it in detail yet tho
<Marex>
jrernst: btw are you a student or working already ?
<jrernst>
if we take one bit in the stream and then looking where it is used in other bitstreams or LABs it is maybe possible to find the common entries in the RCF.
<jrernst>
I'm out of office and use my free time for this fun. Work starts again on monday.
<jrernst>
I worked on the eqn to spot how the lines with "--register power-up is low" make any sense.
<jrernst>
I thought it's the init value. Unfortunately I saw no difference when initializing 32 FFs with 0 and 32 FFs with 1.
<Marex>
yeah, same here then, real work starts Monday
<jrernst>
let's use the rest of the time to the max
<azonenberg>
Do you guys get a really long new year holiday or something?
* azonenberg
returned to work tuesday of this week
<Marex>
azonenberg: too bad :)
<azonenberg>
i even was supposed to work like 2 or 3 days between xmas and new years
<Marex>
I'm slowly picking up the pace
<Marex>
mostly reviewing kernel patches these days tho
<azonenberg>
but used vacation days for them so i'd have one big vacation instead of two long weekends
talsit has left ##openfpga [##openfpga]
jhol has joined ##openfpga
m_w has joined ##openfpga
amclain has joined ##openfpga
Bike has joined ##openfpga
azonenberg_work has quit [Ping timeout: 248 seconds]
<rqou>
time for every traveller's favorite (/s) pastime
<rqou>
waiting for a connection at EWR
<rvense>
what's an ewr
<qu1j0t3>
airport
<rqou>
Newark Liberty International Airport
<rqou>
it's a large transfer airport on the US east coast
<rqou>
"like Amsterdam Schiphol but with ruder staff and more delays" :P
<cr1901_modern>
Hey, you're in scenic New Jersey :P
<cr1901_modern>
take a look around while you wait
pie__ has joined ##openfpga
pie__ has quit [Changing host]
pie__ has joined ##openfpga
<rqou>
I see United planes :P
<rqou>
btw security is very theater in the US
<azonenberg>
ya thnk?
<azonenberg>
lol
<azonenberg>
you can easily bring li-ion batteries and a few bottles of vodka
<azonenberg>
who needs a bomb?
<rqou>
whereas the EU rail network doesn't try but doesn't pretend
<azonenberg>
that's mostly true for the US rail network
<azonenberg>
i've never had any kind of screening riding amtrak
<azonenberg>
although i saw national guard troops in penn station a few times as a show of force
<lain>
lol
<lain>
"look at all these guns we will wave around after someone blows the place up!"
<lain>
yeah US security is a joke, it's sad
<lain>
it's frustrating because if it were ACTUALLY doing any good, I'd be fine with it
<lain>
but it isn't
<lain>
so it's just a waste of my time :P
<rqou>
and tax dollars?
massi has quit [Quit: Leaving]
<lain>
yeahhhh
<lain>
well I guess I've accepted the fact that my tax dollars do a lot of things I don't support
<rqou>
like defunding Obamacare? :P
<lain>
lol
<rqou>
or shutting down the government to defund Planned Parenthood? :P :P
<rqou>
for those of you not in the US:
<rqou>
Planned Parenthood provides reproductive health services
<rqou>
at some point some Republicans considered blocking a budget just to force them to not get as much funding
<rqou>
this fortunately didn't happen
m_w has quit [Quit: leaving]
m_w has joined ##openfpga
<lain>
someone is doing some kind of campaign around my city against planned parenthood
<lain>
there's always protestors outside the planned parenthood north of town
<rqou>
what state?
<lain>
indiana, but I'm north, near chicago area
<lain>
our city is the only one that tends to vote /against/ the rest of the state on stuff like this
<lain>
but you still get some people....
<lain>
well ok I guess indianapolis probably also votes against the rest of the state, but it's still not enough :P
<rqou>
yeah, I can see that
<lain>
also lately there's lots of billboards in town with like "we will support your child" and stuff, anti-abortion
<rqou>
support how?
<lain>
yeah I dunno, they're creepy
<lain>
like one has a very pregnant lady standing there smiling, and like 4 people standing around, each one putting a hand on the pregnant lady's belly
<lain>
and they're all smiling really wide
<rqou>
"dump in foster system" =/= support
<lain>
and it just says like "we can help"
<lain>
that's all it says lol
<lain>
yeah, I think it is an adoption system maybe? not sure.
<lain>
I'm not going to call and find out lol
<rqou>
call from Google Hangouts?
<lain>
haha
<rqou>
:P
<rqou>
call and claim you have 12 kids and are pregnant and ask what you should do :P
<cr1901_modern>
In a channel I frequent, someone put that as my enter message that a bot says when I enter the room
<cr1901_modern>
I wonder who did it... b/c it's not wrong
<rqou>
I think many people might have that type of relationship towards FPGAs :P
<jn__>
i'm so glad urbandictionary exists, so i can look up words like tsundere :)
<cr1901_modern>
Anyone who knows what it means w/o looking it up watches too much anime
<lain>
lol
<rqou>
wasting time and looking at the Minecraft network protocol
<rqou>
apparently it now uses RSA
<rqou>
but no PFS
<rqou>
not sure if I should call it a fail or not
<lain>
the nsa is spying on your mines
<rqou>
hmm my reading of the RE'd protocol spec seems to imply that keys don't have to be long-lived
<rqou>
you can generate a new one per auth request
<rqou>
idk what the vanilla server does
<rqou>
wait
<rqou>
this protocol isn't immune to mitm
pie___ has joined ##openfpga
pie___ has quit [Changing host]
pie___ has joined ##openfpga
pie__ has quit [Ping timeout: 245 seconds]
<mtp>
shokku
<mtp>
(notch is a bad programmer)
<rqou>
this is a post-Notch change
<mtp>
((it's a matter of "birds of a feather"))
<rqou>
or you can argue that it's what's wrong with PKI :P
<rqou>
it's analogous to using self-signed server certs because CAs are hard
<whitequark>
I don't think that incompetence is related to Notch in any way
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
<rqou>
also, apparently keys are 1024-bit only so the NSA can see your obsidian <obscene structure>s :P
<mtp>
god
<mtp>
in 2013 i was asked to add raw RSA support to the thing i was working on. i tried setting a lower bound on the key length as 1024 and got pushback saying i had to make it 512
<mtp>
because they were doing idiot things with RSA client-side javascript
<mtp>
anyway, i ended up quitting that job,
<rqou>
*cough* *cough* TI
<rqou>
nProtect
<mtp>
yeah i think i mentioned to management that i could factor that RSA key on my pocket calculator
<mtp>
which is a SLIGHT exaggeration
<rqou>
not quite
<mtp>
but not quite
<rqou>
it took me several months on a q6600
<rqou>
(the old nProtect key factors are somewhere in the log for this channel :P )
<mtp>
nice, nice
<lain>
hah
<rqou>
unfortunately for those cheating at the vidya nProtect added a new 2048-bit key
<rqou>
(didn't make the rest of the product any better)
<azonenberg>
rqou: speaking of minecraft
<azonenberg>
did you ever set up a server i can join? :p
<rqou>
not yet
<azonenberg>
mtp: i'd make 2048 a lower bound for rsa keys
<rqou>
I created a wiki page :P
<azonenberg>
also, client side js...
<mtp>
azonenberg, well, yes, but i knew i wasn't even gonna get fucking 1024
<azonenberg>
reminds me of client code i've seen
<azonenberg>
Your project wasnt a SCADA system, was it?
<mtp>
no
<azonenberg>
Well, there's more than one of these out there then :p
<mtp>
yes
<azonenberg>
Do you guys think 42 slides (40 if you ignore the title and Q&A) is a bit long for a half-hour talk?
<rqou>
azonenberg: I'm _still_ at EWR, give it time :P
* azonenberg
is trying to slim it up
<lain>
azonenberg: do you have to take questions at the end?
<azonenberg>
I expect to
<azonenberg>
No questions allowed at the big stage b/c too much audience and not enough time
<lain>
talk fast :3
<azonenberg>
the technical deep dive track is smaller and less crowded
<rqou>
anyways, Minecraft
<rqou>
I'm thinking at least 2 servers at this point
<rqou>
one heavily-modded 1.7.10
<azonenberg>
oh? one for fun and one for RTL testing?
<rqou>
one lightly-modded latest version
<azonenberg>
Why 1.7.10?
<azonenberg>
mods dont support latest?
<rqou>
it's the "legacy" mod version
<rqou>
yes, MC has "legacy"
<azonenberg>
did they drop mod support in latest or something?
<rqou>
mods took/are taking forever to catch up to the graphics refactor
<azonenberg>
ah
* azonenberg
has been out of touch for a bit, i dont know much about this refactoring
<rqou>
changing immediate mode to pre-baked models
<azonenberg>
wait
<azonenberg>
waaaait
<rqou>
I've also been out of touch
<azonenberg>
they were using immediate mode until WHEN?
* azonenberg
facepalms
<rqou>
iirc they still are
<rqou>
some VBOs are also used
<rqou>
anyways, the "latest MC" will hopefully have project red logic gates and wires and no other mods
<rqou>
except misc minimap and Google Maps-esque maps and similar
<rqou>
you'll still need a Forge client
<rqou>
other possible servers depending on interest:
<rqou>
TerraFirmaCraft, Better than Wolves
<rqou>
aaand the catering car is late. Thanks EWR
<rqou>
Schiphol didn't have any of these problems
<rqou>
KLM even managed to serve everyone a slice of cake on a 50 minute flight
<azonenberg>
lol
<rqou>
and Schiphol/KLM aren't even Germans :P
<rqou>
IME the slowest/worst staff in EU was the Belgian border control
<rqou>
even slower than the French :P
pie___ has quit [Ping timeout: 255 seconds]
Ardeshir has joined ##openfpga
<jrernst>
Marex: I have new results
<Marex>
oh?
<jrernst>
I was working the whole day on the correlation method
<jrernst>
It worked
<jrernst>
As a simple task I choose to find the bit which initializes the FF
<jrernst>
It's values which is set before any clock has set Q of the FF
<jrernst>
correct: It's the value which is set before any clock has set Q of the FF
<jrernst>
I constructed a VHDL to have 256 FFs and they are initialized 50% to 0 and 50% to 1
<jrernst>
Then quartus_cdb compile and back-annotation the get the names into the QSF file
<plaes>
aa
<plaes>
sry
<jrernst>
Then parsing the QSF to get the position e.g. FF_X13_Y17_N5 and the name of the VHDL signal
<jrernst>
From then CHDL signal name I know which bit is set to 0 or 1
<jrernst>
Then I split the task in 2 parts: a) grab the LEs which must have the 0s b) grab the LEs which must have the 1s
<jrernst>
Then another split of this data in 2 parts. a) the upper part with LLLLLLLL LUT and b) the lower part with llllllll LUT
<jrernst>
Because I cannot correlate them both to find one bit.
<jrernst>
Then I ANDed als the 1 parts
<jrernst>
Then I negated all the zero parts and then ANDed them as well
<jrernst>
The final AND of them gave on bit set
<jrernst>
I can post the 8 lines here
<jrernst>
First result of the upper half:
<jn__>
u
<jrernst>
...................................
<jrernst>
...................................
<jrernst>
..................LLLLLLLL.........
<jrernst>
.................XLLLLLLLL.........
<jrernst>
..................llllllll.........
<jrernst>
..................llllllll.........
<jrernst>
...................................
<jrernst>
...................................
<jn__>
(oops, i mistyped)
<jrernst>
Similar the lower half:
<jrernst>
...................................
<jrernst>
...................................
<jrernst>
..................LLLLLLLL.........
<jrernst>
..................LLLLLLLL.........
<jrernst>
.................Xllllllll.........
<jrernst>
..................llllllll.........
<jrernst>
...................................
<jrernst>
...................................
<jrernst>
The found position in the bitstream is where the X is.
<jrernst>
This position is mentioned in your docs.
<jrernst>
You wrote:
<jrernst>
(Uncertain: Q/q - enable COMBOUT routing outside of the LE ?)
<jrernst>
And your LAB slice bits pattern was:
<jrernst>
|....EZ...........BAAABBBBBAA.......|
<jrernst>
|.................BAAABBBBBAA.......|
<jrernst>
|.......QLLLLLLLLMDCDDDDDCCCC.......|
<jrernst>
|....SO..LLLLLLLLNDCDDDDDCCCC.......|
<jrernst>
|....so..llllllllnbaaabbbbbaa.......|
<jrernst>
|.......qllllllllmbaaabbbbbaa.......|
<jrernst>
|.................dcdddddcccc.......|
<jrernst>
|....ez...........dcdddddcccc.......|
<jrernst>
You see it has found the position where the Qs are.
<jrernst>
Sorry, its not the Q its between the Qs
<jrernst>
anyway
<jrernst>
Marex: which search do you think is wirth a next try?
<jrernst>
Marex: which search do you think is worth a next try?
<jrernst>
In your doc there is
<jrernst>
M/m - C input mux configuration (combinatorial mux #1)
<jrernst>
N/n - C input mux configuration (combinatorial mux #2)
<jrernst>
Or maybe the FF control signals
<Marex>
jrernst: you can double-check the signals I located, then it'd be great to figure out the global LAB signals
<Marex>
jrernst: or do you feel like routing ? :)
<jrernst>
That's what I'm doing. I first would like to find the simple things. On to go I'll perfecting the scripts. Then routing will be a goal.
<jrernst>
From your experience what's the best next choice to check?
<jrernst>
M/n N/n or FF controls?
<Marex>
muxes should be easy
<jrernst>
yeeessss... but I don't have the scripts ready for that.
<jrernst>
I need something which do not need to scan the RCF at the moment
<jrernst>
Only what's in the QSF: FFs and LCCOMBs connected to their names.
<Marex>
you mean in the RCF, no ?
<jrernst>
I mean QSF
<jrernst>
I'm scanning the set_location_assignment lines
<jrernst>
The preparation needs two distinct properties and the name tells which property I gave them in the HDL
<jrernst>
example: I want to see where the init bit is
<jrernst>
First I make some bits e.g. signal test0 : unsigned(31 downto 0) := x"00000000"
<jrernst>
The second set is e.g. signal test1 : unsigned(31 downto 0) := x"FFFFFFFF"
<jrernst>
So I have to distinct sets of FFs. 50% initialized with 0 and 50% with 1.
<jrernst>
When the name test0 is shown in the QSF I know that every bit is initialized to 0. Same with test1 -> 1
<jrernst>
Then scanning the LABs in the bitstream and correlating.
<jrernst>
Importent is only to superpose the correct set. Only the LABs fron the 0 set and only the LABs from the 1 set.
<jrernst>
Due to superposition the common feature will remain and the variating features will be removed.
<jrernst>
And it is not important where the LABs will be placed. Only the amount is important. The set has to be large enough to extract the feature and to remove the noise.
<pointfree>
A lot of interesting IRC backlog to read about cpld bit isolation. I've been writing a collection of tools (psoc-rebit) for Cypress PSoC 5LP correlation (.route file <---> config.bin).
<pointfree>
Work smart; not hard.
<pointfree>
I've been adapting the technique in the "from bitstream to netlist" paper and debit.
<Marex>
jrernst: I see :)
<jrernst>
pointfree: I read the paper. "From the bitstream to the netlist" from Jean-Baptiste Note and Éric Rannaud. Was very interesting.
<jrernst>
And I tested debit.
<jrernst>
Unfortunately the altera code was unfinished :-(
<pointfree>
"variating features will be removed" <--- sounds kind of like Quine-McCluskey. Maybe there is a connection there?
<Marex>
jrernst: and cryptic as hell
<Marex>
(the debit altera code)
<jrernst>
No it's not Quine-McCluskey. It's simply statitics.
<pointfree>
I thought about just extending debit... but I eventually decided to just write my own project.
<jrernst>
Noise has different properties than regular features.
<jrernst>
It's more the same mathematics used in analyzing data from side channel attacks
<pointfree>
I've been implementing Mill's methods as part of psoc-rebit https://en.wikipedia.org/wiki/Mill's_Methods It's a way of determining causation. It was invented before statistics. I'll see how it goes.
<jrernst>
I see what wikipedia says. Reminds me of something.
<jrernst>
ah there it is. It's from a talk: "Analysing the bitstream of altera's MAX-V CPLDs"
<jrernst>
Mill's Method reminds me of this said on slide 30 of the talk:
<jrernst>
ANALYZING INTER-CELL CONFIGURATION
<jrernst>
For a given route R:
<jrernst>
A := all bitstreams who use R
<jrernst>
B := ~A
<jrernst>
I := intersection of each element in A
<jrernst>
("the bits who are set in all bitstreams that use R")
<jrernst>
That's the simplest form to implement it.
<jrernst>
But there's a better way: (slide 31)
<jrernst>
For a given route R:
<jrernst>
A := all bitstreams who use R; B := ~A
<jrernst>
I := intersection of each element in A
<jrernst>
("the bits who are set in all bitstreams that use R")
<jrernst>
J := union of the complements of each element of B
<jrernst>
("the bits who are not set in at least one of the bitstreams that doesn't use R")
<jrernst>
Configuration bits for R are the intersection of I and J
<jrernst>
("the bits who are set in all bitstreams that use R and are not used in at least one bitstream that doesn't use R")