On Wed, May 20, 2015 at 8:41 AM, Slichter, Daniel H. <daniel.slich...@nist.gov> wrote: >> This mode can represent many rational frequencies but is certainly not >> "exact". > > I am just using the datasheet terminology of "exact", referring to how > rational frequencies can be exactly represented.
It's still misleading. >> Agreeing on 0.2 nHz (!) is seemingly easy. But either we abandon profile >> mode, data modulation and phase/amplitude and frequency ramps or you >> need to specify at what level and how you want to switch between these >> mutually exclusive modes. > > These modes do not need to be abandoned; you just can't use the ramp > generator or the frequency changing function of profile mode if programmable > modulus is enabled. We should be able to They are mutually exclusive. If you want to support both, you have to specify how to resolve conflicts, inconsistencies, and what should happen if you switch modes, e.g. with phase tracking. > How long does it take to write 64 bits (8 write cycles) to the DDS chips? Is > this limited by the FPGA? The DDS itself takes minimum ~ 10 ns per write > cycle, so changing frequency would require ~ 100 ns in programmable modulus > mode from DDS limits alone. That is a simplistic. You are assuming that frequency writes are optimized. Currently it would be closer to 0.5 µs. > Some questions for Sebastien: How does the current DDS programming firmware > work? Does the SoC need to do any processing, or is it just fetching > precomputed register values (done at compile time) and pushing them to an > output FIFO? If a DDS is programmed to change frequency, say, at a > particular time, how is it determined when the register programming commands > are output to the DDS bus? How does the system handle it if more than one > DDS chip is supposed to change frequency/phase/amplitude at the same time? https://github.com/m-labs/artiq/blob/master/soc/runtime/dds.c The rationale is in the IRC logs. > From a hardware perspective, the DDS registers can be programmed ahead of > time and then the actual change of output freq/phase/amplitude occurs when > the IO_UPDATE (aka FUD) command is sent. So if multiple DDS chips need to be > updated to new output parameters at the same time, one would program them one > at a time over the DDS parallel bus, then send them all a common IO_UPDATE > signal at the appropriate time for the update to happen. The system would > thus need a way of recognizing this condition (or similar conditions) and > allowing enough lead time for DDS programming so that they can all be > programmed before the IO_UPDATE needs to go out. Dito -- Robert Jordens. _______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
