pie__ has quit [Remote host closed the connection]
pie__ has joined ##openfpga
<pie__> https://arstechnica.com/information-technology/2017/05/steve-ballmer-we-should-have-turned-microsoft-into-a-world-class-hardware-company/ "At the end of the day there's only going to be silicon and the cloud: everything in the client is going to get built into silicon, and everything else will be in the cloud."
<pie__> ugh plz no
<pie__> or yes?
<pie__> then again, what does that even mean
<lain> a return to the days of dumb terminals
<pie__> right
<pie__> thats bad right
<pie__> then again
<pie__> >bandwidth
<cr1901_modern> I'd rather be dead, quite frankly
<azonenberg> Has he considered what happens when you go offline?
<azonenberg> :p
<cr1901_modern> And I'm not sure if that's hyperbole either
<pie__> then again its not like that will ever completely happen
<pie__> azonenberg, oh right i forgot about hat
<azonenberg> But, this is how you make money on subscription services
<pie__> that, hat, same thing
<pie__> yup
<azonenberg> you dont sell perpetual software licenses
<azonenberg> or software licenses at all
<azonenberg> you sell monthly access to some server running it
<azonenberg> then nobody can just buy it once, drop offline, and keep using it
<azonenberg> Which is exactly what i like doing :p
<pie__> and you cant crack it either
<azonenberg> literally the only benefit from doing this is that you force your users to pay constantly for the software
<azonenberg> it basically eliminates any semblance of ownership
<azonenberg> They want a world where nobody owns a computer
<azonenberg> they rent one on a monthly basis
<azonenberg> and provide a constant source of income
<lain> computers aren't profitable anymore
<pie__> yeh
<cr1901_modern> Good thing Lexmark just lost that one case
<azonenberg> it makes sense in a sick capitalistic sense
<lain> the PC industry is dying
<lain> most people just want a tablet or a phone
<lain> which is /basically/ just a dumb terminal anyway, the way people use them
<cr1901_modern> Or a Broadcom devboard
<azonenberg> lain: i think that is actually a good thing
<azonenberg> it means the remaining sources of PC gear will be less consumer and more engineer/developer focused
<pie__> azonenberg, need to hurry up with homecmos :P
<lain> azonenberg: my thoughts exactly
<azonenberg> Xeons for everyone :D
<pie__> you know i bet windows piracy actually did take a decent chunk of windows profit
<pie__> well or im just projecting myself >.>
* pie__ runs lunix now naturally
<azonenberg> i've never pirated windows
<azonenberg> i got it with computers, kept that version
<pie__> heh
<rqou> i thought most of the profit for windows was from OEMs?
<azonenberg> then started using linux
<azonenberg> :p
<azonenberg> rqou: yeah, the microsoft tax
<pie__> rqou, i have no idea
<azonenberg> doesnt matter what people want, they get it
<rqou> also, pie__ aren't you in eastern europe? isn't all software pirated there? :P
<pie__> well i would have done that but half the time i couldnt find the stickers or something
<pie__> lol
<pie__> rqou, basically.
<pie__> i cant figure out how to put this in one sentence
<pie__> there are some people who i know how they use their computers
<pie__> ^ how the heck do you say that propely
<pie__> going by that sample yes everything is pirated here lol xD
pie__ has quit [Remote host closed the connection]
pie__ has joined ##openfpga
pie__ has quit [Read error: Connection reset by peer]
pie__ has joined ##openfpga
pie__ has quit [Read error: Connection reset by peer]
pie__ has joined ##openfpga
pie__ has quit [Remote host closed the connection]
m_w has quit [Quit: leaving]
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vHR1Z
<openfpga-github> openfpga/master 33f09eb Andrew Zonenberg: Continued work on GreenPAK characterization driver. Refactored into multiple source files.
<cyrozap> azonenberg: Always-online DRM and software subscriptions don't eliminate ownership, they eliminate the *illusion* of software ownership. Because, of course, when you "purchase" a piece of software, you aren't buying the software, you're buying a license to use it. So, IMO, this is a very good thing for FOSS advocates, because it reveals the true cost of using proprietary software :)
<azonenberg> cyrozap: well the difference is
<azonenberg> you used to be able to buy a perpetual license to use the software
<azonenberg> Whatever rights the license gave you, you kept indefinitely
<azonenberg> (for that version at least)
<azonenberg> It's no longer possible, for many popular tools like e.g. adobe CS
<azonenberg> to pay once and get the ability to use it for an indefinite time period
<azonenberg> And i'm not RMS
<azonenberg> I'm all for free software but i realize that we can't reimplement everything
<azonenberg> there are going to be times when you have to use a proprietary tool because in the end you have to get your job done
<azonenberg> At which point this rent-seeking gets annoying :p
<lain> yeah
<lain> were you aware of the lawsuit some years ago where autodesk was able to, iirc, prevent someone from selling their copy of autocad
<azonenberg> o_O
<lain> because the license is non-transferrable
<azonenberg> grr
<lain> yep.
<azonenberg> things like that are stupid
<azonenberg> i want to see software legally treated like a book
<azonenberg> once you buy it, you own that book
<azonenberg> You can sell it, rent it, destroy it
<azonenberg> Write on it
<azonenberg> But not sell copies
<lain> I loved the related case where microsoft tried to do the same thing to someone selling a boxed, unopened copy of windows on ebay... and when asked where the terms about non-transferrable license are, microsoft said "they're in the EULA", and the EULA is displayed during the install and also I think a written copy is in the box
<lain> so the person was like "the box is unopened..........."
<lain> and then microsoft lost the case
<lain> court found, sanely, that the seller cannot be held to terms they can't have read :P
<azonenberg> Lol
<azonenberg> Basically, i think you should have the right to RE, patch, or otherwise do whatever to your copy of a program
<azonenberg> Just not distribute copies
<lain> yeah, agreed
<azonenberg> It gets gray when the binary includes features you dont have a license to
<lain> lol remember oracle's security person going apeshit a few years ago?
<azonenberg> But if you want to, say, figure out how some feature works and implement an interface to an internal library to script something that wasnt meant to be public
<azonenberg> that should be explicitly legal
<azonenberg> lol
<balrog> whitequark: are you or anyone here familiar with the awful state of machine embroidery software/formats?
<Zarutian> balrog: saw the format for a knitting machine once. It was pretty much like the pattern description you get in knitting magazines, just in ASCII plus some bit of formatting. But I have not seen any embroidery formats.
<Zarutian> lain: iirc in EU, not allowing such RE or vulernability scanning actually VOIDS the 'AS IS' clause of the EULA and the vendor takes all liability and or damages which can be shown to arise from vulernabilities or blatant errors in their code.
<lain> Zarutian: nice
<lain> well, sorta nice
<lain> as long as allowing it doesn't void that
<lain> as a developer, it would suck to be held liable :P
<lain> though there are people who believe developers should be held liable, and I dunno. software is hard. lawsuits get out of hand quickly and, at least my view, often have little to do with harm done and more to do with padding pockets :P
<Zarutian> lain: the vendor is held liable. If the code is opensource then the end user is liable because he or she could have hired someone to go over and fix the code.
<lain> I see
<lain> very interesting
<Zarutian> and as I am in a field that has the unspoken threat that the lawyers are just the start of your troubles I find that I am pretty unsympathetic with such propertary code vendors.
<lain> here in the US recently, iirc, they've made exceptions to the DMCA to allow reverse engineering and security research, which is a good first step
<lain> I generally frown upon government sticking its nose in things, but it's clear that big companies aren't going to back down, so some federal "stop suing the reverse engineers [as long as they're not pirates]" regulation might be nice :P
<Zarutian> lain: or just "gee this code has not been properly certified by UL or <those EU and EEZ agencies> that insist on picking a random reverse engineering team unknown to the provider to actually"
<Zarutian> sorry, continues "to actually look and see if it is as advertised"
<lain> yeahhh
<lain> while I appreciate the end goal of agencies like UL, my brief experience with them in the past has been gross :P
<lain> it's possible I just had an isolated bad experience but the impression I got was UL exists to turn a profit above all else, heh.
<Zarutian> most USA companies do.
<Zarutian> That there is no non profit independent certification authorities there boggles me mind
<lain> yeah
<lain> I only saw glimpses but when I worked in engineering for a company that makes panel meters, and they were trying to get UL certified since some places require it, UL wanted like $85k/year or something like that
<azonenberg> o_O
<lain> they claimed they used "the majority" of that money to buy our products under umbrella corps to do random sample testing
<lain> but there's no way lol
<Zarutian> one thing I noticed with the VW thing is the ineffectiveness of some EU countries. I thought a company that did those kind of things (dieselgate) would just loose its charter and be forcefully dispanded. All assets taken by the state as one hundred percent tax/fine.
<lain> ultimately major corporations like that probably make significant money for their home country
<lain> it always comes down to money :P
<lain> samsung is like 30% the gdp of south korea or something. that company is frighteningly huge.
<azonenberg> One of my roommates had a saying
<lain> they make friggin boats.
<azonenberg> "if it doesn't make sense there's probably money involved"
<lain> azonenberg: hah, yeah
<UmbralRaptor> I assume by boats, this means DDGs, or the like?
<Zarutian> well, the thing I described would make share holders doubly paranoid that the company the have share in follows the rules or their shares effectively become worthless.
<azonenberg> Zarutian: you forget politicians own those shares too
<Zarutian> azonenberg: proper disclosure of ties should show that. Usual conflict of intrest rules would apply then.
<lain> UmbralRaptor: I dunno what DDG means, but they're big boats, like massive shipping-container-hauling things
<lain> the kind that take years to build
<lain> they're one of the world's largest shipbuilds of some of the world's largest ships, iirc :P
<UmbralRaptor> Ah, sorry. DDG as in guided missile destroyer.
<azonenberg> aaand when every politician in the country is taking money from at least one corporation who's terrified they would be one regulatory violation away from going out of business
<lain> ah lol
<azonenberg> there's zero chance of something like that passing
<UmbralRaptor> But still, something very expensive.
<lain> UmbralRaptor: indeed
<lain> UmbralRaptor: I seem to recall reading some of their ships take 8+ years to build
<lain> I can't even imagine the logistics of that sort of thing
<Zarutian> azonenberg: not one regulartory violation but something as deliberate as VW dieselgate
<azonenberg> Zarutian: you're missing the point
<azonenberg> everyone is doing it
<azonenberg> did you not see the paper where fiat-chrysler was caught doing something similar, both using the same Bosch ECU core?
<azonenberg> or wells fargo creating new checking accounts for people without their consent to charge them minimum balance fees?
<Zarutian> azonenberg: if everyone jumped off a cliff would you do it? even for say one trillion gold dollars?
<azonenberg> Zarutian: you're missing the point
<azonenberg> Causing every large corporation in the world to go out of business won't solve anything
<azonenberg> new ones will spring up and they'd be just as corrupt, making their owners rich until they got shut down because they got caught
<Zarutian> azonenberg: making the threat does.
<azonenberg> That asusme it isnt an empty threat
<azonenberg> Which it would be, because corrupt politicians will never enact such a law
<openfpga-github> [openfpga] azonenberg pushed 3 new commits to master: https://git.io/vHRQK
<openfpga-github> openfpga/master ff750fd Andrew Zonenberg: Continued work on timing characterization
<openfpga-github> openfpga/master 3dc8431 Andrew Zonenberg: Refactoring: broke more stuff up in to separate files
<openfpga-github> openfpga/master 498b0ec Andrew Zonenberg: Greenpak4LUT: Added MakeXOR()
<azonenberg> Seems like some pin-to-pin paths are upwards of 2 ns faster than others
<azonenberg> Through the crossbar
<Zarutian> azonenberg: that is assuming such political corruption wont end in say, gibblet cages, cangues or, their modern equivs. But enough of this.
<azonenberg> Given that data can anybody think of how to solve for input / output / crossbar delays?
<azonenberg> each path is ibuf delay + crossbar delay + obuf delay
<azonenberg> i think it should be possible to, at minimum, solve for ibuf delay
<azonenberg> and (crossbar + obuf) delay
<azonenberg> (note, crossbar delay is unique for each destination)
<azonenberg> Oh, i also have to do better calibration of the dev board since i don't do every pin bidirectional yet
pie_ has joined ##openfpga
Zarutian has quit [Quit: Zarutian]
<rqou> azonenberg: very rough, but i made a thing: https://gist.github.com/rqou/411f318f4ee4e0b9fa0279dc05dc50a7
<rqou> (no, not intended to be synthesizable)
theMagnumOrange has quit [Ping timeout: 245 seconds]
<azonenberg> rqou: goal is a full sim model of the entire device, or what?
<azonenberg> oh wait
<azonenberg> this is a bitstream parse?
theMagnumOrange has joined ##openfpga
<azonenberg> rqou: What i'd love to do
<azonenberg> and probably could at this point
<azonenberg> is write a synthesizeable verilog model of an xc2c32a
<azonenberg> that $readmemh's a bitstream (with some trivial parser to turn a jed into the bitfile, until i implement a jtag loader)
<azonenberg> and runs on a real fpga
<rqou> hmm
<rqou> that actually sounds like a much more useful idea
<azonenberg> I think your time would be better spent on RE and visualization at this point though
<azonenberg> Do you think you have any chance of black-boxing the 64a ZIA?
<rqou> making this helped me think through what was missing though
<azonenberg> Yeah
<azonenberg> well my eventual goal is to generate random bitfiles
<rqou> (which was mostly "what happens if nothing is selecter or if i do something dumb")
<azonenberg> run on an virtualized coolrunner as well as a real one
<azonenberg> and diff the io pins every clock
<azonenberg> well random verilog and compile it
<azonenberg> to ensure its a legal non-busfight state
<azonenberg> Re the 64a ZIA, first step i'd try to do is find bit groupings, i suspect it's a tree of one-hot muxes
<azonenberg> so try to find groups of bits that are one-hot
<azonenberg> like, there's always one of bits 2-4 set, one of 5-10, etc
<rqou> i mean, there are .chp files that have the mapping
<rqou> the only thing we don't have is bit encoding
<azonenberg> I dont want to look at that if possible
<azonenberg> just to try and stay a bit more legally kosher
<rqou> hmm zia outputs are the same for every FB, right?
<azonenberg> This is the case for the 32a
<azonenberg> I am not 100% this is true on the 64a and larger, but it seems likely
<azonenberg> Anyway, the other thing to figure out is the extra features in the 128+ macrocells
<azonenberg> after that it's just ZIAs
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
<rqou> azonenberg: how do i force the zia to output a zero?
<rqou> anyways, i have the 64 ZIA encoding (but i relied on the tainted files)
<azonenberg> rqou: ah
<azonenberg> yeah that has to be figured out cleanly
<azonenberg> to output a zero you do 8'b00111111
<azonenberg> bit 7 = active-high "drive constant 1"
<rqou> er, how do i write verilog to force the zia to be zero?
<azonenberg> bit 6 = active-low "drive constant 0"
<azonenberg> ... oh
<azonenberg> i dont actually know if that is possible
<rqou> i wrote verilog to force the 13 inputs for the 64 ZIA
<azonenberg> it'd just create a pterm with no values selected
<rqou> there's not an obvious answer for how to encode zero
<azonenberg> Yeah
<azonenberg> sorry kinda busy with greenpak characterization atm
<azonenberg> will have some really cool results in the very near future
<rqou> anyways, I have this:
<rqou> 1111111011110110
<rqou> 1111111011110101
<rqou> 1111111011110011
<rqou> 1111111011100111
<rqou> 1111111011010111
<rqou> 1111111010110111
<rqou> 1110110011111111
<rqou> 1110101011111111
<rqou> 1110011011111111
<rqou> 1100111011111111
<rqou> 1010111011111111
<rqou> 0110111011111111
<rqou> 1111111111111111
<rqou> for the 64 ZIA
<rqou> there's no obvious way to select "zero" here
<rqou> oh wait
<azonenberg> most likely one bit is set everywhere
<azonenberg> (for used rows)
<rqou> i think zero is "1111111101111111"
pie_ has quit [Ping timeout: 240 seconds]
<rqou> lining them up with the right font can maybe show this :P
<azonenberg> Basically, an idle row should be everything de-selected except the 'drive 1' state since that's active high
<azonenberg> all other rows should have drive-1 deselected
<azonenberg> as well as other stuff
<rqou> so for the "official" zia choices, we have:
<rqou> 1111111011110110
<rqou> 1111111011110101
<rqou> 1111111011110011
<rqou> 1111111011100111
<rqou> 1111111011010111
<rqou> 1111111010110111
<rqou> 1110110011111111
<rqou> 1110101011111111
<rqou> 1110011011111111
<rqou> 1100111011111111
<rqou> 1010111011111111
<openfpga-github> [openfpga] azonenberg pushed 2 new commits to master: https://git.io/vHRj4
<openfpga-github> openfpga/master 210bd5b Andrew Zonenberg: Improved error reporting in solver for un-solvable systems
<openfpga-github> openfpga/master d50942b Andrew Zonenberg: Added constraint solver to ease future measurements
<rqou> 0110111011111111
<rqou> 1111111111111111
<rqou> 1111111101111111???
<rqou> the last one might be zero, i'm not sure
<rqou> er, last one maybe should be 1111111001111111
<rqou> so there seems to be a "left half" and a "right half"
<azonenberg> Suggestive of a 2-level mux?
<rqou> yeah
<rqou> oh the zia for the larger parts is going to be a huge pain
<azonenberg> Yes, lol
<rqou> the xc2c512 has 78 choices per row
<azonenberg> lol
<rqou> that must be super slow
<azonenberg> It is
<azonenberg> :p
<azonenberg> look at the fmax / timing delay numbers
<rqou> anyways, 64a looks basically the same except the zia
<azonenberg> :)
eduardo_ has joined ##openfpga
eduardo__ has quit [Ping timeout: 240 seconds]
amclain has quit [Quit: Leaving]
<rqou> i found some fun typos in the datasheet
<rqou> the HSTL/SSTL io standards in the datasheet have _1
<rqou> not _I
<rqou> anyways, we're going to need to do a bunch of hardware testing to understand all the interactions, but i figured out the basic meaning of the new macrocell bits in the 128+ parts
<azonenberg> :D
<azonenberg> make a new doc in the coolrunner docs dir
<rqou> sec, currently poking the 128 zia
<rqou> this takes forever btw
<rqou> is the ZIA uniform timing from any FB to any FB?
<azonenberg> in theory
<rqou> btw do you want the zia column to bit pattern map in the file?
<rqou> i needed the .chp to find it, but it doesn't actually contain data from the .chp
<azonenberg> No
<azonenberg> We can blackbox that easily enough i think
<rqou> so right now i'm basically blackbox-ing except i'm looking at the .chp to figure out where to LOC things
<rqou> you technically don't need to do that if you just exhaustively test everything
<azonenberg> Yeah
<azonenberg> I can verify by SEM/FIB probing in the near future
<azonenberg> as needed
<azonenberg> And delayering
<azonenberg> i intend to shoot sem photos of the macrocell on the 32a first
<azonenberg> also, grrr
<azonenberg> this timing stuff is tricky
<azonenberg> i keep ending up with N equations and N+1 unknowns :'(
<rqou> interestingly the xilinx tools keep telling me that my LOC constraint got dropped
<rqou> but it didn't
<rqou> welcome to "xilinx tools are shitty" :P
<azonenberg> i cant get over how awesome this is, btw
<azonenberg> having multiple active RE/toolchain projects running at once :)
pie_ has joined ##openfpga
<rqou> also, the way the clock divider is instantiated is dumb
<rqou> it's a different name for each divide factor
<rqou> not a parameter
pie_ has quit [Ping timeout: 260 seconds]
<azonenberg> lol yeah i saw that
pie_ has joined ##openfpga
<azonenberg> also interesting
<azonenberg> it seems like going east to west takes about a nanosecond more than west to east
<azonenberg> This trend is consistent across two different dies, although one die is about 500ps faster than the other
<rqou> hmm if I instantiate a clock divider without cdrst, Oe gets set to CGND
<rqou> (for the cdrst pin)
<azonenberg> is there a reset required?
<rqou> that was the only change between the no-cdrst and has-cdrst files
<rqou> so that seems to imply that that pin is always hooked up to cdrst
<rqou> and you lose use of it if you use the clock duvider
<azonenberg> interesting
<rqou> I wonder if DGE works like that toi
<rqou> *too
<rqou> but that seems to contradict the part where the software sets it to CGND
<rqou> so driving the pin high would be a short?!
<azonenberg> i think if you enable OE
<azonenberg> it doesnt go cgnd
<azonenberg> but if you disable OE, it forcibly drives the obuf low so you dont *need* to tie it off on the pcb
<rqou> no, Oe is set to 1110 automatically
<azonenberg> interesting
<rqou> the AR seems to imply that you can "just use the pin anyways"
<azonenberg> yeah
<azonenberg> which is not true
<rqou> but AFAIK that just causes a short
<azonenberg> possible between 2012 and 2014 they patched ISE
<azonenberg> to tie it off
<azonenberg> then never updated the AR
<rqou> thanks xilinx
Hootch has joined ##openfpga
<rqou> anyways, stuff seems fairly consistent across devices
<rqou> azonenberg: do you think the eeprom array has unused cells in it? for e.g. buried macrocells in the larger parts?
<rqou> potential watermarking?
pie_ has quit [Ping timeout: 255 seconds]
<azonenberg> I think they do have unused cells
<azonenberg> not for buried macrocells
<azonenberg> but ones that dont map to a sram cell at all
<azonenberg> and yes, potentially useful for stego
<rqou> you know, i'm surprised the xc2 parts haven't been REd earlier
<azonenberg> They arent all that complex
<azonenberg> Also, i'm having fun doing process corner measurements on greenpaks
<rqou> i remember opening the .jed and thinking "this shouldn't be too hard" something like 8 years ago
<azonenberg> i'm measuring some delays over 5 dies
<azonenberg> so far i've found one that is definitely on the fast process corner and two that seem about the same
<azonenberg> i'm also seeing what looks like definitely a consistent curvature, there's a few cross connections that are consistently slower than others by a few hundred ps
<azonenberg> Not linear, oddly enough
<azonenberg> i havent tested if this trend occurs when using other pins yet
<rqou> hmm so just out of curiosity i just opened the xpla3 architecture datasheet
<rqou> xpla3 is weird
<rqou> it's like a coolrunner-ii except everything has slightly more special cases
<azonenberg> aand this is another fast corner die
<azonenberg> rqou: yes, i actually figured out how the cr2 zia worked
<azonenberg> in part
<azonenberg> by reading the xpla3 docs
<azonenberg> they explained some of the background theory quite well
<azonenberg> The architecture is clearly an ancestor
<rqou> wait, there were XPLA2 and XPLA E parts?
<rqou> i've never seen these
<azonenberg> me neither
<azonenberg> first i heard about them
<azonenberg> i mean it makes sense xpla3 had ancestors
<azonenberg> but they were philips
<azonenberg> xilinx bought xpla3 from philips
<azonenberg> then i think developed coolrunner2 in house
<rqou> is xpla3 pure digital as well?
<azonenberg> I believe all coolrunner were
<azonenberg> could be wrong
clifford has quit [Ping timeout: 268 seconds]
pie_ has joined ##openfpga
<rqou> huh but xc2 lost the foldback nand feature
<rqou> although i believe yosys/abc can't use that either
<azonenberg> didnt the xor replace that?
<rqou> xpla3 also has the xor
<rqou> i believe the xor isn't equivalent
<azonenberg> :D
<rqou> wait shit
<rqou> i think i have a guess what inz really controls
<rqou> maybe the coolrunner-ii also works like this? and not like the diagram in the datasheet
pie__ has joined ##openfpga
pie_ has quit [Read error: Connection reset by peer]
<azonenberg> rqou: explains?
<rqou> so we've been assuming that the zia in the coolrunner-ii has inputs from input buffers and macrocells
<azonenberg> and?
<rqou> the input from the macrocell is controlled by the FB bits
<rqou> we've been assuming that the other inputs are from the input buffers and are enabled/disabled by the INz bits
<rqou> on the XPLA3, there is the macrocell feedback path the same way
<rqou> but the "input buffer" feedback path can select either the input buffer or the output of the register
<azonenberg> Hmm
<rqou> maybe coolrunner-ii still has that?
<azonenberg> Unlikely, what would clock that register?
<rqou> the clock signal still runs to the register
<azonenberg> which clock
<rqou> GCKn/CTC/PTC
<azonenberg> and selected by the same clksrc mux?
<azonenberg> i doubt it
<rqou> why not?
<azonenberg> What would the point be
<rqou> in the xpla3 white paper, they show using both the register to register an input and using buried combinatorial feedback
<azonenberg> hmm
<azonenberg> How would you test this hypothesis?
<rqou> i'm thinking
<rqou> it's kinda tricky to test :P
<rqou> hmm wait
<rqou> set the register to be a T-flipflop
<rqou> then we can mess with inz and see if the result changes between "0 vs 1" and "constant vs toggling"
<azonenberg> Hmmm
<azonenberg> still not sure i fully understand
<azonenberg> but try it :p
<rqou> hmm all the xilinx parts have an extra xor gate
<rqou> they're just hooked up in different ways
<rqou> we really do need to teach yosys/abc about this
<rqou> even the xc9500xl has an xor gate
<rqou> hmm the 9500 architecture is totally different and weird
<azonenberg> yes
<azonenberg> 9500 is a PAL, not a PLA
<azonenberg> the OR array is fixe
<azonenberg> fixed*
<azonenberg> product terms are not shareable
<rqou> but it has weird product term steering stuff
<rqou> and is overall a giant mess
<azonenberg> Yes i never fully understood that
<azonenberg> That, plus the lack of comments in the jed to give me a foothold
<rqou> e.g. xpla3 seems possible to support with extra effort
<azonenberg> were the reasons i went with cr2
<azonenberg> xpla3 seems inferior in most/all respects to cr2
<rqou> 5v tolerant?
<azonenberg> i'm only going to support an older device family if there's a good reason
<azonenberg> is it?
<azonenberg> and is it significantly faster than greenpak? :p
massi has joined ##openfpga
<rqou> idk about faster
<rqou> but yes, it's 5V tolerant and slightly bigger
<rqou> basically the only reason it still exists :P
<azonenberg> Lol
<azonenberg> more like, resupply of legacy stuff
<azonenberg> :p
<azonenberg> same reason xilinx still makes virtex2s
<rqou> hey, xpla3 isn't even NRND yet afact
<rqou> *afaict
<rqou> hmm or is it?
<rqou> maybe it is
<azonenberg> i consider it nrnd
<azonenberg> idk about what xilinx says :p
<azonenberg> then again i consider spartan3a nrnd too
<azonenberg> and that isnt dead either
<rqou> even the xc9500xl doesn't have the "– PRODUCT OBSOLETE / UNDER OBSOLESCENCE –" stamp yet :P
pie__ has quit [Ping timeout: 260 seconds]
<rqou> hmm the website doesn't seem to mention xpla3 anywhere anymore
<rqou> for some reason it still mentions xc9500xl
<azonenberg> lol
<azonenberg> it may be dead / nrnd then
<rqou> but xpla3 is better than xc9500xl wtf
<azonenberg> is it?
<azonenberg> i mean i guess pure digital vs sense amp
<azonenberg> but i think they killed off xpla3 as soon as cr2 came out
<rqou> it's at least a PLA
<rqou> no they definitely didn't
<rqou> i remember using some xpla3s for the 5v-tolerance
<rqou> ages ago
<rqou> digikey says xpla3 is still active
<azonenberg> interesting
<azonenberg> i decapped some but never got beyond top level imaging
<azonenberg> never used in a design
<rqou> wtf
<rqou> the coolrunner (one?) xcr3032 parts have _both_ a PLA and a PAL
<rqou> (they're also obsolete)
<azonenberg> o_O
<rqou> hmm digikey has them under the wrong category
<rqou> digikey things they're xpla3
<rqou> and digikey doesn't have them properly marked obsolete
<rqou> so maybe xpla3 is dead
<rqou> wait wait wait
<rqou> now i'm getting confused
<rqou> xcr3032 is obsolete and is just a "coolrunner"
<rqou> xrc3032xl is different
<rqou> the "XL" version is XPLA3
<rqou> and might not be obsolete yet???
<rqou> but it's totally different from the not-XL version
<azonenberg> lol
<azonenberg> wow
<azonenberg> some of that renaming may have come as part of the philips -> xilinx acquisition?
qu1j0t3 has quit [Ping timeout: 240 seconds]
<rqou> huh meanwhile altera cplds are all lies :P
<rqou> max 10/max V are lut-based
<azonenberg> There's two main taxonomies for FPGA vs CPLD
<azonenberg> altera uses volatile vs nonvolatile
<azonenberg> xilinx uses lut vs pla
<azonenberg> i prefer the latter
<rqou> max ii is also lut-based
<azonenberg> meanwhile greenpak is a crossbar of luts
<rqou> didn't altera have pla-based devices at one point?
<azonenberg> yes
<azonenberg> sec
<azonenberg> go tell me this isn't product term based
<azonenberg> just by looking at the die
<azonenberg> you can see four function blocks, macrocells to either side, then a routing matrix in the middle
<azonenberg> very similar to the 2c64a
<azonenberg> This is TSMC 350 nm
<azonenberg> so same process generation as xpla3 / xc9500xl
<azonenberg> but it's sense amp based
<azonenberg> so basically the altera competitor to xc9500xl
<rqou> ahh so that's why back in those days (and earlier) my father always used altera cplds
<rqou> the interconnect was better
<azonenberg> better than xilinx you mean?
<rqou> yeah
<azonenberg> Why do you say that
<rqou> apparently it hit unroutable conditions less often
<azonenberg> that may be software
<azonenberg> but yeah, xc9500* had more unroutable states than coolrunner
<azonenberg> due to the extreme flexibility of the PLA vs PAL
<azonenberg> i dont actually know anything about the altera chip's microarchitecture
<azonenberg> it could well be just as bad as xc9500
<rqou> hmm actually nvm
<rqou> i think you're right that it's about the same
<rqou> maybe the xilinx software was just shittier
<rqou> yeah the max3000 looks almost exactly the same as the xc9500
<rqou> does anybody except xilinx still make product-term cplds?
<azonenberg> lattice maybe?
<azonenberg> greenpak is a cpld-style crossbar routing architecture but lut based
<azonenberg> which is kinda orthogonal to classic PLA + crossbar CPLDs and 2D LUT fabric FPGAs
<azonenberg> the missing fourth architecture is a 2D fabric of PLAs
<azonenberg> to my knowledge no such device was ever released
<azonenberg> but xilinx patents and marketing info lead me to believe the planned 130/90 nm bladerunner architecture was intended to use it
<azonenberg> before, presumably, xilinx decided to restructure, kill off the project, and focus on high end fpgas
<rqou> ah ok lattice still has some product-term cplds
<rqou> wtf it's also a PAL
<rqou> not a PLA
<azonenberg> wtf
<rqou> (ispMACH4000)
<rqou> it's actually an even bigger mess because it has _two_ "from/to other or gate" wires
<azonenberg> my takeaway from this: xilinx makes the only true cpld worth anything at this point
<azonenberg> also bedtime
<rqou> yeah same here
<rqou> hmm lattice has a clone of datagate as well
pie__ has joined ##openfpga
pie__ has quit [Ping timeout: 268 seconds]
qu1j0t3 has joined ##openfpga
<rqou> azonenberg: so the latest xilinx discontinuation notice I can find mentioning xpla3 is XCN16027
<rqou> which states that some bare die products were discontinued
<rqou> but not xpla3 itself
<rqou> this was Nov. 2016
<rqou> so I think xpla3 is still technically active
qu1j0t3 has quit [Ping timeout: 258 seconds]
qu1j0t3 has joined ##openfpga
clifford has joined ##openfpga
pie_ has joined ##openfpga
<pie_> whitequark, proposition: adobe flash is a textbook stack machine
clifford has quit [Remote host closed the connection]
clifford has joined ##openfpga
pie_ has quit [Ping timeout: 255 seconds]
pie_ has joined ##openfpga
Zarutian has joined ##openfpga
<pie_> azonenberg, when can i start calling myself a full stack reverse engineer? (and never again be taken seriously)
amclain has joined ##openfpga
<qu1j0t3> stack overflow engineer
<pie_> stack overflow is a memetically occupied position :(
<pie_> s/position/term/
<Zarutian> would that be return- or data-stack overflow?
<Zarutian> in seriouseness, what are peeps opinion here on vectored interrupts in MCUs and such?
<cr1901_modern> vectored interrupts?
<pie_> Zarutian, thats for like....dual stack architectures right? (something something itanium?)
<Zarutian> pie_: dual stack architectures such as Harris RTX2010 (popular in Nasa spacecraft as general supervisor chip etc)
<pie_> oh cool! :)
<pie_> (not familiar with it, but at least NASA is still a respectable name...i think :P)
<Zarutian> cr1901_modern: when interrupted the processor pushes program counter onto stack and loads it from a certain memory location depending on the interrupt.
<Zarutian> cr1901_modern: so no need to do something like a jump table in the Interrupt Service Routine. (Because there is more than one basically)
massi has quit [Quit: Leaving]
Guest63856 is now known as gruetzkopf
m_w has joined ##openfpga
<azonenberg> When i hear dual stack i think 6to4 lol
<azonenberg> Zarutian: Cortex-M* generally uses vectored interrupts
<azonenberg> i havent written code for them but i've reverse engineered a lot
<azonenberg> it seems to work well enough
scrts has quit [Ping timeout: 240 seconds]
<cr1901_modern> Zarutian: Ahhh, well in that case, non-vectored is MUCH cleaner to implement in a CPU IMO. It's as "simple" as overriding the fetch stage (or Address stage, in the case of lm32) and flushing the pipeline. No need to have special logic to load the PC from a memory location.
<azonenberg> All of my homemade CPUs have been either a single interrupt
<azonenberg> or no interrupts at all, purely message driven
<cr1901_modern> Well, lm32 is a single interrupt, technically, but it has a bunch of exceptions as well, and the interrupt logic is reused for exceptions
<cr1901_modern> (Using that as an example b/c I've read the source to it)
scrts has joined ##openfpga
<Zarutian> azonenberg: how does message driven work? you poll mailbox registers regularly?
<Zarutian> azonenberg: there there is the middle way. Instead of loading pc from memory depending on the interrupt. Do the equiv of call to an hardcoded address that depends on the interrupt.
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
<rqou> azonenberg: random unrelated question: can spartan6 generate/receive sgmii without the serdes block?
<rqou> wikipedia says sgmii is 625MHz DDR, which is within spec for a normal IO
<azonenberg> rqou: it cannot do clock recovery
<azonenberg> you may be able to do it if the sgmii source is spec-compliant and also provides a clock
<azonenberg> last time i checked jitter was not within spec
<azonenberg> but you could probably make it work
<azonenberg> why not just do RGMII? its not that many more pins
<azonenberg> Zarutian: no, you don't poll anything
<rqou> RGMII is twelve pins
<azonenberg> well unless you're doing nonblocking reads
<cr1901_modern> Why would an I/O pin have jitter when it's not *generating* the signal?
<rqou> SGMII is 4 pins
<azonenberg> the CPU has a hardware thread scheduler
<azonenberg> so if you issue a blocking read and there's no messages it just context-switches
<azonenberg> rqou: yes but do those 8 pins really matter?
<azonenberg> are you that squeezed for space?
<rqou> the idea is to fit in a usb type-c connector again :P
<azonenberg> it only really matters, in most cases, if you're trying to do many interfaces (like a switch)
<azonenberg> ... oh
<rqou> sgmii even with clock does fit
<rqou> as does RMII
<rqou> but not rgmii
<azonenberg> one possibility is a MAX24287ETK+
<azonenberg> discrete serdes that can take [R]GMII and bridge to 1000base-KX or SGMII
<azonenberg> but at that point you may be better off with a phy and 1000baseT over the connector
<azonenberg> if you want a single chip solution, idk
<rqou> yeah
<azonenberg> odds are, you can make it work with sgmii
<azonenberg> but it may jitter more than the spec allows
<rqou> why is s6 so shitty? :P
<azonenberg> cr1901_modern: and because of the fpga clock tree etc
<azonenberg> rqou: it's xilinx's windows me
<azonenberg> artix and spartan7 are descendents of virtex6
<azonenberg> not spartan6
<rqou> but it's so cheap!
<azonenberg> they killed off the old spartan architecture
<cr1901_modern> and it's available in non BGA
<azonenberg> cr1901_modern: thats not a good thing
<azonenberg> a tqfp144 is huge
<rqou> meh, FT256 i heard is easy enough to deal with
<cr1901_modern> azonenberg: You already know how to solder BGA, I don't want to hear it ;)
<azonenberg> a ft256 takes up less pcb space, gives you 70% more io pins
<azonenberg> is still compatible with cheap batch 4-layer fab
<azonenberg> heck, you can do it in 2 layers if you're ok with using ~half the pins and having bad signal integrity at high speed
<rqou> is spartan-7 out for real yet?
<azonenberg> wolfspra1l did a ft256 in one layer once for lulz
<azonenberg> on a home etched board too
<cr1901_modern> azonenberg: Also, artix isn't cheap
<cr1901_modern> $40 for a 15t?!
<rqou> i want my really cheap ~$10 or so FPGA
<rqou> a 15t is also much bigger it's labeled
<rqou> (we should work on that at some point btw :P )
<rqou> a 15t is just like the lattice hx4k
<cr1901_modern> I know a 15t is a 50t or so internally.
<azonenberg> rqou: i believe lain already RE'd the CRC and confirmed it works
<rqou> yeah, and a 50t is enormous
<azonenberg> basically what you have to do is, patch the idcode in the bitstream
<azonenberg> then update the crc to match
<azonenberg> do your compile for a 50t
<cr1901_modern> (2:32:05 PM) azonenberg: cr1901_modern: and because of the fpga clock tree etc <-- oh, you're assuming the I/O pin itself is synchronous?
<azonenberg> cr1901_modern: yeah
<azonenberg> in general fpga clock trees have lots of jitter
<azonenberg> compared to a dedicated serdes output
<rqou> oh wow xc7s6
<rqou> that's adorable :P
<cr1901_modern> I suppose a PLL is ill-suited for recovering the clock from an embedded clock stream?
<cr1901_modern> azonenberg: The other issue w/ me using new Xilinx devices is my hard drive can't handle the burden of both ISE and Vivado
<rqou> lool
<cr1901_modern> erm, "clock embedded within the data"
<rqou> contribute to the (stalled) 7-series RE effort?
<rqou> hmm can s7 output sgmii? it also doesn't have serdes
<rqou> also, why is virtex-7 divided into V, VX, and VH variants?
<rqou> how many mortgages do i need to afford an XC7V2000T? :P
<Zarutian> azonenberg: how does such a hardware thread scheduler work? Is there an instruction down counter and machinary to push a lot of general registers on context switch?
<rqou> hmm also the XC7V2000T seems pretty IO constrained? only 1200 user IOs for such a huge part
<rqou> heh meanwhile the VU13P has only 832 normal IOs
<rqou> it compensates by having apparently 128 GTYs
<rqou> aaanyways, back to actual work :P
<rqou> azonenberg: why is the 32a's obsolete PC44 package totally different from the VQ44?
<rqou> what's the difference between VQ and TQ?
<azonenberg> Zarutian: No, you just have multiple register files
<azonenberg> well one large file and the thread ID is the high address bits
<azonenberg> a context switch is one cycle
<azonenberg> in fact, that core was a barrel-style scheduler, it switched every clock
<azonenberg> i.e. no two consecutive instructions were from the same thread
<azonenberg> made the pipeline a lot simpler b/c no hazard checks
<azonenberg> but destroyed single-thread performance
<azonenberg> also the 7v2000t is around $30k - 60k list price
<rqou> meh, just brand it "pentagon" and you'll have yourself a nice DSP :P
<azonenberg> so not a mortgate, just like a high-end car loan
<azonenberg> rqou: VQ vs TQ is, i think, package thickness
<azonenberg> rqou: and lol yes, xilinx makes larger parts targeting either io-focused or logic-focused applications
<azonenberg> cr1901_modern: re a PLL, the xilinx plls are meant for clocks
<azonenberg> and wont handle a data stream well if at all
<azonenberg> Though it would be fun to try and see what happens :p
<cr1901_modern> azonenberg: That's what I thought. So my confusion: what do you base your statement of "the jitter is too high" on if the PLLs aren't useful for clock recovery in the first place?
<rqou> azonenberg: i just tested my INz hypothesis from last night at i'm pretty sure it's right
<rqou> so the left bit controls the selection between the io pad and the register output
<rqou> the right bit is an enable
<rqou> why doesn't ISE seem to know how to use this?
<rqou> and why is the coolrunner-ii datasheet misleading?
<azonenberg> cr1901_modern: i meant jitter from the PLL plus the PLL-to-FF and FF-to-output-buffer path
<azonenberg> rqou: lol
<azonenberg> interesting
<azonenberg> I'll look at it after work and put more time into looking at it
Hootch has quit [Quit: Leaving]
<cr1901_modern> http://www.whizoo.com/reflowoven This looks fun (except I don't think I have an appropriate drill for it)
<cr1901_modern> (This is an open source tool for FPGAs, CPLDs, etc. I consider it on-topic :)...)
<rqou> hmm maybe i'm reading it wrong but even the coolrunner-ii timing model doesn't seem to show this particular path
<azonenberg> Are you sure it exists?
<azonenberg> still smells like we might be reading too much into things
<azonenberg> at the same time we *do* have a bit whose function we don't understand :p
<rqou> my experiment strongly hints that it exists
<azonenberg> i feel like at this point we have to delayer the macrocell
<rqou> but even my blackbox experiment strongly shows it exists
<azonenberg> yeah but still
<azonenberg> there's some hypotheses i want proven
<rqou> ok, maybe this crudely-drawn diagram can help explain what I've set up
<rqou> the hypothesis is that setting INz to 00 selects the A path and setting INz to 10 selects the B path
<rqou> i've set up the flip-flop in the macrocell corresponding to an input pin to be a T-flipflop
<rqou> it's clocked by GCK0, and the GCK0 net is enabled
<rqou> and the flip-flop is using the direct path
<rqou> so when the input pin is low, the output is a constant zero/one
<rqou> and when the input pin is high the output constantly toggles at 2mhz
<rqou> the outputs A/B are just directly output onto an LED
<rqou> via one of the "FBx pad y" ZIA choices
<rqou> when I set INz to 00, the output led tracks the IO pin as expected
<rqou> and when I set INz to 10, the output is dim (e.g. pulsing) when the io pin is high
<rqou> and I can get the output to become a stable 0/1 (visibly brighter) by bringing the pin low
<rqou> so that seems to be pretty conclusive that this path I mentioned exists
<cr1901_modern> (3:05:36 PM) azonenberg: cr1901_modern: i meant jitter from the PLL plus the PLL-to-FF and FF-to-output-buffer path <-- By FF-to-output I assume you mean "the jitter between when the I/O line is sampled and when it's available for the rest of the FPGA to use"?
<azonenberg> no i meant output
<azonenberg> i.e. your data will not change exactly every 800 ps
<azonenberg> you may have one edge 750ps after the last
<cr1901_modern> But we're *receiving* a signal in rqou's example
<azonenberg> and the next 850 later
<azonenberg> SGMII is bidirectional
<rqou> this hypothesis also explains why when i was testing it before it didn't seem to do anything
<cr1901_modern> Oh...
<azonenberg> The big issue i remember reading about with spartan6 and sgmii
<azonenberg> is output jitter being out of spec
<rqou> when i tested it before iirc GCK0 was already enabled for something else
<azonenberg> If your receiver is sensitive enough, it might work
<rqou> and the default state for the FF is just a D-flip-flop
<cr1901_modern> But you also have to make sure the clock is sent separately, correct?
<rqou> so the signal was delayed, but i couldn't see it because i was just looking at the LEDs
<cr1901_modern> b/c s6's alone can't do recovery without a SERDES
<azonenberg> cr1901_modern: sgmii requires a discrete clock anyway
<cr1901_modern> Ahhh
<azonenberg> Receivers are allowed to do clock recovery and ignore it
<azonenberg> or use it
<azonenberg> but transmitters must provide it
<rqou> further evidence: i disabled GCK0 and set inz to 10 and the output is now a constant 0
<rqou> which is different from the previous "didn't seem to do anything" result
<azonenberg> interesting
<azonenberg> rqou: can you draw up a nicer figure? we'll talk more after i'm done with work
<rqou> ugh fine :P
<cr1901_modern> azonenberg: Okay I misunderstood when you said "(2:28:23 PM) azonenberg: you may be able to do it if the sgmii source is spec-compliant AND ALSO provides a clock", I thought the clk was optional. Got it now!
pie_ has quit [Changing host]
pie_ has joined ##openfpga
m_w has quit [Quit: leaving]
<rqou> azonenberg: if you read between the lines of "Any macrocell flip-flop can be configured as an input register or latch, which takes in the signal from the macrocell’s I/O pin, and directly drives the AIM. The macrocell combinational functionality is retained for use as a buried logic node if needed."
<rqou> this seems to support what i discovered
<azonenberg> Hmmm
<azonenberg> interesting
<azonenberg> I feel like we need to do circuit analysis but can write it up in the docs as a tentative
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
lexano_ has quit [Ping timeout: 240 seconds]
<whitequark> pie_: yes I'm extremely well aware how AVM2 works, I wrote an AVM2 decompiler that beats almost every commercial one AFAIK
<rqou> wait you did?
<rqou> dang how much stuff have you done over the years?
<whitequark> pie_: well it beats just every if you want to automate feature extraction from obfuscated files using pattern matching, but it doesn't if you want to recompile the decompiled code, it's a tricky question
<pie_> rqou, apparently whitequark is a quiet fod
<pie_> *god
<rqou> meanwhile i just have a wasteland of abandoned/half-finished projects with nothing to show for it
<whitequark> i got contracted by an author of an online flash game bot to extract packet IDs and field order from their swf files
<pie_> rqou, ugh tell me about it
<whitequark> they change those regularly and if you send a single packet with a wrong ID you get banned for cheating
<pie_> hey whitequark dumb question, whats your iq if you dont mind me asking
<pie_> lol nice
<rqou> wait was this adventurequest? :P
<pie_> lol
<pie_> whitequark, yeah i kinda want to work on something similar
<rqou> WAIT WTF WHY IS AQ STILL AROUND?!
<whitequark> most bots rely on human labor for that. I wrote a pattern matcher and a deobfuscator; within two minutes since a software update we had a job finished that had the new packet definitions in XML, and pushed to bot clients
<pie_> except m not going for the effective cheatin thing, more the: i want to play with writing ai thing
<pie_> so i want to instrument game interfaces
<pie_> rqou, dude i dont even know. teens need their games
<whitequark> rqou: no that was darkorbit
<pie_> whitequark, shit lol
<pie_> that was going to be my second target
<whitequark> pie_: LOL
<whitequark> seriously?
<pie_> my friend play and i thought id help him out a bit if he wants
<whitequark> any chance you know what bot that was
<pie_> never played it in my life
<pie_> no idea
<whitequark> ahhh
<whitequark> well yeah that was >5 years ago at this point, I lost all code I had access to
<pie_> damn
<pie_> :P
<pie_> all i have so far is a script for mitmproxy that enables debug mode on all the swf that go through it with FFDec
<whitequark> if you ask "grindars" maybe he'll sell you the sources
<pie_> debugging is blocked on a bug i cant fix beccause i cant wrap my head aorund how the decmpiler works and lack of comments
<whitequark> we had a bit of falling out so I can't help you there
<pie_> wel not how the decompiler works but how the relevant portion of code works
<pie_> line numbering is messed up so breakpoints become useless
<pie_> as a "learning haskell" project im thining of attempting to write a swf parser in attoparsec or something after i have some more basics down
<rqou> heh, maybe you can help make shumway actually work :P
<whitequark> complete avm2 decompiler that can convert all 20k+ classes in darkorbit back to sources
<pie_> whitequark, so, basically i was trying to ask if flash is in fact pretty much a textbook stack machine
<pie_> whitequark, i did poke you about that probably a week ago
<whitequark> the pattern matcher and deobfuscator parts are solid, the relooper should be rewritten based on the emscripten paper
<whitequark> the existing relooper is kind of extremely hacky
<pie_> god i have no idea what im doing
<whitequark> it works though
<whitequark> rqou: I offered, they had no interest in that
<whitequark> shumway's problem is mostly flash's API
<whitequark> and the graphics parts
<whitequark> the VM is really the simplest one by far
<rqou> huh
<rqou> i guess that makes sense
<whitequark> pie_: you dont need to poke the swf all that much
<rqou> (i've never actually used flash and have no idea how the normal authoring flow works)
<whitequark> rqou: has nothing to do with authoring flow
<rqou> no, what I meant was "idk anything about flash and didn't realize the APIs are the hard part"
<pie_> whitequark, yeah i read the docs a little the vm doesnt seem tooo complicated
<whitequark> just... the graphics parts of flash are extremely bad. to give you an idea, they use bitfields EVERYWHERE
<pie_> so this might actually not be a terrible choice for a starter project
<whitequark> for example you look at coordinates and they're 5-bit fields not aligned to octet boundaries for no obvious reason
<rqou> wait what
<rqou> why?
<whitequark> except sometimes they are aligned
<pie_> > for compression reasons
<rqou> bullshit
<pie_> it says so in the spec
<rqou> really?
<whitequark> that is correct
<pie_> *space saving reasons
<rqou> but it's so much slower to process
<rqou> and how much do you actually save in size?
<whitequark> so like they actually gzip it afterwards
<whitequark> since early 2000s
<rqou> wtf
<rqou> so that's doubly useless
<whitequark> I think the original flash devs did not know about gzip
<whitequark> and they never changed the encoding
<rqou> but gzip/deflate predates flash
<whitequark> the devs of flash are not really all about competence
<rqou> lol true
<whitequark> their pre-AVM1 VM is Extremely Bad
<whitequark> their language is Doubly Extremely Bad
<rqou> is this the one that was previously getting sploited every month or so? :P
<whitequark> pie_: well, exceptions are the hard part
<whitequark> and the fact that the spec is outright incorrect in many places
<pie_> whitequark, to put things in perspective i have no formal CS training
<whitequark> e.g. the way they describe encoding negative numbers in the spec is just wrong
<pie_> whitequark, ah crap....i was hoping the spec is relatively accurate
<pie_> so howd you figure that stuff out
<whitequark> they *specifically spend space in pdf describing how they encode negative numbers*
<whitequark> and that's wrong
<whitequark> the way you would *expect* that to be implemented based on programmer laziness is what happens though
<pie_> im pretty sure the spec hasnt been updated since oy ulast worked on it
<whitequark> there are also a few record types that arent described
<whitequark> it hasnt been updated since like 2009
<rqou> why are negative numbers hard anyways?
<rqou> "it's twos-complement"
<rqou> done
<pie_> i did notice an "omisison" where they said if field is set to 1 what happens but nothing about what happens otherwise
<whitequark> rqou: I think what htye describe is similar to sleb128
<whitequark> and what they implement is encoding two's complement....... using uleb128
<pie_> whitequark, and my informal cs self-training is pretty lacking for now
<rqou> both choices are kinda suck
<whitequark> this is extremely flash
lexano_ has joined ##openfpga
<pie_> so stuff is hard
* pie_ pokes his semantics book
<whitequark> they see two shitty ways to implement something, so they combine them to make an extremely shitty way instead
<pie_> lol
<whitequark> pie_: i never had any formal cs training
<pie_> how are you so good
<pie_> or am i just young
<whitequark> i'm not
<whitequark> um, i'm like 23 or something
<pie_> im 21 :I
<pie_> "or something" xD
<whitequark> i dont remember my age and too lazy to calculate it right now
<pie_> yeah i wish i didnt have a bunch of things ramming my age into memory rigt now
<whitequark> yeah that sucks
<pie_> id love to have zero reason to think about it
<rqou> wait pie_ you're "21 or something?"
<rqou> i thought you were older than that
<pie_> yeah
<pie_> rqou, was i shaven when we met?
<rqou> not very much so maybe that's why :P
<pie_> yeah that might be it xD
<whitequark> lol
<whitequark> i think people tend to strongly misidentify my age on the internet
pie__ has joined ##openfpga
<pie__> the network is really bad in this corner
<pie__> <rqou> not very much so maybe that's why :P
<pie__> <pie_> yeah that might be it xD
<pie__> <pie_> also i had a pretty bda cold, which probably didnt help either
<pie_> also i had a pretty bda cold, which probably didnt help either
pie_ has quit [Remote host closed the connection]
<cr1901_modern> whitequark: You said your first IDE was Turbo C++. That would make me think you're well in your 30's lol
<rqou> hey, my first IDE was also some borland c++ thing
<whitequark> pie__: rqou: i was talking to [redacted] who is a practicing MD close to 40 in age and they were expecting me to be somewhere in 30-40s
<whitequark> when i spilled my age i think i caused a small BSOD
<whitequark> especially after a few things they confided to me having expecting that age bracket...
<pie__> whitequark, yeah thats roughly what i expected too i think
<pie__> but like how are you 23 and knocking out all the shit i still dont get it
<pie__> like its not like i want to inflate your genius complex or anything
<pie__> maybe its just that i have to deal with so much crap i dont have time to learn this stuff myself :P
<whitequark> so yeah no i just had an unhealthy fascination with older tech as a child, hence turbo c++ and knowing a few things about dos or ibm pc/xt
<pie__> and now im complaining instead of studying moar
<whitequark> not because i actually like older tech, we just had books lying around
<whitequark> and... on top of that i recently realized that with the amount of docs, it is utterly trivial to learn anything i want about tech of any age
<whitequark> from super old pc floppy drive controllers to the way pcie works on two year old intel chipsets
<whitequark> like people tend to have perception of both being some sort of in-depth knowledge worth lots of respect
<rqou> um... what about 90s stuff that is awkwardly digitized but bitrotting?
<whitequark> in reality you just open the fucking datasheet and read the fucking explanations
<rqou> e.g. APM, VLB, etc.
<whitequark> rqou: I actually don't know much about APM or VLB
<whitequark> well VLB is hilarious
<whitequark> APM I just know nothing about
<rqou> my father worked on PCs at that time and said, "yeah, VESA just makes shitty specs"
<rqou> :P
<whitequark> but also people who like old crap tend to really not like VLB and stuff
<pie__> lol
<whitequark> because it's not elegant in the way ISA etc is perceived to be elegant
<cr1901_modern> ISA *is* elegant :D.
* pie__ sighs
<cr1901_modern> You can make an I/O card from TTL logic. Simple, effective, and slow.
<pie__> standards orgs and crappy standards :P
<pie__> someone linked a rant about usb vs rs232 the other day, dunno if that was from this channel
<rqou> ISA never even had a standard afaik
<rqou> still had problems
<rqou> there's a story somewhere on the Old New Thing about a shitty PC that only worked if the graphics card was in the ISA slot closest to the CPU
<rqou> otherwise the signal integrity sucked too much for it to work
<rqou> my father mentioned that when he was working on PCs he saw a coworker actually debugging this same problem
<whitequark> cr1901_modern: strongly disagree about isa
<rqou> except they actually fixed it rather than saying "eh, ship it"
<cr1901_modern> whitequark: Well, I was kinda joking. It's concept of PNP is utterly broken
<whitequark> wat
<whitequark> you think devices identifying themselves to the host is somehow wrong??
<cr1901_modern> ISA Plug-n-Pray was really "Plug-n-Pray"
<whitequark> oh, ISA PNP
<rqou> ISA had PNP?
<whitequark> lol rqou
<whitequark> isa "had" "pnp"
<rqou> how does that work?
<whitequark> it's pnp not in sense of hotplug
<whitequark> but in sense of os identifying isa devices
<rqou> right, but i thought isa cards worked by cards just deciding "this is my address"
<whitequark> yes
<cr1901_modern> whitequark: My affection for ISA is that it's an easy bus to interface to, and I wish there was anything remotely similar in 2017 on modern PCs besides UARTs which have bandwidth slower than ISA.
<rqou> LPC?
<whitequark> ^
<whitequark> also, LPT
<whitequark> like, use a PCIe LPT card
<cr1901_modern> How do you attach your shiny new device to an LPC chip?
<whitequark> they have bandwidth that is only really limited by LPT being shitty electrically
<whitequark> cr1901_modern: LPC bus.
<rqou> wait wtf why is the isapnp spec a .rtf?
<whitequark> and it's broken out on the motherboard.
<rqou> thanks MSFT
<cr1901_modern> whitequark: I... was not aware of that
<whitequark> rqou: rtf is not an msft standard
<rqou> wait it isn't?
<whitequark> cr1901_modern: rqou: LPC is kind of crappy though
<whitequark> oh wait it is
<whitequark> hm
<cr1901_modern> I guess USB is the next best thing. By some metric of "best"
<rqou> aand apparently nautilus thinks it should open .rtf files in wine wordpad
<rqou> thanks
<pie__> rqou, yeeeeah i get that with images and internet explorer for some reason
<pie__> wine pls
<cr1901_modern> whitequark: Why is LPC crappy (well besides having its roots in ISA IIRC)?
m_w has joined ##openfpga
<whitequark> cr1901_modern: USB is reeeeally hard to interface with and then you don't get bounded latency easily anyway
<whitequark> well you have interrupt transfers (easy but super low bw) and isochronous transfers (hard and still not especially good guarantees)
<whitequark> and isochronous require usb2
<whitequark> so you need some sort of hardware controller
<whitequark> cr1901_modern: as for LPC
<whitequark> read the spec
<whitequark> LPC bus mastering is really awkward, LPC IRQs are clearly optimized for legacy compat and not elegance
<whitequark> in general LPC is not made to be easy to implement
<rqou> yeah i noticed that last time i looked at it
<rqou> also huh isapnp works by essentially hijacking certain IO addresses
<rqou> one of which is supposed to be unused??
<rqou> and one of which was previously read-only and is hijacked into a write-only register
<rqou> (0x2769 printer status)
<rqou> *0x279
<rqou> i guess this works
<cr1901_modern> whitequark: I respectfully disagree it's "just open the datasheet" if you want to know about how logical blocks/physical chips connect together, and the path the electrical signals take from CPU to I/O register on an expansion card.
<cr1901_modern> From experience, "just reading the datasheets" will not be enough, for instance, to get a PC XT running your custom code by themselves, thanks to DRAM refresh being implemented by hijacking the DMA controller.
<rqou> cr1901_modern: have you seen zet? http://zet.aluzina.org/index.php/Zet_processor
<cr1901_modern> rqou: I have! I never got around to trying it
<rqou> interestingly zet doesn't have a dma controller
<rqou> apparently you don't really need one for most programs
<rqou> (zet does dram refresh automatically "by magic")
<rqou> i asked my father and he said that the dma was also supposed to be used for disk io
<rqou> but zet doesn't have that either
<cr1901_modern> Part of the reason I resent modern SoCs and the like is this information about how logical blocks on a single chip and interfaces (pinouts/timings) between chips are underspecified so you really don't have a good idea what's going on between "inside the CPU" and "observable effect on the outside world"
<cr1901_modern> rqou: It was on the oldest MFM and IDE drives
<whitequark> cr1901_modern: this is literally described in an overiew section of intel datasheets
<whitequark> and then they go into even more detail elsewher
<whitequark> like, intel describes their on-chip interconnect in significant detail *because it matters*
<whitequark> and for most modern SoCs it's also true
<cr1901_modern> What do they use nowadays? QPI and DDIO?
<whitequark> you have like AMBA or stuff, they're either described to the level you talk about or actually open standards
<rqou> i thought AMBA/AXI aren't truly "open"
<whitequark> not truly open, but open enough to understand
<whitequark> cr1901_modern: QPI successor, what was it called
<rqou> iirc you aren't allowed to implement an ARM-compatible cpu with AMBA/AXI buses :P
<cr1901_modern> I like Wishbone/MiSoC designs (not an endorsement) :P
<whitequark> wishbone is shitty
<whitequark> rqou: enough for cr1901_modern's question
<whitequark> cr1901_modern: anyway I think your criticism is misguided
<cr1901_modern> So DDIO is a technology that is used to bypass main memory when reading data from a network card and put it directly in cache. Intel doesn't explain in any greater detail how it works from their website. Just that it "does".
<whitequark> all the things you claim aren't described ARE described
<rqou> it's hooked into the cache coherency/snooping logic
<whitequark> ^
<rqou> you need this for multi-socket anyways
<whitequark> it's kind of obvious how it works if you know what MOESI is
* cr1901_modern didn't know what MOESI was
<cr1901_modern> not that that's an excuse
<whitequark> pie__: regarding your flash stuff
<whitequark> "how'd I learn how it works"
<whitequark> by compiling and looking at what happens
<whitequark> there's an OSS compiler and OSS VM because flash's VM was used in early mozilla code
<whitequark> tracemonkey
<whitequark> rqou: regarding flash being hacked
<whitequark> no AVM2 isn't particularly ba
<whitequark> bad
<whitequark> it was just used for JIT spraying and such
<whitequark> flash itself had lots of API code not written wiht security in mind
<whitequark> sstuff like type ocnfusion issues and so
<whitequark> but these are prevalent even in modern JS engines written with that in mind
<whitequark> am going AFK now
<pie__> whitequark, thanks o/
<pie__> hopefully ill get somewhere faster than eventually :P
<whitequark> pie__: well tbh i'd say just use my code
<whitequark> no super good reason to rewrite it in haskell if you wanna write a bit
<whitequark> bot
<whitequark> interface with it across processes
<whitequark> the network code alone is bad enough
<whitequark> anyway ur welcome to ask me about flash
<pie__> im interested in program analysis too though. to be fair one of these projects at a time would be neough
<whitequark> pie__: also re genius complex, jesus fuck no, i'm extremely well aware of everything i don't know and will never know
<pie__> i didnt mean it that way :P
<whitequark> i do specifically lie awake at night thinking about there literally being not enough time in a human life to learn everything i want to know
<cr1901_modern> whitequark: Your knowledge about technical topics is nearly a proper superset of what I know lmao
<whitequark> honestly i recommend you just get high on drugs and fuck with everyone and die happy instead
<pie__> yeah thats not for us i think
<pie__> :P
<whitequark> aw dang
<pie__> not for us driven men
<whitequark> cr1901_modern: spend more time reading papers and datasheets
<whitequark> pie__: (or women :p)
<pie__> heh
<whitequark> cr1901_modern: like, try to read one paper per day
<whitequark> or at least per week
<pie__> reading more is generally a good idea
<whitequark> same for pie__ about cs
<pie__> and decreasing unnecessary distractions
<pie__> tv, unnevessary facebook 9gag etc
<whitequark> i started with nothing known about cs
<rqou> no $FANCY_SCHOOL required? :P
<pie__> ofc you dont need to turn into a boring recluse
<cr1901_modern> That's part of my issue. Learning happens in bursts for me
<cr1901_modern> I'm working on it, but it's tough
<pie__> (though im more saying this to myself riht now haha)
<whitequark> i read papers, said a lot of stupid things on the web
<pie__> cr1901_modern, definitely tough
<whitequark> it got better though
<pie__> especially if youre not used ot it
<whitequark> it took a few years to get all the terminology but now it's very easy for me to grab a random paper and just read it
<whitequark> except the really terminology-heavy ones, type theory and such
<whitequark> used to be impossible
<pie__> something which we all know but i discovered recently is _attempting_ to drive yourself harder doesnt really work. at least it didnt for me
<cr1901_modern> it'll be a while before I'm used to it. It IS mentally exhausting (I don't want to sound like I can't/won't do it.)
<rqou> two hardest problems in CS are cache invalidation, naming things, and off by one errors :P
<pie__> you need to drive yourself but oyu need to be consistent and stay within limits
<whitequark> all i'm saying is, believe in yourself, you can learn it
<whitequark> don't give up thinking it's too complex / impossible to understand
<cr1901_modern> pie__: The biggest help for me has been to recognize when I'm exhausted, and just power through it. And reward myself afterward.
<pie__> what i mean is trying to spend all day learning is probably less effective than maybe 3 hours relatively focused every day
<whitequark> pie__: yeah absolutely
<cr1901_modern> whitequark: Ack. Thanks, I needed to hear that.
<pie__> and ofc im saying this but not practicing it
<whitequark> you have to learn letting yourself give up
<pie__> if somethings fucky
<whitequark> because in reality you will not forget about the thing and will return to it in a week anyway
<pie__> take a step back and think about what youre doing on a meta level
<whitequark> whereas if you exhaust yourself you will build up some sort of resentment towards it
<whitequark> and that will just make it harder to return unnecessarily
<whitequark> it takes time and introspection
<whitequark> this is actually one of the few genuinely valuable things school teaches you
<whitequark> HS, uni, whichever school
<cr1901_modern> whitequark: It's psychological that I'm afraid I *will* forget between the time I take a break and return to it.
<whitequark> the rest can be done just by asking around and spending time reading
<whitequark> cr1901_modern: make a bookmark, write a blog post, w/e
<whitequark> and also
<whitequark> if you really do forget maybe it wasnt all that important anyway
<whitequark> the things you genuinely strongly desire to learn arent ones you will easily forget
<cr1901_modern> Fair enough. On that note, back to learning what a monad is
<pie__> assuming you properly learn them in the first place :P
<pie__> cr1901_modern, do not try to learn the monad
<pie__> learn around the monad
* pie__ waves arms
<cr1901_modern> A bit too late. The Maybe monad clicked a few days ago, so there's progress.
<pie__> \o/ :D
<pie__> way ahead of me
<pie__> ive wrote like 20 lines of code total
<pie__> ok now ive completely lost what i was doing
<pie__> thank god for keeping windows and tabs open
* whitequark sighs
<pie__> (someone say something about focus?(
* pie__ pats whitequark
<whitequark> pretty sure all of you already know hwat a monad is
<whitequark> the word is more scary than the concept by 1000 times
<pie__> i was going to say that
<pie__> even im scared of it even though im 90% sure monad fear is a social construct
<rqou> i just know that every single time i tried to look at haskell it was full of all sorts of weird arrow-like shapes and i couldn't understand anything that was going on
<pie__> rqou, thats just syntactic sugar
<pie__> or, well not necessarily
<pie__> but operators, yknow
<whitequark> haskell is stupid
<pie__> sure me saying that doesnt help xD it does take some getting used to
<whitequark> the language is just kinda bad
<whitequark> the community is bad
<pie__> im more interested in idris
<pie__> yeah?
<whitequark> the documentation is crappy
<whitequark> don't kcik yourself if you dont understand haskell
<whitequark> thats mostly haskell's failure
<rqou> and the conferences? :P
<rqou> (too soon?)
<whitequark> no idea
* rqou was attempting to reference lambdaconf
<pie__> why do you think its bad
<whitequark> oh you mean lambdaconf? thats not representative of haskell conferences
<whitequark> ucfp is
<whitequark> icfp
<pie__> why do you think haskell and its community are bad?
<pie__> (i wouldnt know)
<whitequark> lambdaconf is ran by dumb people that are, of 2nd lambdaconf, outright unethical, what with tax avoidance and stuff
<whitequark> they attract smart but antisocial in shitty ways people
<whitequark> the entire thing is incredibly overblown
<whitequark> like honestly id ont think it is as bad as many say. i mean sure, white supremacists keynoting on a conf, is that really new to you? you must be new to like, anglosphere
<whitequark> it's bad but it's ALSO a manufactured controversy to a very large degree
<whitequark> idont wish to discuss it further. on that note.
<azonenberg> oooook so
<azonenberg> on topic
<azonenberg> have a fun question
<azonenberg> Suppose i have a device with x1 and x2 drive strength on an output buffer
<azonenberg> Is it reasonable to assume the x2 is exactly double the drive current of x1?
<rqou> no :P
<azonenberg> Why do you say that?
<azonenberg> So, here's my thinking
<rqou> idk, normal silicon weirdness :P
<azonenberg> I can measure the difference in propagation delay between pin A to B with x1
<azonenberg> and A to B with x2
<azonenberg> (the fets are right next to each other, should be very well matched)
<whitequark> rqou: pie__: re haskell community: one of the people who created haskell dislikes the haskell community with its worship of cs-themed obfuscation so much that he gave up
<azonenberg> Anyway, so here's the extrapolation
<whitequark> like, it was created by cs people for whom cs terminology was *natural* and it turned into a wankfest by people for whom it's *unnatural*
<azonenberg> Suppose i treat this as a system of 2 equations in 2 unknowns
<whitequark> for precisely that reason
<azonenberg> I know (input buffer delay + route delay) + (output x1 delay)
<whitequark> as for why it's a bad lanugage.... all the language extensions fracture it, the package management is bad, typeclass coherence is a bad idea
<whitequark> the way it's done in haskel
<azonenberg> And I know (input buffer delay + route delay) + (output x2 delay)
<whitequark> since you don't import instances
<azonenberg> Assuming (output x2 delay) = 0.5 * (output x1 delay)
<whitequark> into scope
<pie__> whitequark, D:
<azonenberg> We can solve for (input buffer delay + route delay) and (output x1 delay) individually
* rqou mumbles something incoherently about parasitic capacitances
<whitequark> anyway i finally want to do something useful, and not spam openfpga with offtopic discussion...
<azonenberg> rqou: This isn't going to be exact
<azonenberg> BUT
<azonenberg> my conjecture is that it will be a) close enough to enable a useful degree of analysis
<rqou> oh in that case? probably works
<azonenberg> and b) since the values sum the same, the final timing numbers will be the same
<azonenberg> i.e. i have to guesstimate the fraction of the sum to assign to each component as i cant easily measure
<azonenberg> but the choice of where to partition is somewhat arbitrary and not really important
<azonenberg> I can decap a greenpak and land fib pads on the die at some point
<azonenberg> to get a more accurate ratio
<azonenberg> but for now i'll use 0.5
<azonenberg> From that, i gather that, on the specific slg46620 die i have in my zif right now
<azonenberg> the pin13 to 15 delay is 12.149 ns at x2 and 15.234 at x1, or a delta of 3.085 ns
<rqou> heh the zif/rest of the environment probably has a much bigger parasitic capacitance than any potentially-not-on drive FETs
<azonenberg> So our approximation says, OBUF x2 delay is 3.085
<azonenberg> OBUF x1 is 6.170
<azonenberg> And IBUF + crossbar is 9.064
<rqou> wait this is all in ns?
<azonenberg> Yes
<rqou> wow that's slow
<azonenberg> This is at 3.3V core
<azonenberg> at 5V VCCINT it's faster
<azonenberg> But yes its not super fast
<azonenberg> Which is why coolrunner still has a place
<azonenberg> despite being larger mechanically, more expensive
<azonenberg> it's in-system programmable, not OTP, large logic density, and faster
<azonenberg> Next step is going to be to extrapolate an input buffer delay
<azonenberg> i'm gonna try to measure an input buffer with and without a schmitt trigger
<azonenberg> and guesstimate what fraction of the total input buffer delay that is, maybe based on some timing numbers from coolrunner which is also a 180nm cmos process
<azonenberg> i.e. assume the ratio of coolrunner input delay with/without schmitt trigger
<rqou> oh wow coolrunner's schmitt trigger is slow too
<azonenberg> is equal to the ratio of greenpak delay with/without schmitt trigger
<rqou> 4ns on a 32a-6
<rqou> (max)
<azonenberg> Based on that, i can guesstimate the total input buffer delay
<azonenberg> and from that, extrapolate the pin to pin crossbar delay
<azonenberg> again, it wont be accurate necessarily
<azonenberg> but i need *a* number for timing analysis to work with
<azonenberg> And as long as the sum comes out the same, it doesnt matter
<azonenberg> I can adjust the ratio and re-calibrate once i get data from fib probing
<felix_> rqou: yep, patching the idcode and either then patching or disabling the outer crc works
<lain> disabling the outer crc seems like a bad plan ;)
pie___ has joined ##openfpga
pie__ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
pie___ has quit [Remote host closed the connection]
<felix_> lain: sure. but for a first test if it's really only the idcode that was sufficient ;)
<azonenberg> felix_: it's been tested
<azonenberg> it worked
<azonenberg> right?
<felix_> yep
<rqou> would you get sued if you tried to ship a product like this?
<rqou> or does first sale doctrine apply here?
<lain> I wouldn't chance it personally
<rqou> what about "hx4k" parts programmed via icestorm?
<azonenberg> yeah i consider it a cool party trick but i wouldnt attempt to exploit it at scale
<felix_> i definitely wouldn't call isa elegant. iirc it doesn't even have a proper spec (timings aren't specified). i've spent multiple days debugging weird isa problems at some company... well, the legacy (non-busmastering) isa dma doesn't work when using a pci->isa bridge and even with a lpc->isa adapter or a native isa bus on a new x86 soc the bus timing can still be a problem (dma and interrupt request timin
<felix_> gs are still diffenrent)
<rqou> solution: don't use bus-mastering ISA
<felix_> i'd strongly avoid shipping a product with a patched bitstream
<rqou> don't be a masochist :P
<rqou> oh wait ISA has a NON-bus-mastering DMA?
<felix_> well, those isa cards still work; only the hosts die and need to be replaced...
<felix_> i dno't really remember, but iirc yes, but it's very unusual
<rqou> wtf isa
<felix_> lpc >> isa. sure it shares a lot of problems isa had, but it has a proper spec and less wires
<rqou> new solution: use an fpga with it's own piece of ram and bounce buffers
<rqou> (i can see how that could stop working too)
<felix_> rqou: you can implement and release your own axi stuff. you're not allowed to call it axi though. guess why the risc-v people call it nasti ;) and from technical point i rather strongly prefer axi over wishbone
<lain> lol @ nasti
<azonenberg> sounds kinda like mips-1
<azonenberg> patents are expired
<azonenberg> you can implement your own mips-1 cpu
<azonenberg> you just cant call it mips :p
<azonenberg> b/c patents are expired, but not trademarks
<lain> ™
<felix_> speaking of nasty stuff: in borland c++ 5 (i think it was 5) you could disable scoping. and yes, i've seen that "feature" being used...
<azonenberg> o_O
<rqou> wtf
<lain> felix_: what fresh hell is this!?
<rqou> although something that might be useful might be "disable SFINAE"
<rqou> :P