talsit has joined ##openfpga
manderbr1t is now known as manderbrot
promach has joined ##openfpga
<rqou> offtopic: i want to heat something in the microwave, but i can't because our apartment is already at max power
Lord_Nightmare has quit [Ping timeout: 260 seconds]
Lord_Nightmare has joined ##openfpga
kuldeep has quit [Read error: Connection reset by peer]
kuldeep has joined ##openfpga
kuldeep has quit [Read error: Connection reset by peer]
kuldeep has joined ##openfpga
amclain has quit [Quit: Leaving]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 260 seconds]
Lord_Nightmare has joined ##openfpga
digshadow has quit [Quit: Leaving.]
Lord_Nightmare has quit [Ping timeout: 255 seconds]
Lord_Nightmare has joined ##openfpga
Hootch has joined ##openfpga
azonenberg_work has quit [Ping timeout: 240 seconds]
azonenberg_work has joined ##openfpga
digshadow has joined ##openfpga
promach has quit [Quit: Leaving]
kuldeep_ has joined ##openfpga
kuldeep has quit [Ping timeout: 240 seconds]
kuldeep_ has quit [Ping timeout: 260 seconds]
kuldeep has joined ##openfpga
kuldeep has quit [Ping timeout: 260 seconds]
kuldeep has joined ##openfpga
<rqou> arrgh, ubuntu'
<rqou> ubuntu's software is ancient
<azonenberg> rqou: lol
<azonenberg> not complaining about debian? :p
<rqou> i run sid :P
<rqou> fortunately the particular piece of software i was having problems with was qemu-user-static
<rqou> note the -static
<rqou> i can just say "f*ck it" and steal sid's version
<rqou> in other news, apparently the ip diffserv to pfifo_fast mapping is borked in linux right now
<rqou> housemates were not happy that crashplan was inducing lag while playing Overwatch :P
<azonenberg> and here i am still running jessie
<azonenberg> upgrading to stretch once it's officially released
kuldeep_ has joined ##openfpga
kuldeep has quit [Ping timeout: 255 seconds]
<rqou> stretch is being released soon, isn't it?
<azonenberg> They froze earlier this month
<azonenberg> i expect to see beta installers shortly
<azonenberg> release maybe march-april?
<azonenberg> sorry i meant april-may
<azonenberg> i mean its probably more than safe to upgrade now
<azonenberg> but i have a policy of running stable
<azonenberg> and then building from bleeding-edge or recent released source for specific things (e.g. yosys) if i need a current version
<rqou> do you not usually get stable->stable upgrade breakage?
<rqou> i specifically went to rolling-release because i got sick and tired of that
<azonenberg> it rarely breaks things for me
<azonenberg> and i'd rather have thing break during a planned upgrade cycle
<azonenberg> than break at random unpredictable times
<azonenberg> when i install patches i dont want to worry about something changing under me
<rqou> hmm interesting
<rqou> my setups always seem to be sufficiently weird that i get major breakages all the time
<azonenberg> lol
<azonenberg> b/c stable-stable upgrade is officially supported and should Just Work (tm)
<rqou> and breakage (for ubuntu) would be in april or october
<rqou> e.g. "middle of the semester crunch time"
<azonenberg> ubuntu is based on debian unstable :p
<azonenberg> also, you dont have to upgrade right away
<azonenberg> i often put off upgrades until i have time as the old stable still gets patches for a year or so with debian
<azonenberg> maybe more
<azonenberg> i forget
<rqou> so what ended up happening was that i would defer upgrades until after finals
<rqou> and then i would say "f*ck it, i finished finals; i'm not doing sysadmin-ing"
<rqou> and then it would be deferred until EOL
<rqou> :P
<azonenberg> lol
<azonenberg> You remind me, i still have two or three boxen on debian 7
<azonenberg> that i should upgrade at some point
<azonenberg> a vm, a beaglebone, and a vps
<rqou> worst upgrade so far was ubuntu 14.04->16.04
<rqou> where i suddenly got "this systemd thingy" without a single mention in the release notes
<azonenberg> lol
<azonenberg> yes systemd is a nightmare that should never have existed
<azonenberg> the transition to it a) should not have happened and b) was pretty much unavoidably going to be painful
<rqou> i would care as much if they actually pretended to have a transition plan at all
<rqou> *wouldn't
<rqou> great, i have a systemd problem again
<cr1901_modern> If systemd if necessary for this complicated world going forward (I mean, sysadmins praise not having to use shell scripts anymore) we're so utterly fucked. Same with containers.
<rqou> containers seem to work fine for me
<rqou> i have no idea what advantages systemd gained me though
<rqou> from my perspective, none at all
<azonenberg> yeah same here
<azonenberg> init worked
<azonenberg> it had problems, and should have been replaced eventually
<azonenberg> but not with systemd :p
<rqou> but afaik systemd doesn't actually "fix" any problems
<cr1901_modern> But not with that monstrosity that consumes all
<rqou> it just makes race windows smaller
<cr1901_modern> But parallel startup/boot times are so important!!11
<rqou> dalias seems to feel that startup/boot times are important
<rqou> i personally don't care too much
<cr1901_modern> <troll?>We're never going to have low boot times again. SSDs were the last great speedup were going to get.</troll?>
<rqou> imho boot times are amortized by only having to reboot like twice a month
<azonenberg> yeah i reboot a few times a year to push out the kernel patches i've been deferring
<azonenberg> twice a month???
<rqou> sid
<rqou> :P
<azonenberg> i reboot more like once a quarter
<azonenberg> lol
<azonenberg> if that
<cr1901_modern> Acknowledge that adding layers for user convenience has tradeoffs elsewhere
<rqou> although one of my housemates pointed out that the most disappointing boot times have got to be android
<azonenberg> lolol
<azonenberg> yes
<azonenberg> that's awful
<rqou> on a flagship (nexus/pixel)
<rqou> it takes longer to boot than a whitebox PC
<rqou> to boot into WIndows
<azonenberg> Does android use systemd out of curiosity?
<azonenberg> i havent looked at the boot chain recently
<rqou> i have no idea
<cr1901_modern> Honestly, my software philosophy can glibly be summed up as: "Layers are bad. All abstractions are leaky. Thus abstractions aren't all that useful b/c most of your cognitive bandwidth will be spent where leaks happen and interact."
<rqou> i have no idea how "anything that interacts with the user" is constructed nowadays
<rqou> whenever i try to file bugs about it it gets ignored
<rqou> afaik because i'm "not in the loop enough"
<rqou> lool
<azonenberg> cr1901_modern: this is kinda where the exokernel comes in
<cr1901_modern> azonenberg: I'm still trying to wrap my head around getting rid of interrupts tho :P.
<cr1901_modern> This is mainly personal reasons tho
<azonenberg> when was the last time you used interrupts in a linux c program?
<azonenberg> you just call read(2) on a file descriptor and wait for stuff to come back
<azonenberg> what happens under the hood is not your problem
<cr1901_modern> I mean, read(2) will eventually can an interrupt :)
<azonenberg> In linux, yes
<azonenberg> but there's no inherent reason for that API to use it
<azonenberg> its just the most efficient way to do it on x86
<cr1901_modern> It's either polling or interrupts at the CPU level, correct? In antikernel you just delegate the polling to gateware, right?
<azonenberg> its not polling
<azonenberg> it's message passing
<azonenberg> the hardware sends a message when something happens
<cr1901_modern> it gets stuck in a queue somewhere
<azonenberg> Yeah
<cr1901_modern> CPU reads queue
<azonenberg> then the cpu will be executing other threads (or sleeping, if nothing is runnable) while waiting for it to come back
<azonenberg> once the message shows up, it wakes up your thread
<azonenberg> and you can see if this is the message you were expecting or something unrelated
<azonenberg> if something unrelated, shove it in a buffer and go back to sleep until another message arrives
<azonenberg> if it's the one you're waiting for, process it then do whatever stuff you need to do, maybe send more messages
<azonenberg> and go back to sleep
<cr1901_modern> The sleep wakeup b/c "something's in the queue" is... an interrupt tho? I mean, it's a single signal that tells the CPU "hey something external happened! Attention required". >>
<azonenberg> It's not an interrupt in the classical sense b/c the cpu doesnt jump to an ISR or anything
<azonenberg> it just sets a bit in the scheduler that says "you can now consider thread #42 for execution"
<azonenberg> then the next context switch (or several later, depending on priority etc) your thread runs
<cr1901_modern> I see
<azonenberg> bearing in mind the context switching is a single cycle hardware operation
<azonenberg> all you're doing is writing one bit to a register somewhere
<azonenberg> and everything keeps on running like normal until the end of the current time quantum
<azonenberg> In my current prototype Tq = 1 clock
<azonenberg> but that is likely to change in the future
<azonenberg> my next cpu will be true hyperthreading and allow one thread to monopolize the cpu for the duration of its time slice
<azonenberg> rather than forcing 1/8 utilization which kills performance if you dont have 7 other active thread
<azonenberg> s
<cr1901_modern> Well, as long as it isn't polling then I suppose it doesn't bother me (other than for personal reasons that don't really matter for getting a product to market)
<azonenberg> Yeah it definitely is not polling
<azonenberg> i mean it kinda-sorta is from userspace, if you consider blocking/nonblocking io to be polling :p
<azonenberg> nonblocking: check for message, if not ready then go do something else
<azonenberg> blocking: check for message, if not ready then sleep
<azonenberg> but in either case you don't query in a tight loop
<azonenberg> you query once then sleep or go do something else
<cr1901_modern> nonblocking can ultimately result in wasting energy if nothing's ready :P (unless you manually sleep in that case)
<azonenberg> Well yeah
<azonenberg> the assumption is that you have other work to do
<azonenberg> If you have nothing to do, you'd send a message to a timer peripheral saying "wake me up in X ms"
<azonenberg> then block until a message arrives
<azonenberg> which is either the timer or somebody else with new data for you to crunch
<cr1901_modern> I thought Saratoga was superscalar?
<azonenberg> Yes, it issued two instructions from one thread per clock
<cr1901_modern> what's the difference between that and hyperthreaded?
<cr1901_modern> Oh
<azonenberg> a barrel processor (which is what saratoga is) issues N instructions from one thread on the first clock
<azonenberg> then N from another thread the next clock
<azonenberg> and so on
<azonenberg> With the restriction that you can never have more than one pipeline stage executing a given thread at once
<azonenberg> this lets you cut out most of the pipeline hazard checks you'd have in a conventional cpu
<cr1901_modern> What happens if theres a data dependency between the N instructions issued for a given thread?
<azonenberg> Then the scheduler issues <N
<azonenberg> and fills the empty stages with nops
<azonenberg> this check is done statically during instruction decode time
<azonenberg> basically just if insB.rs == insA.rd || insB.rt == insA.rd
<azonenberg> then skip it
<cr1901_modern> I see... fair. Is there any other way to handle it (for say a conventional superscalar?)
<cr1901_modern> conventional == not barrell :P
<azonenberg> register renaming, out of order, etc
<azonenberg> in a strict in-order processor, not really
<azonenberg> anyway
<cr1901_modern> let's assume in order
<azonenberg> so the diff between barrel and hyperthreading
<azonenberg> is that HT allows consecutive insns to be from the same thread
<azonenberg> and switches on a longer time scale
<azonenberg> typically either when you block on a cache miss/io operation or when a timer elapses
<cr1901_modern> which means you must add back the traditional hazard-checking hw
<azonenberg> Yeah
<azonenberg> But it also means you can run a handful of threads efficiently
* cr1901_modern doesn't blame you for not impl it yet tho :P
<azonenberg> you still get best utilization with >1
<cr1901_modern> >1 what?
<azonenberg> active thread
<azonenberg> since if you have nothing to switch to when you block you're wasting time
<azonenberg> but you can run one heavy thread and a few light ones more efficiently on HT than on a barrel
kuldeep__ has joined ##openfpga
<rqou> hmm, crashplan probably doesn't appreciate the large number of .CR2 and .vmdk files i have :P
kuldeep_ has quit [Ping timeout: 260 seconds]
Bike has quit [Quit: sleep now though]
pie__ has quit [Ping timeout: 240 seconds]
kuldeep_ has joined ##openfpga
kuldeep__ has quit [Ping timeout: 260 seconds]
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 240 seconds]
<rqou> gaaah i thought multilib was supposed to just WORK
<rqou> why is everything conflicting with everything?
<rah> rqou: to make it Interesting for you
<rah> where would be the fun if it all just worked?
<rqou> maybe it works if you're not doing the particular unholy union i'm trying to do here
<rah> that'll be it; it's punishment from The Great Moral Authority
<rqou> so you know how debian tells people not to make franken-debians?
<rqou> i'm currently making a franken-raspbian
<rqou> even better
<rah> hmm
<rah> good luck with that :-)
<rqou> so it's double-frankensteined
kuldeep__ has joined ##openfpga
kuldeep_ has quit [Ping timeout: 255 seconds]
kuldeep has joined ##openfpga
kuldeep__ has quit [Ping timeout: 240 seconds]
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 268 seconds]
rah has quit [Killed (Sigyn (Spam is off topic on freenode.))]
rah has joined ##openfpga
massi has joined ##openfpga
pie_ has joined ##openfpga
kuldeep_ has joined ##openfpga
kuldeep has quit [Ping timeout: 240 seconds]
kuldeep has joined ##openfpga
kuldeep_ has quit [Ping timeout: 240 seconds]
pie_ has quit [Ping timeout: 268 seconds]
kuldeep_ has joined ##openfpga
kuldeep has quit [Ping timeout: 240 seconds]
kuldeep__ has joined ##openfpga
kuldeep_ has quit [Ping timeout: 255 seconds]
<rqou> azonenberg: is there a way to make the openfpga build system NOT try to run tests?
<whitequark> it's an open bug
<nats`> ctrl-C ? :D
<rqou> i f*cking hate build systems
kuldeep_ has joined ##openfpga
<rqou> i mean, there's always the "comment out the tests in the makefile" solution
<rqou> oh whitequark i'm curious how you feel about my nesting vs your nesting :P
<whitequark> rqou: you just don't know how to cook them :p
kuldeep_ has quit [Read error: Connection reset by peer]
kuldeep__ has quit [Ping timeout: 240 seconds]
<rqou> also yosys builds really slow
<whitequark> apt-get install berkeley-abc
kuldeep_ has joined ##openfpga
<whitequark> don't let it build abc
<whitequark> kinda
<rqou> i mean, it's reasonable if i throw -j20 at it :P
kuldeep__ has joined ##openfpga
kuldeep_ has quit [Read error: Connection reset by peer]
kuldeep__ has quit [Remote host closed the connection]
kuldeep has joined ##openfpga
kuldeep_ has joined ##openfpga
kuldeep has quit [Ping timeout: 240 seconds]
kuldeep_ has quit [Read error: Connection reset by peer]
kuldeep_ has joined ##openfpga
<openfpga-github> [openfpga] rqou opened issue #65: Enumerate build-time/runtime dependencies https://git.io/vyJGt
<openfpga-github> [openfpga] whitequark commented on issue #65: More like get an actual README https://git.io/vyJGO
pie_ has joined ##openfpga
<openfpga-github> [openfpga] rqou opened issue #66: Incorrectly claims docs will be built when passing -DBUILD_DOCS=off https://git.io/vyJ0u
<openfpga-github> [yosys] azonenberg pushed 11 new commits to master: https://git.io/vyJML
<openfpga-github> yosys/master 34d4e72 Clifford Wolf: Added SystemVerilog support for ++ and --
<openfpga-github> yosys/master d25b6a7 Clifford Wolf: Update ABC to hg rev 8da4dc435b9f
<openfpga-github> yosys/master 242c5f0 Clifford Wolf: Add "yosys-smtbmc -S <opt>"
Bike has joined ##openfpga
kuldeep_ has quit [Read error: Connection reset by peer]
kuldeep_ has joined ##openfpga
amclain has joined ##openfpga
<rqou> arrgh i hate cmake
laintoo has quit [Ping timeout: 268 seconds]
<whitequark> what now?
<rqou> hacking up somebody's cmakefile to do what i want
<rqou> anyone got a quick example for the ice40 hx8k eval board (NOT the icestick)?
<whitequark> sure
<whitequark> what sort of files do you need
massi has quit [Remote host closed the connection]
<rqou> whatever blinks leds and requires the least amount of effort on my part :P
<whitequark> no i mean
<whitequark> .v or .txt or
<rqou> er, a verilog file
<rqou> that goes through the yosys+arachne-pnr+icestorm flow
<whitequark> okay sec
<whitequark> note I haven't actually tested this because I left the board in another country
<whitequark> but it's extracted from my true and tested build system
<rqou> you code had a bug, but otherwise it works, thanks
<rqou> your existing code blinks with a duty cycle of 1/2^24 :P
<nats`> almost done my meta board azonenberg :)
<whitequark> rqou: oh
<whitequark> that was the only part I wrote from scratch
digshadow has quit [Quit: Leaving.]
laintoo has joined ##openfpga
<azonenberg> nats`: :)
<nats`> I'm talking with an analog expert about the sampling part which will be an other board because it's really WAY FUCKING HARDER
<azonenberg> Well yeah
<azonenberg> to do it right you need jitter down in the tens of ps or less
<azonenberg> Single digit ideally
<nats`> azonenberg that's even more harder
<nats`> because basically with no trick you need things like 20GHz TH amplifier
<nats`> like INPHI or HIttite crap
<nats`> and all the design coming with it
<azonenberg> lol well yeah if you have a signal coming in that isnt ready to digitize directly
<azonenberg> you're gonna have fuuun
<azonenberg> even just for a 1:1 buffer 20 GHz gbp
<nats`> yep and basically you need a really slow ADC with a fucking huge BW
<nats`> because high speed adc = pipeline = crappy jitter
<nats`> and undertermined trigger to sample time
<nats`> so it exist some smart trick used especially by tektronix in 90's to make all the communication analyzer
<azonenberg> Use a comparator and DAC
<azonenberg> Since you're doing equivalent time sampling anyway
<azonenberg> actually if you want to cheat a bit
<azonenberg> you can probably find a stupid low jitter comparator
<nats`> we are talking about 10 ps jitter :p
<nats`> eache element shouldn't not add more than that
<nats`> don't forget even powering will add amplitude modulation which will add jitter too
<azonenberg> Yeah
<azonenberg> i've successfully used this approach at 1.2 GSa/s and i think it will scale to at least 5 without a ton of trouble
<azonenberg> but getting higher will be tricky
<azonenberg> The MAX9601 is 500 ps propagation delay, 30 ps dispersion, 10 ps skew
<azonenberg> 300 fs jitter
<nats`> I know those pretty well :)
<nats`> but what ADC do you use behind ?
<nats`> you need an ADC with an external trigger/clock system and with an aperture of like 100 or 200ps max
<azonenberg> So you could plausibly get 20 GSa/s if you can keep the overall jitter to say 50 ps
<azonenberg> No, you dont need an ADC :)
<azonenberg> You need a comparator and a DAC
<azonenberg> Set DAC to 0x00
<nats`> ah I see what you mean
<azonenberg> sample the comparator every ns using a PLL to drive the latch
<azonenberg> Then set DAC to 0x01
<azonenberg> repeat
<nats`> it's ok but not for what I want to do
<azonenberg> then phase shift your sample and trigger clocks by 50 ps
<azonenberg> and do it again
<azonenberg> This is what i did for my TDR
<nats`> but with a si5338 it should be ok to 10GHz equivalent BW
<azonenberg> Except with real-time sampling of the comparator
<azonenberg> the only equivalent-time step was jumping the DAC
<azonenberg> So i topped out at 1.25 GSa/s b/c that was the limit for the kintex iob
<nats`> you mean kintex IOB can have such small delay step ?
<azonenberg> The kintex IOB is 1.25 Gbps max in LVDS RX mode
<azonenberg> the delay line on the IOB is about 39 ps per tap with a 400 MHz reference clock but there's also 5 ps of pattern-dependent jitter and i dont know if it stacks as you go to more taps
<azonenberg> my bigger concern would actually be jitter from the FPGA PLL if i was trying to sample faster
<azonenberg> This is why my plan was to use an external PLL chip and a max9601
<azonenberg> so i could latch the comparator with that clock
<azonenberg> then sample with the FPGA a short time later
<azonenberg> and a bit of jitter wouldnt matter as the latch output is stable
<azonenberg> and the comparator was clocked directly by the stupid-low-jitter pll
<nats`> [21:19:27] <nats`> in your case it's slightly different
<nats`> [21:19:42] <nats`> in the case of a sampling scope you take an external clock as a time base
<nats`> [21:19:47] * Disconnected
<nats`> usually you need a cdr if you don't have it
<azonenberg> In my case i mostly wanted to do eye measurements
<nats`> yep it's the same goal
<azonenberg> So my plan was to have the PRBS generated from the same PLL as my sampling
<nats`> but on a sampling scope you have a few more option
<nats`> sure
<azonenberg> at a lower speed
<nats`> that's the usual way to do it
<azonenberg> so say a 1 Gbps PRBS sampling at 20 GSa/s
<nats`> in my case the only difference is the external clock
<nats`> it basically reset the timebase counter
<nats`> and regularly you sample at previous_time + 1
<nats`> time behind relative to that external trigger
<nats`> -behind +being
<azonenberg> yeah my plan was to just have it be an end to end unit
<azonenberg> SMA out, SMA in
<nats`> yep :)
<nats`> anyway with the first board I'll be able to do testing using my real sampling scope :)
<azonenberg> :)
<nats`> I'll make a tiny diagram of expected setup :)
<openfpga-github> [openfpga] azonenberg commented on issue #63: Actually a Yosys bug. Fixed in cliffordwolf/yosys:cf25dc9 https://git.io/vyU0k
<openfpga-github> [openfpga] azonenberg closed issue #37: Figure out constraint file or other way to support LOC constraints on vector top-level ports https://git.io/vyU0s
kuldeep__ has joined ##openfpga
kuldeep_ has quit [Remote host closed the connection]
pie_ has quit [Ping timeout: 240 seconds]
pie_ has joined ##openfpga
<openfpga-github> [openfpga] rqou opened issue #67: gp4prog needs a codeless kext on macOS https://git.io/vyUa9
Hootch has quit [Read error: Connection reset by peer]
ZipCPU|Laptop has joined ##openfpga