<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
<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]