01:16 <zyp> hi, is this the right place to ask for help with migen?

01:35 <sb0> yes

01:37 <zyp> okay, let me start by saying that I'm completely new to migen, and fairly new to FPGA development in total

01:39 <zyp> I've currently written a FSM where I set some signals in some states, and want them left alone in states where I don't explicitly set them, but the generated verilog always sets them to a set of default values before the FSM case statement

01:39 <zyp> what is the proper way to achieve what I want?

01:41 <sb0> use a "load enable" signal

01:41 <sb0> self.sync += If(load_enable, target_signal.eq(some_value))

01:41 <sb0> and then fsm.act(..., load_enable.eq(1))

01:42 <zyp> that sounds roundabout

01:45 <sb0> what do you mean?

01:47 <zyp> wouldn't this also imply that load_enable gets set synchronously, and then target_signal doesn't get set until a cycle after?

01:48 <zyp> I don't see how it's a good solution for acieving what I want

01:51 <zyp> oh, right, all the statements in the FSM are combinatoric, that's what I'm doing wrong

02:00 <sb0> yes

02:52 <zyp> how do you simulate a module containing a TSTriple?

02:56 <sb0> depends what you want to do with it

02:57 <sb0> if something complicated, you should simulate before the tstriple

02:58 <sb0> tstriple is only supported for io, and there's no special handling code to use it otherwise in simulations

03:01 <zyp> I'm writing a module that interfaces a wishbone bus to an external memory bus

03:40 <GitHub151> [artiq] sbourdeauducq pushed 6 new commits to master: http://git.io/qQj0Kg

03:40 <GitHub151> artiq/master a0ea83c Sebastien Bourdeauducq: frontend/client: connection parameters

03:40 <GitHub151> artiq/master f106b23 Sebastien Bourdeauducq: pc_rpc: report exception traceback

03:40 <GitHub151> artiq/master 513aa39 Sebastien Bourdeauducq: pc_rpc: avoid 'close' name conflict in client

03:41 <GitHub3> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/iZj-cw

03:41 <GitHub3> artiq/master 3f1391f Sebastien Bourdeauducq: devices: basic pdq2 controller/client

04:44 <rjo> zyp: there are also FSM.(before|after)_(entering|leaving) that give you those enable signals or can be used ofr other neat tricks.

04:44 <rjo> s/ofr/for/

04:45 <zyp> I saw that

04:49 <zyp> I got simulation of the tristate output to work, but the input seems to always read 0

05:42 <sb0> what did you connect the tristate to?

09:27 <GitHub195> [artiq] sbourdeauducq pushed 4 new commits to master: http://git.io/wzDjPQ

09:27 <GitHub195> artiq/master 6ac3c5d Sebastien Bourdeauducq: worker: use pyon

09:27 <GitHub195> artiq/master 489bcb3 Sebastien Bourdeauducq: pyon: add bool support

09:27 <GitHub195> artiq/master ee225d5 Sebastien Bourdeauducq: pc_rpc: raise RemoteError on non-existing method RPC attempt

09:35 <GitHub156> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/z7qOhw

09:35 <GitHub156> artiq/master 47c0352 Sebastien Bourdeauducq: test/pc_rpc: tougher test for string encoding

11:27 <awallin> sb0: do you know if anyone has worked further on your tdc-core design available from ohwr? I'd like to take a look at it when I have time...

11:34 <sb0> awallin, some people at synchrotron soleil did, but I haven't had news for a while

11:35 <sb0> plus a few PET companies

11:36 <mumptai> i used it to read some ds18b20 ... if you want to call that a use (basically striped it from all its tdc-core parts and used the rest of the example)

11:37 <awallin> ok, you said earlier it might not be possible to fit in a spartan6 LX9, but I recently found the pipistrello that has the LX45 - I guess the code was developed for LX45?

11:37 <sb0> yes

11:38 <sb0> if you want to fit in lx9, you probably have to mess with low-level details of the fpga to design a more efficient delay line

11:38 <sb0> that's probably feasible, just some work

11:38 <awallin> so LM32, tdc-core, and some ethernet interface should fit in the LX45? that could make a nice hobby-level tdc..

11:38 <sb0> yes, that should definitely work

