date:20160310

Re: [casper] Working with demux modes of 'ADC16x250-8 coax rev 2'

2016-03-10 Thread Jack Hickish

You could always just try just throwing delays in there just to check it
fixes the compile, then at least you know that's the issue. Worrying  about
making a filter implementation that is both valid and meets timing can then
come later.

Good Luck!

Jack

On Fri, 11 Mar 2016 at 01:52 Nilan Udayanga  wrote:

> Hi Jack,
>
> Yes, We tried lookahead pipelining as well. Even in that case, it compiled
> without the software register. However, when we add the software register,
> it failed for timing (similar to the previous design).
>
> Regards,
> Nilan Udayanga.
>
> On Thu, Mar 10, 2016 at 8:38 PM, Jack Hickish 
> wrote:
>
>> Hi Nilan,
>>
>> Yeah, I figured that would be a problem... :)
>> Does something like this (which i confess I haven't read, but Fig 14
>> looks potentially relevent) help? --
>> http://www.xilinx.com/support/documentation/white_papers/wp330.pdf
>>
>> Jack
>>
>> On Fri, 11 Mar 2016 at 01:21 Nilan Udayanga  wrote:
>>
>>> Hi Jack,
>>>
>>> We can not add any more delays to the feedback loop multipliers and
>>> adders, since it changes the filter transfer function. However, we can try
>>> on distributing corresponding delays over adders and multipliers, without
>>> adding separate delays. But, I don't know whether it may change the
>>> critical path delay.
>>>
>>> Regards,
>>> Nilan Udayanga.
>>>
>>> On Thu, Mar 10, 2016 at 8:02 PM, Jack Hickish 
>>> wrote:
>>>
 I think if you can add latency in those multipliers / adders you'll
 probably find your problem will go away. It's the blow path that's
 breaking, so I don;t think you can get around ijnserting some registers to
 split up thje logic stages --


 
 Slack:  -15.890ns (requirement - (data path - clock
 path skew + uncertainty))
   Source:
 ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42/srl_delay.synth_reg_srl_inst/partial_one.last_srl17e/reg_array[27].fde_used.u2
 (FF)
   Destination:
  
 ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm13_dda55e6716/block_z_1_0d8d8d72ce/mult1/comp1.core_instance1/blk0001/blk0006
 (FF)
   Requirement:  5.000ns
   Data Path Delay:  20.585ns (Levels of Logic = 12)(Component
 delays alone exceeds constraint)
   Clock Path Skew:  -0.245ns (1.869 - 2.114)
   Source Clock: adc0_clk rising at 0.000ns
   Destination Clock:adc0_clk rising at 5.000ns
   Clock Uncertainty:0.060ns

   Clock Uncertainty:  0.060ns  ((TSJ^2 + DJ^2)^1/2) / 2 + PE
 Total System Jitter (TSJ):  0.070ns
 Discrete Jitter (DJ):   0.097ns
 Phase Error (PE):   0.000ns

   Maximum Data Path at Slow Process Corner:
 ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42/srl_delay.synth_reg_srl_inst/partial_one.last_srl17e/reg_array[27].fde_used.u2
 to
 ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm13_dda55e6716/block_z_1_0d8d8d72ce/mult1/comp1.core_instance1/blk0001/blk0006
 Location Delay type Delay(ns)  Physical Resource
Logical
 Resource(s)
 -
  ---
 SLICE_X64Y79.CQ  Tcko  0.381
 ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42_q_net(27)

  
 ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42/srl_delay.synth_reg_srl_inst/partial_one.last_srl17e/reg_array[27].fde_used.u2
 SLICE_X65Y79.C1  net (fanout=2)0.584
 ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42_q_net(27)
 SLICE_X65Y79.C   Tilo  0.068
 ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42_q_net(19)

  
 ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/convert8/std_conversion_generate.convert/Mmux_din[24]_GND_129_o_MUX_41_o11
 SLICE_X62Y79.D6  net (fanout=1)0.248
 ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/convert8/std_conversion_generate.convert/Mmux_din[24]_GND_129_o_MUX_41_o1
 SLICE_X62Y79.D   Tilo  0.068
 ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42_q_net(23)

  
 ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/convert8/std_conversion_generate.convert/Mmux_din[24]_GND_129_o_MUX_41_o13
 SLICE_X61Y81.A6  net (fanout=26)   0.521

