> >> 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.
Take it up with AD. > >> 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. My proposal had been *not* to support the profile mode and digital ramp right now, just programmable modulus, since these other two modes will require considerable work on the compiler which programmable modulus does not. If others in addition to Joe feel that we should support these features right now, then yes we will need to figure out a protocol for resolving conflicts/inconsistencies, and this is something that would need to be thought out carefully, agreed. > > 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. My sentence states "from DDS limits alone", implying a lower bound assuming the FPGA is infinitely fast (which is obviously not a good assumption, thus my question). My question was in fact "how long does it take to write 8 write cycles to the DDS chips? Is this limited by the FPGA?". It appears your answers are "approx. 500 ns" and "yes". > https://github.com/m-labs/artiq/blob/master/soc/runtime/dds.c > The rationale is in the IRC logs. Ack. > > 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 This can just be refactoring the FUD into dds_fud() from dds_set_one() so it can be called independently. It would then either need an array of ints to specify which channels to update, or perhaps better use a long long int as a bitmask for channels to be updated (as long as there are fewer than 64; I doubt we'd ever have more than 64 DDS chips hanging off a single FPGA from simple wire count considerations). Daniel _______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
