<rqou>
seems to somehow cause random keypresses to get spammed
<rqou>
but it _does_ end up printing "Detected empty SLG46620V"
<rqou>
so it kinda works?
<rqou>
(needs root btw; both of these do at least for now)
<rqou>
this is interesting that at least my phone's kernel does have hidraw
coino has quit [Ping timeout: 276 seconds]
azonenberg_work has joined ##openfpga
specing has joined ##openfpga
_whitelogger has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
test123456 has joined ##openfpga
Hootch has quit [Ping timeout: 260 seconds]
Hootch has joined ##openfpga
_whitelogger has joined ##openfpga
<rqou>
arrgh, yet another android bug
<rqou>
setting the password doesn't work when rooted
qu1j0t3 has quit [Ping timeout: 260 seconds]
<rqou>
heh, mobile vulkan drivers are shitty
qu1j0t3 has joined ##openfpga
scrts has quit [Ping timeout: 276 seconds]
m_t has joined ##openfpga
scrts has joined ##openfpga
_whitelogger has joined ##openfpga
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
specing has joined ##openfpga
m_t has quit [Quit: Leaving]
teepee has quit [Ping timeout: 260 seconds]
teepee has joined ##openfpga
_whitelogger has joined ##openfpga
specing has quit [Ping timeout: 260 seconds]
scrts has quit [Ping timeout: 240 seconds]
specing has joined ##openfpga
scrts has joined ##openfpga
clifford has joined ##openfpga
http_GK1wmSU has joined ##openfpga
http_GK1wmSU has left ##openfpga [##openfpga]
test123456 has quit [Ping timeout: 260 seconds]
test123456 has joined ##openfpga
digshadow has quit [Quit: Leaving.]
specing has quit [Ping timeout: 246 seconds]
ZipCPU_ has joined ##openfpga
ZipCPU has quit [Ping timeout: 246 seconds]
ZipCPU_ is now known as ZipCPU
specing has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
Hootch has quit [Ping timeout: 268 seconds]
Hootch has joined ##openfpga
scrts has joined ##openfpga
Hootch has quit [Ping timeout: 268 seconds]
Hootch has joined ##openfpga
Hootch has quit [Remote host closed the connection]
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
test123456 has quit [Quit: Leaving]
test123456 has joined ##openfpga
test123456 has quit [Remote host closed the connection]
test123456 has joined ##openfpga
test123456 has quit [Remote host closed the connection]
scrts has quit [Ping timeout: 276 seconds]
scrts has joined ##openfpga
coino has joined ##openfpga
* coino
o/
coino_ has joined ##openfpga
coino has quit [Ping timeout: 276 seconds]
coino_ has quit [Ping timeout: 240 seconds]
coino_ has joined ##openfpga
<pointfree>
o/ coino_
<coino_>
0/
<coino_>
|0| [are you still there]
<coino_>
[now you're thinking with portals]
<pointfree>
So there's a #PSoC channel, everybody. coino_ and myself are in it.
coino has joined ##openfpga
coino_ has quit [Ping timeout: 240 seconds]
d33pb00k-GK1wmSU has joined ##openfpga
d33pb00k-GK1wmSU has left ##openfpga [##openfpga]
scrts has quit [Ping timeout: 268 seconds]
scrts has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
coino has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
<azonenberg>
pointfre: hey, quick question for you
<azonenberg>
if you're around?
<balrog>
pointfree: ^
<pointfree>
azonenberg, balrog: Hello!
<azonenberg>
pointfree: so, where do we stand on psoc stuff?
<azonenberg>
in particular, if i wanted you to write an app that converted a PSoC UDB configuration (in any format you want - raw dump, ELF, source code register list, whatever)
<azonenberg>
into a Yosys JSON netlist
<azonenberg>
how hard would that be?
teepee has quit [Ping timeout: 255 seconds]
<cyrozap>
azonenberg: That's what I was (kind of) working on
<cyrozap>
The problem right now is there's no documentation on the JSON netlist format.
pie___ has quit [Read error: Connection reset by peer]
<cyrozap>
But all the PSoC-related info is there.
<cyrozap>
Ironically :P
<azonenberg>
Lol
pie_ has joined ##openfpga
<azonenberg>
cyrozap: well if you could get me something in the next week or so that would be extremely helpful, if not then end of the month (i'll be AFK from the 15th to the 27th, mostly, on a camping trip)
<cyrozap>
azonenberg: Any particular reason for the deadline? Conference talk?
<azonenberg>
Yes - the talk is on FPGA/CPLD bitstream RE, the week of Sept 17th
<azonenberg>
I'm on vacation Aug 15-27 with limited to no internet access
<azonenberg>
then possibly onsite with a client Sept 28-8
<azonenberg>
leaving me only ~2 weeks of research plus whatever i can squeeze in around the vacation and work travel
<azonenberg>
it's on bitstream RE using an IR-based flow
<azonenberg>
so bitstream -> native cell library in yosys -> techmap with cells_sim library to give RTLIL -> optimize netlist -> perform coarse-grained extractions of shift regs, adders, counters, etc -> export verilog
<azonenberg>
If time permits i'd love to have front ends for greenpak4, ice40, coolrunner2, and psoc5
<rqou>
wow, an IR-based flow! how amazing! /s
<rqou>
you mean hardware RE isn't just done with spreadsheets, graph paper, and schematics?
<rqou>
:P
teepee has joined ##openfpga
<pie_>
IR?
<azonenberg>
intermediate representation
<pie_>
oh right
<azonenberg>
i want to be able to do all of the high-level analytics once
<azonenberg>
not for every cell library
<pie_>
how does this work
<rqou>
oh i forgot. hardware RE actually has modernized. we now have inkscape as well :P
<pie_>
rqou, xD
<qu1j0t3>
if u can't do it with PowerPoint is it worth doing
<rqou>
i mean, powerpoint _does_ have OLE...
<pie_>
i mean im reading your -> thing but im not getting it :P
<azonenberg>
pie_: So once we know how the bitstream works
<rqou>
qu1j0t3: "i bet you sales guys even browse the web in powerpoint" (really obscure reference)
<rqou>
damn ninja'd
<azonenberg>
it's straightforward to load a bitstream and export it to a netlist in Yosys's JSON format, right?
<pie_>
rqou, omg.
<pie_>
synchronized
<pie_>
rqou, i rewatched these like..yesterday
<azonenberg>
just a conversion between two identical representations of the same circuit
<pie_>
damn whole world is synced
coino has joined ##openfpga
<pie_>
azonenberg, but i thought bitstreams were like encrypted or something
<pie_>
err wait thats not even the problem
<pie_>
i thought the problem was REing the bitstream?
<azonenberg>
pie_: so first off, most bitstreams are not encrypted (a lot of chips don't support it, for those that do many people don't use it)
<azonenberg>
second, for the devices i've mentioned the bitstream format has already been RE'd
<azonenberg>
so now i'm working on the bigger problem, which is how to turn a bitstream into actionable intelligence rather than a pile of unsorted gates
<azonenberg>
Anyway, so after this first step we now have a netlist that is, effectively, the output of synthesis on the original source code (with symbols stripped)
<azonenberg>
i.e. it is logically equivalent to the original code, using the target device's native cell library
<coino>
azonenberg, how close is xcos to hdl
<azonenberg>
coino: xcos?
<coino>
oh dear
<azonenberg>
pie_: Basically the algorithm is
<awygle>
coino: if you're talking about what i think you are - not.
<awygle>
the simulink-esque thing?
<coino>
xcos is the open source simulink
<pie_>
oh wait you mean bitstream RE like "assembly -> source code"?
<azonenberg>
pie_: So, this step is the equivalent of disassembly
<pie_>
not bitstream re as in what bit does what on the chip
<azonenberg>
ELF -> big pile of opcodes
<awygle>
bitstream file RE not bitstream file format RE :P
<azonenberg>
Correct
<coino>
why do people use that smiley
<azonenberg>
Anyway, once we have the 'disassembly' done, in a machine-readable format
<coino>
it triggers me
<azonenberg>
the next step is to load it into Yosys, along with a behavioral Verilog model of each of the cells in the library
<pie_>
oh well that was my main point of confustion then xD
<azonenberg>
Use the "techmap" command to replace each cell with the model
* pie_
listens
<coino>
pie are you gen z
<pointfree>
cyrozap, azonenberg: I'm rather unfamiliar with the yosys flow and preoccupied with my on-chip JIT logic synthesis. Let me know if you stumble upon unexpected errors or have any questions regarding: https://hub.darcs.net/pointfree/psoc-tabular I would welcome someone else helping with the yosys portion.
<azonenberg>
Then optimize to clean all of the redundant stuff out
<azonenberg>
At this point, we have a *technology independent* netlist that is equivalent to the original
<azonenberg>
Which is basically what you'd have after synthesis but before techmapping to the target cell library
<pie_>
ok, i think i understand mostly.
<azonenberg>
I have this part mostly working, i need to finish support for a few primitives in greenpak
<rqou>
the power of cells_sim.v!
<pie_>
thanks for explaining
<azonenberg>
So from now on, the goal is twofold
<azonenberg>
first, add support for going from other devices to this level of abstraction
<azonenberg>
Since the bitstream formats for (smaller) coolrunner-2, ice40, greenpak4, and psoc5 UDBs are all known at this time, it should be straightforward, just a question of findign time and debugging it
<coino>
azonenberg, how often do you explain the roadmap
<azonenberg>
Second, increase the level of abstraction
<azonenberg>
coino: This part is not documented anywhere b/c it's prep for an upcoming con talk
<azonenberg>
the bitstream RE stuff is pretty much my own research
<azonenberg>
i'm just asking the folks on the individual chips' teams to write importers
<rqou>
if you were in las vegas in meatspace you would have heard the roadmap :P
<pie_>
"low-level thinking in high-level shading languages"
<azonenberg>
coino: Down the road, i want to make a flow with a feedback loop, where you can add hierarchy etc to the netlist, name signals, etc
<azonenberg>
Like IDA
<azonenberg>
But the first step is to demonstrate the flow
<azonenberg>
OOook so next step is to refactor cells_sim as previously discussed
<cyrozap>
azonenberg: I can't guarantee I'll have anything done by the end of the month, since I really only do this work when I feel inspired to, and I'm currently occupied by another project. If I do manage to get something done, I've mostly been ignoring the datapath elements, so anything I'd make would just do PLDs + Macrocells + UDB interconnect + (maybe) DSI stuff for pin I/O.
<azonenberg>
cyrozap: That would be better than nothing
<azonenberg>
But if you cant finish it, not a problem
<azonenberg>
It will just make my talk better if I can show off more chips supported
<awygle>
azonenberg: is the yosys json format an alternative to BLIF, or does it fill a different role?
<azonenberg>
It's a netlist interchange format similar to blif that can be more easily parsed by commonly accessible parsers, and is far more human readable
<rqou>
idk about the human-readable part
<rqou>
it's full of magic net indices
<awygle>
mk, just checkin', thanks
<azonenberg>
rqou: more readable than blif
<azonenberg>
IMO
<rqou>
maybe. i've never actually looked at blif
<azonenberg>
rqou: look it up
<azonenberg>
its pretty awful
<azonenberg>
:p
<azonenberg>
awygle: and we chose to use that format b/c we were already using json as the intermediate between synthesis and PAR in the forward design flows
<azonenberg>
So it seemed logical to use it for un-synthesis as well
<awygle>
azonenberg: just in gp4par/xc2par? or in the icestorm flow as well?
<azonenberg>
I don't know what the intermediate format for icestorm is
<rqou>
it's blif
<azonenberg>
ah, ok
<azonenberg>
eew :p
<rqou>
i think only our flows use json
<awygle>
that's what i thought. ok makes sense
<rqou>
or maybe it was edif?
<pie_>
> people looking down on json
<pie_>
>> still better than blif!
<rqou>
json is fine as long as you don't care too much about corner cases
specing has quit [Ping timeout: 240 seconds]
<awygle>
json makes me sad inside but i've accepted it. like python.
<rqou>
iirc json parsers have had lots of "fun" with inputs like a number that overflows the variable
<rqou>
different parsers would return different answers
<rqou>
which is always good for finding sploits
<openfpga-github>
[yosys] azonenberg pushed 1 new commit to master: https://git.io/v7rWi
<openfpga-github>
yosys/master b735a0f Andrew Zonenberg: Refactored GreenPAK4 cells_sim into cells_sim_ams and cells_sim_digital
<pie_>
oh goodness...these slides just reminded me that floating point numbers are hard kthx...
specing has joined ##openfpga
<azonenberg>
rqou: so here we are, with the cells_sim i have now (i.e. counters not fully implemented)