<futarisIRCcloud>
Wow. The PG27UQ 4K G-Sync monitor has a $2600 Intel Arria 10 FPGA inside.
<kc8apf>
in qty, that FPGA costs nVidia/Asus nowhere near that price
<rqou>
pie_: we need a silly codename for if i ever decide to RE a very lorge FPGA :P
<pie_>
hm
<kc8apf>
spruce goose
<pie_>
what is BIG
<pie_>
ugh
<pie_>
lucoa
<rqou>
looooool
<pie_>
you had me thinking for a while there
<rqou>
I'm going to go with that for sure
<pie_>
im pretty sure you already thought of this and was testing if i would
<rqou>
i actually didn't
<pie_>
lies
<rqou>
i decided to ask you before ever giving it any thought
<pie_>
so you're saying this was all my idea
<rqou>
too bad arria 10 is a totally different uarch, qnd I can't even afford to pay for the quartus for that
<pie_>
one cna dream
<rqou>
pie_: dream of stratix 10? :P
<rqou>
(definitely not happening, way too much $$$ and totally new uarch)
<qu1j0t3>
kc8apf++
<sorear>
stratix and aria are "totally" different?
<rqou>
stratix _10_ is totally different
<rqou>
it's currently the only finfet part, for one
<rqou>
they couldn't get wires anywhere near the desired performance, so stratix 10 has registers _everywhere_
<rqou>
while the low-end parts are stuck in a time warp (_especially_ max v)
Adluc has quit [Ping timeout: 245 seconds]
Marex has quit [Ping timeout: 255 seconds]
Marex has joined ##openfpga
<rqou>
altera seems to have three major types of uarchs (with tweaks in between): lut4, lut6/alm, and stratix 10
<rqou>
I'm not sure when column-based arrays showed up
<balrog>
rqou: is stratix 10 on intel process?
<balrog>
(and which? 14nm?)
<rqou>
i think so?
<balrog>
(or 22nm?)
<rqou>
it's on 14nm finfet
<rqou>
whereas arria 10 is on iirc 20nm planar
<balrog>
rqou: also how far back does lut4 go?
<balrog>
all the way to cyclone I?
<rqou>
yeah
<rqou>
max v is especially in a time warp because it's derived from the cyclone _I_ architecture
<balrog>
we have very little info on FPGA lifecycles/histories
<balrog>
:/
<rqou>
er, that's not true?
<balrog>
there's info here and there strewn around in different places
<balrog>
eh, I should reword
<balrog>
there's nothing concise or well collected
<rqou>
that's definitely true
Adluc has joined ##openfpga
ZombieChicken has quit [Remote host closed the connection]
ZombieChicken has joined ##openfpga
<cyrozap>
Looks like you can get used Dell G-Sync monitor PCBs complete with Arria V-based G-Sync modules for ~$40 on ebay. Worth it?
<rqou>
probably
<cyrozap>
I feel like if I buy one it'll just add to the "list of things I want to hack on but will never actually have time to do so"...
<futarisIRCcloud>
cryozap: S2716DG main board ???
Bike has quit [Quit: Lost terminal]
<rqou>
azonenberg: ping?
<cyrozap>
futarisIRCcloud: Also S2417DG.
<rqou>
hmm, i don't know if i'm doing this wrong or what, but it seems if aload is used then the clock lines can't use mux2/3
<rqou>
hmm, this is actually documented
<rqou>
ugh
<rqou>
so these do actually share a mux somewhere
<azonenberg>
not a mux, but a config bit maybe
<rqou>
there's no reason why they can't be sharing a mux too
<rqou>
but yeah, maybe just a config bit
<rqou>
but this means that it's not _exactly_ as drawn in the datasheet
wolfspraul has quit [Ping timeout: 245 seconds]
digshadow has joined ##openfpga
<awygle>
the last few days are all "wtf is happening" followed shortly by "oh its in the datasheet" lol
<rqou>
well, not everything is in the datasheet
ZombieChicken has quit [Quit: Have a nice day]
<qu1j0t3>
words to live by
<rqou>
so new guess based on rules of "what can be used with what" is that there are 6x 2-to-1 muxes
<rqou>
and the outputs of these are somehow distributed among the 10 signals that need them
<rqou>
oh, except maybe addnsub is different
<rqou>
since that one can select between muxes 3/4
<azonenberg>
rqou: So we had a busy day of insulation today
<rqou>
is the house nice and cozy and insulated now?
<azonenberg>
Not fully, but a good start
<azonenberg>
The corner bedroom on the 1st floor is just about done, it took a while because of some awkward stud placement that meant lots of half-sized pieces getting cut
<azonenberg>
The office is about 90%, i have to put a few extra studs in for sheetrock support still
<azonenberg>
and i'm holding off on insulating those cavities until they get put up
<rqou>
does it actually get noticeably warmer? :P
<rqou>
your house already had a nice long time constant for temperature swings without any insulation
<azonenberg>
oh and we also did about half of the living rom
<azonenberg>
room*
<azonenberg>
some areas are blocked by the giant pile of insulation
<azonenberg>
so i have to hold off on those for a bit :p
<azonenberg>
The first floor is mostly below grade level so it has a very long time constant b/c it's buffered by the ground
<azonenberg>
especially w/ no insulation on
<azonenberg>
So far we dont have enough insulation up to provide a perceptible difference but the ambient temps are also quite comfortable right now day and night
<rqou>
wtf why can't i get enable lines to activate the way i expect?
inoor has joined ##openfpga
inoor has quit [Remote host closed the connection]
<rqou>
wtf
<rqou>
it somehow couldn't tell that two of my LEs _was_ using the same pair of clk/ena signals
<rqou>
ok, behavior so far is consistent with the sharing mux hypothesis
<rqou>
huh, these two signals are sharing the mux so much that they share invert bits too
<rqou>
clock/aload don't though
<rqou>
presumably because clocks still need individual inverts if they are driven from the global net
<rqou>
OH WTF
<rqou>
sclr behaves totally differently
<rqou>
hmm, maybe i misread some of the docs
<rqou>
maybe sclr doesn't actually share the mux
<rqou>
yup, i misunderstood the docs
<rqou>
a doc claims that only two aclr+sclr can be _routed into_ a lab
<rqou>
global != routed into
<rqou>
so this restriction is "just" because both can only use mux4/5
<rqou>
azonenberg: so, would it ever make sense in a design to share a synchronous or asynchronous load signal with a clock or a clock enable?
<rqou>
i'm wondering why they saved the small number of transistors here
<azonenberg>
i wonder if it was metal density limitations?
<azonenberg>
i.e. they had space for X signals on a given layer
<azonenberg>
and had to let something slide
<rqou>
maybe
<rqou>
whee, now i get to figure out wtf "dynamic arithmetic mode" is supposed to be doing
<rqou>
supposedly quartus won't let you use the inverta input unless you used either a carry in or a carry out
<rqou>
which requires activating dynamic arithmetic mode at the same time
<rqou>
azonenberg: thoughts on having a "footgun mode" when i go to writing my own tools?
Miyu has joined ##openfpga
<rqou>
the "i promise i read the LAB packing rules" mode
<azonenberg>
you know me
<azonenberg>
i like tools that cant produce invalid output
<rqou>
it's not invalid
<azonenberg>
in fact, early on when doing low level dev
<azonenberg>
is the time when i want DRCing more than ever
<rqou>
using inverta without carries connected is totally valid afaict
<rqou>
the only problem is that you destroy packing efficiency if you're an idiot
<rqou>
azonenberg: so, what about things like this?
<azonenberg>
I have no problem with low level features that may not give optimal results
<azonenberg>
As long as they aren't overtly harmful (frying the chip, producing a bitstream that's not equivalent to your rtl, etc)
<rqou>
yeah, it's none of those
<rqou>
afaict it's "almost nobody wants a wire that inverts only input A, and does so for _every_ lut in the tile"
<rqou>
azonenberg: btw, afaict this chip is _really good_ at implementing various math ops
<rqou>
but you have to be smart about how you do it
<azonenberg>
yeah
<azonenberg>
iirc xilinx can for example do 3-input adders in a single lut per bit
<azonenberg>
but ise is not good at inferring these
<azonenberg>
i think vivado is better? been a while since i tried
<rqou>
O_o
<rqou>
i don't think this chip can do that
bitd has joined ##openfpga
<rqou>
wat
<rqou>
i tried to enable arithmetic mode and none of the bits i expected to change did change
<rqou>
azonenberg: what if "dynamic arithmetic mode" is not actually a thing that exists in the bitstream?
<rqou>
what if it's just a software rule for "no, you cannot be an idiot and connect cin/cout all over the place"?
<rqou>
alright, evidence i have so far is definitely "dynamic arithmetic mode does not change any bits in the bitstream"
<rqou>
hmm wtf using inverta is causing _two_ control bits to change
<rqou>
there must be some additional feature here i don't understand
<rqou>
there's also still some bits that i haven't managed to toggle, so i'm definitely missing something
pakesson has quit [Ping timeout: 256 seconds]
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
pakesson has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
dfgg has quit [Ping timeout: 276 seconds]
<rqou>
wtf, "LE RAM" appears to be a lie?!
<rqou>
> Warning (287001): Assertion warning: Current device family (MAX V) does not support synchronous RAM -- implementing the synchronous RAM as a DFFE array instead File: /home/rqou/intelFPGA_lite/18.0/quartus/libraries/megafunctions/altram.tdf Line: 297
<rqou>
> Warning (287001): Assertion warning: Current device family (MAX V) does not support asynchronous RAM -- implementing the asynchronous RAM as a latch array instead File: /home/rqou/intelFPGA_lite/18.0/quartus/libraries/megafunctions/altram.tdf Line: 291
<rqou>
does max v not actually have distributed ram?
<rqou>
in that case, wtf are the mystery control bits actually controlling?
<daveshah>
rqou: perhaps when they say "LE RAM" they do literally mean just a DFF array
<rqou>
that's stupid
<daveshah>
it's a bit like Lattice advertising the MachXO3 as supporting something like "logic-based multipliers"
<daveshah>
we didn't manage a DSP core, but you can use the LUTs to do multiply
<rqou>
um, duh?
<rqou>
in this case the max ii and max v fabrics should be identical
<rqou>
in terms of featureset
<rqou>
i wonder how similar the bitstreams are
<rqou>
the only change should be in the IOs
<daveshah>
btw when they say in the datasheets the DFFs can be used as TFFs, JKFFs, etc, is that really a config bit, or just use of the LUT/routing?
<rqou>
afaict it doesn't exist either in the bitstream
<cr1901_modern>
maybe not the code proper, but the way it builds is
<rqou>
i seem to recall that your change specifically broke me
<rqou>
although it's late af so i might be misremembering
<rqou>
cr1901_modern: can i please ask you to properly root-cause this?
<rqou>
oooh
<rqou>
cr1901_modern: among other things, your way breaks win64
<rqou>
can you please try and find a better solution?
<cr1901_modern>
That config was never meant for win64
<rqou>
wat
<cr1901_modern>
I specifically point to the 32-bit compilers
<rqou>
i specifically don't want to do that
<cr1901_modern>
Then create your own win64 config
<cr1901_modern>
which btw, is _also_ broken on my end
<rqou>
msys2 should be a generic config
<cr1901_modern>
No it shouldn't, there's three environments for a reason. Don't mix and match
dfgg has joined ##openfpga
<rqou>
what three environments?
<cr1901_modern>
msys, mingw32, mingw64
<cr1901_modern>
ignore msys, it's cygwin but worse
<rqou>
i just have one environment
<cr1901_modern>
Are you cross compiling or not?
<rqou>
yes
<rqou>
i just use the debian mingw64 packages
<cr1901_modern>
I've never tested that config in cross-compiling configuration
<cr1901_modern>
in any case, it was meant only for 32-bit builds
<rqou>
i've always been using that config in cross-compiling :P
<cr1901_modern>
I'm trying to make a 64-bit target now, but abc has decided it still doesn't want to work
<cr1901_modern>
so now I have _two_ yosys' and neither of them work
<rqou>
ooh, in case i wasn't clear, i'm compiling _on_ linux
<rqou>
i assume you're not?
<cr1901_modern>
Yes, I know
<cr1901_modern>
and I'm native compiling
<rqou>
hrm
<cr1901_modern>
In any case, _your options_ are fine for a native 64-bit compile
<cr1901_modern>
but abc breaks for another reason (32-bit/64-bit dll mismatch) I haven't figured out yet
<rqou>
hrm
<rqou>
no, it seems to be hosed
<cr1901_modern>
So I needed to compile a 32-bit version and seems to be wrong
<rqou>
something is borked with my config
<rqou>
but i swear i tested it?
<rqou>
hrm
<cr1901_modern>
It doesn't matter. I'm am _saturated_ with dependency hell this week, and it's only Wednesday
<rqou>
i probably just mucked around with setting CC and CXX until the problem went away
<cr1901_modern>
Why did the "-DSIZEOF_VOID_P=8 -DSIZEOF_LONG=4 -DSIZEOF_INT=4" options disappear?
<cr1901_modern>
Are they not needed?
<rqou>
i specifically killed those because i hated them
* cr1901_modern
is rebuilding w/ the correct CC setting and will see what happens
<rqou>
hmm, it seems you are correct
<rqou>
CC needs to be gcc, not g++
<rqou>
i guess i must have been overriding it somewhere else
<rqou>
cr1901_modern: can you properly root-cause this?
* rqou
zzzzz
<cr1901_modern>
When I have a working yosys on _both_ configs, native compile, sure :)
<cr1901_modern>
I'm not delving into that hell build system unless I have to
<rqou>
cr1901_modern: so the workaround I just tested a few minutes ago was to change the line that sets CC in ABCMKARGS
<rqou>
change it from $(CXX) to $(CC) and then i can just override everything in the make command line
Miyu has quit [Ping timeout: 256 seconds]
<rqou>
of course, the _real_ solution would be for someone to get a comically oversized trout and slap alanmi with it and tell him to use development practices from this decade (literally, he uses VC++6 which came out in 1998)
<daveshah>
lol
<daveshah>
cannot believe VC++6 lives on
<daveshah>
almost as old as I am
<rqou>
hmm, just realized what I'm missing control bits for: chaining carry across tiles
<rqou>
going to investigate tomorrow
* rqou
zzz for reals
<keesj>
realz
Bike has joined ##openfpga
genii has joined ##openfpga
soylentyellow__ has joined ##openfpga
soylentyellow_ has quit [Ping timeout: 248 seconds]
soylentyellow_ has joined ##openfpga
soylentyellow__ has quit [Ping timeout: 240 seconds]
afiskon has quit [Quit: Lost terminal]
afiskon has joined ##openfpga
afiskon has quit [Quit: Lost terminal]
afiskon has joined ##openfpga
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale has joined ##openfpga
noobineer has joined ##openfpga
<awygle>
what if... being awake is just zzz for imaginaries?
gnucco has joined ##openfpga
taralx has joined ##openfpga
noobineer has quit [Ping timeout: 276 seconds]
Bike has quit [Ping timeout: 260 seconds]
Bike has joined ##openfpga
amclain has joined ##openfpga
amclain has quit [Quit: Leaving]
m_w has joined ##openfpga
<keesj>
awygle: sounds plausible
<awygle>
wow. always go home lol. last night this problem was inscrutable, today i solved it in less than five mines.
<awygle>
*minutes
<qu1j0t3>
yes
<qu1j0t3>
reliable technique
Miyu has joined ##openfpga
taralx has quit [Quit: Connection closed for inactivity]
<rqou>
whelp, SCOTUS is fucked
<shapr>
?
<shapr>
oh, because they upheld the travel ban?
<rqou>
because Kennedy is retiring
<cr1901_modern>
rqou: Suspending my horror re: America for a moment... the source of my woes is that the "static" library provided w/ abc is a DLL stub
<rqou>
yes
<rqou>
that is correct
<cr1901_modern>
And if you knew that, why didn't you tell me?
<rqou>
why is that a problem?
<cr1901_modern>
B/c it doesn't install the dll on the path
<rqou>
oh lol
<cr1901_modern>
how do you handle this w/ cross compiling?
<cr1901_modern>
B/c what I'd rather do is -lpthread, since it works just the same
<rqou>
i just let it use the dll?
<cr1901_modern>
I mean, do you package it w/ the binary manually?
<cr1901_modern>
(it == the dll)
<rqou>
yes
<cr1901_modern>
Yea, the idea of my configs was that you _didn't_ have to do that manually
<cr1901_modern>
(it was a happy accident that yosys didn't break until now. What changed on my end isn't relevant :P)
<rqou>
wait, so what are you getting when you link pthread?
<cr1901_modern>
It works fine, except it's using the pthread provided by gcc instead of the one provided by abc
<rqou>
hmm, I'm starting to think that the windows mingw distributions are different from the linux ones
<rqou>
they package different things
<cr1901_modern>
rqou: My mistake, pthreads _is_ an msys2 package
<rqou>
want to hunt down the (i assume) missing extern C in the abc code?
<cr1901_modern>
No I don't, really
<rqou>
do you know if win32 pthreads can be statically linked? or does it require a dll to get thread attach/detach notifications?
<cr1901_modern>
I don't know much about dlls period. According to Dependency Walker, the actual dll loaded is libwinpthread-1.dll, even though I passed -lpthread on the command line
<cr1901_modern>
I have no idea what magic the linker did to change the library actually loaded
<cr1901_modern>
It's layers and layers and layers of crap and special cases that 10 ppl on the planet know how it actually works and I'm just tired of the principle of least surprise being violated
<rqou>
afaik its not magic
<rqou>
the .lib/.a "just" has to include a different name in the data that builds up the import table
<rqou>
you can also mismatch the symbol name in your code and the name in the imports section
<rqou>
as well as importing "by ordinal"
<cr1901_modern>
rqou: Well, libpthread.dll.a (which is under /mingw32/i686-w64-mingw32/lib/libpthread.dll.a) has a bunch of relocation records for winpthread
<cr1901_modern>
but I haven't found anything in objdump that tells me which dll file to actually load
<rqou>
it should be in the raw contents of the sections of the object files in the .a