digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 245 seconds]
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
digshadow has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 256 seconds]
digshadow has joined ##openfpga
pointfree has quit [Remote host closed the connection]
pointfree has joined ##openfpga
balrog has quit [Ping timeout: 252 seconds]
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
balrog has joined ##openfpga
Bike has quit [Quit: sleeped]
<azonenberg> whitequark: you around?
<azonenberg> had a few things i wanted your thoughts on
<openfpga-github> [logtools] azonenberg pushed 1 new commit to master: https://git.io/vXqfe
<openfpga-github> logtools/master f926aeb Andrew Zonenberg: Added initial (not yet functional) skeleton of ColoredSTDLogSink
<openfpga-github> [logtools] azonenberg pushed 1 new commit to master: https://git.io/vXqfm
<openfpga-github> logtools/master 53a9e80 Andrew Zonenberg: Fixed overzealous searhc-and-replace bug
<openfpga-github> [logtools] azonenberg pushed 1 new commit to master: https://git.io/vXqfn
<openfpga-github> logtools/master 03375ea Andrew Zonenberg: Fixed std:: again
<openfpga-github> [logtools] azonenberg pushed 1 new commit to master: https://git.io/vXqfr
<openfpga-github> logtools/master 2605e97 Andrew Zonenberg: Fixed yet another typo... must be time to sleep :)
bibor has quit [Ping timeout: 265 seconds]
kuldeep has quit [Ping timeout: 244 seconds]
kuldeep has joined ##openfpga
bibor has joined ##openfpga
scrts has quit [Ping timeout: 245 seconds]
tecepe has quit [Read error: Connection reset by peer]
scrts has joined ##openfpga
talsit has left ##openfpga [##openfpga]
massi has joined ##openfpga
scrts has quit [Ping timeout: 244 seconds]
scrts has joined ##openfpga
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
tecepe has joined ##openfpga
scrts has quit [Ping timeout: 250 seconds]
scrts has joined ##openfpga
<whitequark> azonenberg: re tests: shared tests seem totally fine
<whitequark> mostly i think execution of compiled greenpak test code should be confined to when 'make test' is run
<whitequark> if that's the case and i misunderstood, then it's all ok
scrts has quit [Ping timeout: 268 seconds]
scrts has joined ##openfpga
doomlord has joined ##openfpga
massi has quit [Quit: Leaving]
digshadow has quit [Ping timeout: 268 seconds]
scrts has quit [Ping timeout: 244 seconds]
scrts has joined ##openfpga
amclain has joined ##openfpga
Bike has joined ##openfpga
digshadow has joined ##openfpga
<azonenberg> whitequark: you mean execution of gp4par?
<whitequark> that too yes
<whitequark> we are trying to test gp4par
<whitequark> oh and also
<whitequark> cross-compilation
<azonenberg> whitequark: i'll see if i can restructure it a bit
<azonenberg> Make a ticket and i'll get to it after work
<azonenberg> So the other thing i wanted your thoughts on
<azonenberg> In my old build system (splash v0.1x) i color coded error messages using ansi escape sequences
<azonenberg> I want to do the same in some of my projects now
<whitequark> sure
<azonenberg> My current thought is, add a new log sink ColoredSTDLogSink derived from STDLogSink
<azonenberg> then add a hook function to the base Log class that pre-processes a string before rendering it
<azonenberg> default to doing nothing
<whitequark> sure
<azonenberg> in the override class, replace "ERROR" with "(red)ERROR(default)"
<azonenberg> sound like a sane architecture?
<whitequark> composition would be more elegant
<whitequark> but probably not worth the hassle
<openfpga-github> [openfpga] whitequark opened issue #58: Don't run compiled code right away for tests https://git.io/vXmJH
<azonenberg> whitequark: can you go into more detail?
<azonenberg> re composition
<whitequark> instead of adding a hook function to be overridden, implement a proxy logger that accepts a logger in the constructor
<azonenberg> yeah that sounds overly complex for such a simple functionality
<azonenberg> i mean the original design i had would just override WrapString() but that functionality isnt changing
<azonenberg> seemed easier to just add a "preprocess one line of text" function
<whitequark> it's actually simpler because you have fewer moving parts. i mean, logically a logger is just a single function
<whitequark> but it sounds awkward in C++
<whitequark> it comes out*
<whitequark> hence "not worth the hassle"
<azonenberg> Lol yeah
<azonenberg> whitequark: i guess this means i have to figure out how to make tests depend on each other or something?
<azonenberg> (re ticket)
<azonenberg> also i'm going with a happy medium between our originally proposed policies as far as the bitstreams for socket testing, etc goes
<azonenberg> I am shipping the source for those netlists so that i can easily re-generate them on demand
<azonenberg> but also caching a hard coded hex binary in gp4prog
<azonenberg> with comments referencing the source files
<azonenberg> "to reproduce, build foobar for slg46140v"
<azonenberg> having a bitstream sitting there with hdl in a comment is a pain to rebuild if something changes
<whitequark> azonenberg: yup sounds good
<azonenberg> having the source ship with the app, so you can just gp4prog --hexdump the bitstream, makes more sense
<azonenberg> also idk if you saw i added a separate hexdump option that dumps the bitfile in a form you can feed right to BitstreamFromHex
<whitequark> regarding test dependencies, i don't think you can easily do that
<azonenberg> the debug option has tx and rx traffic all intermingled
<azonenberg> and hmm, will have to think about this more then
<azonenberg> this is the kind of awkward dependency issue that prompted me to create Splash
<azonenberg> lol
scrts has quit [Ping timeout: 265 seconds]
<whitequark> ctest is kind of just... crap
<azonenberg> well, if you have a better idea i'm not opposed to moving
<azonenberg> i would even consider migrating the whole project to splash once i get it working, but a full client-server distributed build environment seems overkill for this :p
scrts has joined ##openfpga
<whitequark> oh
<whitequark> wait no ctest *does* have test dependencies
<whitequark> set_property(TEST testX APPEND PROPERTY DEPENDS testY)
<whitequark> so you can just use that
<azonenberg> make a note of that in an issue comment and i'll get to it later
<openfpga-github> [openfpga] whitequark commented on issue #58: ctest has test dependencies: `set_property(TEST testX APPEND PROPERTY DEPENDS testY)` https://git.io/vXmtL
wolfspra1l has quit [Quit: leaving]
wolfspraul has joined ##openfpga
amclain_ has joined ##openfpga
amclain has quit [Ping timeout: 260 seconds]
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
scrts has quit [Ping timeout: 265 seconds]
scrts has joined ##openfpga
doomlord has joined ##openfpga
tecepe has quit [Remote host closed the connection]
scrts has quit [Ping timeout: 268 seconds]
scrts has joined ##openfpga
tecepe has joined ##openfpga
<rqou> azonenberg: on the xilinx kintex die shot, are the square/octagon shapes distributed throughout the die also power/gnd pads?
<rqou> why are they a different style from the squares around the edges?
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
<azonenberg> rqou: it's an artix, not a kintex
<azonenberg> i believe those are power/ground, you ca nsee they hook directly up to the grid going across the chip
<azonenberg> it looks like left and right side plus middle pads are power/ground
<azonenberg> bottom left is GTPs
<azonenberg> top and bottom edges are GPIO
<azonenberg> i dont know why
<azonenberg> those might only be used in flip-chip packages or something?
<azonenberg> except i didnt think artix did flip chip in the low gate count die
<azonenberg> so idk
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
kuldeep has quit [Quit: Leaving]
kuldeep has joined ##openfpga
<rqou> do you know what's under the vertical power/gnd wires in the center right?
<rqou> is it dcm/clock/other analog stuff?
<reportingsjr> azonenberg: what did you call the verilog -> kicad schematic converter you made?
<rqou> oh btw offtopic: ~1 day after putting debian sid on my imac for lulz, debian drops powerpc as a release architecture for debian 9 :P
<rqou> ppc64el is still supported for people who have g5 towers i guess?
kuldeep has quit [Ping timeout: 260 seconds]
<qu1j0t3> :|
<rqou> arrgh firefox e10s is interacting very poorly with pdf.js
<rqou> it'll hang the entire browser until pdf.js finishes rendering
<rqou> which was the opposite of what e10s wanted to achieve :P
<cr1901_modern> azonenberg: *Cough cough* https://twitter.com/whitequark/status/793190795369123840
m_w has joined ##openfpga
<rqou> the stm32l433 microcontroller has a "firewall" feature
<rqou> i don't know how i feel about that
<rqou> it's designed to allow for a particular part of the flash to become execute-only
<rqou> while still allowing "hostile" code in the rest of the flash
<rqou> it seems like careless programming will always negate its usefulness
<gruetzkopf> g5 towers are traditionally bigendian
<rqou> but you can run them little endian anyways, right?
<gruetzkopf> never tried
<gruetzkopf> but power8 boxes are often run littleendian
doomlord has joined ##openfpga
<rqou> i thought connectix virtual pc put the ppc into little endian mode?
<gruetzkopf> ppc970 is missing LE support
<rqou> hmm, maybe that's not right then
<rqou> was there ever a "flip endian" opcode in ppc?
<rqou> maybe it just used that a lot
<rqou> which is more unorthodox? little endian ppc or big endian arm?
<rqou> :P
<gruetzkopf> there are load/store word with byte reversed instrs
<rqou> yeah, that sounds right
<gruetzkopf> well, ppc is going LE to go after x86, and arm is going BE to go after ppc...
<rqou> except i don't know of anybody other than nintendo that ever actually used a BE ARM
<gruetzkopf> aah yes, the 'security' arm in wii /wiiu
<gruetzkopf> starlet/startbuck
<gruetzkopf> *starbuck
<rqou> yes, that
<rqou> quick quiz ##openfpga, what is the difference between strncmp and memcmp? :P :P
<gruetzkopf> :D
<rqou> pkcs#1 padding is also just for show, right? :P
<gruetzkopf> nintendo makes such nice fuckups in otherwise well thought out cryptosystem
<rqou> 3ds A9LH? :P
<gruetzkopf> like when they totally killed 3ds boot authentification by releasing a new binary with a big flaw that didn't even need to be signbed with that key
<gruetzkopf> yes
<rqou> rumor says the Switch is powered by a Tegra
<gruetzkopf> they could just have switched keys for n3ds and avoided half the mess
<gruetzkopf> yeah
<gruetzkopf> tegra X?
<rqou> expecting a jailbreak within a week :P
<gruetzkopf> some people are willing to say armv8 and both be/le
<gruetzkopf> for easier porting from both sided of the endianess divide
<rqou> um... that's more footgun potential than I would like
<rqou> I guess one thing that's not super fair for Nintendo is that they're constantly a hacker target
<rqou> for both homebrew and piracy
<rqou> and (at least in the past) unlicensed games
<gruetzkopf> they'd get less piracy if you didn't need to totally pwn the console for homebrew
<rqou> I thought the Wii was pwned for piracy before the strncmp bug was found?
<rqou> people ported over GameCube drivechips or something?
<gruetzkopf> they attacked the drive, yeah
<rqou> I thought they used GC-mode code execution and the infamous tweezer trick before they found strncmp and got Wii-mode code execution
<gruetzkopf> yes, that was the team twiizers/hackmii/failoverflow side of things
<gruetzkopf> datel also found the signing bug and released a cheating tool
<rqou> and somehow during this someone decided to try renaming Epona? :P
<gruetzkopf> as soon as you can dump binaries you do dump binaries
<gruetzkopf> and then reverse them :D
<rqou> unfortunately tmbinc never finished his articles about how the GC actually authenticates disks
<rqou> at least GC/Wii discs are much less annoying to dump vs e.g. GD-ROMs
<gruetzkopf> yes
<cr1901_modern> f***ing CLV vs CAV
<gruetzkopf> stick in wii, start ftp server, download iso
<gruetzkopf> fastest method
<rqou> I thought "dump to USB stick" is faster?
<gruetzkopf> (well, using the eyepatch-approved tools is faster)
<rqou> someone with infinite free time should take scanlime's coastermelt research and make a "stupid ODD tricks" (GC/Wii/GD-ROM/etc.) dumper
<gruetzkopf> and then there was this "rare" (i have 20 from old school computers) lg dvd drive that could be made to read them
<gruetzkopf> but thats SLOOW
<rqou> it shouldn't be if you actually hack the firmware to recognize them for real
<rqou> rather than the LG hack that iirc used some "debug dump buffer" command of some kind
<gruetzkopf> yeah
<rqou> anyways, now that it's 2016, is the best gd-rom dumping method still "some stupid swap trick" or "use an actual dreamcast"?
scrts has quit [Ping timeout: 245 seconds]
scrts has joined ##openfpga
<azonenberg> reportingsjr: never named it
<azonenberg> it didnt get beyond PoC stage
<azonenberg> whitequark: re hdl to kicad
<azonenberg> are you interested in collaborating on a project to do that?
* cr1901_modern would be interested as well, and his desire to quickly do schem capture overrides his desire not to code
<azonenberg> Lol
<azonenberg> Well, in that case i'll throw up a github repo soon and we can start working on some notes in the wiki
<azonenberg> the basics are easy
<azonenberg> the hard part is doing proper ERCing, parameterizable IP cores, etc
<azonenberg> selecting passive values from nearest E-number to a given tolerance
<azonenberg> selecting the actual part you want to use from some database
<rqou> i've never used the erc in either kicad or eagle
<azonenberg> rqou: o_O
<azonenberg> that is pretty critical for anything large
<rqou> i never bothered to correctly assign net classes for everything
<cr1901_modern> I don't BLAME you, rqou
<cr1901_modern> I do it, but I don't blame you at all
<cr1901_modern> it's a pita
<rqou> ok, so i do look at erc errors
<rqou> but erc can't generate too many useful errors because every pin on every part is flagged as bidirectional i/o or whatever
<rqou> also, eagle (which I've used a bit more than kicad) has a really stupid and useless erc
<azonenberg> rqou: yeah i want to do a GOOD erc here
<azonenberg> Let me create a repo now and add you guys as wiki contributors
<azonenberg> see if we can hash up some ideas
<azonenberg> no code for a while
<rqou> sure
<rqou> anyways, example of stupid erc: every i/o pin on a microcontroller/fpga gets flagged as "bidirectional i/o" because that's what it is
<rqou> so you can connect any of the pins to anything, right? :P
<azonenberg> rqou: well
<azonenberg> what i would like to do
<rqou> (eagle can't do custom pin types/classes)
<azonenberg> is design an erc that reflects things like io banking rules
<azonenberg> and vih/vil
<azonenberg> So if you try to drive a 3.3V input with a 5V output it'll fail
<rqou> oh i really want that
<azonenberg> If you try to drive a 5V input with a 3.3V output it may or may not be ok
<azonenberg> depending on the specific parts
<rqou> now I don't have to print out "that one TI appnote with the vih/vil chart" over and over again :P
<azonenberg> Lol
<azonenberg> anyone have ideas for what to name the project?
<azonenberg> the repo*
<rqou> use the github auto name thing? :P
<azonenberg> i prefer nsanamegenerator.com for that
<azonenberg> how about just "v2pcb"
<azonenberg> rqou: are you rqou on github?
<rqou> yes
<azonenberg> https://github.com/azonenberg/v2pcb/wiki rqou whitequark cr1901_modern
<azonenberg> https://github.com/azonenberg/v2pcb/wiki/ERC add more stuff there
<azonenberg> discuss that
<azonenberg> gotta get back to work
kuldeep has joined ##openfpga
<azonenberg> rqou: i would eventually like to support fancy erc for things like "diff pair polarity" etc as well
<azonenberg> or even "bus can be reordered" / "bus must be in order"
<azonenberg> for DRAM A / DQ
<whitequark> azonenberg: first off: I'm probably going to try to use TopoR
<whitequark> it's proprietary but i like its autoplacer
<whitequark> azonenberg: actually the repo's empty
<whitequark> are you uh
<whitequark> is that basically a request for proposals?
<azonenberg> whitequark: yes
<whitequark> ahhh ok
<whitequark> i'll churn out some things later, also have work
<azonenberg> it links to my legacy code in the antikernel repo
<azonenberg> but i dont want to just import that code as it was a PoC rather than something i would actually use
<whitequark> azonenberg: one general design note is i don't want to be tied to verilog forever
<whitequark> for now i don't think verilog is not the best fit
<whitequark> but it's not a good fit for anything in general
digshadow1 has joined ##openfpga
<whitequark> i guess we can define some RTL format like EDIF to be the "canonical" representation, IR if you'd like
digshadow has quit [Ping timeout: 260 seconds]
<whitequark> then write tools (by using yosys mostly) that transform EDIF into whatever the layout engine wants
<whitequark> i would strongly like to support multiple layout engines
<whitequark> a) kicad, because foss b) eagle, because i don't want to learn c) topor because of its autoplacer and autorouter
<azonenberg> whitequark: i was going to suggest using yosys json as the IR
<azonenberg> We can translate edif/verilog/whatever to that using yosys
<azonenberg> and multiple back ends is a good design goal
<azonenberg> just have a class for netlist output logic
<azonenberg> that you can swap out as needed
<whitequark> yosys json is a bit yucky as IR because i don't think it's stable
<whitequark> on the other hand
<azonenberg> yosys json is
<azonenberg> RTLIL is not
<azonenberg> thats an internap rep
<whitequark> ah
<azonenberg> the json is the recommended interchange format
<whitequark> yosys json works then
<whitequark> just to verify
<whitequark> yosys json can be used for stuff like blackbox IP exchange?
<whitequark> we probably don't actually want that
<whitequark> but its an indicator of stability
<azonenberg> that's the idea
<azonenberg> But again you can also export something as EDIF
<azonenberg> then use yosys to convert to json
<azonenberg> afaik the json was added specifically as a stable interchange format
<azonenberg> that was easy to parse
<whitequark> ah I see
<whitequark> it's extended sometimes
<whitequark> so we can't reject unknown fields for example
<azonenberg> Correct
<whitequark> but I suppose it's stable enough
<azonenberg> anyway at this point i basically am soliciting suggestions from people on what the setup should look like
<azonenberg> my existing PoC is not necessarily the way to go at this point
<azonenberg> just "it's been done":
<whitequark> ack
<azonenberg> i think the parser for that was written in PHP :P
<azonenberg> so it needs a total rewrite no matter what
<whitequark> in... what
<whitequark> you DID WHAT
<azonenberg> Lol
<azonenberg> My point exactly
<whitequark> so uh
<whitequark> ack/nak on doing the rewrite in "not C++"
<rqou> rust?
<whitequark> I find working with graphs in C++ very obnoxious
<whitequark> rust is one option
<whitequark> idk if azonenberg wants to learn it. it's not unfair if he doesn't
<azonenberg> whitequark: I have no strong preferences at this point, although i am more comfortable with c/c++ than pretty much any other language
<azonenberg> Let's figure out a high level design
<azonenberg> before making implementation decisions
<whitequark> alright
<azonenberg> "what to build" then "how to build it" :p
<whitequark> verilog generators, yuck
<whitequark> one of my main concerns is actually writing this in verilog
<whitequark> this is why i focus so much on an IR
scrts has quit [Ping timeout: 250 seconds]
<azonenberg> well thats why one of the things i want to do is work out a hdl schema
<azonenberg> like, figure out how sane it actually is to do in verilog
<azonenberg> whether to write IP cores in verilog or as c/c++/python/whatever that exports an EDIF
<azonenberg> the works
<whitequark> so i have a mild preference to a migen-like design
<whitequark> "mild" because migen's lack of type system bites me pretty hard
<whitequark> on the other hand trying to introduce a type system without prototyping the hell out of this design will not work
<azonenberg> Yeah
<whitequark> so the choice is basically between verilog-like or python-like systems
<whitequark> maybe we can decide just by implementing both frontends
<azonenberg> Perhaps, lol
<azonenberg> i'm leaning toward verilog plus additional typing using hdl attributes to denote signal types
<azonenberg> bear in mind we wont be using RTL
<azonenberg> just structural constraints
<whitequark> yeah, no actual "registers" :D
<azonenberg> although its plausible we could add a 74xx inference library eventually :P
<azonenberg> not that i recommend it lol
<whitequark> so i feel like the python impl would be a win, based on your prototype code
<azonenberg> anyway i also want to offload a lot of the stuff i did in verilog in my PoC (like E-number rounding)
<azonenberg> to the post-processing code
<azonenberg> in a real programming language, not a HDL
<whitequark> specifically because you have lots of calculations and input verification and wire "forwarding"
<azonenberg> Yes exactly
<whitequark> all of which are super awkward in verilog
<azonenberg> What might make sense is to do both somehow
<whitequark> being able to specify paths through a passed module is quite amazing
<azonenberg> have python or something for ip cores
<azonenberg> then structural verilog for top levels
<azonenberg> But that just a wild guess
<whitequark> wait what?
<whitequark> i would actually go the *opposite* way
<whitequark> if I did that
<azonenberg> i dont know yet, just hypothesizing
<azonenberg> pure python is not necessarily a horrible way to go
<whitequark> toplevel verilog is a nightmare, mor1kx uses an actual emacs plugin to manage that
<whitequark> because it has dozens of signals
<azonenberg> for antikernel i generate all my top leve lverilog too
<azonenberg> fwiw :p
<whitequark> thousand-line files with just forwarding
scrts has joined ##openfpga
<azonenberg> using a domain specific lang right now although i plan to switch the schema to YAML for easier parsing
<whitequark> the more i think about it the more i think full-on python is the way to go
<whitequark> i even wonder if we should drop yosys
<azonenberg> open question at this point
<azonenberg> Throw your thoughts in the wiki along with a justification for the viewpoint
<whitequark> yup, will do
<azonenberg> but again we're still in high level requirements ID phase
<azonenberg> So things like, what kind of features do we want to have
<azonenberg> what kind of ERC do we want to do
<azonenberg> etc
<whitequark> yup
<azonenberg> mostly, i want parameterizable IP cores with input validation
<whitequark> i want that as well as easy interconnect
<azonenberg> Yeah
<azonenberg> I also want good handling of pin swapping
<azonenberg> for fpgas etc
<azonenberg> so there has to be some way to denote what pins can go where
<whitequark> that would be quite awesome
<whitequark> integration with .pcf files
<whitequark> two-way even
<azonenberg> Being able to generate a constraint file would be nice down the road
<whitequark> (why the hell don't we have a standard constraint file format?)
<azonenberg> short term, though, i just want to be able to say things like "this is a clock, it must go on a clock capable pin"
<azonenberg> or "these N signals have to be in the same bank"
<azonenberg> Good question
<azonenberg> for antikernel i made a meta-constraint format
<whitequark> i'd like to be able to specify erc rules in a real language easily
<azonenberg> that the back end converts to xdc, ucf, etc
<whitequark> and have some default library
<azonenberg> That would be nice
<whitequark> migen has a nice hack where it can extract names from source code, we could extend that to get reasonably decent error reporting through to the python source
<whitequark> but it might be worse still than what verilog has, assuming yosys now can record the full elaboration path
<azonenberg> Yes
<whitequark> thats a downside of python
<azonenberg> We need to be able to create a short refdes as well
<whitequark> well, could probably do full backtraces
<whitequark> refdes?
<azonenberg> like U3 or R17
<azonenberg> and have traceability from that back to the HDL
<whitequark> oh obviously
<azonenberg> Since printing the whole hierarchial path in silkscreen is... not practical
<whitequark> i'm more concerned about erc reporting, which should do hierarchical path
<rqou> you don't just blindly hit "renumber" when you're about to ship? :P
<whitequark> pfffff
<azonenberg> whitequark: yes i agree
<azonenberg> this is what my old flow output
<azonenberg> you can imagine this becoming... problematic :p
<whitequark> lol
talsit has joined ##openfpga