lekernel changed the topic of #m-labs to: Mixxeo, Migen, MiSoC & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
mumptai has quit [Quit: Verlassend]
<rjo>
mumptai: or even latch-down...
sb0 has joined #m-labs
<sb0>
rjo, I'm still looking into lm32 support... that would save even more LUTs, and clean up the ISA/ABI
<sb0>
rjo, by the way, the phase tracking computation is just ptw = ftw*fud_time_in_sysclk_cycles mod 2**32, right?
<sb0>
for ad9858 at least, haven't looked closely at the new one yet...
aeris has quit [Ping timeout: 245 seconds]
aeris has joined #m-labs
xiangfu has joined #m-labs
sb0 has quit [Quit: Leaving]
xiangfu has quit [Ping timeout: 258 seconds]
xiangfu has joined #m-labs
<rjo>
sb0: POW on the AD9858 is only 14 bits iirc, so divide that by 2**18.
<rjo>
sb0: you want to clean up the lm32 isa/abi? like overflow handling and such?
<rjo>
sb0: re POW, i always wondered if it would be nice/helpful/necessary from an experimentalist point of view to set the time zero for phase to something more sensible than the beginning of the experiment.
<rjo>
sb0: nice reasonably short hostname you have there from ctinets. i noticed that Deutsche Telekom is generating PTRs for their IP6 space that are _much_ longer than the ipv6 address itself...
<rjo>
sb0: re fusion for everyone: the decisive difference is that one is impractical and the other one impossible ;)
<rjo>
and we will speak again when in a few years everybody will have an good atomic clock (cold neutrals/BEC or ion based) in their pockets for inertial navigation ;)
xiangfu has quit [Ping timeout: 244 seconds]
xiangfu has joined #m-labs
fengling has joined #m-labs
sb0_ has joined #m-labs
<sb0_>
rjo: well, fusion does happen, just not with a positive energy balance ;)
<sb0_>
what's your take on ITER, NIF, W7X, etc.?
<rjo>
sb0_: beautiful tech and physics. and if energy comes out of it one day, even better.
<rjo>
sb0_: but i have no idea when.
<sb0_>
regarding ISA/ABI cleanup, what I meant is that LM32 does not have the OR1K idiosyncrasies (flags, delay slot, weird exception addresses, weird register numbers for passing function parameters, etc.)
<sb0_>
unlike OR1K, LM32 does not support overflow exceptions. do we want them?
<sb0_>
they are useful in some cases, in others - such as computing the POW - the wraparound can be put to good use...
<rjo>
sb0_: i don't know CPU design. no idea how (often/easily) compilers make use of them.
<sb0_>
most compilers don't, and the overflow exception is something for the user to deal with...
<sb0_>
at a low level
<rjo>
sb0_: just held joe's hand through getting a virtual machine with a dev env set up.
<rjo>
sb0_: i suspect he will be writing more bug reports and will certainly make the installation readme more verbose.
<sb0_>
if we really want to match the Python semantics (Python has bigints and so overflows never occur), we can enable the overflow exception whenever a kernel is executed, and raise a Python exception to tell the user that the code is not executing as it should
<sb0_>
but I'm not sure if it's worth bothering with this detail
<sb0_>
additionally, I think stuff like 64-bit additions make use of the overflow
<rjo>
sb0_: i remember following the denormals topic for jackd (rt audio). there, FP denormals (nan, inf, div-by-zero depending on the fpu flags) caused funny glitches due to longer computation times for those audio-denormals....
<sb0_>
so we'd have to disable and re-enable the exception everytime, which will slow down things, and they're not already not that fast as I understand
<rjo>
i would not bother with matching python bigints. 64 bit ints are good enough.
<rjo>
what 64-bit additions? those from the lm32-crt?
<sb0_>
llvm doesn't call the crt for those but directly inserts the arithmetic code in-place. but yes
xiangfu has quit [Ping timeout: 244 seconds]
<sb0_>
how did the setup go for Joe? it seems ysionneau didn't trip too much...
<rjo>
if you add all the "typical windows/mac user" problems together...
xiangfu has joined #m-labs
<sb0_>
like what?
<rjo>
hmm. concept of a umask (NIST sets umask 027, which kills sudo make install), "editor", environment variables, xilinx ise/vivado installation, sourcing their settings. /dev/ttyUSB* permissions, difference to /dev/bus/usb device permissions
<sb0_>
ise installation is a pain for everyone afaict. especially when you need to debug license problems with strace...
<sb0_>
ok, let's add info about how the flash proxy bitstream works in the doc
<rjo>
sb0_: good thing that you can use a mac address of "00:00:00:00:00:00" on a VM if you want to ;)
<rjo>
i believe he is about to do that. also MSCDIR
<sb0_>
that assumes that the flexlm crippleware can find the mac address at all...
<rjo>
sb0_: yes.
<rjo>
but i have seen it prefer some tun/tap interface over a physical interface. that may help ;)
<sb0_>
rjo: how many DDS reprogrammings do you need, and in what time?
<rjo>
peak rate?
<sb0_>
and is there any decision regarding clock syncing?
<sb0_>
if we put the DDS programmer on RTIO, yes, we can max out the bus as long as the FIFO isn't empty...
<sb0_>
the next question is how large that FIFO should be
<rjo>
sb0_: afaict there will not be a way to do clock syncing in the near future.
<sb0_>
and if the peak rate is always below ~1MHz, it sounds the current software solution would be good enough...
<rjo>
sb0_: same size as RT-GPIO should do it.
fengling has quit [Ping timeout: 244 seconds]
fengling has joined #m-labs
<rjo>
sb0_: as i mentioned. a use case would be two back-to-back dds pulses with a phase shift in between. and we have done dds pulses as short as ~40ns (with lots of hackery and additional devices).
<sb0_>
rjo: what about rough clock syncing?
<sb0_>
bring all clocks within 1ns of each other
<rjo>
sb0_: by length matching and synchronous reset?
<sb0_>
rjo: if the RF switch is off at the beginning, the current software can already do two back-to-back DDS pulses of a few dozen ns with a phase switch in the middle
<rjo>
for some applications we want to do the same as NMR: what you find if you do a google image search for "NMR pulse sequence".
<sb0_>
program phase #1, FUD, program phase #2, turn on RF switch, FUD, turn off RF switch
<sb0_>
the last 3 operations are RT-GPIO
<rjo>
yes. then three back-to-back pulses ;P
<sb0_>
rjo: yes, or by having the FPGA scan the reset phase for each DDS chip individually, until it detects that its return clock has the same phase (within the RTIO resolution) as the others
<sb0_>
if you put a mux for the return clock in the DDS box, the length matching requirements are minimal
<rjo>
as a timescale for those pulse lengths in the images, assume ~100ns (with 37ns being the lowest that we ever did).
<rjo>
sb0_: i agree. in the discussion that seemed to be too complicated/error-prone.
<sb0_>
we can even try syncing them to one 3.5GHz clock with some FPGA hackery
<rjo>
page 18, now assume a short T2 (or a long one but you still want to scan at short free evolution times). and assume that we want to change the phase of the echo pulse (the pi-pulse in the middle).
<rjo>
this is afaict a real nmr system (very short pulses) but the issue is the same.
<rjo>
we would like to do "X_pi/2, T2, Y_pi, T2, X_pi/2" sequences with X_pi/2 meaning a ~100ns pulse with phase 0, T2 a variable but possibly short (<100ns) evolution, Y_pi a 2*100ns pulse with 180deg phase shift.
<rjo>
the phase is the axis around which you flip your qubit, the duration (times intensity) of the pulse is the angle how far you rotate.
<rjo>
after all that we do a projective measurement (up _or_ down).
<rjo>
sb0_: i gathered that there will not be an integrated return for any synclk.
<rjo>
in that pulse sequence you have to program the phase within 300ns (Y_pi + T2) before the last X_pi/2 pulse.
<rjo>
sb0_: the 100 MBps in the datasheet are Mbytes/s, how do you get "~80 ns for a 8-bit word"?
sb0_ has joined #m-labs
<sb0_>
ah, I thought it was Mbit
<sb0_>
I read "The serial mode supports data rates of up to 80 Mbps." and assumed they used the same unit previously
<sb0_>
so it's actually 10ns, close to the "minimum write time" in table 13
<sb0_>
Joe's computation is incorrect too
<sb0_>
rjo: regarding clock syncing: if the jitter is low enough (below the unspecified reset setup/hold time at 3.5GHz) I think ODELAY for the reset and delay-line TDC for the clock feedback would work
<sb0_>
or hack a pair of transceivers into TDC/DTC
<rjo>
sb0_: yes. would be too easy if AD datasheets were consistent ;)
<rjo>
there is this weird appnote about doing idelay clock tracking for a makeshift clock-less serdes.
<rjo>
oversampling based tracking.
sb0_ has quit [Ping timeout: 246 seconds]
<rjo>
sb0_: i agree it sounds possible to do that with a low jitter synclk mux.
<rjo>
but i think you need to match reset to fud length for each dds and matched synclk returns (both to within the fud timing requirements)
<rjo>
sb0: is "your internet" broken? ;)
nengel has quit [Ping timeout: 255 seconds]
nengel has joined #m-labs
FabM has quit [Quit: ChatZilla 0.9.91 [Iceweasel 31.1.0/20140903072827]]
<rjo>
sb0: why not make compiler-rt a submodule of misoc as well?
FabM has joined #m-labs
<ysionneau>
we would need to import it into a git repository before that, wouldn't we?
<ysionneau>
I think it's SVN tracked
<ysionneau>
then we get the burden of keeping our git copy in sync with upstream svn
<rjo>
i always forget about their presence and how to use them...
<ysionneau>
yes it's easy to forget to fetch them but they are very nice tools to do very precise dependency version tracking on source code
<zyp>
I agree, submodules is a nice way to ensure that you can still build old versions of a project even if they rely on dependencies with a not completely stable API
xiangfu has quit [Remote host closed the connection]
<sb0>
what determines the synclk phase is when the reset was sent wrt sysclk, no?
<sb0>
the timing requirements on fud are also much relaxed, as it is synchronous to synclk...
<sb0>
the only thing that really needs to be matched tightly is synclks to mux
<sb0>
the fpga can scan the reset timing similarly to DDR3 write leveling
<sb0>
and this will absorb any reset line length mismatch
<sb0>
fud will perhaps need some length matching too, but the tolerance is one order of magnitude above synclk to mux
<sb0>
I guess the whole point of synclk is this relaxed timing requirement
sh4rm4 has quit [Remote host closed the connection]
sh4rm4 has joined #m-labs
sb0 has quit [Ping timeout: 265 seconds]
<rjo>
sb0: if fud has arbitrary length you have no idea when it arrives relative to synclk and you can not meet fud-to-synclk timing.
<rjo>
as i said. you need to mach reset to fud to within the sunclk-to-fud timing.
* mumptai
..ooOO( fud can't be fear, unvertainty and doubt )
<rjo>
one thing tat needs to be ensured is that the address decoders for fud and reset need to be the same/matched or there need to be individual fuds.
<rjo>
fear of not meeting timing requirements, uncertainty about the real timing reqs, doubt that the reqs can be met.