<pie_> :D
<qu1j0t3> shop cats ftw
<egg|egg> "tick(s)"? that sounds like something that's going to be a pain to internationalize :-p
<egg|egg> something something CLDR
<jn__> there should be a way to express "singular or plural" in most languages
<rqou> some languages have multiple singular/plural forms though
<rqou> e.g. slavic languages
<jn__> well, then you let the reader choose any of them
<rqou> oh and apparently some languages have singular, dual, and plural
<egg|egg> rqou: and then there are languages that have even more forms :D
<egg|egg> rqou: enjoy the madness of i18n cldr.unicode.org/index/cldr-spec/plural-rules
<jn__> egg|egg: i haven't done much l10n/i18n at all, but i think strings that actually care about cardinality are more work to translate
<rqou> yeah, i've taken a basic linguistics course and know about a bunch of these features
<whitequark> *sigh* kids
<whitequark> you know gettext solved this, right?
<whitequark> you write an expression that evaluates to the form number and then select a message based on that
<whitequark> it's tedious and you have to split messages a lot but it's a solved problem by and large
<egg|egg> yes, I know about how to do this, it's my job >_>
<egg|egg> that's basically what the CLDR plural mechanisms are about
<egg|egg> whitequark: CLDR also handles more involved stuff, like fractions (which also get handled differently depending on language, http://cldr.unicode.org/index/cldr-spec/plural-rules#TOC-Fractions1), which apparently gettext doesn't https://github.com/mlocati/cldr-to-gettext-plural-rules#reference
theMagnumOrange has joined ##openfpga
<egg|egg> also I should do like tuco and sleep, goodnight whitequark rqou jn__ et al.
egg|egg is now known as egg|zzz|egg
* egg|zzz|egg jumps on server rack
<rqou> lol
<rqou> i actually need to leave right around now too thanks to social obligations
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
<cr1901_modern> https://twitter.com/whitequark/status/874082442793156608 I reconcile my disdain for software that has a lot of code paths/features as "essential complexity", but that doesn't mean I like it. Esp b/c after a certain code base size it becomes impossible for a single person or even multiple people to reason about how layers interact). Can we just conclude that humans are awful w/ their wildly varying needs, and that if we got rid
<cr1901_modern> s/conclude/agree/
<whitequark> if you're incapable of navigating LLVM's codebase that doesn't mean that everyone is. it likely means that you should get better at navigating codebases.
<whitequark> and no, suggesting that humans having wildly varying needs are "awful" doesn't merit a response other than "get out"
<azonenberg_work> Aaand back to playing reworkctf for a bit while waiting for FPGA bitstream to compile
<azonenberg_work> trying to debug my greenpak characterization code
<azonenberg_work> i can measure rising/falling edges as opposite phases of the same test waveform
<azonenberg_work> vs one rising and one falling test then averaging 100 times
<azonenberg_work> but the new firmware is randomly reporting a delay of 0 ps for falling edges
<azonenberg_work> Some, but not all, of the time
pie_ has quit [Ping timeout: 260 seconds]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<rqou> hey azonenberg azonenberg_work available right now?
<azonenberg> rqou: back
<rqou> anyways, i think the xc2c128 die layout looks like this: https://goo.gl/photos/VpVf3gviEpfRixjK7
<rqou> so the .map file is mirrored left/right
<azonenberg> Let me see
<rqou> and the right group of 4 FBs is upside-down
<rqou> but the bits aren't flipped up/down, the order is just changed
<azonenberg> Totally plausible
<azonenberg> Would make sense if it's a single physical shreg
<azonenberg> they want to keep the bit-to-bit hops short
<rqou> so on my scribble, the shreg looks like it's an S shape, not the obvious U shape
<azonenberg> Well when we decap we can get more detailed info on the layout
<rqou> so FB1/3 are last and FB6/8 are first
<azonenberg> Any thoguhts on the 256+ yet? or too soon still
<rqou> i have a similar scribble, sec
* azonenberg is debugging greenpak timing analysis now
<azonenberg> you have no idea how awesome it is to have multiple toolchain projects in progress now lol
<jn__> it's like building an iron foundry in order to make yak-shaving tools
<rqou> azonenberg: I think 256 looks like this: https://goo.gl/photos/UNQubA3RV68jc6y48
<azonenberg> jn__: no i meant
<azonenberg> having both coolrunner and greenpak projects actively progressing
<rqou> so as i mentioned on twitter there seem to be two major designs
<rqou> "OR terms in the middle of AND terms" and "OR terms on the side of AND terms"
<jn__> azonenberg: progress is nice, of course
<rqou> 32/64/256 are the former and 128/384/512 are the latter
<azonenberg> rqou: I consider the devices "low end" (4 metal layers, FBs stacked vertically around a single spine, no buried macrocells, no SSTL etc)
<azonenberg> and "high end" (5 layers, FBs in a H shape with multiple columns and routes between them, buried macrocells, SSTL)
<rqou> but then 256 is weird
<azonenberg> interesting to note the division isn't quite as clean as that
<azonenberg> exactly
<azonenberg> all the others fall cleanly on the boundaries
<rqou> also, the bit ordering for the "OR terms on the side" is really really strange
<rqou> hints to it being almost certainly a tree, not the naive "straight line"
<azonenberg> I pretty much knew the PLA was a tree already
<azonenberg> I wanted to see the full structure
<azonenberg> i have some images but not enoguh to fully RE it
<azonenberg> there seem to be "leaf" and "upper level" nodes in the AND array
<azonenberg> i havent looked at the OR
<azonenberg> (in the 32a)
<rqou> so i was saying something about that last night
<rqou> if you look at this photo: https://siliconpr0n.org/archive/lib/exe/fetch.php?cache=&media=vendor:xilinx:xc2c32a_bf_neo5x.jpg
<rqou> the "OR" part in the middle of each FB looks like a "solid reddish rectangle"
<azonenberg> Yes
<rqou> but if you look at this one: https://siliconpr0n.org/archive/lib/exe/fetch.php?cache=&media=azonenberg:xilinx:xc2c128_bf_neo5x.jpg
<azonenberg> Although, the lower level image shows it off better
<rqou> the "solid reddish rectangle" isn't there
<azonenberg> Innnteresting
<azonenberg> The 128 is, i think
<azonenberg> still 4 metal layers in a single column
<rqou> but it looks like there is a "solid reddish rectangle" is on the left/right hand side instead
<azonenberg> So it looks like we have clean-blurry-clean
<azonenberg> 32/64 low end
<azonenberg> 384/512 high end
<azonenberg> 128-256 blurry
<azonenberg> i feel like we really need delayered shots of all coolrunners
<rqou> anyways, as an extra note, in the https://siliconpr0n.org/archive/lib/exe/fetch.php?cache=&media=azonenberg:xilinx:xc2c64a_bf_neo5x.jpg picture, the red artifacts look exactly the same as the 32a
<azonenberg> yes, its just two copies of the same FB block
<azonenberg> I did not notice the dissimilarity in the larger devices until you pointed it out, though
<azonenberg> i had only spent any real time looking at the 32 and 64
<rqou> oh btw the 32a and 64a macrocell bits are in a different order
<rqou> hmm if i look more closely at the 128 die
<rqou> the bottom half is mirrored
<azonenberg> Does that mess with your theory?
<rqou> but the way the jtag register seems to be constructed "un-mirrors" it
<azonenberg> is it possible it's a U shape?
<rqou> it does match
<azonenberg> and not a S/
<azonenberg> i.e. U with a "twist" added by the mirroring
<azonenberg> or something
<rqou> so if you look at my scribbled-on version of the pinout diagram, FB5 is on the same side as FB1
<rqou> if it were a U, FB5/7 should be below FB2/4
<rqou> but it's not
<azonenberg> Hmm
<azonenberg> Yeah
<azonenberg> Well, lots of good insights coming out of this work :)
<rqou> hmm so i think i misspoke earlier
<rqou> so the entire .map is mirrored left/right
<rqou> and the "bottom half stuff" seems like it should be mirrored top/bottom on the die
<azonenberg> Theory: physical addresses move out from central horizontal jtag register
<rqou> but the hypothesis about the JTAG register being an S shape means that it gets "unflipped top/bottom" in the register
<rqou> yeah exactly
<azonenberg> hmmmm
<azonenberg> But
<azonenberg> that would mean the physical shreg is a U not a S
<azonenberg> L-R in top, R-L in bottom
<azonenberg> or vice versa
<azonenberg> no?
<azonenberg> the jtag reg does not do anything in the verticla axis
<azonenberg> Physical addresses move in/out, not up or down
<azonenberg> i.e. the sram word lines are u-shaped
<rqou> hmm but a U shaped sreg would make it hard for TDO to be on the opposite side of the die as TDI (which it is)
<azonenberg> Hmmm that is a fun wrinkle
<azonenberg> it is on all dies?
<azonenberg> not just the linear ones like the 32?
<azonenberg> That would fit better with a S shape
<azonenberg> Suggesting there'd be one really long right-to-left wire in the middle
<rqou> it is on all parts
<azonenberg> hmmmmm
<azonenberg> oooh
<rqou> i wonder if you can time it somehow?
<azonenberg> what if
<rqou> by deliberately clocking the jtag engine too quickly
<azonenberg> no, wait
<azonenberg> new hypothesis
<azonenberg> in larger parts the jtag shreg is two N/2 bit registers
<azonenberg> Initially, both are dontcare
<azonenberg> You clock in the first N/2 bits
<azonenberg> push it to the second register
<azonenberg> in parallel
<azonenberg> then clock in the second N/2
<azonenberg> Both move left to right
<azonenberg> But there's no long wire
<rqou> ahh that sounds quite possible
<rqou> but what does the programmer qualification doc say?
<azonenberg> This would just be done with a mux on the second bank of FFs that loads them after N/2 TCK clocks when configuring the device
<azonenberg> pseudo-verilog
<azonenberg> reg[127:0] shreg_a;
<azonenberg> reg[127:0] shreg_b;
<azonenberg> reg[7:0] count;
<azonenberg> always @(posedge tck)
<azonenberg> shreg_a <= {shreg_a[126:0], tdi}
<azonenberg> shreg_b <= {shreg_b[126:0], 1'b0}
<azonenberg> count <= count + 1
<azonenberg> if(count == 127) shreg_b <= shreg_a
<azonenberg> tdo <= shreg_b[0]
<azonenberg> Sound plausible?
<rqou> sounds quite inelegant, but plausible
<rqou> probably better than a huge wire
<rqou> anyways, i think for now unless we have evidence to the contrary i'm going to implement "crbit" on the larger parts assuming the top/bottom are mirrored
<rqou> and that the entire .map is mirrored left/right
<rqou> lots of fun how we have three different addressing schemes now: crbit/physical, jtag, and logical
<azonenberg> lol
<azonenberg> i was thinking of having crbit be in jtag space
<rqou> crbit/physical and jtag are easy to interconvert
<rqou> oh so you don't actually care about physical physical space?
<rqou> yeah that's a lot less error-prone
<azonenberg> Why do we care about die coordinates, except for like FIBing the die?
<rqou> :P
<rqou> i thought that's what you wanted crbit for?
<azonenberg> i would rather have the file format work in jtag space
<rqou> ah ok
<azonenberg> then just have diagrams showing the physical position of the layout
<azonenberg> i.e. TDI here, TDO here, FB0 here, FB1 there
<azonenberg> etc
<rqou> so you can write your own "azonenberg special physical die space" :P
<azonenberg> i didnt plan to ever have any software work in that
<rqou> except the visualizer?
<azonenberg> just hand drawn address maps on die photos
<rqou> ah ok
<azonenberg> hmmm maybe the visualizer should be physical
<rqou> so now there's only two address spaces
<azonenberg> that would make more sense
<azonenberg> But easy to convert in the rendering engine
<rqou> hmm how about outputting svf?
<rqou> (importing will probably not be added)
<azonenberg> so, right now
<azonenberg> libjtaghal can take a jed and program a 32a/64a
<azonenberg> i have no support for largr devices or svf
<rqou> oh yeah btw i'm going to be re-testing all the macrocell bits to make sure they don't change meanings across devices: https://docs.google.com/spreadsheets/d/13LDLje02CDh3-69LJP49AgiSppYbbDbR-N80leMNENU/edit?usp=sharing
<openfpga-github> [openfpga] azonenberg opened issue #104: Figure out how to properly package / install static timing data files https://git.io/vHSGL
<rqou> oh azonenberg: can $readmemb files contain comments?
<azonenberg> rqou: Dont know
<azonenberg> i know you can specify addresses to make them sparse
<azonenberg> but its been a while since i've read the LRM
<azonenberg> how's that for accurate blind drilling? :D
<rqou> if they can contain comments, crbit can be $readmemb-compatible
<azonenberg> freehand milling to expose an inner layer short
<rqou> for when we write xc2c-model.v :P
<azonenberg> Why does crbit need to have comments?
<azonenberg> the code is open source, we'll have a library for parsing it
<rqou> speed grade/package?
<azonenberg> Does it matter?
<azonenberg> physical layout doesnt care about package
<azonenberg> or speed
<rqou> for correct round-trip conversion it kinda does
<azonenberg> eh, fine
<rqou> xilinx .jed files already have hot comments :P
<azonenberg> how about you define a magic address at the end of the array or something for the idcode then?
<azonenberg> that would make it testable in the verilog model
<rqou> can $readmemb files be jagged?
<rqou> eh, i guess you can pad it
<azonenberg> also
<azonenberg> quick googling suggests both C comment syntaxes are accepted in readmem
<rqou> nice, i can have a hot comment :P
<rqou> hot comments ftw :P :P
<azonenberg> Maybe some time this week or next, if i have a chance
<azonenberg> i'll try to bang up a 32a-only version of the xc2c sim model
<azonenberg> See if it will fit on an xc7a100t :p
<azonenberg> And, then the best part
<azonenberg> connect a xilinx jtag dongle to it
<azonenberg> and see if ISE correctly IDs it as, and can program it as, a 32a lol
<rqou> lol wtf
<azonenberg> that was the end goal, right?
<azonenberg> Be able to program our emulated coolrunner as if it was a real CPLD
<azonenberg> And then make a pmod or something with a real coolrunner
<rqou> we also need to find a read-protect bypass :P
<azonenberg> and do cycle-by-cycle equivalence checks between the model and real chip
<azonenberg> Yes
<azonenberg> As soon as the FIB at work is up and running again i'm going to work on that
<rqou> I wonder if you can non-invasively glitch it
<azonenberg> then try to develop a non-invasive attack
<azonenberg> that's an ongoing research question
<azonenberg> i am 100% certain i can defeat it invasively
<azonenberg> and i think i know exactly where
<rqou> also, reflashing idcode? :P
<azonenberg> That would be cool too
<rqou> did you ever figure out what the "extra" pads are for?
<azonenberg> No, that's another open question
<rqou> hmm for crbit, do you care about mirroring left/right?
<rqou> if not I'll probably mirror it to match the physical die
<azonenberg> I thought the intention of crbit was to be in jtag space
<azonenberg> so it'd be something you could directly program the device with
<rqou> right, but mirroring left/right can vary
<rqou> depending on convention
<rqou> so either "bits on left are shifted in first" or "bits on right are shifted in first"
<rqou> you know, the conventional source of bit ordering bugs :P
<azonenberg> Lol
<azonenberg> No real preference there
<rqou> also I just realized, I think the part might still work if you do that
<azonenberg> then make a wiki page to document
<rqou> just all FBs will be mirrored
<azonenberg> yes, all ios etc would be mirrored
<azonenberg> global config would be borked though
eduardo has joined ##openfpga
<rqou> oh right
<azonenberg> but combinatorial would probably work
<rqou> the global config really is just randomly shoved in places
<azonenberg> it is
<azonenberg> they just had to stick it somewher
<azonenberg> although i am curious if the gck muxes are near that
<azonenberg> the io standard bits totally dont belong where they are :p
<rqou> testing this is going to be a pain
<rqou> the entire openfpga project needs more tests
<azonenberg> Totally aggreed
<rqou> unfortunately there isn't a really good way to test essentially what is "does my mental model match this physical reality" other than "check very carefully"
<azonenberg> HiL FTW
<rqou> sure, but HiL is much more effort than conventional software testing
<rqou> and we don't even have boards for the 384/512
<rqou> but yeah, I'm about to do a round of "check very carefully"
<rqou> really annoying that we couldn't come up with a code example to force combinatorial buried feedback
<azonenberg> yeah
<azonenberg> also
<azonenberg> 384/512 support will probably not ever be important
scrts has quit [Ping timeout: 246 seconds]
<azonenberg> i'm inclined to simply say we'll do best effort but have not tested on hardware
<azonenberg> and leave it at that
<rqou> but what if someone wants to make a next gen SystemACE? :P :P
scrts has joined ##openfpga
<azonenberg> Tell them to get their head examined
<azonenberg> duh :p
<rqou> or do it with a uC? :P
<rqou> so i asked my father earlier about "wtf is the point of the 384/512 macrocell cplds?"
<rqou> and he said "oh yeah, i used a 512-MC cpld back in the day"
<rqou> it was a scatter-gather dma controller, and FPGAs of the era weren't fast enough / didn't have deterministic enough timing
<rqou> apparently my father said that that particular design was done on a brand-new (at that time) altera product line
<rqou> and the FAEs used it to show off how good altera CPLDs were :P
<azonenberg> lol nice
<azonenberg> and when you say deterministic
<azonenberg> do you mean run to run? chip to chip?
<azonenberg> my understanding is cpld/fpga routing fabrics have similar ptv variation
<azonenberg> but tminig closure is easier on cpld
<rqou> er, i meant different paths pin/pin
<rqou> this was in the "cpu has a big parallel bus" era
<rqou> the dma controller was specifically designed to steal cycles from the cpu by asserting some bus hold/not ready pin
<azonenberg> yeah but what i mean is
<azonenberg> skew of <1 clock shouldnt matter right?
<rqou> this might have been asynchronous
<rqou> also fpga pin-to-pin delays used to be sloooow
eduardo has quit [Ping timeout: 268 seconds]
eduardo has joined ##openfpga
<rqou> azonenberg: something is weird with the 64a "terminate" option
<rqou> when I change it from pullup to float, not all macrocells change
digshadow1 has quit [Read error: Connection timed out]
m_t has joined ##openfpga
massi has joined ##openfpga
pie_ has joined ##openfpga
qu1j0t3 has quit [Ping timeout: 260 seconds]
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
<pie_> azonenberg, re:reworkctf, seems neat
<pie_> i need this
m_t has quit [Quit: Leaving]
<pie_> azonenberg_work, hypothetically would it be possible to buy these at some point or something
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
<openfpga-github> [openfpga] rqou pushed 9 new commits to master: https://git.io/vHSao
<openfpga-github> openfpga/master 803e350 Robert Ou: xc2bit: Test the slew rate bit on all the other sizes
<openfpga-github> openfpga/master 0919562 Robert Ou: xc2bit: Add a test for the slew rate bit for 32-MC
<openfpga-github> openfpga/master e10c2f4 Robert Ou: xc2bit: Add a very crude testing framework...
qu1j0t3 has joined ##openfpga
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
amclain has joined ##openfpga
eduardo_ has joined ##openfpga
eduardo has quit [Ping timeout: 260 seconds]
Zarutian has joined ##openfpga
m_w has joined ##openfpga
DingoSaar has quit [Remote host closed the connection]
DingoSaar has joined ##openfpga
DingoSaar_ has joined ##openfpga
DingoSaar has quit [Ping timeout: 260 seconds]
indy has quit [Ping timeout: 240 seconds]
kristianpaul has joined ##openfpga
indy has joined ##openfpga
<azonenberg> pie_: the design files are on github
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
massi has quit [Remote host closed the connection]
DingoSaar_ is now known as DingoSaar
DocScrutinizer05 has quit [Remote host closed the connection]
DocScrutinizer05 has joined ##openfpga
bercut has joined ##openfpga
bercut has quit [Client Quit]
Hootch has joined ##openfpga
scrts has quit [Ping timeout: 255 seconds]
scrts has joined ##openfpga
Hootch has quit [Read error: Connection reset by peer]
eduardo_ has quit [Ping timeout: 240 seconds]
pie_ has quit [Changing host]
pie_ has joined ##openfpga
eduardo_ has joined ##openfpga
<rqou> azonenberg: 512 has inverted IO standard bits
<rqou> even compared to 384
digshadow has joined ##openfpga
<azonenberg> rqou: wut
<azonenberg> now i understand why it was so awesome
<azonenberg> that 7 series was a nice clean orthogonal design
<rqou> hey, coolrunner-ii seems to be mostly orthogonal for everything else
<azonenberg> Yeah its better than say greenpak
<azonenberg> lol
<azonenberg> where no two chips have anything in common :P
<azonenberg> ok its not quite that bad
<azonenberg> but like, the LF oscillator on the 46620 and 46140 are not the same frequency
mtp has quit [Quit: Who ever quits IRC?]
<rqou> at least as far as i've tested I haven't found any macrocell bits get encoded differently yet
<azonenberg> :)
<azonenberg> just the big <128 and >=128 split for the sstl etc support?
<rqou> yeah
<rqou> although our notes file has an error for the "Clk" bits
mtp has joined ##openfpga
mtp has joined ##openfpga
mtp has quit [Changing host]
<rqou> i need to update that file
<rqou> i also haven't tested Oe because of how much effort that is
<azonenberg> Makes sense
<rqou> or the "non-obvious" INz/FB bits because we never got ISE to generate those
<azonenberg> lol
<azonenberg> Yeah
<azonenberg> Welp
<azonenberg> also
<rqou> also hmm i swear last night i saw something weird happening with the Tm bit on 64a
<azonenberg> How close are you to being able to make a jed-to-crbit converter?
mifune has joined ##openfpga
mifune has joined ##openfpga
<rqou> but I can't reproduce right now
<rqou> i'm still doing a final round of "compare with ISE"
<azonenberg> ah ok
<rqou> and writing tests
<azonenberg> because i wanted to try writing a coolrunner verilog model soon
<rqou> (not very good tests, but we now have tests)
<azonenberg> LIke, maybe even later today
<azonenberg> and being able to $readmem a bitstream would be a lot more convenient than dealing with the mess that is JED
<rqou> because testing is hard, I have copied the firefox "reftest" mechanism
<rqou> where the tests just compare the program output with the reference output
<azonenberg> as in you make a bitstream and verigy it decodes right?
<rqou> and if it's different, the test fails
<azonenberg> yeah
<azonenberg> That works lol
<azonenberg> Just means you need lots of data files
<azonenberg> also ther
<rqou> but this means that if you change anything, tests break and you have to update them
<azonenberg> Yes
<azonenberg> Thats the problem :p
<rqou> but at least this documents what you've changed and how
<azonenberg> Also
<azonenberg> there should be a wiki page for the crbit file format
<azonenberg> if it doesnt exist yet
<rqou> nothing exists yet; working on it
<azonenberg> Ok
<azonenberg> Also, at least initially
<azonenberg> i am not going to model the timing of the config process
<azonenberg> i.e. if you send the right instructions on the jtag iface the timing wont matter
<azonenberg> but my first implementation won't even have jtag
<azonenberg> it'll be fabric only
<azonenberg> i will also ignore the iostandard bits rather than attempting to do partial reconfig on the FPGA :p
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
<azonenberg> rqou: also re the reftest stuff
<azonenberg> can you move that to the tests/ directory?
<azonenberg> and not under src?
<azonenberg> it seems to make more sense to keep all the tests in one spot
<azonenberg> also why is there a second src dir under xc2bit?
<rqou> so not right now I can't
<rqou> the tests blindly assume reftests is in the cwd right now
<rqou> and there's a second src dir because Cargo wants it that way
* azonenberg adds ticket to fix the tests later
<openfpga-github> [openfpga] azonenberg opened issue #105: Refactoring: xc2bit reftests should be in the tests/ directory https://git.io/vHHUH
<openfpga-github> [openfpga] rqou commented on issue #105: Right now the tests assume that the reftests/ directory is found immediately in the current working directory. This needs to be replaced with a new mechanism to correctly find the project root. https://git.io/vHHTU
pie_ has quit [Ping timeout: 260 seconds]
pie_ has joined ##openfpga
<cr1901_modern> azonenberg: This isn't jittering in the electronics sense, but I think you'll like it as a visualization aid: http://www.perceptualedge.com/articles/visual_business_intelligence/the_datavis_jitterbug.pdf
<cr1901_modern> for your timing measurements*
<rqou> huh it's pretty tricky for force XorIn to all the possible combinations
fpgacraft1 has quit [Quit: ZNC 1.7.x-git-709-1bb0199 - http://znc.in]
fpgacraft1 has joined ##openfpga
<openfpga-github> [openfpga] rqou pushed 11 new commits to master: https://git.io/vHH3B
<openfpga-github> openfpga/master 09e7c75 Robert Ou: xc2bit: Add tests for st bit
<openfpga-github> openfpga/master 7c3e74f Robert Ou: xc2bit: Add tests for inz bits
<openfpga-github> openfpga/master b3be044 Robert Ou: xc2bit: Fix 512-MC io standard...
<openfpga-github> [openfpga] rqou pushed 1 new commit to master: https://git.io/vHHGt
<openfpga-github> openfpga/master 31d97c2 Robert Ou: xc2bit: Fix bug with 32A ZIA encoding...
<pie_> can IANASE be a thing; i am not a security expert. akin to IANAL
<pie_> well i mean it doesnt have a sex joke in it though
<openfpga-github> [openfpga] rqou pushed 1 new commit to master: https://git.io/vHHGq
<openfpga-github> openfpga/master 9760a5b Robert Ou: xc2bit: Add a test for the 32-macrocell ZIA
mifune has quit [Ping timeout: 240 seconds]