Re: [casper] Working with demux modes of 'ADC16x250-8 coax rev 2'

2016-03-10 Thread Jack Hickish

Hi Nilan,

Yeah, I figured that would be a problem... :)
Does something like this (which i confess I haven't read, but Fig 14 looks
potentially relevent) help? --
http://www.xilinx.com/support/documentation/white_papers/wp330.pdf

Jack

On Fri, 11 Mar 2016 at 01:21 Nilan Udayanga  wrote:

> Hi Jack,
>
> We can not add any more delays to the feedback loop multipliers and
> adders, since it changes the filter transfer function. However, we can try
> on distributing corresponding delays over adders and multipliers, without
> adding separate delays. But, I don't know whether it may change the
> critical path delay.
>
> Regards,
> Nilan Udayanga.
>
> On Thu, Mar 10, 2016 at 8:02 PM, Jack Hickish 
> wrote:
>
>> I think if you can add latency in those multipliers / adders you'll
>> probably find your problem will go away. It's the blow path that's
>> breaking, so I don;t think you can get around ijnserting some registers to
>> split up thje logic stages --
>>
>>
>> 
>> Slack:  -15.890ns (requirement - (data path - clock path
>> skew + uncertainty))
>>   Source:
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42/srl_delay.synth_reg_srl_inst/partial_one.last_srl17e/reg_array[27].fde_used.u2
>> (FF)
>>   Destination:
>>  
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm13_dda55e6716/block_z_1_0d8d8d72ce/mult1/comp1.core_instance1/blk0001/blk0006
>> (FF)
>>   Requirement:  5.000ns
>>   Data Path Delay:  20.585ns (Levels of Logic = 12)(Component delays
>> alone exceeds constraint)
>>   Clock Path Skew:  -0.245ns (1.869 - 2.114)
>>   Source Clock: adc0_clk rising at 0.000ns
>>   Destination Clock:adc0_clk rising at 5.000ns
>>   Clock Uncertainty:0.060ns
>>
>>   Clock Uncertainty:  0.060ns  ((TSJ^2 + DJ^2)^1/2) / 2 + PE
>> Total System Jitter (TSJ):  0.070ns
>> Discrete Jitter (DJ):   0.097ns
>> Phase Error (PE):   0.000ns
>>
>>   Maximum Data Path at Slow Process Corner:
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42/srl_delay.synth_reg_srl_inst/partial_one.last_srl17e/reg_array[27].fde_used.u2
>> to
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm13_dda55e6716/block_z_1_0d8d8d72ce/mult1/comp1.core_instance1/blk0001/blk0006
>> Location Delay type Delay(ns)  Physical Resource
>>Logical Resource(s)
>> -  ---
>> SLICE_X64Y79.CQ  Tcko  0.381
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42_q_net(27)
>>
>>  
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42/srl_delay.synth_reg_srl_inst/partial_one.last_srl17e/reg_array[27].fde_used.u2
>> SLICE_X65Y79.C1  net (fanout=2)0.584
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42_q_net(27)
>> SLICE_X65Y79.C   Tilo  0.068
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42_q_net(19)
>>
>>  
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/convert8/std_conversion_generate.convert/Mmux_din[24]_GND_129_o_MUX_41_o11
>> SLICE_X62Y79.D6  net (fanout=1)0.248
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/convert8/std_conversion_generate.convert/Mmux_din[24]_GND_129_o_MUX_41_o1
>> SLICE_X62Y79.D   Tilo  0.068
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42_q_net(23)
>>
>>  
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/convert8/std_conversion_generate.convert/Mmux_din[24]_GND_129_o_MUX_41_o13
>> SLICE_X61Y81.A6  net (fanout=26)   0.521
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/convert8/std_conversion_generate.convert/din[24]_GND_129_o_MUX_41_o
>> SLICE_X61Y81.A   Tilo  0.068
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/convert8_dout_net_x31(23)
>>
>>  
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/convert8/std_conversion_generate.convert/Mmux_result221
>> DSP48_X3Y30.B7   net (fanout=16)   1.178
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/convert8_dout_net_x31(7)
>> DSP48_X3Y30.PCOUT8   Tdspdo_B_PCOUT_MULT   3.691
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm12_2626363f3e/block_t_z2_f45dc8cbb6/mult2/comp0.core_instance0/blk0001/blk0005
>>
>>  
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm12_2626363f3e/block_t_z2_f45dc8cbb6/mult2/comp0.core_instance0/blk0001/blk0005
>>

