specify frequencies consistently in DDB

[sbourdeauducq]

Currently:

        "class": "Core",
        "arguments": {"ref_period": 1e-9}

        "class": "CoreDDS",
        "arguments": {"sysclk": 3e9}

I propose to take as convention: specify all frequencies in Hz, and take the value of any signal supplied by the user. In this example, the core device would be changed to "rtioclk": 125e6 and the DDS would stay as it is.

[dhslichter]

I heartily second this proposal. Much easier than taking inverses in my head.

[whitequark]

Can't we use *ms etc in pyon?

[sbourdeauducq]

No, but I've been thinking the device db could be turned into an executable python module. Also allows for programmatic generation of device entries, factorization of constants e.g. the DDS bus_channel, etc.

[whitequark]

Sounds good, also makes it explicit that pyon is evaluated by eval'ing.

[sbourdeauducq]

Evaling is an implementation detail, because I do not like reinventing wheels.

[sbourdeauducq]

And what I am proposing here is import, not eval.

[whitequark]

I mean that pyon files contains executable python code that can do anything. I.e. pyon is not a proper data format but is weakly defined by python semantics.

[sbourdeauducq]

PYON is JSON with Fraction, numpy, sets, etc. and strictly enforcing this is is not worth reinventing another parser and/or evaluator.

[whitequark]

Rigorously treating input data is not 'reinventing' anything.

[jordens]

Maybe this is esoteric, but:

I would go to times and away from frequencies for a lot of things, especially in digital logic. A frequency is useful if you actually intend to describe a periodic signal. RTIO is wideband and rather aperiodic. If you think you can make life easier by "preferring frequencies over times", you find yourself adding inverse frequencies all the time (haha) to build sequences of events. RTIO granularity is multiples of 8 ns, and not the inverse of integer fractions of 125 MHz. A pulse takes 10 µs and not 1/100 kHz. DDS and SPI logic timings are given in seconds, not in inverse Hz. Latency is multiples of the RTIO granularity. The timestamp is given in ns and not inverse GHz. Sure: DDS output frequencies are in Hz. But the rest? Where would you ever want the dominant rtio timing parameter given as a frequency? You can obviously do 144 ns pulses exactly. But did you know that 6.9444444 MHz can easily occur in the spectrum of a digital output but that a narrow 6 MHz is much harder?

@dhslichter where are you forced to calculate unnecessary inverses currently? I would claim the opposite is true.

[sbourdeauducq]

Yes, that was my logic as well when choosing the definition of ref_period.

[dhslichter]

@sbourdeauducq @jordens At the end of the day, these frequencies are most likely going to be put into the device_db once for any given setup and then never changed again, since in most cases they will be generated by some fixed-frequency oscillator (or a divided/multiplied fixed-frequency oscillator), so really either way it's not a big deal. You are correct that most things (pulse durations, RTIO timestamp resolutions, etc) are delineated as times, and so it makes sense to be thinking in terms of times instead of clock frequencies when writing experiments. However, when you are setting up a clock to put in, the clock generator (be it a crystal, synthesizer, whatever) is set in frequency units, so I feel that I am less likely to make an error putting things in the database if I express the clock as a frequency rather than a period. Again, it's not that difficult to the calculate the inverse yourself and put that in to the device_db, it just seems more natural to me to use frequencies since they are coming from a device where frequency is specified.

[sbourdeauducq]

Since there is no clear consensus on this detail, let's do nothing and avoid breaking existing ddbs.