cyrozap has quit [Quit: Client quit]
pie_ has quit [Ping timeout: 268 seconds]
kuldeep has quit [Ping timeout: 252 seconds]
cyrozap has joined ##openfpga
kuldeep has joined ##openfpga
azonenberg_work has joined ##openfpga
prpplague has quit [Remote host closed the connection]
azonenberg_work has quit [Ping timeout: 272 seconds]
wbraun has joined ##openfpga
unixb0y has quit [Ping timeout: 268 seconds]
unixb0y has joined ##openfpga
emeb has left ##openfpga [##openfpga]
Miyu has quit [Ping timeout: 252 seconds]
Bicyclidine has quit [Quit: Lost terminal]
rohitksingh_work has joined ##openfpga
kuldeep has quit [Read error: Connection reset by peer]
kuldeep has joined ##openfpga
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 260 seconds]
azonenberg_work has joined ##openfpga
jevinskie has joined ##openfpga
jevinski_ has quit [Ping timeout: 268 seconds]
soylentyellow has quit [Ping timeout: 272 seconds]
soylentyellow has joined ##openfpga
_whitelogger has joined ##openfpga
kuldeep has quit [Ping timeout: 244 seconds]
s_frit has quit [Read error: Connection reset by peer]
kuldeep has joined ##openfpga
s_frit has joined ##openfpga
lovepon has joined ##openfpga
m4ssi has joined ##openfpga
lovepon has quit [Ping timeout: 250 seconds]
GuzTech has joined ##openfpga
GuzTech has quit [Quit: Leaving]
Miyu has joined ##openfpga
Miyu has quit [Ping timeout: 252 seconds]
rohitksingh_work has quit [Read error: Connection reset by peer]
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
Maylay has quit [Quit: Pipe Terminated]
Maylay has joined ##openfpga
Bike_ has joined ##openfpga
Bike_ is now known as Bicyclidine
rohitksingh_work has joined ##openfpga
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/42511ec2e836c3acba703f39a2b3ad11f57d2790
<openfpga-github> Glasgow/master 42511ec whitequark: gateware.fx2: add missing import.
<travis-ci> whitequark/Glasgow#133 (master - 42511ec : whitequark): The build has errored.
rohitksingh_work has quit [Read error: Connection reset by peer]
Miyu has joined ##openfpga
rohitksingh has joined ##openfpga
Moiman has joined ##openfpga
kuldeep has quit [Read error: Connection reset by peer]
kuldeep has joined ##openfpga
cr1901_modern has quit [Ping timeout: 252 seconds]
emeb has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
<whitequark> azonenberg_work: i found an xc9572 based device
<whitequark> (post card)
<whitequark> can i read out the bitstream?
<whitequark> it has jtag broken out it seems..
<whitequark> lemme see if glasgow picks it up
rohitksingh has quit [Ping timeout: 244 seconds]
<balrog> whitequark: is security enabled?
<balrog> if not you should be able to read it out
wbraun has quit [Quit: wbraun]
<whitequark> balrog: no idea
<whitequark> how do i tell
wbraun has joined ##openfpga
rohitksingh has joined ##openfpga
pie_ has joined ##openfpga
<azonenberg_work> whitequark: there's no documentation for how this works
<azonenberg_work> you need a xilinx programmer, an unlocked chip, and some time to RE it
<azonenberg_work> afaik
<azonenberg_work> the coolrunner programming spec is doucmented but i dont think xc95* is
<whitequark> wtf
rk[ghost] has joined ##openfpga
<whitequark> azonenberg_work: ok so
<whitequark> 00/01/10 is probably EXTEST/SAMPLE/PRELOAD
<whitequark> 11111110 is IDCODE
<whitequark> 11111101 has ASCII "ICP" inside
<whitequark> er, ICP
<whitequark> errrr, _ICP
<azonenberg_work> if the idcode ends in 0x093 it's a xilinx idcode
<azonenberg_work> the BSDL is available, so you know what the instructions are
<azonenberg_work> just not what they do
<azonenberg_work> sec
<azonenberg_work> whitequark: this is a vanilla 72? not the 72xl?
<whitequark> hm let's see
<whitequark> XL
<azonenberg_work> ok those are a different process and might have insn hcanges
* azonenberg_work loads correct bsdl
<whitequark> ohhh
<azonenberg_work> idcode is correct
<azonenberg_work> 1....01 is USERCODE
<whitequark> ok
<azonenberg_work> EXTEST is 00..0, SAMPLE is 000..01
<whitequark> link to bsdl?
<azonenberg_work> INTEST is 00...10 (SAMPLE and PRELOAD are normally same instruction but read vs write)
<azonenberg_work> $XILINX/ISE_DS/ISE/xc9500xl/data/xc9572xl.bsd
<azonenberg_work> if you have an ise install handy
<whitequark> oh
<whitequark> no ise
<whitequark> only vivado
<whitequark> oh WTF
<whitequark> that just links to vivado
<azonenberg_work> is what you want
<azonenberg_work> anyway, likely interesting instructions... entering and exiting ISP mode (not sure what ENC is)
<azonenberg_work> "ISPEN ( 11101000)," &
<azonenberg_work> "ISPENC ( 11101001)," &
<azonenberg_work> "ISPEX ( 11110000)," &
<azonenberg_work> (those are command insns that likely only have a 1-bit DR that's treated as bypass)
<azonenberg_work> "FBLANK ( 11100101),"&
<azonenberg_work> "FBULK ( 11101101),"&
<azonenberg_work> "FPGMI ( 11101011)," &
<azonenberg_work> "FPGM ( 11101010)," &
<azonenberg_work> "FERASE ( 11101100),"&
<azonenberg_work> "FVFY ( 11101110)," &
<azonenberg_work> "FVFYI ( 11101111)," &
<azonenberg_work> look program related
<whitequark> nope
<whitequark> I: glasgow.applet.jtag: IR=11101000 DR[6]
<whitequark> 6-bit DR
<azonenberg_work> huh interesting
<azonenberg_work> maybe its status out?
<azonenberg_work> with coolrunner the enable insn dr isnt even used
<azonenberg_work> you load the ir then go on to another insn
<whitequark> ISPEX is 1-bit
<azonenberg_work> (i havent tried reading/writing the dr though)
<azonenberg_work> note, if they're anything like coolrunner there are timing requirements for programming
<azonenberg_work> you have to add minimum time intervals between some instructions
<azonenberg_work> (also i hope you didn't wipe the chip poking at jtag registers by loading FERASE after ISPEN lol)
<whitequark> wow bsdl is verbose af
<azonenberg_work> whitequark: it's a strict subset of VHDL
<whitequark> and... most of it... is in strings anyway?
<azonenberg_work> duh
<whitequark> what an idiotic format
<azonenberg_work> you see why i dont support it in jtaghal yet/ever? :p
<whitequark> what is the fucking point of having a strongly typed lang if you're gonna embed everything in strings
<whitequark> yeah fuck this shit
<whitequark> someone else can write a converter from bsdl to "something sane"
<whitequark> rqou?
<whitequark> attribute REGISTER_ACCESS of xc9572xl_tq100 : entity is
<whitequark> "BYPASS ( ISPEX, HIGHZ, CLAMP )," &
<whitequark> "ISPENABLE[6] ( ISPEN, ISPENC )," &
<whitequark> "ISADDRESS[18] ( FERASE, FBULK, FBLANK ),"&
<whitequark> "ISDATA[34] ( FPGMI, FVFYI ),"&
<whitequark> "ISCONFIGURATION[50] ( FPGM, FVFY )";
<whitequark> this makes sense it looks
<azonenberg_work> state values where a given insn is legal?
<whitequark> hm?
<whitequark> REGISTER_ACCESS?
<azonenberg_work> yeah
<whitequark> no
<azonenberg_work> i've only used bsdl to read insn values
<azonenberg_work> and idcodes
<whitequark> i assume this says which *actual* register it accesses
<whitequark> so both FPGMI and FVFYI have same "format"
<azonenberg_work> oh, i see
<azonenberg_work> thats not bit 34
<whitequark> yes
<azonenberg_work> that's a single 34 bit register
<whitequark> thats lengths
<whitequark> FVFYI is "verify with internally generated address"
<whitequark> so probably something like a counter?
<whitequark> let me try reading from it
<rqou> sorry what?
<rqou> i don't understand anything about bsdl
<whitequark> rqou: you had a VHDL parser right
<rqou> not complete enough to be used yet
<whitequark> can you make that eat BSDL and shit out something sane
<azonenberg_work> rqou: bsdl is a strict subset of vhdl
<whitequark> i.e. not VHDL
<whitequark> literally anything other than VHDL
<whitequark> COBOL-style fixed width fields are better
<rqou> also yeah, the older cpld jtag algorithms are completely undocumented
<rqou> you need to RE it
<whitequark> well it doesnt look like its
<whitequark> complicated
<whitequark> at all
<whitequark> lemme just fuck around with it
<rqou> there's a "programmer qualification document" like for xc2c, but it documents a completely separate HVPP algorithm
<whitequark> i have two of these boards anyway lol
<whitequark> what, do you expect me to actually read docs
<whitequark> docs are for the weak
<whitequark> chad whitequark vs virgin rqou
<rqou> idk about these parts, but fyi on xc2c if you mess up the done/secure bits enough the chip gets kinda confused
<whitequark> well the chip can go fuck itself
<whitequark> thats not my problem
<rqou> at least on those you can recover by issuing chip erase commands and power cycling
<whitequark> who said i am going to write it?
<whitequark> i just wanna read the bitcode
<azonenberg_work> also fwiw, on coolrunner there is additoinal nvram for things like the jtag idcode
<whitequark> bit... stream
<whitequark> wait what
<whitequark> you can
<whitequark> modify idcode?
<rqou> we don't know how
<azonenberg_work> i dont know about MODIFY
<whitequark> that seems ideal for counterfeiting lol
<azonenberg_work> But what we know is, the idcode is package dependent
<whitequark> isn't it efuses or something
<azonenberg_work> its the only xilinx part where the idcode changes by package
<azonenberg_work> we dont know, however the bsdl hints that its extra flash rows
<azonenberg_work> because theres the normal erase instruction and an "erase all" instruction
<azonenberg_work> Which implies there is more to erase than the bitstream
<azonenberg_work> i havent tried using it since its a probable device brick and i dont have soldering gear set up to repair a bricked board right now
<rqou> if you're brave you can try the HV parallel programming algorithm on the xc9500s
<whitequark> that needs ... more pins
<whitequark> and soldering
<whitequark> and im lazy
<azonenberg_work> for the FPGA devices, efuse is likely used for idcode (or some bits thereof)
<azonenberg_work> because they already are known to have on die efuse, and not flash
<azonenberg_work> coolrunner doesnt have any known efuse
<azonenberg_work> more importantly it has known on die NVM
<azonenberg_work> (which is 2T EEPROM, not flash!)
<rqou> anyways, we don't yet have the ability to decompile xc9500/xc9500xl bitstreams yet
<rqou> the hard part is the internal interconnect
<whitequark> can't ise do it?
<rqou> anyways, I'm about to finally actually start driving down to LA, see you later
rohitksingh has quit [Ping timeout: 260 seconds]
<rqou> no, you can't decompile
<whitequark> oh
<rqou> interestingly lattice can decompile some altera cpld bitstreams
<rqou> lattice has some parts that are a microarchitectural superset of altera parts
<rqou> including interconnect
<whitequark> azonenberg_work: ok, reading FVFYI
<whitequark> D: glasgow.applet.jtag: JTAG: shift tdo=<0011111111111111111111111111111111>
<whitequark> just this
<whitequark> looks like 2 bits "control" and 32 bits "data" ?
<azonenberg_work> might be 2 bits padding/address lsb
<whitequark> if I do IR_ISPEN first
<azonenberg_work> but the 2/32 split seems plausible so far
<whitequark> I get
<whitequark> D: glasgow.applet.jtag: JTAG: shift tdo=<1000000000000000000000000000000000>
<whitequark> and indeed
<whitequark> I am reading some kinda data
<whitequark> mostly zeroes
<whitequark> but occasionaly some bits
<azonenberg_work> whitequark: and no xilinx tools do any kind of bitstream decompile
rohitksingh has joined ##openfpga
<azonenberg_work> none of the public tools support this, by design
<azonenberg_work> they want bitstreams to be write only
<azonenberg_work> NCD etc can be read back and poked at but NCD-BIT is a one way trip
<whitequark> azonenberg_work: how long is the xc9572xl bitstream
<whitequark> whats NCD?
<daveshah> NCD is the neocad post-place-and-route database
<azonenberg_work> NCD is the ISE FPGA (diff file format for CPLDs) par db
<daveshah> that ISE and Lattice Diamond both use
<whitequark> hm
<azonenberg_work> whitequark: a few kB i think? let me generate one and test
<daveshah> Both Lattice (NCL) and Xilinx (XDL) have text representations and tools to convert to/from those
<azonenberg_work> yeah
<azonenberg_work> NCD is something you don't ship
<azonenberg_work> once you go to bit, you're flashing a device and they intentionally do not want you to be able to bit -> ncd
<azonenberg_work> i'm almost certain that for debugging xilinx has an internal bit-ncd converter
<azonenberg_work> But its not released
<daveshah> Lattice ship part of one with Diamond
<daveshah> It can do bitstream to name of bits
<daveshah> but not actually to any kind of netlist
<azonenberg_work> oh interesting
<azonenberg_work> whitequark: 46656 bits
cr1901_modern has joined ##openfpga
<whitequark> let's see
<azonenberg_work> or 1458 32-bit words. if that's how the config mem is structured
<whitequark> yes
<whitequark> it's def 32-bit words
<azonenberg_work> interesting, coolrunner uses array-sized memory
<azonenberg_work> i.e. 48 rows of 260 bits
<azonenberg_work> with explicit x/y addressing
<azonenberg_work> (for the 32a)
<azonenberg_work> this sounds like closer to an fpga-style config architecture
<azonenberg_work> where you push words out to some kind of decoder that later go to the actual registers
<whitequark> azonenberg_work: USERCODE is in the bitstream right?
<azonenberg_work> Yes, it should be
<whitequark> ok, it is not laid out directly ten
<azonenberg_work> its sole purpose is to be a bitstream programmed 32-bit value
<whitequark> looking further
<whitequark> 1267 valid=1 unknown=0 data=00000000000000000000000000011111
<whitequark> 1429 valid=1 unknown=0 data=00000000000000000000000000011111
<whitequark> context
xdeller has quit [Remote host closed the connection]
<whitequark> at read N=1267 there is an unique word 00000000000000000000000000011111
<azonenberg_work> whitequark: http://paste.debian.net/hidden/4258b928/
<whitequark> at read N=1458+1429 there is the same unique word 00000000000000000000000000011111
<azonenberg_work> if this helps, this is the generated bitstream for a mostly-blank device (assign b = a)
<whitequark> so, it definitely loops over
<azonenberg_work> the block boundaries may be insightful
<azonenberg_work> i assume they mean someting
<azonenberg_work> but theres no comments a la coolrunner
<whitequark> after... 0x654 words?
<whitequark> in other words
<whitequark> the period of FVFYI is 1620
<whitequark> let me verify
<azonenberg_work> whitequark: http://paste.debian.net/hidden/eb5b9360/
<azonenberg_work> usercode 00000000 vs 55555555
<azonenberg_work> if that tells you anything
<azonenberg_work> mind you this is jed fuse numbers and idk how they map to programming algorithm info
<azonenberg_work> (i havent made a svf to test)
pie_ has quit [Ping timeout: 272 seconds]
<whitequark> let's see
<whitequark> azonenberg_work: interesting
<whitequark> looks like the first 13 (?) words read from FVFYI
<whitequark> are some kinda prefix
<whitequark> it only starts repeating after that
<azonenberg_work> maybe thats some special header with config info or something
<azonenberg_work> and not stored in the main config memory?
<whitequark> firsttwo words are
<whitequark> -valid=1 unknown=0 data=11001001110010011100100111001001
<whitequark> -valid=1 unknown=0 data=01001010010010100000000101001010
<whitequark> which seems like some kinda info indeed
<whitequark> >>> bitarray("11001001110010011100100111001001", endian="little").tobytes()
<whitequark> b'\x93\x93\x93\x93'
<whitequark> >>> bitarray("01001010010010100000000101001010", endian="little").tobytes()
<whitequark> b'RR\x80R'
<whitequark> hm
<whitequark> azonenberg_work: actually,it is weirder
<whitequark> the first 20 words are totally different between 0th read and 1th read
<whitequark> and identical afterwards
<whitequark> and
<whitequark> on 0th read this is "two special words plus zeroes"
<whitequark> on 1th read this is some weird sorta junk
<whitequark> azonenberg_work: what is the JED format?
<whitequark> how is it structured?
<whitequark> it looks like goddamn gcode
<whitequark> is PPMAP some kinda bit permutation?
<whitequark> oh
<whitequark> bond pad to pin map right?
<azonenberg_work> whitequark: there's a file format spec on the jedec website
<azonenberg_work> i think you have to register but its free
<azonenberg_work> whitequark: is it possible that you have a repeating structure in the bitstream and are just not reading to the end?
<whitequark> azonenberg_work:
<whitequark> no
<whitequark> i've read 6000 words
<whitequark> and i found more than 2 repeats
<whitequark> i am very sure the period is 1620
<whitequark> yeah, fouond it
<azonenberg_work> its meant to be streamed in real time from a pc to a rs232-attached parallel pld programmer
<azonenberg_work> if that helps you understand context
<whitequark> ok hm
<azonenberg_work> so they have stx/etx codes, ascii bit values
<azonenberg_work> etc
<whitequark> does this cpld have an onboard clock generator?
<azonenberg_work> not user accessible but they may self-time flash operations
<azonenberg_work> the coolrunner at least has to have a clock source for the boot process since its flash->sram
<azonenberg_work> i believe, but have not confirmed, that 9500 has floating gate cells directly in the config logic
<azonenberg_work> i.e. there is no config sram
<azonenberg_work> whitequark: also, another thing to keep in mind is that coolrunner violates the spirit of the jed file format and requires an address mapping between jed addresses and actual bitstream bits
<whitequark> oh so it's only flash programmable
<azonenberg_work> i.e. they are 1:1 but it is not a linear address space
<azonenberg_work> i do not know if 9500 is the same
<whitequark> hm
<whitequark> let's see
<azonenberg_work> 9500 was a xilinx in house design and coolrunner was acquired from philips
<whitequark> i'm a bit confused about your diff
<whitequark> 19:35 < azonenberg_work> usercode 00000000 vs 55555555
<azonenberg_work> whitequark: that is two identical bitstreams with usercode of 0x55555555 and (unspecified) which is probably 0x00000000
<whitequark> yes
<whitequark> it is not 0x0000000
<whitequark> it is probably ummm
<azonenberg_work> this is 55555555 vs 41414141
<azonenberg_work> the reason i have these values is because the cpld usercode is specified as 4 ascii character on the command line, not hex
<whitequark> yes, this makes MUCH more sense
<azonenberg_work> like it is in fpgas
<whitequark> can you do a diff between 00000000 (explicit) and 5555AAAA (also explicit)
<whitequark> this should give me all info
<azonenberg_work> i cannot do 00000000
<whitequark> what
<azonenberg_work> it wants me to type the usercode in as 4 chars in a text box
<whitequark> ok, 11111111 then
<whitequark> oh
<whitequark> what the fuck
<azonenberg_work> i can do 30303030
<azonenberg_work> which is "0000"
<whitequark> ok, 30303030 vs 55555555
<whitequark> seems good
<whitequark> since all bit pairs differ
<whitequark> which is what i need to locate
<whitequark> sweet, let me see
<azonenberg_work> whitequark: btw can you write up what you learn from doing this and stick it somewhere?
<whitequark> yes, 32 lines
<whitequark> sure
<whitequark> it will be in glasgow source code
<azonenberg_work> why there?
<azonenberg_work> i was thinking another dir under here
<azonenberg_work> keep it in one place
<azonenberg_work> this is where the coolrunner bitstream spec lives
<whitequark> because this is the canonical location for glasgow engineering documents
<whitequark> e.g.
<whitequark> is an enormous document about ibm floppy drives, for some reason
<whitequark> i dont even remember why i figured out how they work anymore
<whitequark> but it was a pain
<whitequark> shitty 1b2b encoding
<whitequark> that no one even describes as 1b2b
<whitequark> instead they say it is "modified FM"
<azonenberg_work> lol
<azonenberg_work> you see why i dont do legacy stuff?
<whitequark> eh its ok
<whitequark> once you slog through the horrible docs
<azonenberg_work> i work with modern protocols and devices where things are cursed in... different ways :p
<whitequark> actually i think i would have done it faster if i have never read any of the docs at all
<azonenberg_work> lolol
<whitequark> because half of the info there is just misleading
<whitequark> and the other half is plain out incorrect
<whitequark> and the old devices that implement it as specced do things wrong
pie_ has joined ##openfpga
<azonenberg_work> whitequark: in that case we should make a wiki page somewhere
<azonenberg_work> i want there to be some document, somewhere
<whitequark> e.g. the K.C2 MFM comma, you cannot sync on it
<azonenberg_work> that contains pointers to all known fpga/pld bitstream documentation
<whitequark> because it can be found in data shifted by 90°
<whitequark> you can only sync on K.C2 K.C2
<whitequark> but *no one has ever wrote this anywhere*
<azonenberg_work> where the docs live, i dont know or care
<whitequark> and indeed the ibm floppy dontroller has a bug where it syncs on K.C2
<azonenberg_work> but i want an index somewhere
<whitequark> and loses sync
<whitequark> in the middle of a track
<azonenberg_work> lolol
<whitequark> re wiki page: sure
<whitequark> hm
<whitequark> i wonder how is the memory organized block wise
<whitequark> azonenberg_work: did you mention blocks?
<azonenberg_work> (you are gonna have to get a copy of ise to poke at this i think)
pie_ has quit [Ping timeout: 268 seconds]
<whitequark> ehhh I don't have disk space for ise right now
<whitequark> annoyingly so
<whitequark> it's a 512G SSD
<azonenberg_work> https://siliconpr0n.org/archive/doku.php?id=vendor:xilinx:xc9500xl
<whitequark> and I need at *least* 2 TB
pie_ has joined ##openfpga
<azonenberg_work> if the die structure gives you any hints
<whitequark> oh huh
<whitequark> iiiiinteresting
<azonenberg_work> unfortunately do not have a delayered image at the moment
<azonenberg_work> or facilities to do so
<whitequark> ok that's kind of a low res image
<azonenberg_work> https://siliconpr0n.org/archive/lib/exe/fetch.php?cache=&media=azonenberg:xilinx:xc9572xl_bf_neo5x.jpg is the highest i have
<whitequark> aha
<azonenberg_work> i was thinking block diagram level more so than anything else
<azonenberg_work> but you can see the four function blocks in a 2x2 tile
<azonenberg_work> macrocells at top and bottom of the array, routing in the center
<azonenberg_work> then PLA is the triangular structures
<whitequark> whats up with the metal on right?
<whitequark> it's asymmetric
<azonenberg_work> that is likely where the non-array stuff lives
jevinskie has quit [Quit: Textual IRC Client: www.textualapp.com]
<azonenberg_work> jtag, boot, etc
<whitequark> ok
<azonenberg_work> but thats purely a conjecture based on limited data
<azonenberg_work> compare to the coolrunner series https://siliconpr0n.org/archive/doku.php?id=vendor:xilinx:xc2c
<azonenberg_work> where we know a lot more about the bitstream
<azonenberg_work> https://siliconpr0n.org/archive/lib/exe/fetch.php?cache=&media=azonenberg:xilinx:xc2c32a_bf_neo5x_annotated.jpg
<azonenberg_work> note the pla is a much smaller potion of the die because there is separate config eeprom
<azonenberg_work> whoops thats a bad image, let me get you a delayer
<azonenberg_work> here we go
jevinskie has joined ##openfpga
<azonenberg_work> also note that the coolrunner function blocks are based on pure digital trees of and/or gates
<whitequark> azonenberg_work: hang on
<azonenberg_work> while the xc9500 are sense amplifier based
<whitequark> the JED file still needs a xilinx programmer right?
<azonenberg_work> So they're denser (probably one floating gate pass fet per bit or something?)
<whitequark> that knows how to serialize it via JTAG?
<azonenberg_work> but more power hungry
<whitequark> you said 1458 words because of QF46656
<azonenberg_work> whitequark: in theory, it should be possible to feed a jed directly to/from th echip
<azonenberg_work> coolrunner breaks that
<whitequark> hm
<azonenberg_work> but according to the standard it SHOULD work natively
<whitequark> where is the info that says where you feed from JED to the chip?
<whitequark> which IR/DR?
<azonenberg_work> i dont know if that's documented :)
<whitequark> no I mean
<azonenberg_work> or bit ordering etc
<azonenberg_work> the standard is for moving files to black-box programmers
<whitequark> ok
<azonenberg_work> what the programmer does with it is not specified by jedec
<whitequark> I think I figured something out
<whitequark> can you paste me a full jed file
<azonenberg_work> did i not send you one already?
<whitequark> nvm, you did
<whitequark> so it has 972 4x8-bit lines, and 648 4x6-bit lines
<whitequark> which comes out to...
<whitequark> 1620 words.
<whitequark> looks like there are two different memory cell types, but the addressing is uniform
<azonenberg_work> interesting
<whitequark> brb, documenting
<whitequark> oh, even more interesting
<whitequark> it is organized into blocks of 9+6 rows
<whitequark> 9 4x8 rows then 6 4x6 rows
<whitequark> seems remarkably uniform
<azonenberg_work> how many of these blocks are there?
<whitequark> sec
<azonenberg_work> if anything is in groups of 4 tiles you've found the function blocks
<azonenberg_work> also, what might help is if somebody made a nontrivial design and generated a SVF file
<azonenberg_work> which has all of the jtag instructions to read/write the chip
<azonenberg_work> and trace bits from there out to the jed
<azonenberg_work> say, make a jed with only one nonzero bit and trace that to the svf
<azonenberg_work> etc
<whitequark> there are exactly 108 of these blocks
<azonenberg_work> so 27 blocks per function block?
<whitequark> looks like so
pie_ has quit [Remote host closed the connection]
<azonenberg_work> interesting because the fbs have 18 macrocells each
<azonenberg_work> that sounds like a 3:2 relationship
<whitequark> huh
pie_ has joined ##openfpga
<azonenberg_work> eonjcture: the base unit isnt 27
<azonenberg_work> it's 54
<azonenberg_work> conjecture*
<azonenberg_work> and you have one block for each function block plus one for interconnect
<azonenberg_work> totally hypothetical and i could be way off
<whitequark> sure
<whitequark> azonenberg_work: do you think its safe to program the entire chip into zeroes
<whitequark> and, into ones
<whitequark> just to see which bits are stuck at 0
<azonenberg_work> no
<azonenberg_work> definitely not
<azonenberg_work> if it's anything like coolrunner you'll get internal bus fights up the wazoo
<whitequark> aw
<azonenberg_work> coolrunner is loaded with one-hot muxes
<whitequark> shit
<azonenberg_work> that is in fact exactly how i killed the chip on purpose
<azonenberg_work> i set half the inputs of each mux high and half low
<azonenberg_work> then went N-hot
<azonenberg_work> to get a maximal short
<whitequark> hmmmmm $5 per chip
<whitequark> kind of pricey plus i have to rework
<whitequark> ok let's use the brain instead
<whitequark> i can probably just look at which bits are always 0
pie_ has quit [Excess Flood]
pie_ has joined ##openfpga
<whitequark> pfffffff
<whitequark> 11000000110000001000000011000000
<whitequark> 10000000100000001000000000000000
<whitequark> thanks xilinx
<whitequark> the 6-bit fields are definitely MSB-aligned
<whitequark> wait
<whitequark> what
<whitequark> 00101011000001000001000000000000
* whitequark stares
<whitequark> azonenberg_work: i feel like uh
<whitequark> the way they are aligned kinda depends on where they are on the chip
<whitequark> maybe they go left-right
<whitequark> probably not depending on quadrant
<azonenberg_work> they are almost certainly mirrored and rotated
<whitequark> oh
<azonenberg_work> conjecture: left side of the chip in the microscope photo is the top in address space
<azonenberg_work> left and right in address space are mirrored on the die
<azonenberg_work> Whether they're mirrored in the address space i dont know
<whitequark> i think the bitstream does not separate into quadrants
<whitequark> it seems like it goes top-bottom-top-bttom
<whitequark> because of how alignment works out
<azonenberg_work> you may have a logical vs physical bitstream then
<azonenberg_work> similar to how coolrunner is done
<whitequark> sure
<azonenberg_work> where you have to remap before you feed to jtag
<azonenberg_work> or alternatively, the remapping is done in the jtag logic on die
<azonenberg_work> and you feed logical addressing in
<whitequark> ok wtf
<whitequark> 11000001110000001010000011000000
<whitequark> this one makes NO sense
<whitequark> did i mess up my indexing?...
<whitequark> ah yes
<whitequark> I cannot count
<whitequark> off-by-1
<whitequark> no, still this weird shit
<whitequark> maybe the other bits are just invalid?..
<whitequark> and the programmer is supposed to ignore them?
<whitequark> wdyt?
<whitequark> e.g. there would be preveious value left on some floating gate
<whitequark> is that possible?
pie_ has quit [Ping timeout: 245 seconds]
rohitksingh has quit [Ping timeout: 246 seconds]
rohitksingh has joined ##openfpga
kuldeep has quit [Read error: Connection reset by peer]
kuldeep has joined ##openfpga
<whitequark> azonenberg_work: see XAPP069 btw
<whitequark> ISPEX
<whitequark> ISPEX transfers the XC9500/XL/XV memory cell contents to internal low power configuration
<whitequark> latches.
<whitequark> has some docs on the IRs
<azonenberg_work> oh interesting? so there IS a sram latch memory
<whitequark> it documents all IR values other than ISPENC
<whitequark> no idea what C is
<whitequark> differs by LSB
<whitequark> which elsewhere is "command variant"
<whitequark> so not iformative
<azonenberg_work> whitequark: also they summarize the ir values
<azonenberg_work> but dont include details on what the dr's do
<whitequark> yes
<whitequark> but BSDL gives a lot of insight into that
<whitequark> lemme write up
<whitequark> ok so, FPGM and FVFY have a 50-bit DR, FPGMI and FVFYI have a 34-bit DR
<whitequark> conjecture: first two bits are strobes
<whitequark> bit 1 is likely read strobe, bit 1 might be write strobe or something
<whitequark> let me try and experiment with FVFY to see how the address works
<whitequark> FERASE, FBULK, FBLANK all use 18-bit DR
<whitequark> so, 16-bit address, 32-bit data...
<whitequark> this is very easy to RE lol
<azonenberg_work> lol it wasnt meant to be hard
<azonenberg_work> keep in mind it may not be linear addressing
<azonenberg_work> coolrunner is gray coded
<whitequark> lets try to read address 205
<whitequark> this has a bunch of nonzero stuff around it
<whitequark> so i know how the alignment is
<whitequark> ok
<whitequark> first DR read: 00000000000000000000000000000000001111111111111111
<whitequark> second DR read: 00111111111111111111111111111111111111111111111111
<whitequark> ... i did not even have to try and figure out the layout
<azonenberg_work> lol
<whitequark> it literally just shown me
<whitequark> incredible chip
<azonenberg_work> simple, i like it :p
<whitequark> this is literally the least effort i have ever put into reverse-engineering anything
<whitequark> i just... write these things down
<whitequark> thats it
<whitequark> self-documenting hardware lmao
<azonenberg_work> lol
<whitequark> it would have only been easier if they put the ASCII spec in a ROM and shifted it via some infinitely long DR
<azonenberg_work> lool
<whitequark> which is actually something i should do one day
<whitequark> just for shock value
rohitksingh has quit [Ping timeout: 252 seconds]
rohitksingh has joined ##openfpga
<whitequark> ok, so setting any high bit
<whitequark> of the 2 control bits
<whitequark> results in reading first 00000010000000000000000000000000001111111111111111
<whitequark> then 00000000000000000000000000000000001111111111111111
<whitequark> this seems... odd.
<whitequark> oh wait
<whitequark> i forgot to enable isp
<azonenberg_work> whitequark: also possible that they have latency
<whitequark> sure
<azonenberg_work> with coolrunner you do one dr scan writing the address and dontcare data
<azonenberg_work> then another with the next address to read and you get data out of the first round
<whitequark> yes, how else would it even work?
<azonenberg_work> then you pipeline from there out
<whitequark> oh
<whitequark> yeah
<whitequark> exactly
<azonenberg_work> well the other possibility would be a second instruction or something
<whitequark> there's no other way
<azonenberg_work> load addr register then read data reg
<whitequark> ahhh yeah
<azonenberg_work> but thats less efficient
<whitequark> ok, all writes with LSB/LSB+1 set to 0 are just ignored
<whitequark> all writes with LSB set to 1 seem to return 10000000000000000000000000000000000000000100000000 regardless of other bits
<azonenberg_work> transfer bits or similar? or some kind of status flags?
<whitequark> hmm, maybe not
<whitequark> let's see
<whitequark> ok wtf
<whitequark> what???
<whitequark> i think the BSDL lies lol
<whitequark> ISCONFIGURATION is 39 bit long
<whitequark> not 50
<whitequark> because
<whitequark> i write 10100000000000000000000000000000000000000000000000
<whitequark> and i immediately get 10000000000000000000000000000000000000010100000000 back
<whitequark> like, in the same DR exchange
<whitequark> er
* whitequark stares more
<whitequark> oh ffs
<whitequark> typo
<whitequark> nevermind
<whitequark> writes with LSB high are ignored
<whitequark> writes with any other bits except low two are ignored
<whitequark> writes with 0:1 set to 01 are ignored
<whitequark> hm
<whitequark> actually, which writes aren't ignored?
<whitequark> 11 ignored too
rohitksingh has quit [Ping timeout: 240 seconds]
rohitksingh has joined ##openfpga
<whitequark> aha
<whitequark> got it to do something
<whitequark> by writing random junk there
<whitequark> looks like it's address then data
* kc8apf drools over softiron overdrive 3000
<whitequark> lol what
<whitequark> azonenberg_work: so
<whitequark> it gives me the address i wrote into it
<whitequark> in rverse
<whitequark> for some reason
<whitequark> afaict
<whitequark> and it looks like it actually uses byte addressing?..
<sorear> seems brave to be doing this on a chip w/ data you care about
<whitequark> well i've already read out the entire thing
<whitequark> hm
<whitequark> azonenberg_work: looks like bit 8 is necessary and sufficient to be set for the output to change
<whitequark> interesting
<whitequark> other bits seem to be mostly ignored
<whitequark> azonenberg_work: i wonder if ISCONFIGURATION is not just address + data
<whitequark> but more like COMMAND + DATA
<azonenberg_work> very likely
<whitequark> or not even just command
<azonenberg_work> Gimme a sec to make you a SVF for readback
<azonenberg_work> that may help
<whitequark> yep
<whitequark> i think it's not command exactly
<whitequark> i think it's driving an FSM directly
<sorear> like y'all are not even trying to MITM the official programmer?
<azonenberg_work> do you want a trivial bitstream or something with more bits set?
<whitequark> trivial
<azonenberg_work> sorear: whitequark doesnt have a copy of ise
<azonenberg_work> Lol
<whitequark> sorear: or the original programmer
<whitequark> or patience for this shit
<whitequark> its legit easier to just poke the chip than to dig in xilinx crap
<whitequark> azonenberg_work: i think i found out partof the command set already
<whitequark> gimme a sec
<whitequark> ok, bit 7 sets the VALID bit in output
<azonenberg_work> whitequark: its too big for the debia npastebin lol
<whitequark> i wonder why the fuck does it reverse the bits
wbraun has quit [Quit: wbraun]
<azonenberg_work> whitequark: svf program http://paste.debian.net/hidden/20f4db0c/
<whitequark> wow
<whitequark> this is very
<whitequark> ascii
<azonenberg_work> svf verify http://paste.debian.net/hidden/4903620f/
<azonenberg_work> the original file was these two concatenated
<azonenberg_work> i think i split at the right spot
<azonenberg_work> but dont trust me on that
<whitequark> that seems legit given what ive seen so far
<azonenberg_work> note the 20K tck cycles between program operations
<azonenberg_work> probably waiting for each address to program
<whitequark> SDR 50 TDI (00058400000003) TDO (00058000000001) MASK (03fffcfcfcfcff) ;
<sorear> whitequark: sure, I'm just thinking about "what if there's a bonus undocumented erase command"
<whitequark> oh
<whitequark> this
<whitequark> sorear: no the ERASE cmmands are all documented
<whitequark> SDR 50 TDI (000d0400000103) TDO (000d0000000001) ;
<whitequark> RUNTEST 1 TCK;
<whitequark> RUNTEST 1 TCK;
<whitequark> SDR 50 TDI (000d0800000003) TDO (000d0400000101) ;
<whitequark> ok
<daveshah> sorear: halt and catch fire style perhaps :D
<whitequark> i see
<whitequark> azonenberg_work: this actually looks like data:address hmmmmmm
<azonenberg_work> looks like addr:data to me
<azonenberg_work> 24 bit address then 32 bit data
<azonenberg_work> with addr bytewise
<whitequark> no, the low bits are valid + write strobe
<whitequark> i think
<azonenberg_work> the tdo data is verification of the bitstream for this particular design
<whitequark> yeah
<whitequark> so you see address shifted by ... wait, what
<azonenberg_work> the SDR command specifies the tdi data you feed the chip and the expected tdo data
<whitequark> azonenberg_work: no its not 24 + 32 bit
<whitequark> SDR 50
<whitequark> yes
<whitequark> thats why
<azonenberg_work> well ok yeah the high bits are chopped
<azonenberg_work> they padded it i guess
<azonenberg_work> But svf is meant to be executed line by line by a dumb programmer
<whitequark> and 3 is def strobes
<whitequark> sure
<azonenberg_work> probably passed in over rs232
<whitequark> this all makes sense to me
<whitequark> (i should implement SVF lol)
<azonenberg_work> how sure are you that they're strobes? are they not in the jed?
<whitequark> they are not in the JED
<whitequark> for sure
<azonenberg_work> yeah ok
<whitequark> and they look super like strobes elsewhere
<azonenberg_work> then probably valid/strobe bits or something
<whitequark> this is how all its registers look like
<azonenberg_work> i know coolrunner has a "transfer bit" at the start and end of each 260-bit register
* whitequark facedesks
<whitequark> i think i'm miscounting again
azonenberg_mobil has joined ##openfpga
<azonenberg_work> heading out, back in a bit
azonenberg_work has quit [Ping timeout: 268 seconds]
<whitequark> azonenberg_mobil: AAAAAAAA
<whitequark> i fucked up endianness
<whitequark> when converting bitarrays to byte arrays when sending to glasgow
<whitequark> because the python "bitarray" package has a completely braindead interface
* whitequark stabs bitarray several times
<whitequark> thats why i had bits 7 and 8 do something
<whitequark> those were the strobes...
<whitequark> 0 and 1...
<azonenberg_mobil> lolol
<azonenberg_mobil> that would make a lot more sense
<awygle> <3 python
wbraun has joined ##openfpga
azonenberg_work has joined ##openfpga
<whitequark> no, python is ok here
<whitequark> the library is 3rd party from pypi
<whitequark> and it is a good library other than...
<whitequark> awygle: so it has endianness during conversion to/from bytes an inherent property of the bit arrays
<whitequark> but it's only used in tobytes/frombytes
<whitequark> and you cannot specify it *in* tobytes/frombytes
<whitequark> this is idiotic
<awygle> sounds idiotic
<whitequark> it is probably an exposed implementation detail but that doesnt justify it
<whitequark> it has been the second worst source of glasgow bugs after weak typing
<whitequark> in python
<whitequark> i just need to wrap it already i think
<whitequark> the default is big endian ofc
wbraun has quit [Quit: wbraun]
<whitequark> even though it makes no sense because *bytes* go from lsb to msb
<whitequark> so if you do bitarray('10000000') and feed it to glasgow it reverses everything
wbraun has joined ##openfpga
rohitksingh has quit [Ping timeout: 268 seconds]
azonenberg_work has quit [Ping timeout: 260 seconds]
<rqou> whitequark: you have seen this, right? https://github.com/rqou/project14/blob/master/XC9500.md
<rqou> whitequark: this is for the non-xl, but xl is very similar
<whitequark> nope
<whitequark> also i'm nearly done
<whitequark> gimme a sec
<rqou> whitequark: all the cplds have an address map file just like xc2c, but the 9500(xl) are much more in order
<rqou> wait wtf?!
<rqou> you've fully REd the bitstream?!
<whitequark> no
<whitequark> the programming protocol
<rqou> ah ok
<Bob_Dole> I would not put it past whitequark to have fully REd something that fast.
<whitequark> i'm not good at RE
<whitequark> ok, i have bitstream readout functional
<whitequark> i... think?
<whitequark> OH
<whitequark> it's PADDED
<qu1j0t3> twss
<whitequark> azonenberg_mobil: your guess was correct
<whitequark> bitstream when read with NON autoincrement goes in blocks of 30 words
<whitequark> so, 15+15
<whitequark> they are spaced out with
<whitequark> 11001001110010011100100111001001
<whitequark> 01001010010010100000000101001010
<whitequark> in between
<whitequark> also the 1st 24 words appear to be special
<azonenberg_mobil> usercode plus global config?
<whitequark> first 24? no idea, but usercode is unlikely to be there according to JED
<azonenberg_mobil> rqou: wait they have a map file?
<whitequark> it seems to steal bits from bitstream elsewhere
<whitequark> it is also zeroed out entirely here
<rqou> usercode steals bits from elsewhere
<rqou> azonenberg_mobil: yes
<rqou> except the map file has a really obvious pattern
kem_ has quit [Quit: Connection closed for inactivity]
<whitequark> azonenberg_mobil: ok, so it looks like with self-clocking mode
<whitequark> it first outputs the sync pattern above
<whitequark> then 3 dummy words (?)
<whitequark> then 24 initial words
<whitequark> then it goes through every block afterwards WITHOUT padding
pie_ has joined ##openfpga
<whitequark> interestingly
<whitequark> the SVF file programs everything in a sequence like
<whitequark> 0,1,2,3,4 8,9,10,11,12 16,17,18,19,20
<rqou> yeah
<rqou> sounds vaguely familiar
<rqou> just look at the .map files
<rqou> oh wait you don't have ISE do you
<whitequark> nope lol
<rqou> btw while you're at this can you think about writing .crbit to .svf for xc2c?
<whitequark> hmmmm
<whitequark> .svf?
<whitequark> rqou: i might be able to uhhhh
<whitequark> write a glasgow "jtag" interface which is actually a thing that writes svf
<whitequark> so every applet that can talk to jtag directly can directly write svf
<whitequark> this needs to, ah, some refactoring
<whitequark> first-class TDO matching and masking
<whitequark> i think
<whitequark> but that's all
<rqou> whatever i don't care for now
<whitequark> but in general glasgow is not supposed to be an svf player
<whitequark> or recorder
<whitequark> i guess i'll add an svf player
<rqou> why not?
<whitequark> it's fundamentally interactive
<rqou> svf player kinda makes sense?
<whitequark> it doesn't *have* to be i guess
<whitequark> like imagine uh
<whitequark> MIPS EJTAG
<whitequark> the problem is all the register bitfields
<rqou> i still think _playing_ svf makes sense
<whitequark> playing, yes
<whitequark> i will do that
<whitequark> recording will need to be opt-in from applets i think
<rqou> but whatever, you can just do `vi crbit2svf.{sed|rb|py|c|rs}` for all i care
<rqou> I've just never managed to get around to writing this script
<daveshah> Supporting svf would definitely be handy
<rqou> crbit is already munged into the correct bit ordering
<rqou> so you "just" need to wrap the programming setup commands around it
<whitequark> sure, i'll add svf support, i guess
<daveshah> I partly say that because the Trellis "programming" solution is a similar hacky script to make an svf
pie_ has quit [Ping timeout: 268 seconds]
<daveshah> For the ecp5 it's nice and easy because you just set things up then shift the whole bitstream in as is
<whitequark> sure
<daveshah> The same bit file that would go to flash or whatever
<daveshah> If you look at the scripts included with Diamond programmer it clearly supports a whole load of interesting commands
<daveshah> undocumented
<daveshah> Manufacturing trim access, also direct access to the serdes config space
<daveshah> Might be fun to play with at some point
<whitequark> huh
<daveshah> I wonder if there's a way to blow the IDCODE fuses even
<daveshah> They obviously have some way of doing that because the same die has different IDCODEs
<daveshah> For 12k/25k and U/UM/UM5G
<rqou> alright, back to driving
<azonenberg_mobil> yeah jtaghal is fundamentally interactive too
pie_ has joined ##openfpga
<azonenberg_mobil> things like walking arm debug roms arent too practical to do remotely
<whitequark> yeah
<daveshah> yeah, I'd only want svf play functionality
<azonenberg_mobil> agreed. i want play in jtaghal
<azonenberg_mobil> but i have no use for record
Bicyclidine is now known as Bike
azonenberg_work has joined ##openfpga
<pie_> something something that one usb controller bricking fest? <whitequark> the SVF file programs everything in a sequence like
<pie_> eh nevermind
<whitequark> huh?
<pie_> i forgot the name of the company that makes ubiquitous usb controller chip things, and then they did a firmware update that started briching stuff. i think there was something about legit chips writing half-words and counterfeits zeroing the top half or something
<whitequark> ftdi?
<pie_> yeah that
Zylellrenfar has quit [Quit: Bye bye~]
Zylellrenfar has joined ##openfpga