<pie_> rqou, ?
<rqou> infamous uc berkeley professor who teaches compilers and loves parsing
<rqou> and wrote bison's GLR skeleton
<pie_> oddly enough "hilfinger parsing" doesnt give any useful google results
<rqou> nah, you needed to have attended berkeley to know about this :P
* pie_ sighs
<awygle> oh yeah rqou, what system did they build that's worse than telebears?
<rqou> basically it has the same quirks as telebears but now with a web 2.0 theme
<awygle> is it still a phone tree hooked up to a modem hooked up to a web frontend?
<rqou> i hope not
<awygle> that's what telebears was when i was there
<rqou> i hope they've at least fixed the problem of overflowing your virtual punch card deck
<rqou> but basically they web 2.0-ifyed the look and now it's even less intuitive to use
<rqou> the weird phase 1/phase 2/adjustment is still here, as well as CCNs
<awygle> so glad to be out of college, no lie
<rqou> hmm, i didn't dare to test it but maybe the back button is fixed/less broken now?
pie_ has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
scrts has quit [Ping timeout: 246 seconds]
<pie_> wow CLRS doesnt mention parse/parsing even once
scrts has joined ##openfpga
<pie_> ok i take that back the word parse is there 4 times in a seemingly unrelated topic
specing has quit [Read error: Connection reset by peer]
<pie_> qu1j0t3, i should have a pdf but i forgot the name agian, what was the book about functional computer architecture? yknow lispy mahcines or something
<pie_> prolog machines
<pie_> etc
<qu1j0t3> pie_: The Architecture of Symbolic Computers, Peter Kogge
<pie_> yes thanky
<pie_> i kept searcing for functional >_>
<pie_> huh? whats this? http://www.loper-os.org/?p=1871
<jn__> "the informal NSA ban on the manufacture of LinuxBIOS-capable x86 CPUs"?! i gotta ask ron about this
<balrog> loool
<balrog> also lol complaining about lead free solder when using an iron at 250C?
<balrog> 250C is low
<balrog> *even for leaded*
<pie_> jn__, do mention later :P
<rqou> working on it! :P
<balrog> rqou: much FIXME
<azonenberg> lol yes
<azonenberg> the solder only melts at 219C
<azonenberg> i usually set my iron to 300-350 depending on how heavy the thing i'm soldering to is
<balrog> yup
<azonenberg> rqou: yay
* azonenberg is almost done with the greenpak bitstream loader
<balrog> azonenberg: what solder do you generally use? I've probably asked already
<azonenberg> then have to do the json export
scrts has quit [Ping timeout: 240 seconds]
<balrog> here, no-clean-flux SAC305
<azonenberg> Same here
<balrog> people who have only used crap lead-free before are like "wut, lead-free???"
<balrog> and then try it and then are like "oh it's not so bad"
<rqou> azonenberg: how do you want to represent vref/cgnd?
<rqou> silly idea: a CGND primitive that only has one output port
<rqou> the sim model outputs a constant 0
<rqou> and the PAR will detect it and set connected pins to CGND mode
<azonenberg> I dont think there is any way to CGND a single pin, right?
<azonenberg> don't you do it to the entire chip's unused pins?
<rqou> um, yeah you can?
<azonenberg> oh?
<azonenberg> i meant not in the bitstream
<azonenberg> but in HDL
<azonenberg> using the xilinx flow
* cr1901 probably receives the recommended yearly dose of lead mandated by the state of California in one soldering session
<rqou> i think the xilinx flow can cgnd individual pins in the ucf
<rqou> not in HDL
<azonenberg> ah ok
<azonenberg> In that case how about we only do it by constraints then?
<azonenberg> i see no reason to do it in HDL
<rqou> why not? it'd be kinda funny
<azonenberg> From a RE perspective, i don't care about distinguishing CGND from simply driving 1'b0
<rqou> and now you wouldn't need a ucf
<azonenberg> i dont even know if there's a difference
scrts has joined ##openfpga
<azonenberg> other than leaving the macrocell logic less utilized
<azonenberg> i think it's just a "ignore data going into IOB, drive zero no matter what"
<azonenberg> So for RE, we can treat them as indistinguishable
<rqou> afaik you can _still_ use the macrocell on a cgnd pin
<azonenberg> Correct
<azonenberg> hence "leaving the logic less utilized"
<azonenberg> but no difference in the actual buffer
<azonenberg> so for RE we don't care
<rqou> i know for RE you don't care, but for synthesis it'd be nice to not have to mess with a separate constraints file
<azonenberg> How about just (* CGND = "1" *) output wire foo;
<rqou> does that work?
<azonenberg> you might have to assign foo=0 to make synthesis not optimize it out or something
<azonenberg> but yeah
<azonenberg> basically the par would just take any OBUF with an attached CGND constraint and optimize out any macrocell logic connected to it
<rqou> i didn't know you could even put attributes on output wires like that
<rqou> oh wait of course you can
<rqou> that's how you put LOC
<azonenberg> Exactly
<azonenberg> Any constraint that works in a constraint file should also be applicable in HDL the same way
<azonenberg> in our flow
<rqou> so not by instantiating a "CGND" primitive because that would be dumb :P
<rqou> hmm
<azonenberg> Yes
<rqou> once i get this working we need to test whether the attributes that end up being set in the .json can _actually_ be set from verilog
<azonenberg> You can use one internally if this helps
<azonenberg> for example i have a GP_VDD and GP_VSS primitive
<azonenberg> that source all constant-drive nets in the PAR
<azonenberg> so i can have something to use as the source in the routing matrix
<azonenberg> and it's legal to use in HDL but makes no sense when 1'b0 suffices
<pie_> oh heck apparently this is a thing https://archive.is/OExoO
<rqou> i just want to make sure to minimize sim/synth mismatches
<rqou> so attributes that magically change behavior need to be checked pretty carefully in the synth flow
<rqou> e.g. if you put the CGND attribute to a wire, you can't initialize it to 1
<rqou> hmm wait
<rqou> azonenberg: it seems kinda weird to have attributes on wires in the yosys data model
<rqou> you _can_ do that, but wires can have both multiple sources and multiple sinks
<rqou> so any attributes set need to somehow propagate to all of them
<rqou> for extra bonus fun, yosys also has "0" and "1" wires
<rqou> which are constants
<pie_> re loperos, i guess youre not a crackpot if youre right
<pie_> xD
<rqou> i wonder what happens if you connect a driver to one of those?
<pie_> what i dont get is from where/how he distills all this stuff
<rqou> azonenberg: yosys seems in general pretty bad in the "no footguns" aspect
<azonenberg> yes the 0 and 1 constants are a pain in the butt
<rqou> they can also be z and x
<rqou> :P
<rqou> azonenberg: is it ever useful to put a LOC on a BUFG?
<azonenberg> Not sure, but i'd allow the possibility
<azonenberg> It wouldn't be inferred in that case though
<azonenberg> you'd explicitly instantiate
<rqou> but when the LOC on the BUFG disagrees with the lock on the io pad you just get an error?
<rqou> *LOC
<azonenberg> I'm not actually sure how that would work, i havent looked into it
<rqou> i guess someone can LOC a BUFG and not LOC the io pin?
<azonenberg> you'd probably want some way to have a LOC on the IO not propagate to the BUFG
<rqou> i don't think the xilinx flow can do LOC on a BUFG anyways
<azonenberg> I havent tried
<rqou> but for now i'm not going to emit LOC on a BUFG
<azonenberg> pretty sure the attrmvcmp pass pushes LOCs from wires to IBUFs thoguh
<azonenberg> preferentially
<azonenberg> rather than to the downstream device
<azonenberg> i.e. LOC on a wire applies to the node sourcing the wire
<azonenberg> Which would be the IBUF
<azonenberg> if you instantiated a bufg after that, no problem
<rqou> what if there are multiple because you sucked at coding? :P
<azonenberg> and if you inferred a bufg, you'd create a new net called foo_bufg
<azonenberg> which would be sourced by the bufg
<azonenberg> etc
<azonenberg> Multiple bufgs with the same clock?
<rqou> well right now inferring BUFG hasn't been implemented yet anyways
<azonenberg> ah ok
<rqou> multiple drivers for the same wire
<azonenberg> oh
<azonenberg> That should trigger a DRC error, the earlier the better
<azonenberg> i havent actually checked what gp4par does for that
<azonenberg> i forget if yosys catches it
<rqou> right now i know for sure that my code doesn't DRC at all
<azonenberg> :p
<rqou> argh this is annoying
<rqou> i just tested it and yosys puts attributes on wires like i expected
<rqou> but my data model doesn't handle attributes on wires particularly well
<rqou> everybody's data model is slightly different and there's so much impedance mismatch everywhere
<azonenberg> rqou: Look at how synth_greenpak4 does it
<rqou> does what?
<azonenberg> i move the attributes onto the cells, i believe during synthesis
<rqou> er, not when i tried it
<rqou> oooh wait
<rqou> you only move LOC
<azonenberg> ah, ok
<azonenberg> That would explain it
<azonenberg> prob b/c top level ports are a special case
<rqou> well, LOC and src
<rqou> yeah, top-level ports are also weird and annoying
<rqou> hmm we never bikeshedded what we're going to do with vref
<rqou> vref is also a weird hacky special case especially with its physical proximity constraints
<azonenberg> Yes
<azonenberg> Initially i'm going to say don't support SSTL
<azonenberg> file a ticket as a TODO
<azonenberg> Down the road we'll have to figure out physical proximity
<rqou> oh, that's available as a table in an appnote somewhere
<rqou> so only the bikeshedding part needs to happen
<azonenberg> well i meant the best way to implement it
<azonenberg> i'd rather have it be done per die pa
<azonenberg> pad*
<azonenberg> then a remapping table from pin LOC to die pads
<azonenberg> Then if you have numbered die pads it's trivial to figure out what's nearby
<azonenberg> You need the pad numbering anyway to figure out which bitstream IOB configures what
<openfpga-github> [openfpga] rqou opened issue #108: Bikeshed: how to ergonomically implement HSTL/SSTL https://git.io/v7oEU
<rqou> btw i legitimately don't know how to test this (from the EE perspective)
<rqou> how do i generate SSTL/HSTL signals?
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/v7oEt
<openfpga-github> openfpga/master a9a4c13 Andrew Zonenberg: Implemented bitstream loading for IOB type A, ACMP, VREF
<azonenberg> You might have to do some glue logic with another CPLD or something?
<azonenberg> and you'd need some LDOs and discrete resistors
<azonenberg> Not something to do randomly on an existing devkit
balrog has quit [Quit: Bye]
<rqou> that sounds like a pain
<azonenberg> Save it for later, none of the currently supported parts even have sstl support
<azonenberg> Focus on getting the 32a 100% feature complete
<azonenberg> avoid design decisions that will make the larger parts difficult to do, but don't worry about new features the small parts lack
balrog has joined ##openfpga
scrts has quit [Ping timeout: 260 seconds]
<rqou> hmm but overall it seems like having attributes only live on nodes is fine
<rqou> we just have to get yosys to move them around a bit
<rqou> and then i don't need to deal with the complexity of some attributes being on wires and some being on nodes
scrts has joined ##openfpga
<rqou> azonenberg: do you know if iopadmap will create extra bogus io pad cells if i manually instantiate an io pad cell?
<rqou> wow, synthesis has so many corner cases
<pie_> well i just had it pointed out to me that the R-S paper is infamous for verious reasons xD
<azonenberg> rqou: I don't remember
<azonenberg> Try it
<azonenberg> if it does i'd consider that a bug
<rqou> sure
<rqou> it's just annoying how many potential ways there are to mess up
<azonenberg> And now you're beginning to understand why EDA is hard :p
<rqou> and these aren't even "hard" problems, they're just dumb problems
<azonenberg> So goals right now
<azonenberg> Tonight: finish import of greenpak netlists to native format
<azonenberg> Tomorrow: Write exporter to yosys json fully
<azonenberg> At that point i should be able to take a greenpak bitfile and turn it into verilog with the currently-implemented cells flattened
<rqou> i'm about a half-step ahead of you
<azonenberg> Next step is to finish cells_sim
<azonenberg> So that all of the cells that are pure digital can be turned into behavioral RTL
<rqou> azonenberg: do you mind if everything turns into an inout port?
<azonenberg> Then the rest of the week i'll work on high-level analytics
<azonenberg> Pretty sure there's a yosys pass for fixing that already
<rqou> heh nice
<azonenberg> But distinguishing inout from in or out is kind of important
<azonenberg> it helps a lot when REing the design
<rqou> yeah, but that can be done in a future pass
<azonenberg> it should be easy enoguh to figure out if the tristate is statically 1 or 0, right?
<rqou> it makes the json writer simpler
<azonenberg> eh, i dont really like it
<rqou> yeah exactly
<azonenberg> But as long as you confirm that the yosys pass will fix it
<azonenberg> i dont care THAT much
<azonenberg> as long as i get good RTLIL in the end
<cr1901> Never really thought about this, but what's the difference between using a for loop in Verilog by itself and one within a generate statement?
<azonenberg> not much, afaik
<azonenberg> other than, one in a generate statement can instantite module
<azonenberg> modules*
<openfpga-github> [openfpga] azonenberg pushed 4 new commits to master: https://git.io/v7oz8
<openfpga-github> openfpga/master 495c4ab Andrew Zonenberg: ReadMatrixSelector - demoted spammy message from debug to trace verbosity
<openfpga-github> openfpga/master 24bcf7f Andrew Zonenberg: Added const version of GetRealEntity()
<openfpga-github> openfpga/master 4feb4d2 Andrew Zonenberg: Greenpak4DAC: Added load support for unused DACs (active ones not supported yet)
<cr1901> "demoted"
<cr1901> The message was just trying its hardest to stand out T_T
m_w has quit [Quit: leaving]
scrts has quit [Ping timeout: 240 seconds]
nrossi has quit [Quit: Connection closed for inactivity]
scrts has joined ##openfpga
<pie_> apparently our strange friend is into poking at the xilinx toolchain http://www.loper-os.org/?p=1361 ...4 years ago
_whitelogger has joined ##openfpga
<awygle> pie_: what... is this?
<pie_> heck if i know
<pie_> some attempt at rethinking computing
<pie_> for better presumably
<pie_> this is rather frustrating “in _every_ field I know, the difference between the professional and the mass market is so large that Joe Blow wouldn’t believe the two could coexist. more often than not, you can’t even get the professional quality unless you sign a major agreement with the vendor — such is the investment on both sides of the table. the commitment for over-the-counter sales to some anonymous customer is _negli
<pie_> gible_. consumers are protected by laws because of this, while professionals are protected by signed agreements they are expected to understand.”
<awygle> uh oh. i am incapable of resisting technical crazy on the internet. and this is a *decade* of it.
<pie_> awygle, that makes two of us?
<pie_> err the quote is not from the source but quoted by the source in a different artivle
scrts has quit [Ping timeout: 246 seconds]
<awygle> "Those among these criminals against mathematics who prove unrepentant in their final hours would be asked to prove the Turing-equivalence of a spoon to a shovel as they dig their graves." wow
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/v7oVz
<openfpga-github> openfpga/master 6a8b9cc Andrew Zonenberg: Finished initial bitstream loading support for counters
<azonenberg> rqou: ok that's initial bitstream loading implemented
<azonenberg> Now to do export to json (tomorrow)
scrts has joined ##openfpga
m_w has joined ##openfpga
<pie_> awygle, bbl heh
* pie_ crashes into bed for an hour of sleep
digshadow has joined ##openfpga
m_w has quit [Quit: leaving]
<rqou> hmm so i was looking for "that .jed" that goes on "those ebay xc2c64a 'dev boards'"
<rqou> i didn't find it
<azonenberg> lol
<azonenberg> are they preflashed? or no, to avoid DMCA issues
<rqou> but i found more info about the "carefully drill at a very very precise location to break the WP wirebond" hack
<rqou> apparently that hack ends up actually breaking the bond wire for WP
<azonenberg> lol nice
<rqou> and because it's now floating, somebody came up with a really really ingenious hack for how to deassert WP in case the chip needs to be flashed again
<azonenberg> yeah i think i heard, stick the drill bit in?
<rqou> nah, more fun than that
<azonenberg> or just dip a conductive liquid in the hole
scrts has quit [Ping timeout: 240 seconds]
<rqou> somebody discovered that clicking a piezoelectric lighter near the chip enough times will charge or otherwise induce enough EMI to flip the WP state
<rqou> i would never have even thought to try this
nrossi has joined ##openfpga
<azonenberg> loool
<azonenberg> wow'
<rqou> it has pictures
scrts has joined ##openfpga
<rqou> anyways, this definitely deserves to go onto the "neat glitching techniques" list
<azonenberg> lol yeah
<rqou> alright, i got myself some of "those" jeds
<rqou> interestingly, i _don't_ think the source code is available
<rqou> this will be fun once i actually finish coding the json dumper
<rqou> i wonder if any of those "team <foobar>" groups expected that it would be possible for someone to RE their jed files?
<azonenberg> Lol
<azonenberg> Honestly
<azonenberg> i would love to use that modchip as a case study in my talk
<azonenberg> "we found this thing on the internet, here's how it actually works"
<rqou> hey, i never said modchip!
<azonenberg> i assume that's what it is though :p
<rqou> yeah of course :P
<rqou> hmm is the passme using a coolrunner-ii?
<rqou> aw lame it's a 9500xl
<rqou> alright, i just grabbed some jeds for a different and "more advanced" "coolrunner-ii" board
<rqou> this one has an xc2c128
<rqou> unfortunately it's only got xsvf files so we have to mangle that a bit
<rqou> alright, time to actually write the code for this
teepee has quit [Ping timeout: 245 seconds]
<rqou> ugh the 128 board .rar file contains pirated content
teepee has joined ##openfpga
<azonenberg> rqou: ?
<azonenberg> of what
<rqou> it has some patched firmware for the system management microcontroller on the "victim platform"
knielsen_ is now known as knielsen
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
teepee has quit [Ping timeout: 240 seconds]
teepee has joined ##openfpga
digshadow has quit [Ping timeout: 240 seconds]
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
qu1j0t3 has quit [Ping timeout: 240 seconds]
specing has joined ##openfpga
teepee has quit [Ping timeout: 258 seconds]
teepee has joined ##openfpga
teepee has quit [Ping timeout: 260 seconds]
teepee has joined ##openfpga
Spida has quit [Remote host closed the connection]
scrts has quit [Ping timeout: 240 seconds]
qu1j0t3 has joined ##openfpga
seu has quit [Read error: Connection reset by peer]
seu has joined ##openfpga
scrts has joined ##openfpga
fpgacraft1_ has joined ##openfpga
fpgacraft2_ has joined ##openfpga
fpgacraft2 has quit [Ping timeout: 258 seconds]
fpgacraft2_ is now known as fpgacraft2
fpgacraft1 has quit [Ping timeout: 258 seconds]
fpgacraft1_ is now known as fpgacraft1
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
egg|egg has quit [Ping timeout: 268 seconds]
pie_ has quit [Ping timeout: 240 seconds]
bibor has quit [Ping timeout: 255 seconds]
teepee has quit [Ping timeout: 255 seconds]
teepee has joined ##openfpga
<openfpga-github> [yosys] rqou pushed 1 new commit to master: https://git.io/v7opB
<openfpga-github> yosys/master 275e60a Robert Ou: coolrunner2: Add INVERT parameter to some BUFGs
<rqou> needs much more testing, but it at least kinda sorta works
<rqou> sleep time
m_t has joined ##openfpga
scrts has quit [Ping timeout: 248 seconds]
scrts has joined ##openfpga
specing has quit [Ping timeout: 240 seconds]
specing has joined ##openfpga
pie_ has joined ##openfpga
m_t has quit [Quit: Leaving]
scrts has quit [Ping timeout: 255 seconds]
scrts has joined ##openfpga
nurelin has quit [Remote host closed the connection]
nurelin has joined ##openfpga
cr1901_modern has joined ##openfpga
scrts has quit [Ping timeout: 248 seconds]
scrts has joined ##openfpga
pie_ has quit [Ping timeout: 260 seconds]
m_w has joined ##openfpga
coino_ has joined ##openfpga
* coino_ o/
scrts has quit [Ping timeout: 246 seconds]
scrts has joined ##openfpga
pie_ has joined ##openfpga
digshadow has joined ##openfpga
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
amclain has joined ##openfpga
test123456 has joined ##openfpga
clifford has quit [Ping timeout: 255 seconds]
test123456 has quit [Remote host closed the connection]
digshadow has quit [Quit: Leaving.]
test123456 has joined ##openfpga
test123456 has quit [Remote host closed the connection]
test123456 has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
bibor has joined ##openfpga
scrts has joined ##openfpga
oeuf has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
oeuf is now known as egg|egg
scrts has joined ##openfpga
digshadow has joined ##openfpga
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
<openfpga-github> [openfpga] azonenberg pushed 2 new commits to master: https://git.io/v7KMr
<openfpga-github> openfpga/master 3b6c15a Andrew Zonenberg: Added gpkjson cell dump database
<openfpga-github> openfpga/master 22b5922 Andrew Zonenberg: Continued work on GreenPAK JSON netlist export
<azonenberg> rqou: here's what i currently get from importing my netlist, lol
<azonenberg> it's a start, i guess
<rqou> oh, mine is "done" except that i haven't tested any of it
<rqou> so many parts are probably broken
<azonenberg> i have the netlist fully loaded to the internal representation in gpkjson
<azonenberg> But export is very much a WIP
clifford has joined ##openfpga
m_t has joined ##openfpga
<rqou> offtopic: red text compresses extremely poorly in "traditional" video codecs
<lain> o.o
<lain> why specifically red
<rqou> chroma subsampling maybe?
<rqou> somehow blue doesn't look nearly as bad though
<lain> are you using like 4:2:0 or something? :P
<lain> I should learn more about video codecs
<rqou> idk, what does youtube use?
<lain> no idea
<lain> they use different codecs depending on browser, amusingly
<lain> if you use chrome, they'll feed you vp9 codec
<lain> which isn't hw accelerated
<lain> so playing back 4k vp9 video on my core i7-4700mq laptop eats like 20% of all 16 execution threads
<lain> which is just astonishingly stupid
<rqou> is hardware acceleration actually hardware or is it just a dsp?
<lain> meanwhile playing back the same video in Edge, which doesn't support vp9, will get you an mp4 stream, which decodes with gpu assistance iirc
<rqou> or is it "super sekrit NDA" :P
eduardo_ has joined ##openfpga
<lain> but at the same time, google won't feed you a mp4 at 4k, they limit you to like 1440p
<lain> I think it's gpu accel
<rqou> some GPUs really do have decode hw
<rqou> it's not just using shaders
<rqou> i don't really get why video codecs have so much "super sekrit" surrounding them though
<lain> probably because high-end video camera makers still use them as distinguishing features
<lain> like sony's XAVC-S codec stuff
<rqou> i thought high-end cameras just shoot raw?
<lain> personally I'd rather just capture losslessly compressed raw
<rqou> "video people" always seem to come up with shitty tech
<lain> the really high-end do, but there's an upper middle ground that still use codecs
<azonenberg> rqou: do you know how much data uncompresed 4K is?
<rqou> a bit over 10gbps
<azonenberg> say 24-bit color, 3840 x 2160 pixels, 60 FPS = ~1.4 GB/s
<azonenberg> :p
<azonenberg> Or about 10 minutes per terabyte of storage
eduardo has quit [Ping timeout: 246 seconds]
<lain> lossless compression would probably cut that in half
<eduardo_> there is an open source camera effort to record 4k raw www.apertus.org
<lain> yeah
* lain also has some cams she has built that can do raw video capture
<lain> one day I'll finish some of that stuff
<lain> one day...
<rqou> what does that camera record onto?
<rqou> oooh this was that axiom camera i remember hearing about
<rqou> at some point i really need to build my "stop f*cking around and just capture" video capture device
<rqou> basically taking 1080p hdmi in, stripping hdcp, and just transmitting 10GbE containing the raw data
<rqou> also a good ADC for capturing "NTSC" video that actually isn't
<pie_> wait lain is a she :O not that thats surprising actually
* pie_ shrugs and goes back to screwign around
<lain> hehe
<pie_> my sound is off, all i hear is "doink doink doink doink [...]" https://www.youtube.com/watch?v=M8YjvHYbZ9w
<lain> lol
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
<openfpga-github> [openfpga] azonenberg pushed 2 new commits to master: https://git.io/v7KjS
<openfpga-github> openfpga/master a99a604 Andrew Zonenberg: Added GetPrimitiveName()
<openfpga-github> openfpga/master deb0c66 Andrew Zonenberg: Greenpak4EntityOutput: Const-ified a bunch of accessors
<pie_> ok i found a legit wtf thing in python, can someone uhhh....explain this? https://twitter.com/stsewd/status/869577431954444288
<rqou> yeah?
<rqou> er wait
<rqou> no
<rqou> hmm
<rqou> yeah i don't actually know what's happening there
<mtp> pie_, that's how __ works
<mtp> __foo in a class is transformed to _Classname__foo
<mtp> you're just getting that binding from the lexical scope, not the class scope
<mtp> which IS weird
<pie_> its not shown via locals() or globals() :O
<pie_> oh
<pie_> on second read im kinda getting what youre saying
<pie_> that still sounds fucked though
<mtp> >>> '_MyClass__number' in locals()
<mtp> True
<mtp> wfm
<pie_> * mfw? :P
<pie_> well of course it is in locals if you set it
<pie_> ah but of course its not in locals if its created in the class
<pie_> so youd have to call locals in the class
<pie_> ah wait
<pie_> if you define __number in the class you have to access it with self.
<pie_> ...
<pie_> well...idk
<pie_> i dont agree with several of them being odd but this is a very interesting thread https://twitter.com/i/moments/871564334832304128
<qu1j0t3> lolpython *closes window*
<pie_> hey its still not C :P
<pie_> kekekeke
<rqou> azonenberg: now we're getting somewhere: http://i.imgur.com/WAkNlOs.png
<pie_> rqou, yay graphs r vcool \o/
<mtp> pie_, if it's in a class it's in the __dict__
<mtp> iirc
<rqou> hmm, yosys has some problems with my constant z driver
scrts has quit [Ping timeout: 246 seconds]
scrts has joined ##openfpga
<cr1901> azonenberg: Would you object if I made the shift register fix a yosys plugin (that replaces the shreg extraction pass for gp4 synthesis alone) instead of patching yosys, at least for the time being? Sadly I don't have my notes on me right now, but I explicitly recall the shreg pass as-is in yosys "is a good default, just that gp4 has special considerations".
<rqou> no, don't do plugins
<rqou> yosys plugins hit all the fun C++ ABI problems
<azonenberg> multi-tap shregs are likely a concern for other arches too
<azonenberg> Fix it in the yosys code
<azonenberg> just make sure you dont break other arches
<rqou> unless you want to make a binary blob plugin (which doesn't work too well anyways), there is no good reason to make a plugin
<rqou> also azonenberg i really really need the ZIA map for larger parts :P
<azonenberg> yes i know
<azonenberg> One thing at a time :)
<rqou> also, i'm now forced to properly generate IBUF cells rather than always generating IOBUFE cells
<rqou> turns out the way IOBUFE cells are coded confuses yosys's constant propagation pass
<cr1901> "just make sure you dont break other arches" This is exactly what I'm afraid of... but again, don't have my notes, so I'll give it a shot without...
<openfpga-github> [yosys] rqou pushed 1 new commit to master: https://git.io/v76I7
<openfpga-github> yosys/master 633376a Robert Ou: json: Parse inout correctly rather than as an output
<rqou> also ^ is pretty hilariously busted
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/v76LI
<openfpga-github> openfpga/master d245e0e Andrew Zonenberg: Added initial netlist export. Probably not fully functional for connectivity; definitely does not support attributes yet.
<rqou> azonenberg: let's have a bikeshed about io voltage standards
<rqou> how do you want these to be dumped?
<rqou> i was thinking of adding some non-xilinx values of "HV" and "LV" to the IOSTANDARD attribute
<azonenberg> I'd rather say LVCMOS33 or LVCMOS18
<azonenberg> as that allows the dumped code to be resynthesized
<rqou> but that's not strictly accurate
<azonenberg> You can always replace LVCMOS33 with LVCMOS25 if you know the board runs at 2.5V, etc
<azonenberg> It will produce the same bitstream
<azonenberg> if resynthesized
<rqou> sure
<azonenberg> It just might not have the exact same timing
<azonenberg> Alternative option - have your code take an argument specifying vcco for each bank
<azonenberg> presumably you can get that info if you have the bitstream
<pie_> oh god lol what
<pie_> <codeshot> I think OO languages gave up on maturity and decided to give up and stay needy children but we're trying to pull 30-something divorcees in the singles bar of international business and carting around a kid is a good way to get a conversation started.
* pie_ sight i need to take another run at CLaSH one of these days
<rqou> but there's other attributes where i've already broken with xilinx convention because xilinx convention is dumb
<azonenberg> rqou: like what?
<rqou> like how termination is specified
<azonenberg> i generally try to preserve compatibility with vendor tools when possible, I may add a new/better way of doing things
<azonenberg> but the old way should still work
<rqou> which has footgunned us a number of times already
<rqou> i was going to add a "xilinx to openfpga" pass at some point
<rqou> so xilinx-style input will be accepted, but this tool won't output it that way
<rqou> e.g. xilinx has a really fun DATA_GATE attribute that is great for causing synth/sim mismatches
<azonenberg> lol oh joy
<rqou> you can _also_ instantiate LDG manually which will perform as expected
<azonenberg> Yeah that makes sense
<rqou> which will be extra fun the way i intend to code it
digshadow has quit [Quit: Leaving.]
<rqou> one pass will see DATA_GATE, issue a warning, and convert it to LDG
<rqou> another pass will then proceed to absorb LDG back into the io cell
digshadow has joined ##openfpga
<rqou> do work, and then undo it :P
digshadow has left ##openfpga [##openfpga]
<rqou> nice
<azonenberg> Attributes aren't yet implemented so this won't work (none of the luts have truth tables)
<azonenberg> but here's blinky
<rqou> i think i'm still a little bit ahead of you
<rqou> i can fully untechmap a design assuming there are no bugs
<azonenberg> Nice
<rqou> (which there probably are)
<rqou> can you send me some verilog to test with?
<rqou> i'm going to quickly go out and grab some noms, brb
<azonenberg> In a bit, kinda busy here :)
* azonenberg is eating at his deskl
<azonenberg> And well if i can get to that point by the end of today i'll be pretty happy
<azonenberg> and we can spend the rest of the week figuring out higher level un-synthesis stuff on top of the IR
<azonenberg> Also i note that the current dump i showed you is un-bitstreamed but not un-techmapped
<azonenberg> I can't untechmap usefully until i have attributes
<azonenberg> to turn the hard IP back into gates
digshadow has joined ##openfpga
pie_ has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
digshadow has quit [Ping timeout: 246 seconds]
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
<azonenberg> Oook so next up is attribute export
<azonenberg> And then i can start thinking about untechmapping
DingoSaar has joined ##openfpga
<pie_> \o/
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
coin0___ has joined ##openfpga
coino_ has quit [Ping timeout: 260 seconds]
test123456 has quit [Remote host closed the connection]
digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 246 seconds]
digshadow has joined ##openfpga
azonenberg has quit [Ping timeout: 258 seconds]
azonenberg_work has quit [Ping timeout: 255 seconds]
azonenberg has joined ##openfpga
azonenberg_work has joined ##openfpga
digshadow has quit [Ping timeout: 246 seconds]
<rqou> azonenberg: problem: "that .jed" has DDR FFs
<rqou> so we currently can't untechmap it
<azonenberg> Hmmm
<azonenberg> Can you make an untechmap model of a DDR FF based on SDR FFs?
<azonenberg> you know the XOR trick?
<rqou> ugh
<rqou> sure
<rqou> probably later
<rqou> i'm going to test some simpler designs first
<azonenberg> works on xilinx for synthesis
<azonenberg> have not tested on yosys
<azonenberg> but it was explicitly intended to model a coolrunner
<rqou> also, interestingly "that .jed" doesn't enable any GCKs
<rqou> now i'm really not sure how it works
m_t has quit [Quit: Leaving]
<rqou> ah it's using CTC
<rqou> also, yosys is so damn noisy
<rqou> hmm now i'm really really curious what the original code for "that .jed" looks like
<rqou> it's decently full and has a whole bunch of TFFs in addition to DDR FFs
<rqou> as well as zero GCKs
<rqou> damn xdot is slow
<rqou> this is your blinky from your invasive attack blogpost
<rqou> not sure if it's correct or not
<rqou> it's so full of noise it's hard to make heads or tails of it
<felix_> speaking of video cameras, digital video transport and recording/streaming: /me will be working on sdi support for the apertus axiom camera and the hdmi2usb streaming/recording system from next month on for half a year :3
<rqou> and someone is paying you to do that?
<rqou> or just for fun?
<rqou> oh btw i just remembered
<rqou> felix_: what's the current status with getting tickets for CCC?
<felix_> i got funding for that https://prototypefund.de/project/videoactive/
<felix_> rqou: since the congress will be in a bigger venue this year, there probably won't be problems to get a ticket
<felix_> it's in leipzig this year
<rqou> yeah i know that part
<rqou> there's no crazy voucher system?
<felix_> as far as i know not, but i don't know that for sure
<rqou> i just want to make sure i don't end up without a ticket
<felix_> and well, if there was such system again, i could poke certain people again ;)
<pie_> ;D
specing has quit [Ping timeout: 248 seconds]
<felix_> imho open fpga toolchains are important and also very on topic at the c3, so i'll try my best
<azonenberg> rqou: did you opimize yet?
<azonenberg> or no
<rqou> somewhat
<azonenberg> i mean the yosys opt pass
<rqou> yeah, i ran opt
<azonenberg> ah ok
<azonenberg> So this afternoon's focus is implementing attribute export for all of the remaining greenpak hard IP
<azonenberg> alphabetically i'm up to DCMPREF
<rqou> i guess my focus should probably be to write unit tests :P
<rqou> oh, opt_rmdff isn't working for me btw
specing has joined ##openfpga
<azonenberg> Huh
<rqou> which incidentally then causes yosys to not be able to read its own verilog back in
<rqou> it sees @(posedge PAD_FB2_7, posedge 1'h0, posedge 1'h0) and then gives up because it thinks there are multiple edge-sensitive events
<azonenberg> Lol welp
<azonenberg> Did you pull the latest code from clifford?
<azonenberg> a few days ago
<rqou> yeah, i have that commit
<azonenberg> he pushed a fix to some of the reset stuff
<azonenberg> i havent tested it yet
<azonenberg> If it's not working for you, reopen the issue
<rqou> hmm, it seems i can't reopen issues?
<azonenberg> ??
<azonenberg> Comment on the issue?
<azonenberg> or is that not working either
<rqou> yeah, i can comment but it doesn't seem like i can reopen?
<rqou> hmm, one reason the output looks like a huge mess is the TFFs
<rqou> (for your blinky)
<rqou> and othe other reason is that i can't seem to get yosys to remove a bunch of intermediate wires