<azonenberg>
balrog: think what openbsd did to openssl
<azonenberg>
:p
<azonenberg>
this is the level of invasiveness we're talking about
<balrog>
I mean what are your thoughts on that PR? :P
<balrog>
azonenberg: hah
<balrog>
might want to make it into its own fork in its own repo then
<balrog>
since some of us are irked by hidapi :P
<azonenberg>
I might well consider doing that at some point
<azonenberg>
just make a new submodule to import it
<rqou>
hidapi's error handling is pretty hosed overall right now
<azonenberg>
it's not like i have any lack of submodules in the openfpga repo already
<azonenberg>
:p
<rqou>
error handling is hard :P
<balrog>
rqou: yes, but claiming that an error handling function should not be able to handle it getting passed NULL?
<rqou>
yeah, i guess
<rqou>
the linux version is even higher quality in that it just returns NULL always
<rqou>
rust actually has a decent error handling model
<rqou>
(that i didn't learn about when i started xc2bit, hence xc2bit _also_ needs an error-handling rewrite)
<cr1901_modern>
error_chain is interesting, though something tells me it can't be used for _every_ single project
<cr1901_modern>
Maybe Rust doesn't come w/ batteries included, but I feel like something like error_chain should've been included in libstd if you were intended to use it often
DocScrutinizer05 has quit [Read error: Connection reset by peer]
<rqou>
that doesn't seem to help with xc2bit's problem which is "should use structured errors, not strings"
<cr1901_modern>
Use a structure logging library and print to console instead of a file?
<rqou>
no, as in errors should be a proper struct/enum rather than &'static str
DocScrutinizer05 has joined ##openfpga
<whitequark>
I really don't like error_chain
<whitequark>
it's incredibly complicated and "opinionated"
<whitequark>
the threshold of quality for inclusion in libstd or even getting out of nursery is high and that's good
<rqou>
"opinionated" isn't always bad
<rqou>
e.g. cargo is opinionated too
promach__ has joined ##openfpga
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<cr1901_modern>
opinionated?
<whitequark>
it forces a certain error handling scaffold onto you
<whitequark>
for example, hiding of the actual enum
<whitequark>
that's bullshit IMO
<cr1901_modern>
I wasn't saying error_chain should be included in libstd; I was saying is that error propogation is common boilerplate
<whitequark>
well sure
<whitequark>
if something universally accepted emerges it'll make its way through nursery eventually
<rqou>
like the ? operator?
<whitequark>
um no
<cr1901_modern>
I don't know what "?" does, tbh
<whitequark>
that was an RFC
<rqou>
which I just learned the other day was a post-1.0 feature
<whitequark>
cr1901_modern: the same thing as try!
<cr1901_modern>
Ahhh, thanks
<rqou>
the RFC procedure is different from nursery?
<whitequark>
but as a left-associative unary operator, which removes extra parens
<whitequark>
rqou: yes, they're not even closely related
<whitequark>
RFC process is for language and stdlib changes (mostly language these days; the changes to stdlib tend to be minor enough to be basically rubberstamped)
<whitequark>
nursery is for libraries that are important enough that they get brought under the rust-lang umbrella
<rqou>
ah ok
<whitequark>
while the libs are still immature they're in nursery
<cr1901_modern>
https://wuest.me/blog/e/20170528-io-monad-for-rubyists/ This is the clearest explanation for Maybe monad I've seen so far; I also like this approach to error prop, but I imagine it's not appropriate for everything either
<rqou>
is it just me that finds it impossible to figure out the "current status" of a given Rust RFC?
<whitequark>
rqou: there isn't any
<whitequark>
well, it's either merged or not merged
<whitequark>
beyond that it's just "what people have in their brains"
<rqou>
I see
<rqou>
so there's no "project management infrastructure" to track what's prioritized/being worked on?
<whitequark>
you're severely overestimating the amount of manpower as well as its structuredness
<whitequark>
there's like a dozen people with extremely limited time and only half of them actually code a lot, and a bunch of randos who contribute when they really feel like it
<rqou>
heh ok
<whitequark>
for sure, no one orders anyone to work on something
<whitequark>
hence no "prioritization"
promach__ has quit [Quit: Leaving]
<cr1901_modern>
whitequark: What do you mean by a left associative _unary_ operator?
<whitequark>
well normal unary operators are like +E or -E
<whitequark>
and this one is E?
<cr1901_modern>
Does that mean E?? is (E?)?
<lain>
unary postfix
<cr1901_modern>
I think of associativity as being for binary operators, so I got confused
[X-Scale] has joined ##openfpga
<whitequark>
oh, what lain said
<whitequark>
I misused the term
X-Scale has quit [Ping timeout: 240 seconds]
[X-Scale] is now known as X-Scale
<rqou>
sooo, apparently visiting my relatives in the countryside might now be canceled
<rqou>
due to family drama
<rqou>
everybody's favorite!
fitzsim has joined ##openfpga
<openfpga-github>
[openfpga] azonenberg pushed 1 new commit to master: https://git.io/vQU70
<openfpga-github>
openfpga/master f1282b2 Andrew Zonenberg: Initial skeleton of macrocell code. Has correct bitstream values loaded, but largely ignored
<azonenberg>
seems like the name change borked something
<azonenberg>
there's still vestiges of the old name out there
<azonenberg>
Dont know if thats the main problem
<whitequark>
azonenberg: hmm
<whitequark>
lets see
<whitequark>
azonenberg: oh yeah an old process kept running
<whitequark>
2017-06-21 01:10:40+0000 [_GenericHTTPChannelProtocol,62,] processing changes from web hook Traceback (most recent call last): Failure: exceptions.TypeError: character mapping must return integer, None or unicode
openfpga-bb has quit [Quit: buildmaster reconfigured: bot disconnecting]
<whitequark>
azonenberg: should work now
openfpga-bb has joined ##openfpga
DocScrutinizer05 has quit [Ping timeout: 258 seconds]
[X-Scale] has joined ##openfpga
ZipCPU|Laptop has quit [Ping timeout: 255 seconds]
DocScrutinizer05 has joined ##openfpga
X-Scale has quit [Ping timeout: 246 seconds]
[X-Scale] is now known as X-Scale
<rqou>
whitequark: I'm currently interacting with <yet another relative> who is a CS student here in China, and the thing you posted on Twitter a while back about foreign script processing being in the brain's slow path is totally true
digshadow has quit [Quit: Leaving.]
<whitequark>
wait, which thing?
<rqou>
I recall you linking something about an experiment where someone replaced OCaml(?) keywords with Chinese
<whitequark>
yeah sure
<whitequark>
oh I didn't write it, I linked to it
<rqou>
I didn't realize just how true that claim was until I actually encountered it
<azonenberg>
rqou: just to be sure
<azonenberg>
the PLA OR array
<azonenberg>
outputs 1 when no inputs are enabled right?
<azonenberg>
0 i mean
<azonenberg>
sorry
<azonenberg>
The logical degenerate case of a 0-input gate is 1 for AND and 0 for OR
<rqou>
I'm pretty sure that's right
<rqou>
yeah, it kinda has to be to make the PTC fast path work
<azonenberg>
Yeah that was my thought
ZipCPU|Laptop has joined ##openfpga
Zarutian has quit [Quit: Zarutian]
DocScrutinizer05 has quit [Read error: Connection reset by peer]
<azonenberg>
Ok well i clearly have a bug
<azonenberg>
macrocell outputs are giving me inverted outputs for some reason
<azonenberg>
the constant 1 returns 0, and the PTC returns ~PTC
DocScrutinizer05 has joined ##openfpga
<rqou>
meh, just stick another invert on it and call it a day :P
<azonenberg>
lol well i want to figure out where the inversion is :P might be my PTC mux or something
<azonenberg>
Although, the rule of thumb i learned from one of my profs at RPI
<azonenberg>
every working graphics app has an even number of sign errors :p
<rqou>
lolol
<rqou>
try checking the order you pull the mux bits out of the macrocell config
<rqou>
also try checking if it's actually the right bits? :P
m_w has quit [Quit: leaving]
<azonenberg>
ok so let's see... right_zia_out[7] is correct
<azonenberg>
that's a copy of my input signal
<azonenberg>
right_orterms[3] is supposed to be a constant 0 but it's a constant 1
<azonenberg>
right_orterms[4] is supposed to be a constant 0, and it is
<azonenberg>
right_mc_config[4] is the correct macrocell bits
<azonenberg>
Veeery curious how any of the OR array could be mismatched
<azonenberg>
because the PLA OR is all 1s (all fast path)
<rqou>
did you correctly skip over the global config?
<azonenberg>
I'm reading out the actual config bits now
<azonenberg>
problem is, changing my debug stuff requires re-PARing the entire CPLD
<azonenberg>
which is... not small
<azonenberg>
I just found a bug, but it's not the one i wanted
<azonenberg>
it only affected the left side of the device
<rqou>
hmm my random guess is that the interleaving is messed up
<rqou>
off by one?
<azonenberg>
Oh, i'm almost certain the interleaving is off
<azonenberg>
the funny bit is, it shouldnt matter for this bitstream
<azonenberg>
as the entire OR array is 0xff
<azonenberg>
Which means either my OR array itself is busticated
<azonenberg>
or i'm reading from the wrong bitstream locations entirely and pulling something that isn't PLA OR
<azonenberg>
Don't yet know which
<rqou>
if everything is off by one then you could possibly be reading one column into the transfer bits surrounding the global config
<azonenberg_work>
i.e. better to crash on null deref than UaF
<lain>
fair
<rqou>
now we just need to map the null page :P
amclain has quit [Quit: Leaving]
<rqou>
so I'm sitting in on one of $RELATIVE's university lectures, and I really realize that we need internationalized programming languages
<rqou>
cc whitequark
<openfpga-github>
[openfpga] azonenberg pushed 1 new commit to master: https://git.io/vQTTS
<openfpga-github>
openfpga/master 1f7d800 Andrew Zonenberg: Continued initial macrocell implementation. Fixed bugs in AND array inversion. Now can do arbitrary Boolean combinatorial logic from ZIA to macrocell XOR gate, but no feedback to ZIA or stateful stuff implemented.
<cr1901_modern>
Can you emulate a greenpak inside the coolrunner inside the Artix?
<cr1901_modern>
minus analog stuff*
<azonenberg>
cr1901_modern: I'd need a really big coolrunner to emulate a greenpak
<azonenberg>
One bigger than i could fit in this fpga
<cr1901_modern>
why? not enough RAM to store cfg?
<azonenberg>
not enough flipflops and luts actually
<azonenberg>
i'm not using block ram
<azonenberg>
current projections say i could fit an xc2c64a in the current fpga (xc7a100t)
<azonenberg>
an xc2c128 would fill most of my biggest fpga (xc7a200t)
<cr1901_modern>
Doesn't a GP4 have like 20 LUTs though? Not enough room to emulate that in a coolrunner?:
<azonenberg>
For an xc2c256/384/512 you're looking at either a big kintex7 (larger than webpack supports, a virtex7
<azonenberg>
or a small kintex ultrascale
<azonenberg>
Which is supported by webpack and might be sufficient
<azonenberg>
but is like a $500+ chip :p
<azonenberg>
the issue is the bitstream
<azonenberg>
it's ~2kbits
<azonenberg>
a coolrunner has one flipflop per macrocell
<cr1901_modern>
Oh, and no block ram?
<azonenberg>
you only have 512 bits of state
<azonenberg>
block ram is useless for realtime (vs multi-cycle) emulation of a CPLD
<azonenberg>
you can only read one row at a time
<azonenberg>
but you need the whole bitstream all at once to configure the chip
<cr1901_modern>
ahhh
<cr1901_modern>
so not enough flip flops on coolrunner to do it in real time is what you're saying?
<cr1901_modern>
I mean, what's so bad about multicycle/delay outputs for emulation :P?
<cr1901_modern>
(In any case, I'm only asking as a sick joke, not that I want you to do it)
<azonenberg>
Lol
<azonenberg>
seriously though
<azonenberg>
greenpak on artix should be doable
<azonenberg>
This is actually valuable feedback for when i design my own FPGA/CPLD from scratch
<azonenberg>
gives me an idea of how much fpga it'll take to emulate
<cr1901_modern>
why isn't multicycle emulation on, say, a coolrunner valuable feedback?
<azonenberg>
i'm trying to run at full speed and get as close to the actual device microarchitecture as i can
<azonenberg>
Haven't figured out Fmax of the logic engine yet, JTAG passes timing for 66 MHz which is Fmax of the actual coolrunner's jtag
<cr1901_modern>
How about a UART on coolrunner on Artix?
<azonenberg>
That's probably doable
<azonenberg>
my uart core without oversampling should fit in a 2c64a
<azonenberg>
maybe even a 32 if i use a smaller clock divider (I use 16 bits by default)
<azonenberg>
One leg of the uart should fit in a 32a unmodified
<cr1901_modern>
Oversampling?
<azonenberg>
i.e. tx only or rx only
<azonenberg>
to aid in recovery of noisy signals the uart has an option to sample the bit line a couple of times and majority vote
<azonenberg>
i dont use it often but it's there
<cr1901_modern>
Ahhh. I either use 4 or 16 ticks and just take one sample on tick 2 or 8
<cr1901_modern>
(rx)
<cr1901_modern>
World's most space inefficient UART. For science.
<azonenberg>
Hey it'd be a good validation of the emulator
<azonenberg>
i might actually do it
<cr1901_modern>
Please do, it would be wonderful
<azonenberg>
Lol
<azonenberg>
An LED blinky will come first, for sure
<azonenberg>
also, obligatory "bitstreamception" or "yo dawg" lol
<cr1901_modern>
I can't tell you how difficult it was to refrain
<cr1901_modern>
from making that reference
<azonenberg>
lol
<cr1901_modern>
"Is a UART possible on GP4" is still an open question for me. I'd even accept using two of them to implement tx/rx separately
<azonenberg>
I'll try soon and let you know
<azonenberg>
I think the answer is yes, although no FIFO
<azonenberg>
if you use a counter for a BRG and hard code the baud rate in the bitstream
<cr1901_modern>
FIFO doesn't matter for my use case. Neither does programmable baud
<azonenberg>
you'd need pins for tx_en, tx_out, tx_busy plus 8 data lines so 11
<azonenberg>
slg46620 has 18
<azonenberg>
so you cant fit tx+rx just due to pin constraints alone
<azonenberg>
i think there would actually be enough logic fabric
<cr1901_modern>
Well addr and cs lines as well
<azonenberg>
i was thinking a raw native interface
<azonenberg>
not like 16550 compatible
<cr1901_modern>
Oh well, cs then
<azonenberg>
that's tx_en
<cr1901_modern>
excuse me, it's 3:30am
<azonenberg>
proposed interface: set tx_data to an 8-bit value, assert tx_en for one cycle
<azonenberg>
data is clocked out tx_out
<cr1901_modern>
what's tx_out?
<azonenberg>
tx_busy goes high during the byte and goes low at the end
<azonenberg>
alternatively, tx_done goes high for one clock at the end
<azonenberg>
either would be about the same gate count
<cr1901_modern>
and a similar iface for rx_in, rx_en?
<azonenberg>
Yeah
<azonenberg>
I'll try to bang it up later this week as a PoC
<azonenberg>
also... Yo dawg, I heard you like HDL so I put a CPLD in your FPGA so you can have bitstreams in your bitstream
<cr1901_modern>
In any case, the use case was to replace a faulty UART on a retro SBC I planned out some months ago.
<azonenberg>
makes sense
<cr1901_modern>
I could use 3 GP4s; one on the 1-flip-flop ones for addr decoding, two for UART rx/t
<cr1901_modern>
x*
<cr1901_modern>
140* I think is the 1-FF variant?
<azonenberg>
slg46140 is smaller but i dont remember stats
<azonenberg>
and it isn't fully supported by my tools yet
<azonenberg>
(that will change)
<azonenberg>
Anyway, remind me thursday after work and i'll try banging it out
<azonenberg>
i'm at a training all day tomorrow then having a bbq with lain and a friend
<cr1901_modern>
will do. Still haven't purchased the programmer yet (I'm getting to it)
<cr1901_modern>
have fun
<azonenberg>
Having a uart on a greenpak will be a cool demo anyway
<lain>
:3
<azonenberg>
Also
* azonenberg
imagines buying a kintex ultrascale devkit
<azonenberg>
Sales guy: "What are you going to use this for?"
<azonenberg>
Me: "a UART"
<azonenberg>
Sales guy: "???"
<azonenberg>
Me: "Yeah, I wanted to put a UART in my coolrunner design so I needed more gates"
<lain>
hahahahaha
<lain>
I can just imagine the internal conflict
<lain>
of the sales guy
<lain>
debating whether they should try to educate you
<lain>
or just sell you what you want
<azonenberg>
lol
<azonenberg>
i mean right now i am using 34% of a 7a100t for 32 macrocells
<azonenberg>
Assuming a) no growth of the design as i implement the full macrocell features and b) linear scaling
<azonenberg>
Neither of which is super true
<azonenberg>
i need 171 slices per macrocell so an xc2c128 will need 21948 slices or 65% of an xc7a200t
<rqou>
wait lain are you in the Seattle area too?
<lain>
rqou: I be
<rqou>
damn I should have visited you when I was up there
<lain>
ah, well I just got here a couple weeks ago
<lain>
I'm normally northern Indiana
<cr1901_modern>
You moved?
<rqou>
ooh right I forgot about that
<lain>
cr1901_modern: ehhh I'm considering it, staying up here for a while to see how it goes
<azonenberg>
the xc2c256 will need 43896 slices or 60% of an xcku025
<azonenberg>
and an xc2c512 will need...
<rqou>
you people should all come over to HK :P
<azonenberg>
87,792 slices
<cr1901_modern>
Everybody's at least 3000 miles away damnit lol (except balrog and Lord_Nightmare)
<azonenberg>
actually wait a minute
<azonenberg>
the 256 number is wrong
<azonenberg>
43,896 slices is...
<rqou>
or come to the Bay where I normally live :P
<azonenberg>
86% of an XCKU035
<azonenberg>
for an xc2c256, lol
<rqou>
I know azonenberg really really likes the Bay :P :P :P
<azonenberg>
And there is nothing big enough for an xc2c512 or 384 that fits in webpack
<azonenberg>
For lulz lets see how big i'd need
<azonenberg>
87,792 slices is 70% of an XCKU085
<rqou>
azonenberg: super troll-y homecmos project (once that exists): an unlicensed xc2c1024
<azonenberg>
loool
<azonenberg>
not happening in a homebrew process or even a cheap MOSIS run
<azonenberg>
do you know how big that monster would be?
<azonenberg>
the 2c256 is 15.54 mm^2 of 180 nm
<azonenberg>
extrapolating, the 2c1024 would be somewhere in the 65-75 mm^2 range depending on how big the ZIA got (maybe a bit smaller if you didnt have on die flash)
<rqou>
eh, some parts of the PLA might return "unexpected outputs" :P
<azonenberg>
lol
<rqou>
we'll call it "PTV variations"
<azonenberg>
:P
<azonenberg>
Which is actually not as bad as i thought
<azonenberg>
217 mm^2 for a Willamette pentium 4
<azonenberg>
so... about 1/3 the size of a pentium 4 on the same process
<rqou>
wait wtf
<cr1901_modern>
azonenberg: Wouldn't the die be twice as big because multiplying the length by 2 quadruples the area?
<rqou>
once you put it that way, it's totally insane
<azonenberg>
X-Scale: that was the file i was looking at
<rqou>
azonenberg: but the xc9500xl interconnect is described as "FastCONNECT II"
<rqou>
note the "II"
<azonenberg>
I need to get to sleep
<azonenberg>
have to be up in like 5 hours
<nrossi>
wines, artists, and now days they use footballers... ;)
<azonenberg>
nrossi: wait, what? football?
<azonenberg>
Do you know something i don't?
<nrossi>
zynq -> pele, zynqmp -> ronaldo
<azonenberg>
Huh
<cr1901_modern>
I'd name my designs after plants or something...
<azonenberg>
because I thought that 7 series was Fuji
<azonenberg>
and 8 was Olympus
<azonenberg>
and 9 was Diablo
<azonenberg>
(ultrascale / ultrascale+)
<azonenberg>
then the upcoming 14nm family was Everest
<cr1901_modern>
Mons Olympus comes after
<rqou>
wtf where are you guys finding this?
<azonenberg>
and Everestea is either a typo of Everest or a new device after Everest
<nrossi>
azonenberg: sure, they changed it up a bit between 7-series and Ultrascale
<cr1901_modern>
Actually Mons Olympus should be the last family ever created
<azonenberg>
nrossi: you're saying ultrascale was not Olympus?
<azonenberg>
and ultrascale+ was not Diablo?
<azonenberg>
or it was, but they changed names?
<azonenberg>
Or one of those is the codename for the family and one is for the mask set/SKU
<nrossi>
azonenberg: ultrascale was olympus, but it was a mix for ultrascale plus due to the zynqmpsoc stuff. At one point it was diablo, or pico/alto i only vaguely remember
<azonenberg>
ah, ok
<azonenberg>
and Everest? Was that rfsoc or the next-gen family after ultrascale+ (not yet announced)?
<nrossi>
azonenberg: no idea, I left before they started talking post ultrascale+
<azonenberg>
ah, i see
<rqou>
where are you guys finding this stuff?
<azonenberg>
rqou: debug messages in tool output among other things
<azonenberg>
plus talking to people
<rqou>
interesting, I've never noticed these
<azonenberg>
Clearly not looking in the right spots
<azonenberg>
also funny, the codename of vivado itself was/is Rodin
<azonenberg>
The artist who sculpted "The Gates Of Hell"
<azonenberg>
Because rewriting ISE was hell
<azonenberg>
or ISE in general was
<azonenberg>
unclear
<azonenberg>
aaanyway sleepytime, i have stuff to do all day tomorrow
<cr1901_modern>
It's quite a pity my computer can't handle the sheer awesomeness of both Vivado _and_ ISE
* cr1901_modern
can't sleep
<azonenberg>
The tl;dr at this point is that i can probably emulate up to an xc2c128 in my current lab
<rqou>
it's afternoon here, no sleep for me :P
<azonenberg>
1630ish right?
<azonenberg>
(same TZ as shenzhen?)
<azonenberg>
i have shenzhen time on my phone b/c several of my pcb fabs are there
<cr1901_modern>
You have priority shipping?
<azonenberg>
cr1901_modern: if i pay $500+ for a board with controlled impedance and ViP
<azonenberg>
i wont mind $20 in shipping :p
<cr1901_modern>
ViP?
<cr1901_modern>
And why would a board with controlled impedance _alone_ cost $500
<rqou>
all of China is gmt+8 :P
<rqou>
some people who are screwed over by this unofficially use Urumqi time instead