Re: [casper] Working with demux modes of 'ADC16x250-8 coax rev 2'

2016-03-10 Thread Jack Hickish

I think if you can add latency in those multipliers / adders you'll
probably find your problem will go away. It's the blow path that's
breaking, so I don;t think you can get around ijnserting some registers to
split up thje logic stages --


Slack:  -15.890ns (requirement - (data path - clock path
skew + uncertainty))
  Source:
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42/srl_delay.synth_reg_srl_inst/partial_one.last_srl17e/reg_array[27].fde_used.u2
(FF)
  Destination:
 
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm13_dda55e6716/block_z_1_0d8d8d72ce/mult1/comp1.core_instance1/blk0001/blk0006
(FF)
  Requirement:  5.000ns
  Data Path Delay:  20.585ns (Levels of Logic = 12)(Component delays
alone exceeds constraint)
  Clock Path Skew:  -0.245ns (1.869 - 2.114)
  Source Clock: adc0_clk rising at 0.000ns
  Destination Clock:adc0_clk rising at 5.000ns
  Clock Uncertainty:0.060ns

  Clock Uncertainty:  0.060ns  ((TSJ^2 + DJ^2)^1/2) / 2 + PE
Total System Jitter (TSJ):  0.070ns
Discrete Jitter (DJ):   0.097ns
Phase Error (PE):   0.000ns

  Maximum Data Path at Slow Process Corner:
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42/srl_delay.synth_reg_srl_inst/partial_one.last_srl17e/reg_array[27].fde_used.u2
to
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm13_dda55e6716/block_z_1_0d8d8d72ce/mult1/comp1.core_instance1/blk0001/blk0006
Location Delay type Delay(ns)  Physical Resource
   Logical Resource(s)
