zng has quit [Quit: ZNC 1.7.2 - https://znc.in]
zng has joined ##openfpga
SpaceCoaster has quit [Quit: ZNC 1.6.5+deb1+deb9u2 - http://znc.in]
SpaceCoaster has joined ##openfpga
tlwoerner has joined ##openfpga
MarcelineVQ has quit [Read error: Connection reset by peer]
MarcelineVQ has joined ##openfpga
MarcelineVQ has quit [Remote host closed the connection]
Miyu has joined ##openfpga
hackkitten has quit [Ping timeout: 245 seconds]
Flea86 has joined ##openfpga
SpaceCoaster has quit [Ping timeout: 245 seconds]
MarcelineVQ has joined ##openfpga
genii has quit [Quit: Golf, Leafs, Golf! ... Go Raps!]
hackkitten has joined ##openfpga
Miyu has quit [Ping timeout: 245 seconds]
SpaceCoaster has joined ##openfpga
Flea86 has quit [Ping timeout: 248 seconds]
Flea86 has joined ##openfpga
<bubble_buster> so I know this is dumb, I can probably just use malloc instead, or come up with a less-hacky implementation, but I'm curious... how do I compile a 4GB array in C++?
<bubble_buster> currently the linker is failing even with -fPIC -mcmodel=large (also tried medium which was suggested somewhere)
<bubble_buster> verilated.cpp:(.text+0x163): relocation truncated to fit: R_X86_64_PC32 against `.bss'
<bubble_buster> the 4GB array is in my C++ test bench/DPI code, not in the verilog
<sorear> bubble_buster: hmm, that should work if -mcmodel=large is passed to the compiler
<sorear> (it's a compile option, not a link option, if that makes a difference for you)
<bubble_buster> Ah, it does, I only tried adding it to linker options because that's the step that was failing
<bubble_buster> Thanks
Bike has quit [Quit: Lost terminal]
Richard_Simmons has quit [Ping timeout: 268 seconds]
Bob_Dole has joined ##openfpga
<tnt> I'm not sure how every ice40 synthesis isn't broken atm ...
<azonenberg> bubble_buster: i guess the better question is, why are you doing this?
<azonenberg> malloc'ing and loading from a file is almost certainly the better choice
<tnt> memmap is an even better one :p
emeb_mac has quit [Ping timeout: 245 seconds]
<Sprite_tm> Memmap++; put that page cache to good use :P
Jybz has joined ##openfpga
freemint has joined ##openfpga
_whitelogger has joined ##openfpga
Asu has joined ##openfpga
<whitequark> mwk: "This document is known to exist, but is only accessible for members of "the GTZ Lounge"." lmao
rohitksingh has quit [Ping timeout: 264 seconds]
Asu has quit [Ping timeout: 268 seconds]
<pie_> you guys know any articles on when an fpga coprocessor is worth it compared to gpu / optimized intel?
Jybz has quit [Ping timeout: 252 seconds]
Jybz has joined ##openfpga
Asu has joined ##openfpga
Asu has quit [Ping timeout: 272 seconds]
Asu has joined ##openfpga
Bike has joined ##openfpga
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
rohitksingh has joined ##openfpga
Laksen has joined ##openfpga
craigjb has quit [Ping timeout: 268 seconds]
rohitksingh has quit [Ping timeout: 250 seconds]
<tnt> :/ According to my riscv soc, 504 / 24 = 170
<tnt> nm
rohitksingh has joined ##openfpga
Thorn has quit [Ping timeout: 258 seconds]
X-Scale has quit [Quit: HydraIRC -> http://www.hydrairc.com <- s0 d4Mn l33t |t'z 5c4rY!]
freemint has quit [Ping timeout: 245 seconds]
freemint has joined ##openfpga
lutsabound has joined ##openfpga
freemint has quit [Remote host closed the connection]
freemint has joined ##openfpga
Flea86 has quit [Quit: Leaving]
freemint has quit [Ping timeout: 250 seconds]
<bubble_buster> ah yes I forgot about mmap, that would be the best option. not sure what the advantage of malloc would be other than simplifying compilation (could have easily done this but I was curious if there was a way to correctly compile it)
<bubble_buster> really I should be allocating/initializing pages dynamically since most of the memory space will almost never be used, could even implement swapping out to disk to reduce memory utilization
freemint has joined ##openfpga
adamgreig has quit [Quit: WeeChat 1.8]
Jybz has quit [Excess Flood]
Jybz has joined ##openfpga
emeb has joined ##openfpga
rohitksingh has quit [Ping timeout: 250 seconds]
<tnt> Is anyone working on a "hyper-threaded" (interlaced context pipeline stuff) riscv or do I have to get started on one ? picorv32 @ 24 MHz is a bit slow :/
mumptai has joined ##openfpga
<ZirconiumX> tnt: I think VexRiscv is faster as a core, because PicoRV's IPC is pretty bad
<tnt> I'll give it another shot, but the last time I tried, yes, it had a lower IPC ... but lower fmax too and so ended up in the same range.
<ZirconiumX> Depends on the configuration
<tnt> of course because I'm dumb I didn't keep any of the test setup I made or even the exact results :/
X-Scale has joined ##openfpga
Asu has quit [Ping timeout: 245 seconds]
Jybz has quit [Ping timeout: 246 seconds]
Asu has joined ##openfpga
rohitksingh has joined ##openfpga
cr1901_modern has quit [Quit: Leaving.]
Jybz has joined ##openfpga
cr1901_modern has joined ##openfpga
rohitksingh has quit [Ping timeout: 264 seconds]
lopsided98 has quit [Remote host closed the connection]
lopsided98 has joined ##openfpga
rohitksingh has joined ##openfpga
lutsabound has quit [Quit: Connection closed for inactivity]
parport0 has quit [Ping timeout: 245 seconds]
parport0 has joined ##openfpga
Thorn has joined ##openfpga
<azonenberg> So this is going to be fun, i'm trying to make a self-discovery feature for a xilinx fpga project
<azonenberg> by using the ICAP to read its own IDCODE
<azonenberg> (so the bitstream can dynamically figure out what it's running on
<azonenberg> )
<azonenberg> including stepping number etc
<cr1901_modern> Have fun with that :)
<azonenberg> i mean i've used the configuration state machine over jtag already
<azonenberg> but this is my first time using the icap
lutsabound has joined ##openfpga
Jybz has quit [Quit: Konversation terminated!]
emeb_mac has joined ##openfpga
Laksen has quit [Quit: Leaving]
craigjb has joined ##openfpga
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 246 seconds]
<tnt> I know I'm kind of lagging, but anyone knows how nvidia g-sync work on the physical layer ?
<ZirconiumX> How do you mean, tnt?
<tnt> I just learned today nvidia cards paired with special g-sync monitor had a "variable refresh rate".
<tnt> I just wondered exactly how that worked on the DP link.
<tnt> (that's like ... 5 years old tech, so nothing recent, I just never knew that existed)
mumptai has quit [Remote host closed the connection]
<ZirconiumX> tnt: I'd imagine the monitor simply waits for the DP equivalent of Vsync
<ZirconiumX> I think the monitor advertises the range of refresh rates it supports, and then the GPU switches between then
<ZirconiumX> *them
craigjb has quit [Quit: ZNC 1.7.3 - https://znc.in]
craigjb has joined ##openfpga
<gruetzkopf> AMDs "Freesync" uses plain DP VFR support
<gruetzkopf> nvidia apparently does weird stuff which includes special nvidia hardware in the display
<MicroHex> indeed it does
<MicroHex> incredibly expensive in one-off FPGAs
<MicroHex> The Xilinx FPGA modules they use in G-Sync monitors would cost far more than the monitor to anyone who isn't Nvidia.
<pie_> :V
<pie_> time to start scrapping monitors
<MicroHex> $200 to start with
<MicroHex> (so maybe not more than a g-sync monitor in produciton, but yeesh)
<MicroHex> so, uh, yeah
<pie_> the real reason high end tech costs a years untaxed salary
<pie_> *high end scopes
<pie_> or is that not high enough and it needs to be more years or 400k@google
<azonenberg> pie_: pretty sure my lecroy scope has an xc7k325t in it
<azonenberg> or was it an ultrascale? let me check...
<pie_> not that it makes much of a difference to me...
<azonenberg> it was a four digit price tag chip, i know that much
Asu` has quit [Quit: Konversation terminated!]
emeb has quit [Quit: Leaving.]
<bubble_buster> anyone know what the difference between riscv-compliance and riscv-tests is?
<sorear> riscv-tests is much older
<Xark> Looks like riscv-compliance is the official one for: RISC-V Foundation Compliance Task Group