00:03
<
rqou >
infamous uc berkeley professor who teaches compilers and loves parsing
00:03
<
rqou >
and wrote bison's GLR skeleton
00:04
<
pie_ >
oddly enough "hilfinger parsing" doesnt give any useful google results
00:06
<
rqou >
nah, you needed to have attended berkeley to know about this :P
00:09
<
awygle >
oh yeah rqou, what system did they build that's worse than telebears?
00:09
<
rqou >
basically it has the same quirks as telebears but now with a web 2.0 theme
00:09
<
awygle >
is it still a phone tree hooked up to a modem hooked up to a web frontend?
00:10
<
awygle >
that's what telebears was when i was there
00:10
<
rqou >
i hope they've at least fixed the problem of overflowing your virtual punch card deck
00:10
<
rqou >
but basically they web 2.0-ifyed the look and now it's even less intuitive to use
00:10
<
rqou >
the weird phase 1/phase 2/adjustment is still here, as well as CCNs
00:11
<
awygle >
so glad to be out of college, no lie
00:12
<
rqou >
hmm, i didn't dare to test it but maybe the back button is fixed/less broken now?
00:16
pie_ has quit [Read error: Connection reset by peer]
00:16
pie_ has joined ##openfpga
00:43
scrts has quit [Ping timeout: 246 seconds]
00:43
<
pie_ >
wow CLRS doesnt mention parse/parsing even once
00:44
scrts has joined ##openfpga
00:46
<
pie_ >
ok i take that back the word parse is there 4 times in a seemingly unrelated topic
00:54
specing has quit [Read error: Connection reset by peer]
00:57
<
pie_ >
qu1j0t3, i should have a pdf but i forgot the name agian, what was the book about functional computer architecture? yknow lispy mahcines or something
00:57
<
pie_ >
prolog machines
01:00
<
qu1j0t3 >
pie_: The Architecture of Symbolic Computers, Peter Kogge
01:01
<
pie_ >
i kept searcing for functional >_>
01:41
<
jn__ >
"the informal NSA ban on the manufacture of LinuxBIOS-capable x86 CPUs"?! i gotta ask ron about this
01:41
<
balrog >
also lol complaining about lead free solder when using an iron at 250C?
01:41
<
balrog >
250C is low
01:42
<
balrog >
*even for leaded*
01:42
<
pie_ >
jn__, do mention later :P
01:43
<
rqou >
working on it! :P
01:43
<
balrog >
rqou: much FIXME
01:43
<
azonenberg >
lol yes
01:43
<
azonenberg >
the solder only melts at 219C
01:43
<
azonenberg >
i usually set my iron to 300-350 depending on how heavy the thing i'm soldering to is
01:43
<
azonenberg >
rqou: yay
01:43
* azonenberg
is almost done with the greenpak bitstream loader
01:43
<
balrog >
azonenberg: what solder do you generally use? I've probably asked already
01:43
<
azonenberg >
then have to do the json export
01:43
scrts has quit [Ping timeout: 240 seconds]
01:43
<
balrog >
here, no-clean-flux SAC305
01:44
<
azonenberg >
Same here
01:44
<
balrog >
people who have only used crap lead-free before are like "wut, lead-free???"
01:44
<
balrog >
and then try it and then are like "oh it's not so bad"
01:45
<
rqou >
azonenberg: how do you want to represent vref/cgnd?
01:45
<
rqou >
silly idea: a CGND primitive that only has one output port
01:45
<
rqou >
the sim model outputs a constant 0
01:45
<
rqou >
and the PAR will detect it and set connected pins to CGND mode
01:46
<
azonenberg >
I dont think there is any way to CGND a single pin, right?
01:46
<
azonenberg >
don't you do it to the entire chip's unused pins?
01:46
<
rqou >
um, yeah you can?
01:46
<
azonenberg >
i meant not in the bitstream
01:46
<
azonenberg >
but in HDL
01:46
<
azonenberg >
using the xilinx flow
01:46
* cr1901
probably receives the recommended yearly dose of lead mandated by the state of California in one soldering session
01:46
<
rqou >
i think the xilinx flow can cgnd individual pins in the ucf
01:47
<
azonenberg >
In that case how about we only do it by constraints then?
01:47
<
azonenberg >
i see no reason to do it in HDL
01:47
<
rqou >
why not? it'd be kinda funny
01:47
<
azonenberg >
From a RE perspective, i don't care about distinguishing CGND from simply driving 1'b0
01:47
<
rqou >
and now you wouldn't need a ucf
01:47
<
azonenberg >
i dont even know if there's a difference
01:47
scrts has joined ##openfpga
01:47
<
azonenberg >
other than leaving the macrocell logic less utilized
01:47
<
azonenberg >
i think it's just a "ignore data going into IOB, drive zero no matter what"
01:48
<
azonenberg >
So for RE, we can treat them as indistinguishable
01:48
<
rqou >
afaik you can
_still_ use the macrocell on a cgnd pin
01:48
<
azonenberg >
Correct
01:48
<
azonenberg >
hence "leaving the logic less utilized"
01:48
<
azonenberg >
but no difference in the actual buffer
01:48
<
azonenberg >
so for RE we don't care
01:48
<
rqou >
i know for RE you don't care, but for synthesis it'd be nice to not have to mess with a separate constraints file
01:49
<
azonenberg >
How about just (* CGND = "1" *) output wire foo;
01:49
<
rqou >
does that work?
01:49
<
azonenberg >
you might have to assign foo=0 to make synthesis not optimize it out or something
01:49
<
azonenberg >
but yeah
01:49
<
azonenberg >
basically the par would just take any OBUF with an attached CGND constraint and optimize out any macrocell logic connected to it
01:50
<
rqou >
i didn't know you could even put attributes on output wires like that
01:50
<
rqou >
oh wait of course you can
01:50
<
rqou >
that's how you put LOC
01:50
<
azonenberg >
Exactly
01:50
<
azonenberg >
Any constraint that works in a constraint file should also be applicable in HDL the same way
01:50
<
azonenberg >
in our flow
01:51
<
rqou >
so not by instantiating a "CGND" primitive because that would be dumb :P
01:52
<
rqou >
once i get this working we need to test whether the attributes that end up being set in the .json can
_actually_ be set from verilog
01:52
<
azonenberg >
You can use one internally if this helps
01:52
<
azonenberg >
for example i have a GP_VDD and GP_VSS primitive
01:52
<
azonenberg >
that source all constant-drive nets in the PAR
01:52
<
azonenberg >
so i can have something to use as the source in the routing matrix
01:52
<
azonenberg >
and it's legal to use in HDL but makes no sense when 1'b0 suffices
01:53
<
rqou >
i just want to make sure to minimize sim/synth mismatches
01:54
<
rqou >
so attributes that magically change behavior need to be checked pretty carefully in the synth flow
01:54
<
rqou >
e.g. if you put the CGND attribute to a wire, you can't initialize it to 1
01:56
<
rqou >
azonenberg: it seems kinda weird to have attributes on wires in the yosys data model
01:56
<
rqou >
you
_can_ do that, but wires can have both multiple sources and multiple sinks
01:57
<
rqou >
so any attributes set need to somehow propagate to all of them
01:57
<
rqou >
for extra bonus fun, yosys also has "0" and "1" wires
01:57
<
rqou >
which are constants
01:57
<
pie_ >
re loperos, i guess youre not a crackpot if youre right
01:57
<
rqou >
i wonder what happens if you connect a driver to one of those?
01:58
<
pie_ >
what i dont get is from where/how he distills all this stuff
01:59
<
rqou >
azonenberg: yosys seems in general pretty bad in the "no footguns" aspect
02:15
<
azonenberg >
yes the 0 and 1 constants are a pain in the butt
02:16
<
rqou >
they can also be z and x
02:17
<
rqou >
azonenberg: is it ever useful to put a LOC on a BUFG?
02:17
<
azonenberg >
Not sure, but i'd allow the possibility
02:17
<
azonenberg >
It wouldn't be inferred in that case though
02:17
<
azonenberg >
you'd explicitly instantiate
02:18
<
rqou >
but when the LOC on the BUFG disagrees with the lock on the io pad you just get an error?
02:18
<
azonenberg >
I'm not actually sure how that would work, i havent looked into it
02:18
<
rqou >
i guess someone can LOC a BUFG and not LOC the io pin?
02:18
<
azonenberg >
you'd probably want some way to have a LOC on the IO not propagate to the BUFG
02:18
<
rqou >
i don't think the xilinx flow can do LOC on a BUFG anyways
02:18
<
azonenberg >
I havent tried
02:19
<
rqou >
but for now i'm not going to emit LOC on a BUFG
02:19
<
azonenberg >
pretty sure the attrmvcmp pass pushes LOCs from wires to IBUFs thoguh
02:19
<
azonenberg >
preferentially
02:19
<
azonenberg >
rather than to the downstream device
02:19
<
azonenberg >
i.e. LOC on a wire applies to the node sourcing the wire
02:19
<
azonenberg >
Which would be the IBUF
02:19
<
azonenberg >
if you instantiated a bufg after that, no problem
02:19
<
rqou >
what if there are multiple because you sucked at coding? :P
02:20
<
azonenberg >
and if you inferred a bufg, you'd create a new net called foo_bufg
02:20
<
azonenberg >
which would be sourced by the bufg
02:20
<
azonenberg >
Multiple bufgs with the same clock?
02:20
<
rqou >
well right now inferring BUFG hasn't been implemented yet anyways
02:20
<
rqou >
multiple drivers for the same wire
02:20
<
azonenberg >
That should trigger a DRC error, the earlier the better
02:20
<
azonenberg >
i havent actually checked what gp4par does for that
02:20
<
azonenberg >
i forget if yosys catches it
02:21
<
rqou >
right now i know for sure that my code doesn't DRC at all
02:22
<
rqou >
argh this is annoying
02:22
<
rqou >
i just tested it and yosys puts attributes on wires like i expected
02:23
<
rqou >
but my data model doesn't handle attributes on wires particularly well
02:24
<
rqou >
everybody's data model is slightly different and there's so much impedance mismatch everywhere
02:25
<
azonenberg >
rqou: Look at how synth_greenpak4 does it
02:25
<
azonenberg >
i move the attributes onto the cells, i believe during synthesis
02:26
<
rqou >
er, not when i tried it
02:26
<
rqou >
you only move LOC
02:26
<
azonenberg >
ah, ok
02:26
<
azonenberg >
That would explain it
02:26
<
azonenberg >
prob b/c top level ports are a special case
02:26
<
rqou >
well, LOC and src
02:26
<
rqou >
yeah, top-level ports are also weird and annoying
02:28
<
rqou >
hmm we never bikeshedded what we're going to do with vref
02:28
<
rqou >
vref is also a weird hacky special case especially with its physical proximity constraints
02:34
<
azonenberg >
Initially i'm going to say don't support SSTL
02:34
<
azonenberg >
file a ticket as a TODO
02:34
<
azonenberg >
Down the road we'll have to figure out physical proximity
02:35
<
rqou >
oh, that's available as a table in an appnote somewhere
02:35
<
rqou >
so only the bikeshedding part needs to happen
02:35
<
azonenberg >
well i meant the best way to implement it
02:35
<
azonenberg >
i'd rather have it be done per die pa
02:35
<
azonenberg >
then a remapping table from pin LOC to die pads
02:35
<
azonenberg >
Then if you have numbered die pads it's trivial to figure out what's nearby
02:36
<
azonenberg >
You need the pad numbering anyway to figure out which bitstream IOB configures what
02:36
<
openfpga-github >
[openfpga] rqou opened issue #108: Bikeshed: how to ergonomically implement HSTL/SSTL
https://git.io/v7oEU
02:36
<
rqou >
btw i legitimately don't know how to test this (from the EE perspective)
02:36
<
rqou >
how do i generate SSTL/HSTL signals?
02:37
<
openfpga-github >
openfpga/master a9a4c13 Andrew Zonenberg: Implemented bitstream loading for IOB type A, ACMP, VREF
02:37
<
azonenberg >
You might have to do some glue logic with another CPLD or something?
02:37
<
azonenberg >
and you'd need some LDOs and discrete resistors
02:37
<
azonenberg >
Not something to do randomly on an existing devkit
02:38
balrog has quit [Quit: Bye]
02:38
<
rqou >
that sounds like a pain
02:38
<
azonenberg >
Save it for later, none of the currently supported parts even have sstl support
02:38
<
azonenberg >
Focus on getting the 32a 100% feature complete
02:38
<
azonenberg >
avoid design decisions that will make the larger parts difficult to do, but don't worry about new features the small parts lack
02:41
balrog has joined ##openfpga
02:43
scrts has quit [Ping timeout: 260 seconds]
02:45
<
rqou >
hmm but overall it seems like having attributes only live on nodes is fine
02:45
<
rqou >
we just have to get yosys to move them around a bit
02:46
<
rqou >
and then i don't need to deal with the complexity of some attributes being on wires and some being on nodes
02:47
scrts has joined ##openfpga
02:51
<
rqou >
azonenberg: do you know if iopadmap will create extra bogus io pad cells if i manually instantiate an io pad cell?
02:51
<
rqou >
wow, synthesis has so many corner cases
02:52
<
pie_ >
well i just had it pointed out to me that the R-S paper is infamous for verious reasons xD
02:53
<
azonenberg >
rqou: I don't remember
02:53
<
azonenberg >
Try it
02:54
<
azonenberg >
if it does i'd consider that a bug
02:54
<
rqou >
it's just annoying how many potential ways there are to mess up
02:56
<
azonenberg >
And now you're beginning to understand why EDA is hard :p
02:57
<
rqou >
and these aren't even "hard" problems, they're just dumb problems
03:26
<
azonenberg >
So goals right now
03:26
<
azonenberg >
Tonight: finish import of greenpak netlists to native format
03:26
<
azonenberg >
Tomorrow: Write exporter to yosys json fully
03:26
<
azonenberg >
At that point i should be able to take a greenpak bitfile and turn it into verilog with the currently-implemented cells flattened
03:26
<
rqou >
i'm about a half-step ahead of you
03:27
<
azonenberg >
Next step is to finish cells_sim
03:28
<
azonenberg >
So that all of the cells that are pure digital can be turned into behavioral RTL
03:28
<
rqou >
azonenberg: do you mind if everything turns into an inout port?
03:28
<
azonenberg >
Then the rest of the week i'll work on high-level analytics
03:28
<
azonenberg >
Pretty sure there's a yosys pass for fixing that already
03:29
<
azonenberg >
But distinguishing inout from in or out is kind of important
03:29
<
azonenberg >
it helps a lot when REing the design
03:29
<
rqou >
yeah, but that can be done in a future pass
03:29
<
azonenberg >
it should be easy enoguh to figure out if the tristate is statically 1 or 0, right?
03:29
<
rqou >
it makes the json writer simpler
03:29
<
azonenberg >
eh, i dont really like it
03:29
<
rqou >
yeah exactly
03:29
<
azonenberg >
But as long as you confirm that the yosys pass will fix it
03:29
<
azonenberg >
i dont care THAT much
03:30
<
azonenberg >
as long as i get good RTLIL in the end
03:33
<
cr1901 >
Never really thought about this, but what's the difference between using a for loop in Verilog by itself and one within a generate statement?
03:34
<
azonenberg >
not much, afaik
03:35
<
azonenberg >
other than, one in a generate statement can instantite module
03:35
<
azonenberg >
modules*
03:36
<
openfpga-github >
openfpga/master 495c4ab Andrew Zonenberg: ReadMatrixSelector - demoted spammy message from debug to trace verbosity
03:36
<
openfpga-github >
openfpga/master 24bcf7f Andrew Zonenberg: Added const version of GetRealEntity()
03:36
<
openfpga-github >
openfpga/master 4feb4d2 Andrew Zonenberg: Greenpak4DAC: Added load support for unused DACs (active ones not supported yet)
03:42
<
cr1901 >
The message was just trying its hardest to stand out T_T
03:54
m_w has quit [Quit: leaving]
04:04
scrts has quit [Ping timeout: 240 seconds]
04:04
nrossi has quit [Quit: Connection closed for inactivity]
04:11
scrts has joined ##openfpga
04:56
_whitelogger has joined ##openfpga
05:05
<
awygle >
pie_: what... is this?
05:09
<
pie_ >
heck if i know
05:09
<
pie_ >
some attempt at rethinking computing
05:09
<
pie_ >
for better presumably
05:10
<
pie_ >
this is rather frustrating “in
_every_ field I know, the difference between the professional and the mass market is so large that Joe Blow wouldn’t believe the two could coexist. more often than not, you can’t even get the professional quality unless you sign a major agreement with the vendor — such is the investment on both sides of the table. the commitment for over-the-counter sales to some anonymous customer is _negli
05:10
<
pie_ >
gible_. consumers are protected by laws because of this, while professionals are protected by signed agreements they are expected to understand.”
05:11
<
awygle >
uh oh. i am incapable of resisting technical crazy on the internet. and this is a
*decade* of it.
05:13
<
pie_ >
awygle, that makes two of us?
05:13
<
pie_ >
err the quote is not from the source but quoted by the source in a different artivle
05:13
scrts has quit [Ping timeout: 246 seconds]
05:14
<
awygle >
"Those among these criminals against mathematics who prove unrepentant in their final hours would be asked to prove the Turing-equivalence of a spoon to a shovel as they dig their graves." wow
05:28
<
openfpga-github >
openfpga/master 6a8b9cc Andrew Zonenberg: Finished initial bitstream loading support for counters
05:29
<
azonenberg >
rqou: ok that's initial bitstream loading implemented
05:29
<
azonenberg >
Now to do export to json (tomorrow)
05:29
scrts has joined ##openfpga
05:30
m_w has joined ##openfpga
05:43
<
pie_ >
awygle, bbl heh
05:43
* pie_
crashes into bed for an hour of sleep
06:14
digshadow has joined ##openfpga
06:48
m_w has quit [Quit: leaving]
07:05
<
rqou >
hmm so i was looking for "that .jed" that goes on "those ebay xc2c64a 'dev boards'"
07:05
<
rqou >
i didn't find it
07:06
<
azonenberg >
are they preflashed? or no, to avoid DMCA issues
07:06
<
rqou >
but i found more info about the "carefully drill at a very very precise location to break the WP wirebond" hack
07:06
<
rqou >
apparently that hack ends up actually breaking the bond wire for WP
07:06
<
azonenberg >
lol nice
07:07
<
rqou >
and because it's now floating, somebody came up with a really really ingenious hack for how to deassert WP in case the chip needs to be flashed again
07:07
<
azonenberg >
yeah i think i heard, stick the drill bit in?
07:07
<
rqou >
nah, more fun than that
07:07
<
azonenberg >
or just dip a conductive liquid in the hole
07:07
scrts has quit [Ping timeout: 240 seconds]
07:07
<
rqou >
somebody discovered that clicking a piezoelectric lighter near the chip enough times will charge or otherwise induce enough EMI to flip the WP state
07:08
<
rqou >
i would never have even thought to try this
07:08
nrossi has joined ##openfpga
07:10
<
rqou >
it has pictures
07:10
scrts has joined ##openfpga
07:12
<
rqou >
anyways, this definitely deserves to go onto the "neat glitching techniques" list
07:15
<
azonenberg >
lol yeah
07:18
<
rqou >
alright, i got myself some of "those" jeds
07:18
<
rqou >
interestingly, i
_don't_ think the source code is available
07:18
<
rqou >
this will be fun once i actually finish coding the json dumper
07:19
<
rqou >
i wonder if any of those "team <foobar>" groups expected that it would be possible for someone to RE their jed files?
07:19
<
azonenberg >
Honestly
07:19
<
azonenberg >
i would love to use that modchip as a case study in my talk
07:20
<
azonenberg >
"we found this thing on the internet, here's how it actually works"
07:20
<
rqou >
hey, i never said modchip!
07:20
<
azonenberg >
i assume that's what it is though :p
07:20
<
rqou >
yeah of course :P
07:20
<
rqou >
hmm is the passme using a coolrunner-ii?
07:22
<
rqou >
aw lame it's a 9500xl
07:26
<
rqou >
alright, i just grabbed some jeds for a different and "more advanced" "coolrunner-ii" board
07:26
<
rqou >
this one has an xc2c128
07:26
<
rqou >
unfortunately it's only got xsvf files so we have to mangle that a bit
07:27
<
rqou >
alright, time to actually write the code for this
07:28
teepee has quit [Ping timeout: 245 seconds]
07:28
<
rqou >
ugh the 128 board .rar file contains pirated content
07:29
teepee has joined ##openfpga
07:33
<
azonenberg >
rqou: ?
07:33
<
azonenberg >
of what
07:34
<
rqou >
it has some patched firmware for the system management microcontroller on the "victim platform"
07:35
knielsen_ is now known as knielsen
07:43
scrts has quit [Ping timeout: 240 seconds]
07:54
scrts has joined ##openfpga
08:01
teepee has quit [Ping timeout: 240 seconds]
08:03
teepee has joined ##openfpga
08:17
digshadow has quit [Ping timeout: 240 seconds]
08:36
scrts has quit [Ping timeout: 260 seconds]
08:39
scrts has joined ##openfpga
09:07
qu1j0t3 has quit [Ping timeout: 240 seconds]
09:12
specing has joined ##openfpga
09:17
teepee has quit [Ping timeout: 258 seconds]
09:19
teepee has joined ##openfpga
09:38
teepee has quit [Ping timeout: 260 seconds]
09:40
teepee has joined ##openfpga
09:41
Spida has quit [Remote host closed the connection]
09:44
scrts has quit [Ping timeout: 240 seconds]
09:47
qu1j0t3 has joined ##openfpga
09:47
seu has quit [Read error: Connection reset by peer]
09:47
seu has joined ##openfpga
09:48
scrts has joined ##openfpga
09:51
fpgacraft1_ has joined ##openfpga
09:51
fpgacraft2_ has joined ##openfpga
09:54
fpgacraft2 has quit [Ping timeout: 258 seconds]
09:54
fpgacraft2_ is now known as fpgacraft2
09:54
fpgacraft1 has quit [Ping timeout: 258 seconds]
09:54
fpgacraft1_ is now known as fpgacraft1
10:14
scrts has quit [Ping timeout: 260 seconds]
10:15
scrts has joined ##openfpga
10:24
egg|egg has quit [Ping timeout: 268 seconds]
10:27
pie_ has quit [Ping timeout: 240 seconds]
10:52
bibor has quit [Ping timeout: 255 seconds]
10:56
teepee has quit [Ping timeout: 255 seconds]
10:59
teepee has joined ##openfpga
11:02
<
openfpga-github >
yosys/master 275e60a Robert Ou: coolrunner2: Add INVERT parameter to some BUFGs
11:04
<
rqou >
needs much more testing, but it at least kinda sorta works
11:07
m_t has joined ##openfpga
11:14
scrts has quit [Ping timeout: 248 seconds]
11:18
scrts has joined ##openfpga
11:29
specing has quit [Ping timeout: 240 seconds]
11:35
specing has joined ##openfpga
12:01
pie_ has joined ##openfpga
12:11
m_t has quit [Quit: Leaving]
12:14
scrts has quit [Ping timeout: 255 seconds]
12:15
scrts has joined ##openfpga
12:37
nurelin has quit [Remote host closed the connection]
12:38
nurelin has joined ##openfpga
13:07
cr1901_modern has joined ##openfpga
13:42
scrts has quit [Ping timeout: 248 seconds]
13:57
scrts has joined ##openfpga
14:27
pie_ has quit [Ping timeout: 260 seconds]
14:50
m_w has joined ##openfpga
15:02
coino_ has joined ##openfpga
15:13
scrts has quit [Ping timeout: 246 seconds]
15:30
scrts has joined ##openfpga
15:42
pie_ has joined ##openfpga
15:45
digshadow has joined ##openfpga
15:54
scrts has quit [Ping timeout: 260 seconds]
15:58
scrts has joined ##openfpga
16:01
amclain has joined ##openfpga
16:07
test123456 has joined ##openfpga
16:07
clifford has quit [Ping timeout: 255 seconds]
16:08
test123456 has quit [Remote host closed the connection]
16:08
digshadow has quit [Quit: Leaving.]
16:08
test123456 has joined ##openfpga
16:08
test123456 has quit [Remote host closed the connection]
16:08
test123456 has joined ##openfpga
16:13
scrts has quit [Ping timeout: 240 seconds]
16:16
bibor has joined ##openfpga
16:32
scrts has joined ##openfpga
16:38
oeuf has joined ##openfpga
16:43
scrts has quit [Ping timeout: 240 seconds]
16:45
oeuf is now known as egg|egg
16:49
scrts has joined ##openfpga
16:56
digshadow has joined ##openfpga
17:13
scrts has quit [Ping timeout: 260 seconds]
17:18
scrts has joined ##openfpga
17:21
<
openfpga-github >
openfpga/master 3b6c15a Andrew Zonenberg: Added gpkjson cell dump database
17:21
<
openfpga-github >
openfpga/master 22b5922 Andrew Zonenberg: Continued work on GreenPAK JSON netlist export
17:21
<
azonenberg >
rqou: here's what i currently get from importing my netlist, lol
17:21
<
azonenberg >
it's a start, i guess
17:22
<
rqou >
oh, mine is "done" except that i haven't tested any of it
17:22
<
rqou >
so many parts are probably broken
17:22
<
azonenberg >
i have the netlist fully loaded to the internal representation in gpkjson
17:22
<
azonenberg >
But export is very much a WIP
17:50
clifford has joined ##openfpga
17:57
m_t has joined ##openfpga
18:23
<
rqou >
offtopic: red text compresses extremely poorly in "traditional" video codecs
18:26
<
lain >
why specifically red
18:28
<
rqou >
chroma subsampling maybe?
18:28
<
rqou >
somehow blue doesn't look nearly as bad though
18:32
<
lain >
are you using like 4:2:0 or something? :P
18:32
<
lain >
I should learn more about video codecs
18:32
<
rqou >
idk, what does youtube use?
18:33
<
lain >
they use different codecs depending on browser, amusingly
18:33
<
lain >
if you use chrome, they'll feed you vp9 codec
18:33
<
lain >
which isn't hw accelerated
18:33
<
lain >
so playing back 4k vp9 video on my core i7-4700mq laptop eats like 20% of all 16 execution threads
18:34
<
lain >
which is just astonishingly stupid
18:34
<
rqou >
is hardware acceleration actually hardware or is it just a dsp?
18:34
<
lain >
meanwhile playing back the same video in Edge, which doesn't support vp9, will get you an mp4 stream, which decodes with gpu assistance iirc
18:34
<
rqou >
or is it "super sekrit NDA" :P
18:34
eduardo_ has joined ##openfpga
18:34
<
lain >
but at the same time, google won't feed you a mp4 at 4k, they limit you to like 1440p
18:34
<
lain >
I think it's gpu accel
18:35
<
rqou >
some GPUs really do have decode hw
18:35
<
rqou >
it's not just using shaders
18:35
<
rqou >
i don't really get why video codecs have so much "super sekrit" surrounding them though
18:36
<
lain >
probably because high-end video camera makers still use them as distinguishing features
18:36
<
lain >
like sony's XAVC-S codec stuff
18:36
<
rqou >
i thought high-end cameras just shoot raw?
18:36
<
lain >
personally I'd rather just capture losslessly compressed raw
18:36
<
rqou >
"video people" always seem to come up with shitty tech
18:36
<
lain >
the really high-end do, but there's an upper middle ground that still use codecs
18:37
<
azonenberg >
rqou: do you know how much data uncompresed 4K is?
18:37
<
rqou >
a bit over 10gbps
18:37
<
azonenberg >
say 24-bit color, 3840 x 2160 pixels, 60 FPS = ~1.4 GB/s
18:38
<
azonenberg >
Or about 10 minutes per terabyte of storage
18:38
eduardo has quit [Ping timeout: 246 seconds]
18:38
<
lain >
lossless compression would probably cut that in half
18:39
* lain
also has some cams she has built that can do raw video capture
18:39
<
lain >
one day I'll finish some of that stuff
18:40
<
rqou >
what does that camera record onto?
18:41
<
rqou >
oooh this was that axiom camera i remember hearing about
18:42
<
rqou >
at some point i really need to build my "stop f*cking around and just capture" video capture device
18:42
<
rqou >
basically taking 1080p hdmi in, stripping hdcp, and just transmitting 10GbE containing the raw data
18:43
<
rqou >
also a good ADC for capturing "NTSC" video that actually isn't
19:03
<
pie_ >
wait lain is a she :O not that thats surprising actually
19:03
* pie_
shrugs and goes back to screwign around
19:13
scrts has quit [Ping timeout: 240 seconds]
19:21
scrts has joined ##openfpga
19:28
<
openfpga-github >
openfpga/master a99a604 Andrew Zonenberg: Added GetPrimitiveName()
19:28
<
openfpga-github >
openfpga/master deb0c66 Andrew Zonenberg: Greenpak4EntityOutput: Const-ified a bunch of accessors
19:34
<
rqou >
yeah i don't actually know what's happening there
19:34
<
mtp >
pie_, that's how __ works
19:35
<
mtp >
__foo in a class is transformed to _Classname__foo
19:35
<
mtp >
you're just getting that binding from the lexical scope, not the class scope
19:35
<
mtp >
which IS weird
19:35
<
pie_ >
its not shown via locals() or globals() :O
19:35
<
pie_ >
on second read im kinda getting what youre saying
19:36
<
pie_ >
that still sounds fucked though
19:37
<
mtp >
>>> '_MyClass__number' in locals()
19:38
<
pie_ >
well of course it is in locals if you set it
19:38
<
pie_ >
ah but of course its not in locals if its created in the class
19:38
<
pie_ >
so youd have to call locals in the class
19:40
<
pie_ >
if you define __number in the class you have to access it with self.
19:43
<
qu1j0t3 >
lolpython
*closes window*
19:43
<
pie_ >
hey its still not C :P
19:52
<
pie_ >
rqou, yay graphs r vcool \o/
20:01
<
mtp >
pie_, if it's in a class it's in the
__dict__
20:02
<
rqou >
hmm, yosys has some problems with my constant z driver
20:13
scrts has quit [Ping timeout: 246 seconds]
20:22
scrts has joined ##openfpga
20:33
<
cr1901 >
azonenberg: Would you object if I made the shift register fix a yosys plugin (that replaces the shreg extraction pass for gp4 synthesis alone) instead of patching yosys, at least for the time being? Sadly I don't have my notes on me right now, but I explicitly recall the shreg pass as-is in yosys "is a good default, just that gp4 has special considerations".
20:34
<
rqou >
no, don't do plugins
20:34
<
rqou >
yosys plugins hit all the fun C++ ABI problems
20:34
<
azonenberg >
multi-tap shregs are likely a concern for other arches too
20:34
<
azonenberg >
Fix it in the yosys code
20:34
<
azonenberg >
just make sure you dont break other arches
20:34
<
rqou >
unless you want to make a binary blob plugin (which doesn't work too well anyways), there is no good reason to make a plugin
20:35
<
rqou >
also azonenberg i really really need the ZIA map for larger parts :P
20:35
<
azonenberg >
yes i know
20:35
<
azonenberg >
One thing at a time :)
20:36
<
rqou >
also, i'm now forced to properly generate IBUF cells rather than always generating IOBUFE cells
20:36
<
rqou >
turns out the way IOBUFE cells are coded confuses yosys's constant propagation pass
20:37
<
cr1901 >
"just make sure you dont break other arches" This is exactly what I'm afraid of... but again, don't have my notes, so I'll give it a shot without...
20:37
<
openfpga-github >
yosys/master 633376a Robert Ou: json: Parse inout correctly rather than as an output
20:37
<
rqou >
also ^ is pretty hilariously busted
20:39
<
openfpga-github >
openfpga/master d245e0e Andrew Zonenberg: Added initial netlist export. Probably not fully functional for connectivity; definitely does not support attributes yet.
20:40
<
rqou >
azonenberg: let's have a bikeshed about io voltage standards
20:40
<
rqou >
how do you want these to be dumped?
20:40
<
rqou >
i was thinking of adding some non-xilinx values of "HV" and "LV" to the IOSTANDARD attribute
20:40
<
azonenberg >
I'd rather say LVCMOS33 or LVCMOS18
20:41
<
azonenberg >
as that allows the dumped code to be resynthesized
20:41
<
rqou >
but that's not strictly accurate
20:41
<
azonenberg >
You can always replace LVCMOS33 with LVCMOS25 if you know the board runs at 2.5V, etc
20:41
<
azonenberg >
It will produce the same bitstream
20:41
<
azonenberg >
if resynthesized
20:41
<
azonenberg >
It just might not have the exact same timing
20:41
<
azonenberg >
Alternative option - have your code take an argument specifying vcco for each bank
20:41
<
azonenberg >
presumably you can get that info if you have the bitstream
20:42
<
pie_ >
oh god lol what
20:42
<
pie_ >
<codeshot> I think OO languages gave up on maturity and decided to give up and stay needy children but we're trying to pull 30-something divorcees in the singles bar of international business and carting around a kid is a good way to get a conversation started.
20:42
* pie_
sight i need to take another run at CLaSH one of these days
20:42
<
rqou >
but there's other attributes where i've already broken with xilinx convention because xilinx convention is dumb
20:42
<
azonenberg >
rqou: like what?
20:42
<
rqou >
like how termination is specified
20:43
<
azonenberg >
i generally try to preserve compatibility with vendor tools when possible, I may add a new/better way of doing things
20:43
<
azonenberg >
but the old way should still work
20:43
<
rqou >
which has footgunned us a number of times already
20:43
<
rqou >
i was going to add a "xilinx to openfpga" pass at some point
20:43
<
rqou >
so xilinx-style input will be accepted, but this tool won't output it that way
20:43
<
rqou >
e.g. xilinx has a really fun DATA_GATE attribute that is great for causing synth/sim mismatches
20:44
<
azonenberg >
lol oh joy
20:44
<
rqou >
you can
_also_ instantiate LDG manually which will perform as expected
20:45
<
azonenberg >
Yeah that makes sense
20:46
<
rqou >
which will be extra fun the way i intend to code it
20:46
digshadow has quit [Quit: Leaving.]
20:46
<
rqou >
one pass will see DATA_GATE, issue a warning, and convert it to LDG
20:46
<
rqou >
another pass will then proceed to absorb LDG back into the io cell
20:46
digshadow has joined ##openfpga
20:46
<
rqou >
do work, and then undo it :P
20:48
digshadow has left ##openfpga [##openfpga]
20:50
<
azonenberg >
Attributes aren't yet implemented so this won't work (none of the luts have truth tables)
20:50
<
azonenberg >
but here's blinky
20:50
<
rqou >
i think i'm still a little bit ahead of you
20:50
<
rqou >
i can fully untechmap a design assuming there are no bugs
20:50
<
rqou >
(which there probably are)
20:50
<
rqou >
can you send me some verilog to test with?
20:51
<
rqou >
i'm going to quickly go out and grab some noms, brb
20:51
<
azonenberg >
In a bit, kinda busy here :)
20:51
* azonenberg
is eating at his deskl
20:51
<
azonenberg >
And well if i can get to that point by the end of today i'll be pretty happy
20:51
<
azonenberg >
and we can spend the rest of the week figuring out higher level un-synthesis stuff on top of the IR
20:52
<
azonenberg >
Also i note that the current dump i showed you is un-bitstreamed but not un-techmapped
20:52
<
azonenberg >
I can't untechmap usefully until i have attributes
20:52
<
azonenberg >
to turn the hard IP back into gates
20:52
digshadow has joined ##openfpga
20:54
pie_ has quit [Read error: Connection reset by peer]
20:55
pie_ has joined ##openfpga
20:59
digshadow has quit [Ping timeout: 246 seconds]
20:59
pie_ has quit [Remote host closed the connection]
20:59
pie_ has joined ##openfpga
21:02
<
azonenberg >
Oook so next up is attribute export
21:03
<
azonenberg >
And then i can start thinking about untechmapping
21:06
DingoSaar has joined ##openfpga
21:13
scrts has quit [Ping timeout: 260 seconds]
21:15
scrts has joined ##openfpga
21:24
coin0___ has joined ##openfpga
21:28
coino_ has quit [Ping timeout: 260 seconds]
21:33
test123456 has quit [Remote host closed the connection]
21:37
digshadow has joined ##openfpga
21:41
digshadow has quit [Ping timeout: 246 seconds]
21:55
digshadow has joined ##openfpga
21:58
azonenberg has quit [Ping timeout: 258 seconds]
21:59
azonenberg_work has quit [Ping timeout: 255 seconds]
22:00
azonenberg has joined ##openfpga
22:00
azonenberg_work has joined ##openfpga
22:00
digshadow has quit [Ping timeout: 246 seconds]
22:51
<
rqou >
azonenberg: problem: "that .jed" has DDR FFs
22:51
<
rqou >
so we currently can't untechmap it
22:52
<
azonenberg >
Can you make an untechmap model of a DDR FF based on SDR FFs?
22:52
<
azonenberg >
you know the XOR trick?
22:52
<
rqou >
probably later
22:52
<
rqou >
i'm going to test some simpler designs first
22:53
<
azonenberg >
works on xilinx for synthesis
22:53
<
azonenberg >
have not tested on yosys
22:53
<
azonenberg >
but it was explicitly intended to model a coolrunner
22:53
<
rqou >
also, interestingly "that .jed" doesn't enable any GCKs
22:53
<
rqou >
now i'm really not sure how it works
22:55
m_t has quit [Quit: Leaving]
22:56
<
rqou >
ah it's using CTC
22:59
<
rqou >
also, yosys is so damn noisy
23:03
<
rqou >
hmm now i'm really really curious what the original code for "that .jed" looks like
23:03
<
rqou >
it's decently full and has a whole bunch of TFFs in addition to DDR FFs
23:03
<
rqou >
as well as zero GCKs
23:17
<
rqou >
damn xdot is slow
23:22
<
rqou >
this is your blinky from your invasive attack blogpost
23:22
<
rqou >
not sure if it's correct or not
23:22
<
rqou >
it's so full of noise it's hard to make heads or tails of it
23:23
<
felix_ >
speaking of video cameras, digital video transport and recording/streaming: /me will be working on sdi support for the apertus axiom camera and the hdmi2usb streaming/recording system from next month on for half a year :3
23:24
<
rqou >
and someone is paying you to do that?
23:24
<
rqou >
or just for fun?
23:24
<
rqou >
oh btw i just remembered
23:25
<
rqou >
felix_: what's the current status with getting tickets for CCC?
23:25
<
felix_ >
rqou: since the congress will be in a bigger venue this year, there probably won't be problems to get a ticket
23:25
<
felix_ >
it's in leipzig this year
23:26
<
rqou >
yeah i know that part
23:26
<
rqou >
there's no crazy voucher system?
23:27
<
felix_ >
as far as i know not, but i don't know that for sure
23:27
<
rqou >
i just want to make sure i don't end up without a ticket
23:28
<
felix_ >
and well, if there was such system again, i could poke certain people again ;)
23:30
specing has quit [Ping timeout: 248 seconds]
23:31
<
felix_ >
imho open fpga toolchains are important and also very on topic at the c3, so i'll try my best
23:32
<
azonenberg >
rqou: did you opimize yet?
23:33
<
azonenberg >
i mean the yosys opt pass
23:33
<
rqou >
yeah, i ran opt
23:33
<
azonenberg >
So this afternoon's focus is implementing attribute export for all of the remaining greenpak hard IP
23:34
<
azonenberg >
alphabetically i'm up to DCMPREF
23:34
<
rqou >
i guess my focus should probably be to write unit tests :P
23:35
<
rqou >
oh, opt_rmdff isn't working for me btw
23:35
specing has joined ##openfpga
23:38
<
rqou >
which incidentally then causes yosys to not be able to read its own verilog back in
23:38
<
rqou >
it sees @(posedge PAD_FB2_7, posedge 1'h0, posedge 1'h0) and then gives up because it thinks there are multiple edge-sensitive events
23:39
<
azonenberg >
Lol welp
23:40
<
azonenberg >
Did you pull the latest code from clifford?
23:40
<
azonenberg >
a few days ago
23:40
<
rqou >
yeah, i have that commit
23:40
<
azonenberg >
he pushed a fix to some of the reset stuff
23:40
<
azonenberg >
i havent tested it yet
23:40
<
azonenberg >
If it's not working for you, reopen the issue
23:45
<
rqou >
hmm, it seems i can't reopen issues?
23:47
<
azonenberg >
Comment on the issue?
23:47
<
azonenberg >
or is that not working either
23:47
<
rqou >
yeah, i can comment but it doesn't seem like i can reopen?
23:52
<
rqou >
hmm, one reason the output looks like a huge mess is the TFFs
23:52
<
rqou >
(for your blinky)
23:52
<
rqou >
and othe other reason is that i can't seem to get yosys to remove a bunch of intermediate wires