<mithro>
sb0: Any idea if this style has a "name"? It doesn't seem to be the Google or Sphinx style....
fengling has quit [Ping timeout: 240 seconds]
<sb0>
is that the numpy style, maybe?
<cr1901>
The second link suggests indeed it is numpy style
sb0 has quit [Quit: Leaving]
fengling has joined #m-labs
FelixVi has quit [Remote host closed the connection]
sb0 has joined #m-labs
<sb0>
whitequark, i don't think the current implementation of "fire and forget" RPCs will be sufficient
<sb0>
how does it work in the case of a list being RPCd? how long does it stay in the memory of the kernel CPU?
<larsc>
sb0: did you see my comments regarding disp_out
<sb0>
larsc, yup. thanks!
<larsc>
strictly speaking also only 2 of the 4 bits are affected by the alt setting, but in practice that might no matter considering how the CLBs are layed out
<sb0>
wouldn't the synthesizer optimize that?
<whitequark>
sb0: it will block until the entire thing goes into the TCP buffers.
<whitequark>
so it should be a matter of having buffers large enough.
<whitequark>
larsc: the log is down?
<sb0>
so the process is: kernel CPU writes to the mailbox register, waits for the comms CPU to copy all the data into the buffer currently in session.c, and then continues?
<whitequark>
no
<whitequark>
oh, this is just for sending RPCs
<whitequark>
yes
<sb0>
okay. how much of a penalty can the kernel CPU get, if the comms CPU is busy doing something else, e.g. filtering out windows broadcasts on the LAN?
<whitequark>
uh, I don't think we have WCET on requests to comms CPU
<sb0>
wcet?
<whitequark>
worst-case execution time
<larsc>
whitequark: it was down last night, it is back now
<sb0>
well, no, we don't, but what would a typical value be like?
<whitequark>
larsc: oh the https screwup, right
<whitequark>
sb0: I have no idea. I can try measuring it if you want.
<sb0>
ok. that's not urgent (fire and forget rpc is for the next contract which isn't set up yet), but we'll have to look into that at some point and decide how to best implement it
<larsc>
sb0: I don't think the synthesizer can deduce this since there is a register stage in between
<larsc>
with complex dependencies
<sb0>
I think synthesizers do optimize across register boundaries now. maybe not if there are complex dependencies...
<larsc>
they do simple constant propagation, but I think that's pretty much it
<larsc>
now the next step is to have a combinatorical statement and say I want N pipeline stages and let the tools work out the optimum placement
<sb0>
that works sometimes
<sb0>
you describe a comb statement, and just register the output N times
<sb0>
rjo, whitequark, I'm about to turn on a 2.7kW electric oven. that may trip the breaker and turn off the buildserver.
<whitequark>
ok
<whitequark>
did you just buy an oven for this?
<sb0>
a second-hand one
<sb0>
though the previous owner couldn't use it and it's pristine, too big I guess
<whitequark>
hm, now I want to see that setup
<sb0>
so, it works
<sb0>
but the temperature regulation isn't great
<whitequark>
oh
<sb0>
how much power can your fancy PID/solid state relay can handle?
<whitequark>
you could use my PID controller
<whitequark>
look at the relay
<whitequark>
it's the 10A, I think?
<whitequark>
well, if I remember correctly, I selected it for a load at least 3kW, so it should be able to supply that. but verify first.
<sb0>
where is it?
<whitequark>
on my desk, on the left side near the large box
<sb0>
hm, 10A
<whitequark>
that's 2.2kW
<whitequark>
hm
<sb0>
yes
<whitequark>
eh, screw it, close enough
<whitequark>
do you want me to come and configure the PID? it has a somewhat aggravating interface.
<sb0>
the built-in thermostat is a basic on-off switch with hysteresis, temperature oscillates by a dozen C
<whitequark>
pretty shitty for cooking too, to be honest
early has quit [Quit: Leaving]
early has joined #m-labs
<sb0>
re. PID configuration, no hurry, I'm going to try a first bake at low temp to get a quick feel of how this behaves, I guess the crappy thermostat is good enough for that
<whitequark>
okay.
<sb0>
regarding max current of the solid state relay, there is the ghetto solution of lowering the voltage with the variac =]
<whitequark>
or you could get a proper relay from the supplier. it is just near you.
<sb0>
ah, where?
<whitequark>
reclamation st... I have a business card and a GPS point recorded
<whitequark>
that's what, three stops on MTR from you, I think?
<sb0>
I moved to North Point now
<whitequark>
actually the business card is on my desk
<whitequark>
oh
<sb0>
but I could go there, yes
<whitequark>
it'll run you around 200 HKD, IIRC
<whitequark>
don't remember why I cheaped out and didn't get the 20A one
<whitequark>
and if you do that, show this exact relay to them, because they come in a variety of types
<whitequark>
of control inputs, that is
<sb0>
pang tai welding supply?
<whitequark>
the other business card
<sb0>
winfield auto air conditioning
<sb0>
and that's not on reclamation st
<whitequark>
no, that's not the right one either
<whitequark>
let me just find it on map
<sb0>
ha, found it
<sb0>
nam wah control equipments
<whitequark>
yes, that should be it.
<whitequark>
the one with the phone written on it in black pen ink
<whitequark>
dunno why they gave me the phone of the company director but they did
sandeepkr has quit [Read error: Connection reset by peer]
sandeepkr has joined #m-labs
<larsc>
yea
<larsc>
h
fengling has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
fengling has quit [Ping timeout: 240 seconds]
rohitksingh has joined #m-labs
sb0 has joined #m-labs
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
rohitksingh has quit [Ping timeout: 244 seconds]
rohitksingh has joined #m-labs
fengling has joined #m-labs
rohitksingh has quit [Ping timeout: 244 seconds]
fengling has quit [Ping timeout: 240 seconds]
rohitksingh has joined #m-labs
rohitksingh1 has joined #m-labs
rohitksingh has quit [Ping timeout: 265 seconds]
<sb0>
looking at how CDRs work in detail, it sounds like it should be possible to hack a spartan-6 to get 1Gbps transceivers on the regular differential IO pairs
<sb0>
well, maybe. have to do some math.
<key2>
sb0: when you have a transceiver, such as those GTP we use for PCIe, what makes them special ? the fact that they are faster IO ? or it can actually bear a modulation ?
<sb0>
faster IO, CML standard, CDR. plus a bunch of built-in cruft (elastic buffers, 8b10b, channel bonding, etc.) that some users seem to like
<sb0>
equalizers, too
<key2>
so for example, it would be possible to not use Xilinx PCIe core and redev one ourself using just GTP ?
<sb0>
pity the line rate is 2.5Gbps minimum. otherwise it'd be fun to try to run it off a lx9
sandeepkr_ has joined #m-labs
sandeepkr has quit [Read error: No route to host]
sandeepkr__ has joined #m-labs
sandeepkr_ has quit [Ping timeout: 265 seconds]
<sb0>
so, hm, for hacking a spartan6 pll into a cdr, you could switch the VCO phases at 200MHz through the DRP
<sb0>
I cannot find any doc that says whether the phase mux is glitch-free, so I'll have to be optimistic there
fengling has joined #m-labs
<sb0>
so, 5ns between PLL reconfigs, one data bit every 1ns, let's say it the sampling point should not slip by more than 0.5ns before the next PLL reconfig
<sb0>
well that should actually work
<sb0>
why is anyone using transceivers for anything below 1Gbps? :)
<whitequark>
oh, pypy got funding for py3.5
<whitequark>
maybe in a year we can run artiq on that instead of cpython
fengling has quit [Ping timeout: 240 seconds]
<whitequark>
that's a nice alternative to rewriting all the stupid shit that llvmlite does.
<sb0>
actually, even without finicky built-in PLL hacks, you can definitely do a soft CDR that drives an external VCXO
<sb0>
whitequark, how much time is spent in llvmlite again?
<whitequark>
half or something
<sb0>
we can have a mico-kasli, with a lx9
<sb0>
qfp, hand solderable
<whitequark>
this reminds me I should spin a BGA board in my next order, to see if that works with the blowtorch too
<whitequark>
you can test connectivity with JTAG, right
<sb0>
it probably will if you're lucky, people fix motherboards with paint removers
<sb0>
the heat gun thing
<whitequark>
that's actually much harder
<whitequark>
I never figured out how to use a proper (electronics rework) heat gun
<whitequark>
either I spent 20 minutes on a bord and burnt all the plastics, or charred it
<whitequark>
the blowtorch was just instant success
<whitequark>
I attribute it to a much higher airflow level
<whitequark>
possibly a shitty heat gun, too
<whitequark>
well, I guess also true of paint remover
<key2>
sb0: in fact this PCIe core from florent uses a PCIe core from xilinx, he "just" interfaces it !
<cr1901_modern>
Don't you have a rework station?
<whitequark>
yes. well, not anymore. I gave it away to someone when I moved
<sb0>
key2, no, he just uses the transceiver wrapper
<sb0>
there is not much in there.
<whitequark>
the soldering iron in it was usable but not very good compared to my hakko fx-951. the heat gun was crap to use.
<key2>
he does that for sata, not pcie
<cr1901_modern>
The transceiver wrapper is just an utter mess of autogenerated code IIRC
<whitequark>
whether it was just bad or i'm incompetent is irrelevant to whether i want to use it.
<sb0>
litesata doesn't use any xilinx wrapper
<larsc>
the series7 fpgas have hardware pcie module
<larsc>
that does part of the pcie stuff in hardware
<cr1901_modern>
I'm still thinking of my BGA options. I saw a vid yesterday where someone had success with a heat gun with 0.8mm BGA
<sb0>
that's stupid, unless that allows for bitstream loading
<larsc>
there is something called tandem loading which is similar to partial reconfig where you can have a initial bitsteam which just configures the hardware macro and bit of plumbing
<cr1901_modern>
But I'm a bit of a coward around heat guns (and I'm not sure if my wooden workbench would like it either. What's the flash point for wood?
<larsc>
that over pcie you can load the remaining parts of the bitstream
<larsc>
s/that/than
<sb0>
hm, where did I see the transceiver wrapper code?
<key2>
sb0: so he is working on a TLP level. the PCIe core from xilinx does the rest
<key2>
sb0: on the sata
<key2>
sb0: there he does the job himself I believe
<whitequark>
you definitely do not want to do it over a wooden workbench, it will be founled immediately
<larsc>
the other thing with pcie is that it is not hotplug, you have to be ready within 120ms after power-on
<whitequark>
larsc: or what?
<larsc>
or it does not wok
<whitequark>
can't you tell the controller to reconfigure the device?
<larsc>
bios scans the bus once at power-on
<whitequark>
I'm pretty sure I did this via sysfs
<whitequark>
echo 1 >/sys/class/pci/.../rescan
<whitequark>
or something
<larsc>
whitequark: you need still need to reserve slots for all cards
<larsc>
otherwise your resource mapping and allocation does not work
<sb0>
since Intel has touched PCIe, I'm almost certain they do all sorts of imbecilic out-of-band tricks at the electrical level, which will require digging out many obscure GTP parameters to implement correctly
<sb0>
yes, there is source for that in the same repos
<key2>
is it possible otherwise to dump the param from jtag
<key2>
while pcie core from xilinx is running ?
<key2>
to set them to the same config ?
<larsc>
you can read them using drp
<sb0>
maybe. and it's probably not only parameters, but also some signals you need to sequence in a certain way
<larsc>
I think the drp registers are even mapped in the axi register map of the xilinx core
<sb0>
or read the source from the xilinx wizard
sb0 has quit [Quit: Leaving]
key2 has quit [Ping timeout: 250 seconds]
<cr1901_modern>
"(2:05:11 PM) key2: the thing is that to use his litepci in an asic let say, one would need to buy a pcie core :)" What do you mean by this?