<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>
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
<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