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