> On Wednesday, July 11, 2018 04:59 AM, Thomas Harty via ARTIQ wrote:
> > My view is that we shouldn't give up the flexibility of being able to
> > fine-tune the DUC frequency unless there is a good reason to do so.
> > For example: if the complexity/compile times of the current code make
> > development/maintenance problematic(*), or if the current code is
> > going to have issues achieving the full 1GSPS data rate. It would be
> > good to hear a bit more from SB/RJ on the advantages of moving to a
> > simpler DUC parametrization.
> 
> Right now we are producing 4 DAC samples per cycle (150MHz RTIO, 600MHz
> DAC). Moving to 1GSPS will need 8 samples per cycle (125MHz RTIO), i.e.
> requiring twice the FPGA resources plus adding interconnection paths between
> the parallel units. This can only exacerbate issues of compilation time, 
> routing
> congestion, and timing closure. The last two can probably be addressed but
> there is no free lunch - it'll take significant work. And the compilation time
> would always remain problematic.
> 
> Having the fixed DUC frequencies would simplify the sample generation logic
> and reduce the problems.

I think we will really need the 8x interleaving at the RTIO clock rate, because 
1 GSPS is pretty critical (600 MSPS is marginal or a non-starter for most of 
our use cases).  This to me seems much more important than maintaining some 
kind of more arbitrary flexibility for DUC.  I am a little unclear on others' 
use cases regarding DUC on the FPGA itself, but it seems to me that simply 
being able to shift the output by integer multiples of fs/8 (or fs/16, perhaps) 
should be more than satisfactory.  It would appear to me that any tuning with 
finer frequency resolution can/should be done with the baseband signals coming 
out of the 8 interleaved generation blocks.  Sebastien, are you saying that 
even this level of DUC presents substantial challenge?  

Best,
Daniel
_______________________________________________
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Reply via email to