scrts has quit [Ping timeout: 246 seconds]
scrts has joined ##openfpga
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vHHRL
<openfpga-github> openfpga/master 9bbc62f Andrew Zonenberg: Initial work on CoolRunner-II device simulation model
<azonenberg> Gonna have to take a detour to port my coolrunner jtag code from libjtaghal over to the current verison
<azonenberg> so i can test'
<azonenberg> Hopefully by the end of today i'll be able to at least have it detect an xc2c32a in the correct "package"
<rqou> i'm surprised you're bothering to model the jtag stuff
<azonenberg> i'm initially just gonna do idcode and some status
<azonenberg> but will probably do the full programming algorithm eventually
<rqou> including potential bugs? we need more schematic recovery for that, don't we?
<azonenberg> Initially i'm just going to model behavior for the minimal specified subset of instructions needed to program
<azonenberg> We can work on other features, glitches, etc later on
<rqou> so no hacking the idcode yet :P
<azonenberg> But basically i want to be able to shove a jtag dongle into a pmod
<azonenberg> and have it think there's a coolrunner attached
<rqou> i want to be able to counterfeit a 32a as a more-believable 512 :P
<azonenberg> loool
<azonenberg> at least make it be the same package
<azonenberg> like a 32a into a 64a in vqg44
<rqou> xilinx will be very mad at us :P
<azonenberg> well, see
<azonenberg> as far as i can tell making this model is totally legal
<azonenberg> as is testing stuff on it
<azonenberg> The EULA says you can only use xilinx EDA tools to create bitstreams to run on Xilinx devices
<azonenberg> By a literal reading, it's totally kosher to run an XC2C32A bitstream on an XC7Z010
<azonenberg> But not to run an XC2C32A bitstream on e.g. a cyclone iv
<azonenberg> rqou: also fwiw
<azonenberg> there are six undocumented jtag instructions listed in the programmer qual spec
<azonenberg> 0x10 to 0x16
<azonenberg> The BSDL has some info on that
<azonenberg> like "ERASE_ALL"
<azonenberg> and "MVERIFY"
<azonenberg> Guessing ERASE_ALL wipes the idcode
<azonenberg> i'll test that soon
<rqou> um...
<rqou> how are you going to fix it afterwards? :P
<azonenberg> on a 32a? I wont
<azonenberg> i will assume it's a device brick
<rqou> STCTEST also looks interesting
<rqou> why is it commented out?
<azonenberg> i was wondering the same :p
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vHH0v
<openfpga-github> openfpga/master 84e6350 Andrew Zonenberg: Added remaining JTAG instruction declarations
<rqou> are BSDL files intended to be public?
<azonenberg> Yes, they're used by test equipment, jtag tools, etc
<rqou> the eda world's "secret but not really secret" is so weird
digshadow has quit [Ping timeout: 246 seconds]
scrts has quit [Ping timeout: 246 seconds]
scrts has joined ##openfpga
digshadow has joined ##openfpga
Zarutian has quit [Quit: Zarutian]
amclain has quit [Quit: Leaving]
<cyrozap> Cypress's actions as a company often confuse me: http://www.cypress.com/forum/psoc-creator-software/simulating-psoc-udbs-modelsim
<cyrozap> ^ pointfree (et al.)
<cyrozap> tl;dr: Cypress has UDB simulation models available, free of charge. Also, it looks like they're included in PSoC Creator, so it's actually probably better to get those files from there.
<cyrozap> The files are under warp/lib/sim/presynth/vlg.
eightdot has quit [Ping timeout: 260 seconds]
scrts has quit [Ping timeout: 240 seconds]
<pointfree> cyrozap: Is that relevant to your UDB parser? What is it?
<pointfree> cyrozap: A few updates on what I've been up to regarding the PSoC 5LP:
<pointfree> The HV tile reg mappings flip at the second half of the HV tile.
<pointfree> I've isolated the VS registers and bits with some scripts. They get mirrored like all other vertical switching (because vertical switching is always i/o).
<pointfree> Although... I don't like to think of mirroring as mirroring, I like to think of it as akin to Tx/Rx on a uart interface. It's much simpler to say inwards/outwards than up(mirrored?)/down(mirrored?).
<pointfree> The logic fabric is addressed like an https://en.wikipedia.org/wiki/H_tree Look at the register addresses in binary, not as register names and not as hex.
<pointfree> It's looking like the logic fabric can be traversed by shifting a single bit and OR'ing it onto the previous or NOT OR'ing it onto the previous. The routing tiles appear to be nothing but other relevant tiles' addresses OR'd together -- in other words they are interfaces.
<pointfree> I'd like to view the entire logic fabric as a BDD -- that includes not only the PLD's but also the routing fabric. Sign (truth/complement) can also understood as direction (inwards/outwards) for logic minimization, covering set purposes.
<pointfree> This paper is guiding the BDD approach to logic synthesis: https://www.computer.org/csdl/proceedings/dac/1992/2822/00/00227865.pdf Quine-McCluskey is too slow for embedded use. Espresso/other heuristics are fast but don't give the best result. The 1990's BDD-based approach is almost as fast as espresso and gives the best result as well.
<pointfree> I've started trying to make sense of the Digital Filter Block as well... It has it's own instruction set and I'd like to get the encoding for it. This blog http://arttools.blogspot.com/search/label/PSoC%205LP has been helpful right now for the big picture.
<pointfree> As you may have guessed, I'd like to fit the spar into the DFB for live reconfig. Doing so would alleviate the comparatively somewhat smallish size of the UDB array.
eightdot has joined ##openfpga
<cyrozap> pointfree: Regarding the stuff I posted earlier, it's not really relevant to our toolchain stuff--it's just helpful for simulation. Since it includes models for the datapath elements, you can write testbenches for cores that use the datapath(s).
scrts has joined ##openfpga
<pointfree> cyrozap: It does remind me that it would be good have some scripts that sweep through possible logic fabric configurations -- perhaps for gathering timing info later on.
GreeningGalaxy is now known as Ellied
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
digshadow has quit [Ping timeout: 240 seconds]
<azonenberg> pointfree: once you get to that point i will have a good timing characterization setup done for greenpak
<azonenberg> it should be easy to port
<pointfree> azonenberg: Yeah I saw that and thought it would be useful for the PSoC as well. Are you using it for analog stuff as well? I haven't really considered timing at all in my spar. I suppose it's just a matter of including coefficients to influence the spar somehow(?)
<pointfree> (spar == synthesis+placement+routing)
<azonenberg_work> the analog performance of greenpak is well characterized in the datasheet iirc
<azonenberg_work> But i can always measure analog stuff should the need arise
<azonenberg_work> rqou: also playing reworkctf again woo
<azonenberg_work> Swapping a diff pair on an inner layer
<azonenberg_work> this is gonna be fun
<pointfree> azonenberg: Also, I've been working on an spar that fits inside the DFB, but I think people would also like to see something that goes with the verilog+yosys workflow. What is the preferred language for inclusion into openfpga? I see C++ but also some chatter about using Rust.
<azonenberg_work> pointfree: I prefer C++
<azonenberg_work> rqou is doing his coolrunner stuff in rust and dealing with the interop hassle
<azonenberg_work> i dont know rust but as long as he maintains it i'll tolerate it for now
<azonenberg_work> if you know c++ its strongly preferred :p
<rqou> i don't think anybody "knows" c++ except maybe bjarne
<rqou> :P
<azonenberg_work> I know more C++ than rust
<azonenberg_work> is that preferable? :p
<rqou> yeah, i just dislike C++ _that_ much
<pointfree> I know some C++, although maybe not fancy "modern C++" ...I'm learning Rust for https://pijul.org/ but my gut tells me Rust will turn into C++ given too many cooks and enough time ...But I don't know enough about Rust to place a bet on that.
Finnpixel has quit [Ping timeout: 260 seconds]
<cr1901_modern> I would wager that nobody on this planet completely understands c++. Contrast to c, there's a few ppl I suspect know the full standard. Edison Design Group is probably the closest you'll get (last I checked, it was 3 people writing a C++ front end).
<cr1901_modern> And even _they_ took 1.5 person years to write a full C++03 compiler (they have a paper on their experiences implementing "export" semantics, which no other C++ compiler before and since has implemented).
<rqou> export semantics?
<cr1901_modern> implementing the export keyword*
<rqou> cppreference says "The keyword is unused and reserved. "
<cr1901_modern> It had meaning in C++03. It's was taken out of C++11
<cr1901_modern> "All [when asked by other implementers for advice about how best to implement export]: “Don’t.”"
<rqou> "the export feature alone required more effort to implement than it took the same team to create a new implementation of the complete Java language."
<rqou> wtf
<rqou> what does this even do?
<cr1901_modern> it allows you to move template definitions out of header files IIRC
<rqou> "Used to mark a template definition exported, which allows the same template to be declared, but not defined, in other translation units."
<rqou> why do i care about this?
<cr1901_modern> B/c information hiding etc etc
<cr1901_modern> user shouldn't care about template impl etc etc
<rqou> (sorry, still reading the n1426.pdf) I don't see how you get that out of "Used to mark a template definition exported, which allows the same template to be declared, but not defined, in other translation units."
<cr1901_modern> B/c you include the header w/ a template impl if you need to use a particular template. In _every_ source file you need to use the template.
<rqou> i still don't understand what it was _supposed_ to do?
<cr1901_modern> It let you separate declaring a template from defining it in the same file
<cr1901_modern> In any case, I think there's a problem (with the scope of the feature? With the complexity of the entire language?) when it takes a small group of some of the world's best compiler designers 1.5 years to implement a single feature of a language.
<cr1901_modern> Good riddance it's gone, but I can't help but feel it should've never happened in the first place
<rqou> wait, you can't do that normally?
<cr1901_modern> No, try it :)
<cr1901_modern> Or at least I *think* you can't. If you manage to succeed, then ignore my explanation, b/c in that case Idk what it does either :).
<cr1901_modern> "Don’t expect that export means you don’t have to ship source code (or its equivalent) anyway. You still do, and this will not change." Huh...
<rqou> why is this feature so hard to explain?
<rqou> i read up to the appendix and I still have no idea what the intent is
<rqou> ok i read the first appendix and i finally think i get it
<rqou> that's completely useless
digshadow has joined ##openfpga
<azonenberg> rqou: around?
<azonenberg> in the JTAG ID codes
<rqou> yeah?
<azonenberg> the family ID for coolrunner-2 can be either 0x36 or 0x37
<azonenberg> Is there any logical split there?
<rqou> wait where?
<rqou> they're all "011" in the programmer qualification doc?
<azonenberg> xilinx's jtag idcode scheme is
<azonenberg> right bit always 1
<azonenberg> sorry i mean, 0
<azonenberg> or no it is 1
<azonenberg> then next 11 bits are xilinx's vendor ID code
<azonenberg> next 9 bits are array size
<azonenberg> next 7 are family
<azonenberg> the last 4 are stepping
<azonenberg> ah, i see
<azonenberg> So it's 011011 (0x36 << 1)
<azonenberg> then the high bit of the macrocell count overlaps with the normal family ID bits
<azonenberg> So that makes sense
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vHHSA
<openfpga-github> openfpga/master 571e5a6 Andrew Zonenberg: XC2CDevice: added config memory dimensions for all devices
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vHH9f
<openfpga-github> openfpga/master 1d4cbf4 Andrew Zonenberg: Added snaity check for macrocell count
<cr1901_modern> snaity check... I like that
<whitequark> pointfree: i don't think rust will turn into c++, not in any meaningful way, precisely because most of rust's design is specifically in place the way it is because it's learning from the mistakes of c++
<whitequark> what it *might* turn into though is haskell
<whitequark> {-# LANGUAGE foo #-} vs #![feature(foo)]; the latter is at least for now significantly more restricted in the ways it may alter the language, but that's for now, and they still fragment the community
<whitequark> and also things like HKT that invite type-level wankery
scrts has quit [Ping timeout: 246 seconds]
<whitequark> if you want a theorem prover, by all means, please go ahead and use a theorem prover. don't use rustc's typechecker as an extremely bad approximation of a theorem prover though
<cr1901_modern> HKT seems to be a "wish list" feature of the ppl I know who prefer Haskell to Rust
<whitequark> (strictly speaking any typechecker or optimizer is a theorem prover but here under "theorem prover" i mean the more general, often interactive, ones)
<rqou> i really do want type-level integers though (and definitely not the VHDL way :P )
<whitequark> type-level integers would result in *less* type-level wankery
<whitequark> right now people either bail or use peano numbers, both of which are Bad
<whitequark> cr1901_modern: i hope they stay on Haskell, frankly
<whitequark> HKT does solve a few real problems but IMO it causes more damage in return
<cr1901_modern> Rust community I've talk to personally claims not to need HKT. And I don't understand them well enough to comment (though I got close last time I tried).
<cr1901_modern> What is a "bail number"? Google is giving me hits for bail bondsman to contact
<cr1901_modern> ... fuck me, reading fail
scrts has joined ##openfpga
<cr1901_modern> whitequark: https://irclog.whitequark.org/~h~openfpga/2017-06-13#19576868; It's funny. Not gonna name, but I've noticed the same people who harp on Rust for this exact fragmentation point seem to conveniently forgive it for Haskell
massi has joined ##openfpga
<whitequark> I think it was sig who compared #![feature] with {-#LANGUAGE#-}
<whitequark> which---really is a good point!
pie_ has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 255 seconds]
Hootch has joined ##openfpga
<egg|work|egg> whitequark: yeah, type-level integers are nice (something something dimensional analysis)
egg|work|egg has quit [Quit: Page closed]
egg|work|egg has joined ##openfpga
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
pie_ has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
Zarutian has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 240 seconds]
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
<pie__> whitequark, another game ive wanted to try botting for a while is tanki
m_t has joined ##openfpga
eduardo__ has joined ##openfpga
eduardo_ has quit [Ping timeout: 240 seconds]
pie__ has quit [Ping timeout: 240 seconds]
pie_ has joined ##openfpga
DingoSaar_ has joined ##openfpga
DingoSaar_ has quit [Client Quit]
DingoSaar has quit [Ping timeout: 240 seconds]
Zarutian has quit [Quit: Zarutian]
m_t has quit [Remote host closed the connection]
massi has quit [Remote host closed the connection]
digshadow has quit [Ping timeout: 240 seconds]
mifune has joined ##openfpga
mifune has joined ##openfpga
digshadow has joined ##openfpga
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 240 seconds]
pie_ has joined ##openfpga
m_t has joined ##openfpga
<egg|zzz|egg> fyi, catstream is live
<azonenberg> Next Debian comes out on Saturday
<azonenberg> guess i'll have a fun Patch Monday when i get home from REcon
<rqou> meh, just run sid :P
<azonenberg> lol no
<azonenberg> i still have one or two VPSes running oldstable
<rqou> although i haven't updated my sid in over a month, so that's pretty bad too
<azonenberg> lol
<rqou> my servers still run ubuntu because ubuntu tends to be less stale than debian
<azonenberg> s/stale/stable/
<rqou> lol
<rqou> i thought "debian stale" was a common mockery of debian?
<azonenberg> My only complaint with debian is that, although they backport security fixes
<azonenberg> they often do not backport major crashing bugs that aren't exploitable
<azonenberg> i.e. if i cant pop shell with it they won't backport
<rqou> for my workstations i just don't want to deal with major patch days/flag days which is why i run a rolling release
<rqou> meanwhile for servers my opinion is "meh, ubuntu is new enough and popular enough"
<azonenberg> maybe i've been burned by ubuntu
<azonenberg> randomly changing the UI to a totally different appearance every release for a while
<azonenberg> that level of disruption is not tolerable
<rqou> so i hate ubuntu on workstations because everything breaks every major update
<rqou> but only "destop-y stuff" breaks
<azonenberg> Debian doesnt seem to break nearly as badly
mifune has quit [Ping timeout: 240 seconds]
<rqou> although i was _extremely_ unhappy with the last ubuntu lts update
<cr1901_modern> I've never had an Ubuntu upgrade go smoothly. But I only upgrade from LTS to LTS
<rqou> "hi, we switched you to Poeterringware (systemd) and broke all your init stuff and didn't tell you a single word about this in the release notes"
<azonenberg> rqou: debian is running systemd too now
<azonenberg> they do support sysvinit
<mtp> love too use comptuer that switches core software on you without advance consent
<azonenberg> but i didnt have the time to go rip it all out
<rqou> sure, i don't really care about it either way
<azonenberg> and switch
<cr1901_modern> Use Slackware :D?
<mtp> freebsd ;p
<rqou> i was just extremely dissatisfied when i dist-upgraded from utopic to xenial and then everything blew up
<rqou> checked release notes, nothing
<cr1901_modern> Well I use *BSD for servers when possible, so...
<rqou> eventually while poking around why stuff was broken I discovered that there was this new "systemd" thing
<azonenberg> rqou: also after work today i'm going to make a PCB with a greenpak, thermal sensor, INA226, and attachments for a peltier
<rqou> but yeah, my first exposure to Poeteringware was halfway through a dist-upgrade, so i'm not happy
<rqou> before that, i had heard "yeah, there's a lot of noise/drama about this new 'systemd' thing, but meh, don't have time to care"
_whitelogger has joined ##openfpga
<pie_> i dont get its spread
<pie_> it feels like wildfile
<pie_> wildfire
<pie_> then again maybe i was just ignoring the signs
<pie_> denial
pie_ has quit [Changing host]
pie_ has joined ##openfpga
Hootch has quit [Read error: Connection reset by peer]
scrts has quit [Ping timeout: 268 seconds]
<qu1j0t3> pie_: it has been pushed by major distros
<pie_> welll
<pie_> but that happened somehow
<qu1j0t3> (and a lot of the devs work for RedHat so...)
<cr1901_modern> ^This
<cr1901_modern> RedHat can essentially push what they want and it'll be adopted
<qu1j0t3> cr1901_modern: what's also curious is what happened inside RedHat.
<qu1j0t3> in a kind of 'Chernobyl: How it really unfolded' way
<cr1901_modern> Oh? I'm not familiar w/ it. I know Linus himself got sick of Sievers' shit at least.
<pie_> LOL :/
<pie_> re cherno, is that a book or something
m_w has quit [Quit: leaving]
m_w has joined ##openfpga
m_w has quit [Client Quit]
m_w has joined ##openfpga
mifune has joined ##openfpga
mifune has joined ##openfpga
mifune has quit [Ping timeout: 260 seconds]
mfgmfg has quit []
scrts has joined ##openfpga
m_t has quit [Quit: Leaving]
mifune has joined ##openfpga
mifune has quit [Ping timeout: 260 seconds]
<rqou> azonenberg: the 32a zia bits don't mirror themselves even though the PLA/macrocell bits do
<rqou> does that match die observations?
<azonenberg> rqou: Yes
<azonenberg> The ZIA bits are actually interleaved
<azonenberg> you have a single bus coming down vertically
<azonenberg> then two horizontal outputs, one going left and one right
<azonenberg> with eight pass transistors and eight sram bits hanging below
<azonenberg> This is the PLA AND array at left (you can see the two different cell designs in the tree, i havent studied them in detail yet though)
<azonenberg> then the ZIA stuff in the middle is two rows high
<azonenberg> so a total of four channels, two leftbound and two rightbound
<azonenberg> interestingly, the row buffer is three stages so the signal driving into the AND array is inverted relative to what's on the M4 bus
<azonenberg> but since the AND array has both X and !X inputs, that's fine
<rqou> ooh that might be why in the physical bits the inverted inputs come "first"
<rqou> so pairs of bits are in opposite orders in the logical ordering vs the physical ordering
<azonenberg> this is the physical ordering of the bitlines on M2
<azonenberg> Note that the rightmost (0x81) group has only 10 inputs instead of 11
<azonenberg> http://thanatos.virtual.antikernel.net/unlisted/zia_final_noimages.svg is the fully vectorized SVG with SEM photos removed to reduce file size
<azonenberg> with all layers
<rqou> huh, understanding the 32a physical map layout isn't that bad
<rqou> for the 128+ devices, it's probably actually simpler than the logical layout
<rqou> because the numbering doesn't suddenly change when there are buried macrocells
<azonenberg> Lol
<azonenberg> Yeah the physical layout makes a lot of sense to me
<azonenberg> Also if you're curious (warning, large file)
<azonenberg> here is the full ZIA ROM in physical form :p
<azonenberg> 4.5k x 30k pixels
<azonenberg> Dust specks and all
<azonenberg> But you can clearly see one dot in each of the six groups
<azonenberg> for each row
<azonenberg> The polish was not exactly flat so i started to lose the M3 image about halfway down
<azonenberg> since oxide was building up
<azonenberg> but the vias were still visible so i used them to align
<azonenberg> I suspect that those diagonal vias in the middle may have something to do with the global muxes in the middle of the array
<azonenberg> but i dont know for sure, i havent RE'd that part of the chpi
<azonenberg> Toward the bottom of the image you can actually see M4 coming into view, lol
<azonenberg> I could probably do a lot better now
<azonenberg> just with selective fib milling
<rqou> oh did i mention yet that the 64a macrocell bits are in a totally different order?
<azonenberg> Yeah i think you did
<azonenberg> I have sem shots of the 32a macrocells
<azonenberg> but not the 64
<azonenberg> sec let me try and dig them up
<azonenberg> not all layers
<azonenberg> just active i think?