<enriq>
what is the distinction then? size? architecture of cells?
<rqou>
it depends on your definition actually
<rqou>
the one we're using is that CPLD = product terms
<rqou>
whereas FPGA = LUTs
<awygle>
others you may hear include "crossbar vs. routing fabric" and "CPLDs are FPGAs but smaller"
<enriq>
product terms means interconnected logic elements such as gates and flipflops and LUT is for look up table?
<pointfree>
CPLD's have better pin to pin delays
<enriq>
I've read also FPGA is for making microprocessors and CPLD to replace logic chips
<awygle>
enriq: i'd hesitate to subscribe to use-based definitions. certainly FPGAs are for more things than just making microcontrollers.
<enriq>
why manufacturers don't publish the raw code in the datasheet? they don't profit from free tools anyway
<awygle>
if i understand correctly, "product terms" refers to the sum-of-products form of boolean logic. so the coolrunner for example has macrocells which are extremely wide AND gates (products), and then a programmable OR array which ORs (sums) the results of the macrocells
<enriq>
there is a videos of guys using coldrunner ii to make a simple calculator, I don't get how they manage to put that much in there
digshadow has joined ##openfpga
<enriq>
I guess I should stop chatting and buy some simple board to play with. How hard would it be to re purpose one of those coolrunner xbox thingies
<rqou>
you can, but that hasn't been written/debugged yet
<jn__>
i have an Altera USB Blaster (clone). it was cheap (5€) and it seems to work
<jn__>
(as a JTAG dongle)
<rqou>
yeah, but we don't have .jed to .svf written yet
<rqou>
you still need iMPACT
<rqou>
so enriq, you might be noticing that not everything works yet, and contributions are welcome :P
<enriq>
yeah, no problem :) but what do I need to play with openfpga as it is today
<enriq>
I can do some simple stuff right?
<enriq>
I download the code from git, buy some board (which one??) buy some "dongle" (which one?)
<rqou>
at this moment, you can only do single AND gates
<rqou>
that's all that's been tested to work
<enriq>
that's pretty cool
<awygle>
i have a bus blaster for jtag
<awygle>
it works fine, and it was free
<awygle>
rqou: how hard can jed to svf be? svf is pretty simple..
<rqou>
it just hasn't been coded yet
<awygle>
we need a big list of stuff like that
digshadow has quit [Ping timeout: 246 seconds]
teepee has quit [Ping timeout: 260 seconds]
openfpga-bb has quit [Ping timeout: 260 seconds]
brizzo has quit [Ping timeout: 240 seconds]
m_w_ has joined ##openfpga
brizzo has joined ##openfpga
m_w_ has quit [Client Quit]
<rqou>
damn, writing yosys passes is _hard_
<rqou>
it's so easy to make weird mistakes
m_w_ has joined ##openfpga
teepee has joined ##openfpga
enriq has quit [Ping timeout: 260 seconds]
openfpga-bb has joined ##openfpga
lexano_ has joined ##openfpga
lexano has quit [Ping timeout: 260 seconds]
m_w has quit [Ping timeout: 260 seconds]
scrts has quit [Ping timeout: 260 seconds]
m_w_ has quit [Quit: leaving]
scrts has joined ##openfpga
m_w has joined ##openfpga
balrog has quit [Ping timeout: 240 seconds]
<rqou>
hmm, yeah subtractors with borrow don't extract very well
<pie_>
rqou, its the fun part :D
<rqou>
anybody here know how to get yosys to prove two circuits are equivalent?
balrog has joined ##openfpga
<jn__>
o hi, pie_
<rqou>
pie_
<rqou>
the expert at shitposting :P
GenTooMan has quit [Remote host closed the connection]
<pie_>
well at least i can do that ':D
<pie_>
i need to shitpost myself to bed though
<pie_>
jn__, o/
<rqou>
hmm, so apparently i can prove combinatorial circuits equivalent by just naively dumping them into abc
<azonenberg>
Lol
<azonenberg>
abc produces a canonical form?
<rqou>
no, i created a super-module that compares the outputs
<rqou>
and abc successfully reduced the circuit down to a "1"
<azonenberg>
lol
<azonenberg>
That works :p
<rqou>
in general we need to make formal need fewer steps
<rqou>
or possibly even just less "wondering what to do next"
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
azonenberg_work has joined ##openfpga
scrts has quit [Ping timeout: 248 seconds]
scrts has joined ##openfpga
<openfpga-github>
[yosys] rqou pushed 9 new commits to master: https://git.io/v7yV0
<openfpga-github>
yosys/master 1e36e59 Robert Ou: recover_adder_core: Implement the $alu generation
<openfpga-github>
yosys/master 93dc009 Robert Ou: recover_adder_core: Initial commit...
<openfpga-github>
yosys/master 1afc71f Robert Ou: recover_adder_core: Generate $add/$sub in the simple case...
<rqou>
whee
<rqou>
ping azonenberg_work
<rqou>
now try and find bugs in it
<azonenberg>
Will look in a few
azonenberg_work has quit [Ping timeout: 255 seconds]
<azonenberg>
How do you use it?
<rqou>
after techmapping, just run recover_adder
<rqou>
oh yeah, it needs the uppercase cells, not the lowercase cells
<azonenberg>
explain?
<azonenberg>
do you have a techlib i need to use?
<rqou>
so for your addertest.json that you sent me
<rqou>
read_json addertest.json
<rqou>
techmap
<rqou>
recover_adder
<rqou>
show
<azonenberg>
Oh, that's easy enough
<rqou>
yeah, i should have been more clean
<rqou>
*clear
<rqou>
you need to techmap to the yosys "uppercase" cells, which is what "techmap" does by itself
<azonenberg>
Ah ok, yeah
<rqou>
subtractors don't work super reliably
<rqou>
often the upper bit(s) turn into something weird
<azonenberg>
ah
<azonenberg>
Awesome
<azonenberg>
I'm gonna try a test tomorrow that removes unused ports
<azonenberg>
and creates vectors from adder outputs
<rqou>
what are you working on right now?
<azonenberg>
Recompiling a bunch of antikernel stuff
<azonenberg>
then some non-research stuff
<rqou>
is the antikernel stuff also needed for your con talk?
<azonenberg>
Yesterday and today got taken up by makign a sales presentation for $WORK
<azonenberg>
Recompiling meaning, i need jtagd etc
<azonenberg>
:p
<rqou>
oh lol
<azonenberg>
Not doing dev
<rqou>
you should make a simpler jtag abstraction
<azonenberg>
It's as simple as it can reasonably be, i think
<azonenberg>
Anyway, tonight will be tinkering around with some ideas for removing unused ports
<azonenberg>
Just to remove clutter
<rqou>
i think i'm going to tinker with recovering "reduce" operations aka larger gates
<azonenberg>
Ok
<azonenberg>
oh also, on the bus/ferry home from work today
<azonenberg>
i started an outline of the con talk
<azonenberg>
i'll be doing more work on that tomorrow in the morning
<azonenberg>
Tomorrow afternoon is iOS exploitation training at work
<rqou>
lol
<rqou>
software
<azonenberg>
then saturday i'll be tidying up the house but hopefully have some time to do research
<azonenberg>
You've already done enough work to be named a co-author lol
<azonenberg>
This is great
<rqou>
btw your blinky that you have on your blog (the xc2 invasive attack blinky) doesn't turn into a 20-bit counter
<rqou>
ise isn't that smart
<azonenberg>
yeah i think i remember it was TFFs
<rqou>
it's TFFs, but the various count==0 generates a giant and gate
<azonenberg>
Surprise surprise
<azonenberg>
that may be the most efficient way to do it on coolrunner, honestly
<rqou>
although tbh yosys/abc couldn't simplify it either
<azonenberg>
anyway for the slide deck, what do you want your affiliation/title to be listed as?
<rqou>
the initial 18 bits are a chain of TFFs
<azonenberg>
"student, UC Berkeley"?
<rqou>
sure
<azonenberg>
Are/by september will you be a grad student?
<rqou>
next monday :P
<rqou>
yeah, which is why i'm trying to get all the shit done right now :P
<azonenberg>
Lol
<rqou>
anyways, while i was playing with the adder extraction
<rqou>
one observation i had is that we really need a way to tell the tool "no don't touch this part"
<azonenberg>
rqou: where is recover_adder in the yosys tree?
<rqou>
lol it's under techmap
<azonenberg>
There kinda is a way to do this but it's hard to do
<rqou>
sorry passes/techmap
<rqou>
even though this is tech-un-map :P
<rqou>
yeah, you can use the selection mechanism, but it _sucks_
<rqou>
especially when every net and cell is $foopass.cc$randomrandomrandom
<azonenberg>
lol
<rqou>
e.g the adder pass can create a bunch of two-bit adders
<rqou>
which i guess is not wrong, but not necessarily what you wanted
<rqou>
it does refuse to create one-bit adders
<rqou>
i was actually a little surprised initially that the giant (and totally dissimilar) gate piles really do reduce nicely back to adders
<azonenberg>
lol
<awygle>
anybody have a VPS recommendation other than Digital Ocean for cheap, wimpy stuff?
<mtp>
chunkhost
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
Guest40033 is now known as jayaura
jayaura is now known as Guest93461
<lain>
awygle: I had a vpn at vultr for a while, they have a 1 cpu 512mb ram 20gb ssd 500gb bandwidth instance for $2.50/mo, so half the cheapest DO droplet. I only ran it for a short while so I can't speak to reliability / uptime though
<lain>
I've heard vultr is unreliable but I didn't experience that myself in the ~4 months of uptime I used it
scrts has quit [Ping timeout: 240 seconds]
pie__ has joined ##openfpga
scrts has joined ##openfpga
pie_ has quit [Ping timeout: 260 seconds]
specing has joined ##openfpga
<openfpga-github>
[yosys] rqou pushed 1 new commit to master: https://git.io/v7yXD
<openfpga-github>
yosys/master aac4436 Robert Ou: recover_adder: Replace XOR3 and MAJ gates with structural Verilog...
pie__ has quit [Ping timeout: 240 seconds]
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
pie__ has joined ##openfpga
dohzer has joined ##openfpga
pie__ has quit [Ping timeout: 260 seconds]
specing has quit [Ping timeout: 240 seconds]
pie__ has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
m_w has quit [Quit: leaving]
scrts has joined ##openfpga
<rqou>
azonenberg: i can recover blinky.v
<rqou>
but it's not clear how general-purpose this will be
<rqou>
also, the order of passes definitely matters
<openfpga-github>
[yosys] rqou pushed 3 new commits to master: https://git.io/v7y7Y
<openfpga-github>
yosys/master 5b3b960 Robert Ou: recover_reduce: Add driver script for the $reduce_* recover feature
<openfpga-github>
yosys/master 1fd1eae Robert Ou: recover_reduce_core: Finish implementing the core function
<openfpga-github>
yosys/master 5a17c39 Robert Ou: recover_reduce_core: Initial commit
pie__ has quit [Ping timeout: 240 seconds]
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
wolfspraul has quit [Quit: leaving]
wolfspraul has joined ##openfpga
<openfpga-github>
[yosys] rqou pushed 3 new commits to master: https://git.io/v7yF0
<openfpga-github>
yosys/master 5ed0262 Robert Ou: recover_adder_core: Fix crash with ports with >1 bit
<openfpga-github>
yosys/master 6caf7f1 Robert Ou: Fix bug loading libraries when they are already loaded
<openfpga-github>
yosys/master fd83c69 Robert Ou: recover_tff: Add an extraction pass for toggle flip-flops
pie__ has joined ##openfpga
<rqou>
azonenberg: alright, i implemented both TFF extraction and $reduce_* extraction
<rqou>
bedtime
scrts has quit [Ping timeout: 248 seconds]
<openfpga-github>
[yosys] rqou pushed 1 new commit to master: https://git.io/v7yb4
<openfpga-github>
yosys/master 94da51f Robert Ou: recover_tff: Fix copypasta error
<qu1j0t3>
pie__: Why do such screencaps always look as if they've been passed hand to hand like chinese whispers, recompressed each time, so we see this iterated jpeg result
<qu1j0t3>
pie__: like, it's digital, why not just repeat what you received ;)
<qu1j0t3>
(or of course it could have been just one really really bad compression. just funny how often this happens.. the more popular memes the more they look like 40 year old benjamins)
digshadow has joined ##openfpga
<pie__>
right click -> save as doesnt exist in everyone's reality
<pie__>
alternatively, idk
<qu1j0t3>
pie__: Yeah something like that
scrts has joined ##openfpga
azonenberg_work has joined ##openfpga
azonenberg_work1 has joined ##openfpga
azonenberg_work has quit [Ping timeout: 240 seconds]
digshadow has quit [Ping timeout: 276 seconds]
scrts has quit [Ping timeout: 240 seconds]
m_w has joined ##openfpga
pie_ has joined ##openfpga
pie__ has quit [Read error: Connection reset by peer]
azonenberg_work1 has quit [Ping timeout: 248 seconds]
enriq has joined ##openfpga
scrts has joined ##openfpga
<enriq>
hey openfpga was mentioned at The Amp Hour podcast the other day
<enriq>
btw azonenberg_work have you seen you being mentioned at The Amp Hour
<azonenberg_work>
enriq: oh?
<azonenberg_work>
and re that thing, it looks like openocd supports it, not sure if ocd can program coolrunners but somebody's probably figured out a way to do it
<enriq>
I'll attempt a mac build of openfpga, I need what? cmake?
<azonenberg_work>
yes, cmake is our build system
<enriq>
hmm
<azonenberg_work>
youi'll also need a build of our Yosys fork (azonenberg/yosys)
<enriq>
cmake .
<enriq>
then run cmake .
<enriq>
?
<enriq>
or wha
<enriq>
not very used to cmake
<enriq>
ok yosys not found, cargo not found
<enriq>
I need to build yosys right? no bin avail
scrts has quit [Ping timeout: 246 seconds]
<enriq>
so the thing goes from verilog to RTL and then to the specific chip jed?
coino has joined ##openfpga
scrts has joined ##openfpga
scrts has quit [Ping timeout: 248 seconds]
scrts has joined ##openfpga
enriq_ has joined ##openfpga
Hootch has quit [Quit: Leaving]
enriq has quit [Ping timeout: 260 seconds]
enriq_ is now known as enriq
pointfree1 has quit [Read error: Connection reset by peer]
Guest40584 has quit [Ping timeout: 242 seconds]
pointfree1 has joined ##openfpga
teepee has quit [Ping timeout: 255 seconds]
enriq has quit [Ping timeout: 260 seconds]
teepee has joined ##openfpga
scrts has quit [Ping timeout: 246 seconds]
enriq has joined ##openfpga
enriq has quit [Client Quit]
enriq has joined ##openfpga
scrts has joined ##openfpga
azonenberg_work has quit [Ping timeout: 240 seconds]
Guest78256 has joined ##openfpga
azonenberg_work has joined ##openfpga
<openfpga-github>
[yosys] azonenberg pushed 1 new commit to master: https://git.io/v79mF
<openfpga-github>
yosys/master b778485 Andrew Zonenberg: Added opt_rmports pass (remove unconnected ports from top-level modules)
<azonenberg_work>
rqou: ok that's progress, this was another pain point
<azonenberg_work>
note that opt_rmports does not delete the floating wire connected to the port
<azonenberg_work>
it only removes the port and marks the wire not a port
<azonenberg_work>
So you have to do an opt_clean after that
<azonenberg_work>
rqou: also, any objections to me submitting a pull request for the current code?
<openfpga-github>
[yosys] azonenberg pushed 1 new commit to master: https://git.io/v79YK
<openfpga-github>
yosys/master a77f74a Andrew Zonenberg: Removed commented out debug code
<rqou>
the only problem is that there's a whole bunch of unrelated stuff
<rqou>
but you can submit it and see how unhappy clifford is
<azonenberg_work>
Lol
<azonenberg_work>
We can make a new fork and do several PRs at once if we have to
<azonenberg_work>
but let's send this first
<rqou>
yeah i was actually about to point that out
<rqou>
"40 commits ahead" isn't great
scrts has quit [Ping timeout: 276 seconds]
<azonenberg_work>
lol
<azonenberg_work>
Some of those are merges
<azonenberg_work>
But yeah, i should have at least done a PR to push the greenpak techlib updates first
<azonenberg_work>
Oh well
<enriq>
azonenberg_work the reverse engineering of xc2c32a-notes.txt is complete? i.e. I can program a xc2c32a by hand with that doc alone? (provided i get to understand it...)
<enriq>
oh sorry you're merging. forget it. some other day :)
<azonenberg_work>
enriq: Yes, the 32a is fully understood
<enriq>
good
<enriq>
I don't feel like learning verilog
<azonenberg_work>
The 64a is, i believe (rqou correct me if i am wrong) fully understood, except that we don't have the ZIA routing matrix figured out
<azonenberg_work>
enriq: um...
<rqou>
yeah
<azonenberg_work>
You really should :p
<rqou>
well
<azonenberg_work>
We know how to illegally get the data
<rqou>
there are some bogus Oe config values
<azonenberg_work>
We dont have a clean copy of it
<azonenberg_work>
And yeah, but we can make the device useful without them
<rqou>
they probably do nothing, but we don't really know for sure
<azonenberg_work>
They might be bus fights :D
<rqou>
um, i tested one and it behaved exactly the same as one of the other ones
<enriq>
I'd rather print A0 paper with the matrix, set red dots, and write the bits :)
<azonenberg_work>
enriq: lol
<azonenberg_work>
what, no focused ion beam on the flash array?
<azonenberg_work>
s/flash/EEPROM
<azonenberg_work>
i keep forgetting it's 2T eeprom
<rqou>
but anyways, to rephrase: we fully understand the 32a and can use all of its documented features and even some undocumented features. we cannot guarantee that we have found all undocumented features
<enriq>
and those xbox hack boards are the 32 model? you know?
<rqou>
those are 64as
<enriq>
uhhhhhh
<enriq>
that's a bigger paper
<azonenberg_work>
Lol
<enriq>
two A0
<rqou>
the only problem with the 64a is the missing interconnect map
<azonenberg_work>
Yeah
<rqou>
which can be obtained illegally from ISE
<enriq>
yes
<azonenberg_work>
or legally by taking SEM photos of the M3-M4 vias
<enriq>
so I but some 32 from ebay, i cannot get it locally
<enriq>
*buy
<azonenberg_work>
Which I hope to do in the not too distant future
<rqou>
you also need to go image the 384/512 still :P
<azonenberg_work>
rqou: i need to decap them first
<rqou>
i'm also sitting on an alleged xc95288xl that you didn't want me to send you
<azonenberg_work>
But getting this con talk out the road is my first priority
<azonenberg_work>
out the door*
<rqou>
btw i ran recover_tff on your gp4 blinky and it also finds a chain of TFFs the standard way
<rqou>
for the counters
<azonenberg_work>
yeah i've been testing on the blinky
<azonenberg_work>
Great to know that our code works on opposite architectures
<rqou>
the most surprising was still the adders
<enriq>
64a modules are way cheaper...
<azonenberg_work>
enriq: because there's a lot of xbox modchips out there
<azonenberg_work>
We want to support it
<azonenberg_work>
we just have a few things to get done first
<rqou>
azonenberg_work: what's io_3? it's an extremely-high-fanout reset?
<enriq>
well the board will take 2 months to be here
<azonenberg_work>
rqou: yeah, it drives the reset inputs to all of the counters
<azonenberg_work>
Which means it resets all of the TFFs
<rqou>
you didn't tell me about that :P
* rqou
should have read the code :P
<azonenberg_work>
The code is in the repo...
<azonenberg_work>
:p
<azonenberg_work>
I'm gonna do a non-resetting counter at some point too, but i want to add support for resets in the inference
<rqou>
also, xdot is awful with the high-fanout nets
<azonenberg_work>
Yes
<azonenberg_work>
i know :p
<azonenberg_work>
are you working on counter extraction btw/
<azonenberg_work>
?
<azonenberg_work>
or should i do that after i get back from work
<enriq>
if I learn to hack the 32, will that effort be useful to learn to hack the 64
<rqou>
i thought you were doing it?
<azonenberg_work>
rqou: i am planning t
<azonenberg_work>
to*
<azonenberg_work>
just making sure you're not duplicating effort
<azonenberg_work>
I did opt_rmports
<azonenberg_work>
earlier today
<rqou>
what else would you be considering doing?
<azonenberg_work>
then i want to do bus extraction too
<rqou>
ah, then i think i'll do counters
<azonenberg_work>
I was going to do them
<azonenberg_work>
Just not until after work :)
<azonenberg_work>
enriq: The 64 is almost identical to two 32s bolted together
<azonenberg_work>
the macrocell etc configuration is the same
<azonenberg_work>
the function block config is the same
<rqou>
but it lost the input-only special case, thank goodness
<enriq>
ok. So I learn the notes. Can I ask you questions about that
<azonenberg_work>
Yeah, they removed the input-only pin
<azonenberg_work>
then the ZIA is wider and has a new, unknown pattern we have to figure out
<azonenberg_work>
Other than that, the rest is the same
<rqou>
i already did that
<azonenberg_work>
rqou: i meant the rom
<rqou>
ah ok
<azonenberg_work>
we dont have a clean copy of
<rqou>
i did the mux bits already
<azonenberg_work>
enriq: Sure, you can ask me or rqou
<azonenberg_work>
i did the initial reversing then we worked together to figure out all of the remaining bits
<azonenberg_work>
So we probably know the chip better than anyone outside xilinx
<enriq>
1st question: ZIA is an old term for AIM ?
<azonenberg_work>
Yes
<azonenberg_work>
ZIA is a term that was inherited from the old coolrunner xpla3
<enriq>
yes, that's what google told me
<rqou>
which we could probably support if we _really_ wanted :P
<azonenberg_work>
xilinx changed the name to AIM in the cr-ii datasheets but all of the tooling still calls it ZIA internally
<azonenberg_work>
Which is what we use
<rqou>
if someone _really wants_ a 5v-tolerant cpld
<azonenberg_work>
rqou: yeah, lol
<azonenberg_work>
But i dont see it as a priority, we have greenpak for 5V tolerance
<rqou>
you don't do enough retrodev :P
<azonenberg_work>
I dont do any retrodev
<rqou>
i don't get why people keep using the xc9500xl though
<azonenberg_work>
no idea, it hogs power
<azonenberg_work>
xpla3 seems superior
<azonenberg_work>
or, for low voltage, cr-ii
<azonenberg_work>
xc9500 is a touch faster than xpla3 but i think cr-ii beats both
<azonenberg_work>
enriq: If you do actually manage to create a useful, nontrivial CPLD design by hand by poking jed files
<azonenberg_work>
i will be very impressed, lol
<rqou>
i just don't want to figure out how to code for p-term allocators
<enriq>
why
<rqou>
hey azonenberg_work my father used to do that back in the day
<azonenberg_work>
rqou: yeah but those were probably smaller cplds right?
<azonenberg_work>
enriq: actually...
<rqou>
mostly 22V10/20V8s actually :P
<enriq>
well, maybe I ask why because of ignorance
<enriq>
we'll see
<azonenberg_work>
Any chance you could send me the jed files for some of your test projects once you finish them? doesn't matter what the thing does
<azonenberg_work>
tl;dr for legal reasons, i need some coolrunner jed files that were not created by ISE
<enriq>
I'll use my ADC control as example, which is more or less trivial
<enriq>
enable V_input, wait cycles, enable V_ref, wait signal while counting, output the counter
<azonenberg_work>
Sounds easy enough
<enriq>
I could do it with CD4000 chips :)
<azonenberg_work>
But yeah, if you could send me the jed file plus a description of what it's supposed to do
<azonenberg_work>
by, say, the end of this month
<azonenberg_work>
that would be awesome
<enriq>
by august 31?
<enriq>
2017?
<enriq>
lol ok
<azonenberg_work>
The ultimate deadline is the third week of september
<azonenberg_work>
I have a conference presentation the 20th or so
<enriq>
I'll try to figure out how to wire the flip flops to make the 16 bit counter
<enriq>
that eats half chip
<azonenberg_work>
And I want to show off me and rqou's toolchain for analyzing coolrunner netlists
<rqou>
hint: use T-flip-flops :P
<azonenberg_work>
But the ISE license agreement says you're not allowed to reverse engineer the "data files generated by the software" which can probably be interpreted to include bitstreams
<azonenberg_work>
no idea how it would hold up in court
<azonenberg_work>
but if i had a jed file i could prove was not created by ISE, i'm clean
<enriq>
ahhh I love that idea
<enriq>
be cited in court
<enriq>
lol
<azonenberg_work>
Lol i'm hoping that if i mention in my slides that this was not an ISE-generated bitfile
<enriq>
where that would be? who would pay the tickets?
<azonenberg_work>
that i won't get sued in the first place :p
<enriq>
I'll keep the A0 paper
<azonenberg_work>
Lol
<azonenberg_work>
I mean its very unlikely anyone will care
<enriq>
now I have real pressure
<azonenberg_work>
But i want to cover my butt
<azonenberg_work>
In the meantime, i'm doing testing on greenpak parts
<enriq>
but they will ask me how did I write the jed, and I will cite your notes
<azonenberg_work>
In the unlikely event that i was sued perhaps
<azonenberg_work>
Hoping it wont come to that :)
<enriq>
haha
<azonenberg_work>
Anyway greenpak doesn't have any no-RE restrictions (plus i have an open source, working verilog toolchain)
<azonenberg_work>
So i can make as many test bitstreams as i want
<azonenberg_work>
and RE them without any legal issues
<rqou>
azonenberg_work: btw i just decided to waste some time again and looked at the xc9500 bitstream vs the xc9500xl bitstream
<rqou>
they're totally different
<azonenberg_work>
rqou: Lol
<enriq>
I'm from the old times, no internet times, you cannot imagine the things I did to be online
<azonenberg_work>
enriq: But it will make my talk a lot better if i can RE multiple devices' bitstreams using the same toolchain
<azonenberg_work>
Hence wanting to do coolrunner as it's a completely different architecture from greenpak
<azonenberg_work>
And really shows off the benefits of our IR-based reversing flow
<enriq>
cool
<rqou>
which is a surprisingly novel idea for some reason
<rqou>
hardware RE is way behind the times
<azonenberg_work>
rqou: have you seen any prior art using IRs for hardware RE?
<rqou>
not exactly
<azonenberg_work>
Did you look?
<rqou>
i didn't
<azonenberg_work>
we should probably do a literature survey at some point
<azonenberg_work>
awygle: poke
<azonenberg_work>
rqou: and i think it's because there are EEs who can code, and CS's who can use arduinos
<enriq>
this is the first time I hear someone opening chips to figure out things
<azonenberg_work>
But in general, the reason the EDA industry sucks is
<rqou>
i do remember seeing people do things like "throw giant several-kilobyte truth tables at logic optimizers"
<enriq>
the amphour show I linked earlier they talk about some extreme things I think
<azonenberg_work>
there are very few people who know actual software engineering
<rqou>
which isn't really an IR in any sense
<azonenberg_work>
and are also good at digital logic / RTL design
<enriq>
I'm software engineer
<enriq>
but not proven good at digital design
<enriq>
I did a few things in the prehistory with cmos chips
<enriq>
like 20 cmos chips
<enriq>
I used to think that software was going to be 10 times the fun, but it sucks
<azonenberg_work>
Lol
<azonenberg_work>
It's one thing to find people who know some software
<azonenberg_work>
But finding people who actually are good at large-scale system design, parallel algorithm, etc
<azonenberg_work>
and also know EE?
<azonenberg_work>
That's rare
<rqou>
um, berkeley has "EECS" rather than "CS" for a reason :P
<enriq>
at high school I got an electronic technician degree
<enriq>
but at the univ I studied CS
<enriq>
and I've been doing software for... em
<enriq>
oh
<enriq>
30 years
<azonenberg_work>
enriq: ok you have me beat
<azonenberg_work>
Lol
<azonenberg_work>
i've been doing C for 18 years
<enriq>
so now I'm senior at software but junior at EE
<rqou>
wait what
<azonenberg_work>
C++ for 16, and FPGA stuff for 7
<enriq>
I'm *old* rqou
<azonenberg_work>
rqou: i started learning C when i was 9, lol
<enriq>
my first computer was a C64 :)
<azonenberg_work>
By the time i'm 30 i'll have known C for more than 2/3 of my life
<azonenberg_work>
enriq: my first computer was a smith corona PWP-80
<rqou>
azonenberg_work: i did too, but i keep forgetting that you're almost 30 :P
<azonenberg_work>
after that an amd386 running win 3.1, dos 5, and borland C++
<azonenberg_work>
Clocked at a blazing 33 MHz with turbo to 40
<enriq>
that turbo button, amazing thing lol
<azonenberg_work>
rqou: and not for another 3 years
<enriq>
ok I'll get back home
<enriq>
stopping at the papershop for A0 paper lol
<enriq>
see you azonenberg_work , rqou
<rqou>
good luck!
enriq has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
scrts has joined ##openfpga
<rqou>
azonenberg_work: still wasting time a bit, the xc9500 and xc9500xl aren't actually _totally_ different
<rqou>
they're just arranged completely differentlyh
<rqou>
it might be interesting to RE this at some point just for MAME or whatever and then time how long the RE takes
<rqou>
just to tell people that it's not actually that hard (at least for CPLDs)
<azonenberg_work>
Hey, if we can make a front end for our flow that does them
<azonenberg_work>
i'd be down for it
<azonenberg_work>
Just don't have the motivation or time since i have higher priorities
<rqou>
i definitely don't want to do PAR though
<rqou>
although when i asked my father about it he told me "yeah, sometimes the tools just can't fit your design, and you're just screwed"
<azonenberg_work>
Lol
<azonenberg_work>
Also hmm
<azonenberg_work>
my current flow is breaking on my greenpak adder test
* azonenberg_work
investigates
<azonenberg_work>
opt_rmports is optimizing out my adder
<azonenberg_work>
welp
<azonenberg_work>
guess its not ready to go yet :p
<lain>
lol
<rqou>
oh, did you screw up multi-bit wires too? :P
<rqou>
don't worry, i actually got a crash when i messed this up in my code :P :P
awygle_m has joined ##openfpga
<azonenberg_work>
i think i may have
<azonenberg_work>
Time to find out
<awygle_m>
azonenberg_work: the "poke" equivalent of "pong"
<rqou>
is it just me or are the PLA parts much better documented in general than the PAL parts?
<azonenberg_work>
Yes they are
<azonenberg_work>
awygle_m: New thing for you to look into
<azonenberg_work>
Shorter term priority, if possible
<rqou>
cr-ii has all sorts of appnotes, whitepapers, etc.
<rqou>
9500/9500xl has nothing
<azonenberg_work>
Can you try to find papers on circuit reverse engineering using an intermediate representation?
<azonenberg_work>
something akin to llvm ir for hardware
<awygle_m>
I have some time tonight/tomorrow that I could spend on that, sure
scrts has quit [Ping timeout: 240 seconds]
<rqou>
alright, i'm going to stop wasting time now
<awygle_m>
The "prior art" section for your talk essentially?
<azonenberg_work>
awygle_m: exactly
<awygle_m>
Mk, wilco. Probably later this evening + tomorrow. Anything you're already aware of?
scrts has joined ##openfpga
<azonenberg_work>
No
<azonenberg_work>
But i figure if anything exists we should cite it :p
<awygle_m>
Sure sure :-P
<azonenberg_work>
Anything regarding higher level circuit RE would be of interest too, either to cite or to implement/use
<azonenberg_work>
basically, something that tries to find higher level structures in a netlist
<azonenberg_work>
like adders or counters or state machines or whatever
<azonenberg_work>
But IR-based techniques are the main prirotiy
<awygle_m>
Gotcha
<awygle_m>
rqou: sure Berkeley has EECS but I at least felt like I wanted to go through the program 2 or 3 times so I could actually get both sides
<awygle_m>
Fortunately(?) I focused on CS in school and then worked as mostly an EE for the next 5 or so years so I feel decently balanced
<awygle_m>
But yeah, not convinced "graduated from EECS" means "actually good at both" lol
<openfpga-github>
[yosys] azonenberg pushed 1 new commit to master: https://git.io/v79l4
<openfpga-github>
yosys/master 3dfe2b2 Andrew Zonenberg: opt_rmports: Fixed incorrect handling of multi-bit nets
<azonenberg_work>
Welp
<azonenberg_work>
Fixed :p
<azonenberg_work>
rqou: So i guess tonight i'm gonna try and get TFF counter extraction working tonight
<pie_>
azonenberg_work, pretty sure normal compiler style optimization would suffice, i mean it doesnt need to be hardware specific
<pie_>
but im just talking out of my butt
<pie_>
this sounds like something people usually say to implement an optimizing compiler for
<pie_>
youre "just" goin from a lower level target to a higher level one
<pie_>
you know what. that probably makes no sense.
<pie_>
its 'just' program analysis :P
<azonenberg_work>
Yeah exactly
<azonenberg_work>
many of the algorithms are based on those used for synthesis
<azonenberg_work>
But i'm wondering, has anyone ever tried using them for RE?
<azonenberg_work>
That looks like decompilation for a DSP
<azonenberg_work>
similar, but not useful
<pie_>
ehh well looks like its just normal program code stuff
<pie_>
yeah
* pie_
jumped the gun :P
<pie_>
azonenberg_work, conceptually you have a metric fuckton of gates which you need to find higher structure in?
<azonenberg_work>
pie_: Yes
<azonenberg_work>
:p
<azonenberg_work>
So far we can find shift registers and adders, and i'm going to work on counters
* pie_
ponders
* pie_
ponders boolean expressions
<azonenberg_work>
Related problems: trying to guess hierarchial module boundaries (possibly based on min-cut or something?
<azonenberg_work>
creating an interactive GUI for both schematic and HDL views
<azonenberg_work>
that lets you name signals etc
<pie_>
so i have a terrible idea
<azonenberg_work>
creating buses
<azonenberg_work>
etc
enriq has joined ##openfpga
enriq has quit [Client Quit]
<pie_>
compile high level structures to boolean expressions (perhaps with some post-processing) and match truncated subtrees on the original AST
<pie_>
ah well actually i guess that would only work for combinatorial logic in this form
<pie_>
ive been fucking with something similar to wht i jsut said but then i gave up because i couldnt find a non-shit javascript parser for python >_> you may remember.
<pie_>
so for sequential logic, something something subgraph isomorphism?
<pie_>
'Starting with the UNIX pattern-matching, text processing tool awk as a model, a pattern-action netlist processing environment was built to test the concept of writing CAD tools by specifying patterns and actions. '
<pie_>
rqou, ( azonenberg_work ): "Formal Methods for Reverse Engineering Gate-Level Netlists" "Wenchao Li" "Electrical Engineering and Computer Sciences University of California at Berkeley" "December 18, 2013" https://www2.eecs.berkeley.edu/Pubs/TechRpts/2013/EECS-2013-222.pdf