-  ---
SLICE_X64Y79.CQ  Tcko  0.381
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42_q_net(27)

 
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42/srl_delay.synth_reg_srl_inst/partial_one.last_srl17e/reg_array[27].fde_used.u2
SLICE_X65Y79.C1  net (fanout=2)0.584
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42_q_net(27)
SLICE_X65Y79.C   Tilo  0.068
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42_q_net(19)

 
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/convert8/std_conversion_generate.convert/Mmux_din[24]_GND_129_o_MUX_41_o11
SLICE_X62Y79.D6  net (fanout=1)0.248
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/convert8/std_conversion_generate.convert/Mmux_din[24]_GND_129_o_MUX_41_o1
SLICE_X62Y79.D   Tilo  0.068
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42_q_net(23)

 
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/convert8/std_conversion_generate.convert/Mmux_din[24]_GND_129_o_MUX_41_o13
SLICE_X61Y81.A6  net (fanout=26)   0.521
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/convert8/std_conversion_generate.convert/din[24]_GND_129_o_MUX_41_o
SLICE_X61Y81.A   Tilo  0.068
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/convert8_dout_net_x31(23)

 
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/convert8/std_conversion_generate.convert/Mmux_result221
DSP48_X3Y30.B7   net (fanout=16)   1.178
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/convert8_dout_net_x31(7)
DSP48_X3Y30.PCOUT8   Tdspdo_B_PCOUT_MULT   3.691
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm12_2626363f3e/block_t_z2_f45dc8cbb6/mult2/comp0.core_instance0/blk0001/blk0005

 
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm12_2626363f3e/block_t_z2_f45dc8cbb6/mult2/comp0.core_instance0/blk0001/blk0005
DSP48_X3Y31.PCIN8net (fanout=1)0.002
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm12_2626363f3e/block_t_z2_f45dc8cbb6/mult2/comp0.core_instance0/blk0001/sig009b
DSP48_X3Y31.P1   Tdspdo_PCIN_P 1.591
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm12_2626363f3e/block_t_z2_f45dc8cbb6/mult2/comp0.core_instance0/blk0001/blk0004

 
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm12_2626363f3e/block_t_z2_f45dc8cbb6/mult2/comp0.core_instance0/blk0001/blk0004
SLICE_X63Y104.C1 net (fanout=1)2.858
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm12_2626363f3e/block_t_z2_f45dc8cbb6/mult2_p_net(2)
SLICE_X63Y104.COUT   Topcyc0.338
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm7_4234b2b9fe/delay1_q_net(19)

Re: [casper] Working with demux modes of 'ADC16x250-8 coax rev 2'

2016-03-10 Thread Jack Hickish

Also, I don't think the problem is the software register, I think the
problem is present in both your designs, but in the "working" model the
compiler is optimizing away all the failing logic paths, which presumably
aren't actually doing anything given the way the blocks in the model are
connected together.

>From the passing timing report:

Timing constraint:
TS_ears_sbp22_adc16x250_8_ears_sbp22_adc16x250_8_bufg_i_2_ =
PERIOD TIMEGRP
"ears_sbp22_adc16x250_8_ears_sbp22_adc16x250_8_bufg_i_2_"
TS_adc16_line_clk / 0.5 HIGH 50%;
For more information, see Period Analysis in the Timing Closure User Guide
(UG612).

* 1863 paths analyzed, 1143 endpoints analyzed, 0 failing endpoints*
 0 timing errors detected. (0 setup errors, 0 hold errors, 0 component
switching limit errors)
 Minimum period is   3.235ns.

>From the failing timing report:

Timing constraint:
TS_ears_sbp22_adc16x250_8_ears_sbp22_adc16x250_8_bufg_i_2_ =
PERIOD TIMEGRP
"ears_sbp22_adc16x250_8_ears_sbp22_adc16x250_8_bufg_i_2_"
TS_adc16_line_clk / 0.5 HIGH 50%;
For more information, see Period Analysis in the Timing Closure User Guide
(UG612).

* 79231860653 paths analyzed, 61736 endpoints analyzed, 12780 failing
endpoints*
 12780 timing errors detected. (12746 setup errors, 34 hold errors, 0
component switching limit errors)
 Minimum period is  20.890ns.

The lack of paths analysed in the passing report suggests to me that most
of your design has been removed during optimization...

Jack

On Fri, 11 Mar 2016 at 00:18 Jack Hickish  wrote:

