<openfpga-github>
[openfpga] azonenberg pushed 1 new commit to master: https://git.io/vQ94T
<openfpga-github>
openfpga/master 353707d Andrew Zonenberg: Added bitstream reading support for abuf, flipflop, pwrdet, POR
eduardo_ has joined ##openfpga
eduardo__ has quit [Ping timeout: 260 seconds]
digshadow has joined ##openfpga
<openfpga-github>
[openfpga] azonenberg pushed 1 new commit to master: https://git.io/vQ9BB
<openfpga-github>
openfpga/master e47ccc4 Andrew Zonenberg: Added bitstream loading support for bandgap, clock buffer, and DCMP mux
<openfpga-github>
[openfpga] azonenberg pushed 1 new commit to master: https://git.io/vQ9Ru
<openfpga-github>
openfpga/master 766dc7a Andrew Zonenberg: PGA: added bitstream loading support
<rqou>
azonenberg: "in greenpak devices it's possible for one net num to correspond to multiple logical HDL ports depending on device configuration"
<rqou>
what does this mean?
<azonenberg>
Bitstream config can change the port name
<azonenberg>
So, for example
<azonenberg>
GP_DFF Q and nQ are the same routing path
<azonenberg>
there's a 2:1 mux on the DFF output
<rqou>
can't you just model it as a mux instead?
<azonenberg>
So if i have a signal sourced by the DFF, i have to look at the mux bit to see if the signal is coming from the Q or nQ output
<azonenberg>
It works fine for synthesis
<azonenberg>
It's only a problem going the other way
<rqou>
oooh i see
<rqou>
doesn't coolrunner2 have that too with DFF/TFF/latch?
<azonenberg>
possibly. but i'm only working on gp4 so far
<rqou>
also the xor output
<azonenberg>
i'm implementing all of the Greenpak4*::Load()
<azonenberg>
blocks
<rqou>
btw at mtvre somebody asked about bitstream->netlist for some ancient xilinx fpga (pre-xc4000)
<azonenberg>
Most likely what i'll do is add an arg to GetOutputPorts() to make it filter and only return ports that are valid in the current device configuration
<rqou>
apparently the bitstream is known, there's just no tools for what to do next
<azonenberg>
Then i just have to figure out how to load that config
<azonenberg>
Ooh
<azonenberg>
I may be interested in helping with that
<azonenberg>
Short term my targets are gp4, cr2, ice40, s3a
<azonenberg>
in that order
<azonenberg>
for RE
<azonenberg>
i'm going to try to lift them all up to RTLIL
<azonenberg>
then write analytics as yosys passes
<rqou>
while you're working on it, you might want to keep in mind things like uncommitted logic arrays
<rqou>
iirc mame is stuck with a few of those
oeuf has joined ##openfpga
<azonenberg>
So, the eventual plan
<azonenberg>
is to make something that can convert die photos to json netlists as well
<azonenberg>
and then use the same RTLIL-based analytics flow from there on
<azonenberg>
There will most likely be one importer for standard cell CMOS SEM photos
<azonenberg>
one for standard cell CMOS optical photos
<azonenberg>
and we could make one for gate array optical photos too
<rqou>
is there a "state of the art" subcircuit extraction algorithm that actually works?
<azonenberg>
Dont know
<azonenberg>
i'm focusing on getting some bitstream, any bitstream (slg46620 to start) into RTLIL
<azonenberg>
there have been calls for impeachment before
<azonenberg>
but this is the first time anyone has actually submitted a formal written article to the house
<cyrozap>
balrog: To answer your question from earlier, I've only really just started up on this again. I started working on a bitstream->Verilog parser for the whole CPLD (including the interconnect and DSI, not just the UDBs), but by that I mean I've literally just copied my old code into a new file :P
<rqou>
ugh, more trump news
<azonenberg>
cyrozap: rather than going to verilog
<azonenberg>
Can you make it export to a yosys json netlist?
<azonenberg>
that's a much more useful, machine-readable format
<azonenberg>
Which can be easily converted to verilog by yosys should you so desire
<rqou>
why does it seem like all PAR research is canadian while all subcircuit extraction research is taiwanese? :P
<azonenberg>
did you look at names on those papers?
<azonenberg>
hypothesis: it's one university research group for each
<rqou>
hmm yeah the subcircuit extraction papers are all by the same group of people
<rqou>
didn't look too closely at the PAR papers
* azonenberg
is going to get some sleep
<rqou>
already?
<azonenberg>
yeah i have work in the morning and i'm getting tired
<cyrozap>
azonenberg: Sure, that'd probably be easier for me to generate, anyways. I just went with Verilog at the beginning because that's the format I know.
<azonenberg>
Making good progress
<rqou>
ahh finally found a "reasonably common" referenced algorithm for subcircuit extraction that happens to _not_ be taiwanese :P
<rqou>
SubGemini
<azonenberg>
I now have bitstream->in memory netlist for everything but some IOBs (there's two encodings and i only wrote a parser for one), counters, shift regs, acmps, dcmps, dcmpref's, dacs, delay lines, one clock buffer type, oscillators, reset, and SPI
<azonenberg>
As well as a JSON exporter that creates the top level structure of the file but not any of the actual circuit stuff yet
<azonenberg>
I'll be AFK all weekend for a SAR training event
<rqou>
lots of people hacking on this problem apparently, but not all specialized for circuits
<azonenberg>
but hope to get a bit more coding done this week, we'll see
<cyrozap>
balrog: Anyways, my immediate goal is to develop some scripts to dump the PSoC config registers (via OpenOCD) and convert that dumped config into a nicer format (i.e., an ELF file with sections for each of the major config regions).
<rqou>
azonenberg: we need a private-ish (so no copyright problems) notes dumping ground
<cyrozap>
balrog: The next step will then be to actually write the config-to-yosys-json-netlist code.
<cyrozap>
azonenberg: Is there a spec for the Yosys JSON netlist format? Or is it just a "read the source" kind of thing?
<rqou>
afaik it's "read the source"
Hootch has joined ##openfpga
<rqou>
digshadow: apparently some h8 mcus also have a similar warning about their mode pins
<rqou>
your turn to try the same exploit?
scrts has quit [Ping timeout: 240 seconds]
qu1j0t3 has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
<rqou>
azonenberg: something is weird with the xc2c512s i've obtained
<rqou>
the top markings are identical but the bga substrate is different colors
<rqou>
please make sure to take high-res photos before decapping
scrts has quit [Ping timeout: 255 seconds]
scrts has joined ##openfpga
qu1j0t3 has joined ##openfpga
_whitelogger has joined ##openfpga
scrts has quit [Ping timeout: 276 seconds]
scrts has joined ##openfpga
clifford_ has quit [Ping timeout: 260 seconds]
deep-book-gk_ has joined ##openfpga
deep-book-gk_ has left ##openfpga [##openfpga]
scrts has quit [Ping timeout: 260 seconds]
m_t has joined ##openfpga
scrts has joined ##openfpga
<indy>
hi all, can i attach icestick directly to fx3/fx2lp?
<indy>
i want to play with fx2/fx3 fifo examples and yosys/arachne-pnr/icestorm
<pointfree>
balrog, cyrozap: I feel I'm almost done with an on-chip spnr tool for the PSoC 5LP.
<pointfree>
I wrote it mostly on an airplane trip.
<balrog>
pointfree: wow :)
<pointfree>
Thanks to the logic fabric's conveniently regular structure it may just fit in a tweet -- that includes synthesis, placement, and routing of the primitives AND, OR, NOT but not the portpin mappings.
<balrog>
...darn
<pointfree>
The portpin mappings don't really follow a regular pattern so much.
<pointfree>
These are Forth (glue) words and I'll use them for implicit parallelism in a forth, but the functions could of course be translated to other languages for embedding logic spnr into a project.
<pointfree>
Before release I'd like to tweak the code to leverage the PSoC's short circuit routing -- something that the SoftJin tools used by Cypress don't seem to leverage at all.
<pointfree>
That means smaller bitstreams than the proprietary tools but more importantly I think leveraging the short circuit routing will mean faster routes without the overhead of timing characterization.
<pointfree>
I've been a bit distracted by the PSoC5LP's Digital Filter Block and the UDB Status & Control blocks. The latter I pretty much understand, the former not so much. I'm still trying to get a picture of how I would use everything from the DFB in a project. I don't have much experience with DSP's.
<pointfree>
The newfangled crosshairs in the diagram won't crash your browser :) But the coordinates are only correct when the page is not zoomed or zoomed out. I should put this into an svg image and that into a leafletjs map for easier searching and browsing but I'm not really prioritizing that right now.
m_t has quit [Quit: Leaving]
azonenberg_work has quit [Ping timeout: 258 seconds]
digshadow has quit [Quit: Leaving.]
azonenberg_work has joined ##openfpga
<azonenberg_work>
pointfree: Wasnt following the entire conversation
<azonenberg_work>
but if i'm following this
<azonenberg_work>
you think you can get better QoR than the official cypress toolchain?:D
amclain has joined ##openfpga
<azonenberg_work>
LOL ylamarre's CPLD RE project was codenamed "poutine"
<azonenberg_work>
I knew he was working on it but... not the codename
<pointfree>
azonenberg_work: Yes. I deleted parts of a bitstream and it still worked.
<pointfree>
Cypress uses stock SoftJin placement and routing tools that were probably designed for mux-style cplds and fpgas and therefore don't take advantage of the short-circuit routing. The short-circuiting is even mentioned briefly in the patent.
<azonenberg_work>
lol so they put all of this stuff in the silicon
<azonenberg_work>
and dont use it?
<azonenberg_work>
Typical HW/SW team siloing
azonenberg_work has quit [Quit: Leaving.]
azonenberg_work has joined ##openfpga
<azonenberg_work>
back
<azonenberg_work>
pointfree: what was last you got from me?
<azonenberg_work>
Cell reception on the water is spotty
<pointfree>
azonenberg_work: "Typical HW/SW team siloing"
<pointfree>
azonenberg_work: "Cell reception on the water is spotty"
<azonenberg_work>
ah ok yeah that wsa all i sent
<azonenberg_work>
Boat is docking in a few mins so will have to run off and pack up my laptop in a min or two anyway
<balrog>
pointfree: hah. I'm not surprised at all
scrts has quit [Ping timeout: 276 seconds]
azonenberg_work has quit [Ping timeout: 246 seconds]