11:39 <sb0> this is not opencores or some "area doesn't matter" academic team

11:39 <mumptai> didn't it kind of expect the slices of the delay elements to be in a stright like in the fpgas fabric?

11:39 <sb0> yes, it uses a carry chain that must fit in a single device column

11:40 <sb0> but you can replace it with LUTs/routing

11:40 <awallin> sorry I don't follow your "area doesn't matter comment" ?

11:41 <sb0> only you have to do all the P&R manually, which will hurt a bit

11:41 <sb0> awallin, most academic FPGA designs are unusable in practice because they're only interested in theoretical results or asic simulations running in the fpgas

11:42 <mumptai> and might want to find a way to characterise the tdc steps afterwards

11:43 <awallin> oh ok, well I am interested in real measurements and real performance :) if the analog front-end can be kept simple then the pipistrello-board + a 'wing' with the front-end and ethernet interface could make for a quite economical time-itnerval-counter

11:44 <sb0> the tdc core will measure that for you, and you can readback the size of each bin using the debug interface

11:45 <awallin> the commercial ones are specified at 20 or 20 ps RMS (agilent/keysight, srs) - so that's the target :)

11:45 <awallin> eh, 20ps for keysight, 25ps for SRS

11:45 <sb0> that's the good ones... it's more like 100ps on a number of them

11:46 <awallin> so the coarse-counter in tdc-core is at 125MHz, and the interpolator has around 8ns range?

11:47 <sb0> to reach to reach 20ps on the s6, I'd 1) improve the processing of the delay line snapshot - right now it just stops at the first bit transition detected, but there seems to be a noise zone before all taps readback the same value

11:48 <sb0> you may want to take the center/average of that noise

11:48 <sb0> 2) check/shield the board signals carefully for noise sources

11:50 <awallin> ok, thanks for the tips. then there's the wave-union idea, and perhaps also using multiple delay-lines for the same signal and averaging (if there's space on the fpga)

11:50 <sb0> and make sure that your input signal transitions fast

11:50 <sb0> yes, that too

11:51 <sb0> but averaging the noise zone sounds easier and with lower FPGA resource usage than the other options, so I'd try that first

11:55 <awallin> ok - I'll let you know here if I make some progress..

11:55 <awallin> it will take a few months I am sure :) this is a hobby project

11:56 <mumptai> i'd check the io-banks powersupply and what else it used by too

11:56 <awallin> huh?

11:58 <mumptai> noise on the input and the supply of the the io-bank will result in jitter

11:59 <awallin> ok. is there a separate supply-pin for the i/o banks on the fpga? given the BGA-package it doesn't seem likely I'd make my own pcb for the fpga..

11:59 <mumptai> i would avoid using the same io bank for sampling and e.g. a memory interface

12:00 <mumptai> or anything with a lot of simluataneous switching pins, especially single-ended signals

12:01 <awallin> is there a difference in jitter btw. single-ended and differential? should the tdc inputs be differential (lvds?)

12:02 <sb0> yes

12:03 <mumptai> differenential signals will help (a lot), but this is a thing which is hard to predict without a good model of the electronics involved

12:03 <sb0> if receiving a single ended signal, you should add a good analog comparator with LVDS output

12:03 <awallin> on the dio FMC-card they used ADCMP604 on the inputs

12:06 <awallin> so I guess my first try will be two single-ended inputs that go to two ADCMP604, and those LVDS signals to two tdc-channels on the pipistrello - hopefully that will make a decent start for the project

12:21 <awallin> mumptai, sb0: thanks for these comments, I'll be back later if/when there is progress!

15:03 <sb0> rjo, I don't quite get what Rabi oscillations are. I thought photon absorption and reemission were random - now suddenly they are periodic and have a frequency? or is the Rabi frequency the mean frequency?

15:17 <sb0> it seems that you get this result when you consider that the light is not made of photon but is a classical electromagnetic field that you then inject into the hamiltonian - but how do you choose between doing that and the photon model?

17:37 <awallin> I think not just any old photons will do to get rabi-oscillations, it needs to be coherent laser light (so the next question is define 'coherent'...)

17:39 <awallin> the rabi frequency relates to the 'flopping' of your atomic system between a ground-state and the excited state. it's not a property of the photon/EM-field