> 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. > 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 > Also people have to determine whether the programming pattern that we > implemented is fast enough (and will be with the additional 4 writes of the > numerator) or in need of optimization. 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. 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? >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. Daniel _______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
