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