<rqou>
so there's groups of 3 ascending/descending, with a cluster of 12 at the beginning
eightdot has joined ##openfpga
<rqou>
wtf the 128 "OR" block is so tutally out of order
<rqou>
*totally
mifune has joined ##openfpga
mifune has joined ##openfpga
mifune has quit [Client Quit]
<rqou>
azonenberg: i can't quite explain what i mean very clearly, but the way the PLA bits are arranged in the 128 bitstream match the visible wires on the die photo
<rqou>
the wires on the top layer seem to be grouped into groups of 3
<rqou>
and if you line up the bits with the photo, you can see how they match
eightdot has quit [Ping timeout: 268 seconds]
eightdot has joined ##openfpga
m_w has joined ##openfpga
<rqou>
azonenberg: from a not-100%-tested poking around, there are two ways to encode PLAs, three ways to encode macrocells, and only one way to encode the ZIA
<rqou>
PLAs: the 32/64/256 way vs the 128/382/512 way
<rqou>
macrocells: the 32 way, the 64 way, the 256 way, and the 128/384/512 way
<rqou>
the ZIA seems to use the same interleaving no matter what
<rqou>
i wonder which models were designed first? the 64 definitely seems very different and special
<rqou>
azonenberg: i'm starting to suspect the chips were designed 64->32->256->128->384->512
<rqou>
64 is the only weird one that doesn't have extra transfer bits on the sides
<rqou>
32 is then a cut-down 64 but somehow with the macrocell bits rearranged
<rqou>
256 looks like 4 tiled 64s
<rqou>
128 is completely different
<rqou>
and 384/512 look like 128 but with bigger quadrants
_whitelogger has joined ##openfpga
<azonenberg>
lol
<azonenberg>
wow
<azonenberg>
rqou: back
rk[ghost] has joined ##openfpga
<azonenberg>
o/ rk[ghost]
<azonenberg>
Me and rqou were just discussing some subtleties of the coolrunner bitstream
<rqou>
heh, nice hostname rk[ghost]
m_w has quit [Ping timeout: 260 seconds]
<azonenberg>
rqou: So, i have a pmod hooked up to a jtag dongle
<azonenberg>
gonna try and see if i can get my zynq to ID as a 2c32a by the end of tonight
<azonenberg>
then work on the minimal programming/readback stuff
<openfpga-github>
[openfpga] rqou pushed 2 new commits to master: https://git.io/vH52B
<openfpga-github>
openfpga/master aa01de4 Robert Ou: docs: Documented the mystery INz bit...
<openfpga-github>
openfpga/master 85cbfba Robert Ou: docs: Fix error in clock source mux bits
<rqou>
so, bikeshed
<rqou>
azonenberg: crbit or xc2bit? :P
m_w has joined ##openfpga
<azonenberg>
rqou: hmm
<azonenberg>
honestly i'd be fine with .bit :p
<azonenberg>
or we could be lulzy and say xbrbit
<azonenberg>
crbit is easier to type
<azonenberg>
Go with that
<rqou>
hmm, so apparently two people in the same apartment unit decided to be lazy simultaneously and both ordered a pizza :P
<azonenberg>
lolol
<rqou>
but the other guy (not my pizza) went to the wrong unit because this place is a clusterf*ck
<azonenberg>
lool
<rqou>
your place is an actual serious house and not an income source for the extended family of a human trafficker :P
<qu1j0t3>
!!!
<rqou>
he already served his sentence; justice has been served :P
<azonenberg>
0: Xilinx XC2C32A in QFG32 package, stepping 15
<azonenberg>
Scan chain contains 1 devices
<azonenberg>
:D
<rqou>
oh wtf
<azonenberg>
rqou: :)
<rqou>
i should stop wasting time and finish coding the crbit export
<azonenberg>
In case you haven't guessed, there's no stepping 15 in the 2c32a :p
<azonenberg>
This is my jtag code, finally working
<rqou>
now try blanking a real 32a :P
<rqou>
(including the idcode)
<azonenberg>
I'll do that soon
<azonenberg>
i want to work on some other stuff first
<openfpga-github>
[openfpga] azonenberg pushed 2 new commits to master: https://git.io/vH5ib
<openfpga-github>
openfpga/master d0f0ec0 Andrew Zonenberg: Merge branch 'master' of github.com:azonenberg/openfpga
<openfpga-github>
openfpga/master 97bfb2c Andrew Zonenberg: Initial JTAG bringup of XC2CDevice
<azonenberg>
rqou: re the new InZ
<azonenberg>
if i'm understanding this correctly
<azonenberg>
when bit 15 is set, the "IBUF" ZIA input is driven by the flipflop?
<rqou>
yeah
<rqou>
there's two paths to get from the flipflop to the ZIA
<azonenberg>
And you can then use bit 13 to drive the ZIA with the XOR gate
<azonenberg>
innnnteresting
<rqou>
yes, exactly
<azonenberg>
So you can use the FF to register the input
<azonenberg>
and also use the macrocell combinatorially
<azonenberg>
This is experimentally verified?
<rqou>
yes, i've verified it on hardware
<rqou>
it was a bit tricky; the trick i used was to configure the register as a TFF
<rqou>
i think this is what the architecture reference means by "The macrocell combinational functionality is retained for use as a buried logic node if needed."
<azonenberg>
yeah makes sense
<rqou>
i really can't get ise to generate these normally though
<rqou>
i think your design needs to be super full or else you can't trigger these
<azonenberg>
Probably
<rqou>
as i've been playing with ise, i continue to realize that the xc2c512 is ludicrously huge for anything you actually _need_ a cpld for
<openfpga-github>
[openfpga] azonenberg pushed 1 new commit to master: https://git.io/vH5P8
<openfpga-github>
openfpga/master 216ad0e Andrew Zonenberg: Added package codes for remaining device densities
<rqou>
brb, going to clean up my clusterf*ck of a desk
<azonenberg>
also, wow
<azonenberg>
i hope i can fit an xc2c32a in an xc7z010
<azonenberg>
the bitstream is ~12k ff's
<azonenberg>
i only have ~35k in the chip
<rqou>
oh dang i guess it isn't "trivial" like i thought
<rqou>
hey azonenberg when are we going to RE 7-series? :P
<azonenberg>
rqou: once coolrunner and greenpak are done
<azonenberg>
we can think about our next target :p
<azonenberg>
i dont want to become a RE shop that doesnt build tools
<azonenberg>
RE with no tools is no good
<azonenberg>
also, i may not be able to fit an EEPROM-capable model of the 2c32a into a 7z010
<azonenberg>
i have bigger fpgas
<azonenberg>
but for now i'll model the EEPROM writes as going direct to SRAM and ignore the boot process
digshadow has joined ##openfpga
<rqou>
digshadow: can i give a lightning talk at mtvre about progress on coolrunner-ii tools?
Hootch has joined ##openfpga
promach__ has joined ##openfpga
promach__ has quit [Quit: Leaving]
<rqou>
azonenberg: are you not counting the sec/done and idcode fuses as separate rows?
<azonenberg>
i'm using the row counts from the docs
<azonenberg>
But havent got to the sec/done stuff yet
<rqou>
hmm iirc the docs counted them as separate rows
massi has joined ##openfpga
cr1901_modern has quit [Read error: Connection reset by peer]
massi has quit [Remote host closed the connection]
<openfpga-github>
[openfpga] azonenberg pushed 1 new commit to master: https://git.io/vH5yW
<openfpga-github>
openfpga/master ba95711 Andrew Zonenberg: Continued XC2CDevice model. Can now enumerate the device, read the ID code/instruction capture state, erase, and read back. Next up, programming
<rqou>
azonenberg: have you tested with iMPACT? :P
<azonenberg>
Not yet, i've only tested with my tools
<azonenberg>
let me do that next
<azonenberg>
As of right now i'm using 32 FF, 324 LUT, 83 slices
<azonenberg>
because the config memory is all getting optimized down to one block of FFs
<azonenberg>
that will expand massively once i implement writes :p
lexano_ has quit [Ping timeout: 255 seconds]
<azonenberg>
welp, impact doesnt like my digilent dongle
<azonenberg>
huh
<azonenberg>
Guess i wont be testing with impact for now :p
<azonenberg>
Anyway, writes will have to wait till tomorrow
<azonenberg>
Then i'm leaving for REcon and probably wont get much done until monday after work
<azonenberg>
Hoping by the end of tomorrow my hackrunner will be able to, at least, pretend to be a 2c32a over jtag
<azonenberg>
i.e. no actual logic or io, but it'll look like a coolrunner and quack like a coolrunner over jtag
pie_ has quit [Remote host closed the connection]
<azonenberg>
rqou: wellp
<azonenberg>
now trying to synthesize for the 7z010 and choking :p
<azonenberg>
i may have to move this to my 7a100t devkit
<azonenberg>
Synthesis is still running which is probably a bad sign, lol
<azonenberg>
yeah it wants 101% luts now
<azonenberg>
grreat
<azonenberg>
ok so, it wont fit on a zynq
<azonenberg>
time to move to the starshipraider
<azonenberg>
And grab another jtag dongle from the garage in the morning since i dont have enough here :p
pie_ has joined ##openfpga
<azonenberg>
# Registers : 15
<azonenberg>
12740-bit register : 1
<azonenberg>
1-bit register : 5
<azonenberg>
# Registers : 15
<azonenberg>
12740-bit register : 1
<azonenberg>
1-bit register : 5
<azonenberg>
Yep, definitely getting there
<azonenberg>
i'd probably need a small virtex / large kintex to fit one of the bigger devices, lol
<azonenberg>
XST is estimating 38% of an xc7a100t for the xc2c32a model and that's just for the (incomplete) jtag logic plus bitstream flipflops and addressing logic
<azonenberg>
not the actual FB, ZIA, or macrocell logic
<rqou>
wait really?
<rqou>
i'm actually somewhat surprised
<azonenberg>
12K discrete FFs is a lot of state
<rqou>
ahh i guess it's much harder to actually store the entire bitstream
<rqou>
rather than just "produce equivalent logic"
<azonenberg>
yeah
<azonenberg>
Oh, that would be super easy
<azonenberg>
i could probably even do a runtime thing that would generate lut truth tables equivalent to the PLA
<azonenberg>
and store them in lutram
<azonenberg>
or something like that
<azonenberg>
but i'm trying to make a cycle accurate (though slower) version of the actual cpld internal structure
<azonenberg>
And having horrible hold time violations in the PAR, probably due to my current design that clears the whole config mem in one cycle when you erase
<azonenberg>
i should pipeline it or something
<rqou>
meh, probably fine :P
<azonenberg>
its fine after the second round of par
<azonenberg>
I'm going to try and constrain this to proper io pins and hook up a jtag dongle to it tomorrow
<rqou>
// TODO: Explain wtf is happening here
<rqou>
quality :P
<azonenberg>
where?
<rqou>
i just wrote it :P
<azonenberg>
oh
<rqou>
it's in the code that does some insane reordering for the OR terms for the 128/384/512
<rqou>
if you draw enough pictures and squint at the die shot for the 128 long enough, it'll make sense :P
<azonenberg>
lol
<openfpga-github>
[openfpga] azonenberg pushed 1 new commit to master: https://git.io/vH5FP
<openfpga-github>
openfpga/master 7ba4c26 Andrew Zonenberg: Initial work on bitstream programming. Not yet tested in hardware since it doesn't fit on my Zybo. Need to grab more JTAG dongles and test on an XC7A100T
<rqou>
(i need to draw a _lot_ of diagrams to explain this)
<azonenberg>
Who would have guessed that a coolrunner wouldn't fixt in an artix?
<azonenberg>
a small artix*
<rqou>
sneak peek:
<rqou>
let out_y = y + OR_BLOCK_TYPE2_ROW_MAP[and_term_idx / 2];
<rqou>
let mut out_x = or_term_idx * 2;
<rqou>
// TODO: Explain wtf is happening here
<rqou>
if OR_BLOCK_TYPE2_ROW_MAP[and_term_idx / 2] >= 23 {
<rqou>
// "Reverse"
<rqou>
if and_term_idx % 2 == 0 {
<rqou>
out_x += 1;
<rqou>
}
<azonenberg>
lol
<rqou>
} else {
<rqou>
if and_term_idx % 2 == 1 {
<rqou>
out_x += 1;
<rqou>
}
<rqou>
}
<azonenberg>
also LOL looking at the synthesis results here
<azonenberg>
So, i tweaked the design a touch
<azonenberg>
Now it's taking up less space
<azonenberg>
i made erase higher priority than program (since both cant happen at once) which allows it to use the CLB set/reset routing
<azonenberg>
Now my "wipe bitstream" signal is using a BUFG
<azonenberg>
The new design is only using 22% slices
<azonenberg>
and 17% luts
<azonenberg>
it might fit in a 7z010, in fact, but i'm not going to try because as soon as i add actual cpld fabric it will get a lot bigger :p
<azonenberg>
this version is way denser packed though
<azonenberg>
Which is good
<rqou>
also, i'm discovering something neat about "physical" fuse addressing
<azonenberg>
Oh?
<rqou>
there's much less hardcoding everywhere because all blocks have "sane" relative positions to each other
<azonenberg>
Yes
laintoo__ has joined ##openfpga
<azonenberg>
i dont get the whole JED addressing scheme
<azonenberg>
physical makes more sense imo :p
laintoo_ has quit [Ping timeout: 255 seconds]
<rqou>
you do need to hardcode stuff once though
<rqou>
well, i guess you don't _need_ to
<azonenberg>
you have to hardcode the relative offsets, and the array structure, i guess
<azonenberg>
but not every bitstream offset
<rqou>
so i've currently hardcoded one set of coordinates (for the AND array)
<rqou>
and i'm basing everything off of that
<rqou>
the other approach is to only hardcode where the transfer bits are i guess
<azonenberg>
Hmm, that part is your department
<azonenberg>
i'm not deep enough into that part of the toolchain to be able to say what'd work best
<whitequark>
azonenberg: are you modeling a CPLD inside an FPGA?
<azonenberg>
whitequark: Yes
<azonenberg>
i'm trying to make a full cycle-accurate, bitstream-compatible xc2c32a
<azonenberg>
that you can jtag from impact just like a real cpld
<azonenberg>
it just will have worse timing
<azonenberg>
besides the cool factor, it'll help us confirm we fully understand the behavior of the real cpld
<whitequark>
azonenberg: oh neat
<whitequark>
I want to do a de novo FPGA or CPLD some day but that's a long time off
<rqou>
i really need to rewrite my "hangs the browser" .map file viewer
<rqou>
oh dang it's late
* rqou
zzz
<openfpga-github>
openfpga/master a87331a Robert Ou: xc2bit: Add "OR terms in the middle" AND block crbit writing
<openfpga-github>
openfpga/master a960f6d Robert Ou: xc2bit: Initial plumbing for the native "crbit" file format...
<openfpga-github>
openfpga/master aeeb05e Robert Ou: xc2bit: Deduplicate the clock divider fuse handling
<openfpga-github>
[openfpga] rqou pushed 5 new commits to master: https://git.io/vH5hB
pie_ has quit [Ping timeout: 240 seconds]
m_w has quit [Quit: leaving]
Hootch has quit [Ping timeout: 240 seconds]
pie_ has joined ##openfpga
lexano has joined ##openfpga
m_w has joined ##openfpga
amclain has joined ##openfpga
scrts has quit [Ping timeout: 258 seconds]
scrts has joined ##openfpga
<azonenberg>
rqou: i want to do a something full custom too
<azonenberg>
whitequark: *
<azonenberg>
but this is a start
digshadow has quit [Ping timeout: 240 seconds]
m_w has quit [Ping timeout: 260 seconds]
m_w has joined ##openfpga
digshadow has joined ##openfpga
pie_ has quit [Ping timeout: 240 seconds]
pie_ has joined ##openfpga
<digshadow>
rqou: sure if you want
<digshadow>
turnout might be light tonight though
<digshadow>
given no talks announced and REcon this week
* digshadow
flies out in the morning
mifune has joined ##openfpga
mifune has joined ##openfpga
mifune has quit [Changing host]
* azonenberg
too
m_w has quit [Quit: leaving]
<whitequark>
azonenberg: cool
<azonenberg>
i mean i see the endgame of all this
<azonenberg>
as being a f/oss FPGA/CPLD made on a shuttle run or something
<azonenberg>
with open toolchain etc
<azonenberg>
I think something on par with an xc2c32a on CMP 350nm should be easy enough to do with standard cells only, no hand layout (although obviously this would give less awesome gate density)
<whitequark>
I actually have a completely different goal
<whitequark>
but it's a secret :p
<azonenberg>
well the longer term goal is to have a custom asic made on say 90-65 nm process
<azonenberg>
with a risc-v CPU
<azonenberg>
an antikernel noc fabric
<azonenberg>
a bunch of hard IP for ethernet, ram, etc
<azonenberg>
And a f/oss FPGA fabric for peripherals
<azonenberg>
But that will be a lot more expensive than anything i can do in the near future :p
<azonenberg>
the xc2c32a class device on 350nm is something i could buy out of pocket and self-fund a 25-die prototype run
<azonenberg>
we're talking 2000 - 3000 eur
<azonenberg>
assuming i can use an open cell library and tools like magic etc
<azonenberg>
and not have to license any ip or buy cad tools
<azonenberg>
The plan was to have it 100% sram based and boot from an external 25* spi flash
<azonenberg>
Since there's no open flash ip and i dont want to pay for it :p
<rqou>
serious question: how hard would it be to design a vendor-portable flash ip?
<azonenberg>
pretty sure: extremely hard, it'd depend on all kinds of process subtlety, oxide thickness, etc
<azonenberg>
It is probably possible to design a f/oss flash IP for one specific foundry/process
<rqou>
but why is normal digital logic ok?
<azonenberg>
Because there's no tunneling etc
<azonenberg>
aiui floating gate memories are far more sensitive to variations in oxide
<rqou>
hmm, but the xc9500xl moved fabs, didn't it?
<azonenberg>
Quite possibly with a new mask set
<azonenberg>
i could be wrong, but thats my understanding
<azonenberg>
also, if anyone were to design a portable flash ip
<rqou>
ahh i thought you had said it was the same mask set
<whitequark>
rqou: afaik chinese copycats are so flash-averse (and the IP is guarded well enough) that they will gladly put a massive SRAM into the chip and some additional logic to load the data from an associated SPI NOR flash
<azonenberg>
i would suggest doing SONOS or something
<whitequark>
which is something you'd think would be prohibitively expensive
<whitequark>
there was some STM32 clone done like that iirc
<azonenberg>
rather than floating poly gate
<azonenberg>
whitequark: lol
<azonenberg>
i mean thats what fpgas do
<whitequark>
azonenberg: they legit designed the entire thing from scratch, and it was even largely bug-free
<rqou>
whitequark: i don't think that was the reason for the gigadevice parts to use sram
<whitequark>
rqou: oh?
<rqou>
gigadevice was originally a flash manufacturer
<whitequark>
is that clone made by gigadevice?
<rqou>
the zeptobars guess that sounds quite plausible is that it's to save on arm ip licensing costs (because this company is more legit and actually pays them)
<whitequark>
"gd32f1"...
<whitequark>
lol even their product selector looks exactly like STMs
<whitequark>
and for no good reason, STM's is shit
<whitequark>
amazing
<azonenberg>
rqou: also i brought up my hackrunner on an xc7a100t this morning
<azonenberg>
i can detect, erase, and blank check
<azonenberg>
but readback is failing
<azonenberg>
not yet sure why
<azonenberg>
i think it has to do with addressing
<rqou>
azonenberg: this is interesting: "Companies offering SONOS-based products include ..., _Cypress Semiconductor_, ..."
<rqou>
when dmitry.gr gave his talk about dumping the secret rom in the psoc devices, he mentioned that the flash programming algorithms are suuuper weird
<rqou>
i wonder if psoc flash is actually SONOS?
<rqou>
aah i found some lecture notes with sem shots of "real" eeprom cells
<rqou>
apparently it's much more complicated than the traditional simplified explanation
theMagnumOrange has quit [Read error: Connection reset by peer]
<azonenberg>
"The 0.35 - μ m SONOS Technology (known as S4) and 130 - μ m SONOS technology (known as S8) have been
<azonenberg>
Chip (PSoC) and Nonvolatile SRAM (NVSRAM). "
<azonenberg>
running in high volume in multiple fabs. The main products made in Cypress Minnesota fab are Programmable S ystem on
<azonenberg>
They also licensed the tech to a chinese fab
<azonenberg>
So i dont know for sure which fab did the psoc i have
<azonenberg>
that doc even has the voltages for various things
<azonenberg>
as far as change notices i'm not sure why they give some of the details they do
<azonenberg>
but i dont complain :p
<azonenberg>
i conside it OSINT
digshadow has joined ##openfpga
<pointfree>
dmitry told me to look for faults when I try to read memory on the PSoC 5LP, so I've just been dumping the entire PSoC5LP address space searching for faults and interesting things. (This takes a while)
<pointfree>
When doing this I stumbled upon a region at 0x40006100 extending 0x200 bytes that contains a repeating 16 bits. Those 16 bits change after every flash+powercycle from what I can tell.
<pointfree>
0x40006300 through 0x400063FF contains zeros and is apparently unused.
<azonenberg>
interesting
<pointfree>
My first guess is that the repeating 2 bytes is for error correction or detection or something. If that's true, then what are the remaining 0x100 bytes for? Perhaps error correction for unused flash?
<rqou>
hmm, i really need a crash course in the psoc architecture
<azonenberg>
huh maybe?
<pointfree>
PSoC 5LP CY8CKIT-059 has 256KiB of flash. That region is 0x200 bytes in size. That makes for 2bytes per KiB which makes sense given that it contains 2 bytes repeating. So 0x100/2=128KiB. So perhaps there is an additional 128KiB of flash or something?
<azonenberg>
boot rom?
<pointfree>
Hm didn't think of that.
<azonenberg>
no idea how big the srom is
<azonenberg>
but that's plausible
m_w has joined ##openfpga
amclain has quit [Quit: Leaving]
cr1901_modern has joined ##openfpga
<rqou>
azonenberg: interestingly, the 32a macrocell bits are in the exact same order in the .jed and the physical array
<rqou>
the 64a macrocell bits are mirrored horizontally, but multi-bit fields aren't mirrored
<azonenberg>
well the 27 bits are split 9x3, no?
<azonenberg>
And they're mirrored in one of the function blocks
<rqou>
no, so in the 32a the bits are laid out as "Aclk ClkOp Clk:2 ClkFreq R:2 P:2" in the top row
<rqou>
and then "RegMod:2 INz:2 FB:2 InReg St XorIn" in the second row
<rqou>
but the 64a is approximately "P R ClkFreq Clk ClkOp Aclk"
<rqou>
but the fields that have multiple bits are not reversed internally; only the order of the fields is
<azonenberg>
what i meant is
<azonenberg>
in the 32a
<azonenberg>
fb1 vs fb2
<rqou>
right, those are mirrored
<azonenberg>
the bits are not mirrored?
<azonenberg>
ah
<azonenberg>
ok
<azonenberg>
that makes sense
<azonenberg>
So you're saying the 64a is mirrored relative to the 32?
<rqou>
approximately
<rqou>
meanwhile the 256 matches the .jed ordering again
<rqou>
the 256 macrocells are 3 rows x 10 columns
<rqou>
actually wait
<azonenberg>
Are the same bits in each row?
<azonenberg>
then one extra bit in each row?
<rqou>
the 256 is mirrored relative to the .jed ordering
<azonenberg>
or did they move stuff around so thigns arent in the right ordering
<rqou>
so it's "InMod FB DG ClkOp ClkFreq Clk Aclk" in the physical ordering
<rqou>
but "Aclk Clk:2 ClkFreq ClkOp DG FB:2 InMod:2" in the jed ordering
<rqou>
it's completely different from the 32/64
<azonenberg>
huh weird
<rqou>
haven't quite looked at the 128/384/512 yet
<azonenberg>
i feel like this will make a lot more sense when we RE the macrocell
digshadow has quit [Ping timeout: 240 seconds]
mifune has quit [Ping timeout: 240 seconds]
uelen has joined ##openfpga
digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 246 seconds]
mifune has joined ##openfpga
mifune has joined ##openfpga
digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 246 seconds]
<azonenberg>
whitequark, rqou: also, did you see nathan's email? He typoed the part number but apparently he says the 46620 and 46621 are NOT the same die like we had assumed
<azonenberg>
there's apparently a metal layer change
<azonenberg>
They're bitstream compatible but if the power rails are built differently there could potentially be timing changes at least in the pad ring
<rqou>
so like the A/non-A coolrunner parts?
<azonenberg>
quite possibly
<rqou>
i'm still surprised how silego makes money on these tiny parts
<azonenberg>
i think they just sell them by the tens of thousand
<azonenberg>
probably use them in cheap phones for PMICs etc
<rqou>
i thought qualcomm also took over the PMIC space for phones?
<azonenberg>
I guess not
<azonenberg>
also, I love how we're getting red-carpet treatment from silego
<azonenberg>
nathan going out of his way to try to get me samples from another lot number etc
<azonenberg>
i feel like this is probably the kind of treatment say Synopsys or Mentor Graphics get from xilinx/altera lol
<rqou>
ugh hunting down the coordinates of all the global bits is super annoying
<azonenberg>
But honestly, silego probably sees our relationship as similar to that
<azonenberg>
we just happen to not charge for our tools
<rqou>
after i finish this, someone needs to independently verify i didn't typo any of the coordinates for any of the fuses
digshadow has joined ##openfpga
<rqou>
wtf
<rqou>
azonenberg: on the 64 die 6 of the GTS bits are in the top half and 2 of them are in the bottom half
mifune has quit [Ping timeout: 260 seconds]
<azonenberg>
lolwut
<azonenberg>
Does that track at all with which IOBs they go to?
<azonenberg>
it might make more sense if we delayered a 2c64a and looked at the floorplan
<azonenberg>
its possible they couldnt fit it in the gap
<rqou>
no, it doesn't :P
<rqou>
all the GTS pins are adjacent and in FB1
<azonenberg>
Huh
<pointfree>
Nothing was changing anymore at 0x40006100-0x400062FF when I tried flashing things and power cycling. Then I switched it to the neighboring USB port on my docking station and the pattern of "5e df" became "7f df" I switched it back ...and got "3e d7" This could just be that sensor stuff needed to get the weird Cypress flash to work.
<pointfree>
Dmitry mentioned that every flash chip is individually tuned at the fab.
<azonenberg>
"sensor stuff"
<azonenberg>
so what, they calibrate the memory for Vt drift or something?
<pointfree>
I wish I had the slides or could remember more details. There is temperature sensing at least.
<pointfree>
(The flash controller is software defined on psoc4)