> Hi Nilan,
>
> It looks like there's a block called (something like) ppcm12/block_t_z2
> with a huge logic delay -- from line 135 of the failing twr file --
>
>   Data Path Delay:  20.585ns (Levels of Logic = 12)(Component delays
> alone exceeds constraint)
>
> What is this block? It looks like it has some multipliers and adders and
> stuff...
>
> There's also a timing error in the adc yellow block, but my guess is this
> is just because the place and route tool gave up when it hit impossible
> constraints elsewhere.
>
> Cheers,
> Jack
>
> On Thu, 10 Mar 2016 at 23:49 Nilan Udayanga  wrote:
>
>> Hi all,
>>
>> We are having a little weird problem during the compilation of a roach 2
>> design with the adc16 block. I have a design for a specific application. It
>> is well pipelined and we are using ADC interfaces clocked at 200 MHz. When
>> I just terminate the output without using any software registers at the
>> output, there is no timing error (all timing costrains have been met). And
>> when I compile the design using the software register at the output (just a
>> one software register), it has a timing error, and says the maximum
>> frequency that can be achieved is around 50 MHz. I am wondering whether it
>> is a problem with the software register or not. Please find the following
>> attachments for the .twr and .twx files for each cases.
>>
>> I have tried using snapshots blocks too. Thats giving the same timing
>> error.
>>
>> Your help will be greatly appreciated.
>>
>> Regards,
>> Nilan Udayanga.
>>
>> On Wed, Mar 9, 2016 at 4:03 PM, Nilan Udayanga 
>> wrote:
>>
>>> Hi All,
>>>
>>> Thank you very much for all your suggestions.
>>>
>>> I have two more questions,
>>>
>>> Since, ADCs need to be clocked at 480 MHz for the demux=2 mode, how does
>>> the FPGA clock at 240 MHz? does it use a clock divider internally?
>>>
>>> Is there any maximum operating frequency for the FPGA, when we use the
>>> adc16 block?
>>>
>>> Regards,
>>> Nilan Udayanga.
>>>
>>> On Wed, Mar 9, 2016 at 3:22 PM, Jack Hickish 
>>> wrote:
>>>
 With regards to the demux option, for the system you describe you want
 -d 2 (I.e. demux by = run the FPGA at half the sample rate, and process two
 samples in parallel on every FPGA clock cycle). Basically, provided you
 have the up to date ruby package, all you need to do is run adc16_init.rb
 with appropriate options, and that will program your roach and set
 everything up for you.

 I think the default mode of the adc16 ruby script assumes that,
 whatever mode you're using the ADC in, the external clock provided is at
 the sample rate. Though, as Matt added, the ADC supports other dividing
 options if they're useful to you and you're willing to read the ADC data
 sheet to work out how to set the divider properties.

 Cheers
 Jack

 On Wed, 9 Mar 2016, 09:49 David MacMahon, 
 wrote:

> Hi Vishwa,
>
> I am not at my computer right now, so this is from memory, but I think

Re: [casper] Working with demux modes of 'ADC16x250-8 coax rev 2'

2016-03-10 Thread Jack Hickish

Hi Nilan,

It looks like there's a block called (something like) ppcm12/block_t_z2
with a huge logic delay -- from line 135 of the failing twr file --

  Data Path Delay:  20.585ns (Levels of Logic = 12)(Component delays
alone exceeds constraint)

What is this block? It looks like it has some multipliers and adders and
stuff...

There's also a timing error in the adc yellow block, but my guess is this
is just because the place and route tool gave up when it hit impossible
constraints elsewhere.

Cheers,
Jack

On Thu, 10 Mar 2016 at 23:49 Nilan Udayanga  wrote:

> Hi all,
>
> We are having a little weird problem during the compilation of a roach 2
> design with the adc16 block. I have a design for a specific application. It
> is well pipelined and we are using ADC interfaces clocked at 200 MHz. When
> I just terminate the output without using any software registers at the
> output, there is no timing error (all timing costrains have been met). And
> when I compile the design using the software register at the output (just a
> one software register), it has a timing error, and says the maximum
> frequency that can be achieved is around 50 MHz. I am wondering whether it
> is a problem with the software register or not. Please find the following
> attachments for the .twr and .twx files for each cases.
>
> I have tried using snapshots blocks too. Thats giving the same timing
> error.
>
> Your help will be greatly appreciated.
>
> Regards,
> Nilan Udayanga.
>
> On Wed, Mar 9, 2016 at 4:03 PM, Nilan Udayanga 
> wrote:
>
>> Hi All,
>>
>> Thank you very much for all your suggestions.
>>
>> I have two more questions,
>>
>> Since, ADCs need to be clocked at 480 MHz for the demux=2 mode, how does
>> the FPGA clock at 240 MHz? does it use a clock divider internally?
>>
>> Is there any maximum operating frequency for the FPGA, when we use the
>> adc16 block?
>>
>> Regards,
>> Nilan Udayanga.
>>
>> On Wed, Mar 9, 2016 at 3:22 PM, Jack Hickish 
>> wrote:
>>
>>> With regards to the demux option, for the system you describe you want
>>> -d 2 (I.e. demux by = run the FPGA at half the sample rate, and process two
>>> samples in parallel on every FPGA clock cycle). Basically, provided you
>>> have the up to date ruby package, all you need to do is run adc16_init.rb
>>> with appropriate options, and that will program your roach and set
>>> everything up for you.
>>>
>>> I think the default mode of the adc16 ruby script assumes that, whatever
>>> mode you're using the ADC in, the external clock provided is at the sample
>>> rate. Though, as Matt added, the ADC supports other dividing options if
>>> they're useful to you and you're willing to read the ADC data sheet to work
>>> out how to set the divider properties.
>>>
>>> Cheers
>>> Jack
>>>
>>>
>>> On Wed, 9 Mar 2016, 09:49 David MacMahon, 
>>> wrote:
>>>
 Hi Vishwa,

 I am not at my computer right now, so this is from memory, but I think
 you want to specify an IP clock rate of 240 MHz and supply a 480 MHz clock
 to the ADC card(s). The IP clock rate is sometimes called the fabric clock
 rate. It is the rate at which the FPGA logic elements (aka fabric) operate.
 The ADC chips need a sample clock that is commensurate with the sampling
 frequency. When you initialize the ADCs using adc16_init.rb, be sure to
 pass the "-d" option. If your version of adc16_init.rb does not support the
 "-d" option, then you will need to update it.

 Hope this helps,
 Dave

 On Mar 9, 2016, at 08:33, Vishwa Seneviratne 
 wrote:

 Hi David/Jack,

 We are working on a beam former and we use the 'ADC16x250-8 coax rev 2'
 to sample RF signals using ROACH2-Rev 2. The operating BW is 240MHz. Thus,
 we need to sample the signals at 480 MSamples/s. We have few queries
 regarding the adc16 yellow block and how to setup the input clock.

 1. Can we compile a design by setting the IP clock rate to 480MHz?
 2. Should we supply a IP clock frequency of 480MHz to the ADC board to
 achieve a sampling rate of 480MSamples/s.  If not, at what clock rate
 should we supply? And what other parameters needed to setup when running
 the bof file.

 Thank you

 Sincerely,

 *Vishwa Seneviratne*

 *Graduate Student*

 *Dept. of Electrical and Computer Engineering*
 *University of Akron*

 On Wed, Feb 3, 2016 at 12:38 PM, David MacMahon <
 dav...@astro.berkeley.edu> wrote:

> Hi, Vishwa,
>
> The software installed by following the ADC16 user guide had not been
> updated with the newer version of the adc16 code that supports demux mode.
> I have updated the software that the user guide points to, so if you
> reinstall the adc16 gem as per the user guide you should get version 0.4.0
> which

Re: [casper] Working with demux modes of 'ADC16x250-8 coax rev 2'

Re: [casper] Working with demux modes of 'ADC16x250-8 coax rev 2'

Re: [casper] Working with demux modes of 'ADC16x250-8 coax rev 2'

Re: [casper] Working with demux modes of 'ADC16x250-8 coax rev 2'

Re: [casper] Working with demux modes of 'ADC16x250-8 coax rev 2'

5 matches

Site Navigation

Mail list logo

Footer information