Re: [casper] Re: SKARAB Toolflow updates

[Amit Bansod]

Hi Adam,

The debian version is: 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u5.

Cheers,

Amit

On 05-Feb-19 12:15, Adam Isaacson wrote:
> Hi Amit,
>
> Glad to hear that :).  Please state the version of Debian you are
> using, thanks. The how to documentation will be updated to include
> this service pack 6 for Matlab R2018a. Just so you know, CASPER will
> officially support Vivado 2018.2, Matlab R2018a (with service pack 6
> update) and Ubuntu 16.04LTS for the SKARAB. There is talk of moving
> the other modern platforms i.e. SNAP to these versions watch this space!
>
> Kind regards,
>
> Adam Isaacson
> South African Radio Astronomy Observatory (SARAO)
> Hardware Manager
> Cell: (+27) 825639602
> Tel:  (+27) 215067300
> email: aisaac...@ska.ac.za <mailto:aisaac...@ska.ac.za>
>
>   
>
>
>
> On Mon, Feb 4, 2019 at 10:12 PM Amit Bansod  <mailto:aban...@mpifr-bonn.mpg.de>> wrote:
>
> Hi Adam,
>
> I could as well install the Matlab 2018a + Vivado 2018.2 on Debian
> after installing Service pack update 6 for Matlab R2018a. The
> original path issue was at line 380 of ~R2018a/bin/matlab script
> where "newdir" variable wasn't getting initialized correctly.
> After correcting it, it worked!
>
> Cheers,
>
> Amit
>
> On 01-Feb-19 14:14, Adam Isaacson wrote:
>> Hi Amit,
>>
>> I have never used Debian and not sure if this the solution, but I
>> know Feb 1 works on our side. Ah, just remembered - did you
>> install the service pack 1 for Matlab R2018a. This is important
>> as well.
>>
>> Kind regards,
>>
>> Adam Isaacson
>> South African Radio Astronomy Observatory (SARAO)
>> Hardware Manager
>> Cell: (+27) 825639602
>> Tel:  (+27) 215067300
>> email: aisaac...@ska.ac.za <mailto:aisaac...@ska.ac.za>
>>
>>  
>>
>>>>>>>
>>>>>>> 
>>>>>>>
> -- 
> You received this message because you are subscribed to the Google
> Groups "casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to casper+unsubscr...@lists.berkeley.edu
> <mailto:casper+unsubscr...@lists.berkeley.edu>.
> To post to this group, send email to casper@lists.berkeley.edu
> <mailto:casper@lists.berkeley.edu>.

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

[casper] Re: SKARAB Toolflow updates

[Amit Bansod]

Hi Adam,

I could as well install the Matlab 2018a + Vivado 2018.2 on Debian after
installing Service pack update 6 for Matlab R2018a. The original path
issue was at line 380 of ~R2018a/bin/matlab script where "newdir"
variable wasn't getting initialized correctly. After correcting it, it
worked!

Cheers,

Amit

On 01-Feb-19 14:14, Adam Isaacson wrote:
> Hi Amit,
>
> I have never used Debian and not sure if this the solution, but I know
> Feb 1 works on our side. Ah, just remembered - did you install the
> service pack 1 for Matlab R2018a. This is important as well.
>
> Kind regards,
>
> Adam Isaacson
> South African Radio Astronomy Observatory (SARAO)
> Hardware Manager
> Cell: (+27) 825639602
> Tel:  (+27) 215067300
> email: aisaac...@ska.ac.za 
>
>   
>
>>
>>  
>>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] Booting SKARAB

[Amit Bansod]

Hi Adam,

Thanks for the updates.

I have one issue with casperfpga tools. After I changed the golden and
boot images as well as Spartan fpga firmware (from
https://github.com/ska-sa/skarab_bsp_images) to support CASPER toolflow
(https://github.com/ska-sa/mlib_devel), I am able to compile and program
the SKARAB using casperfpga with 1GbE port but connection via 40GbE
needs reprogramming of the fpga. It also often complains about the MTU
to be set to 9000 even though it is already set on our switch as well as
linux machine.  Does the 40G core MTU needs to be manually set as well ?

Kind regards,
Amit

On 08-Jan-18 1:41 PM, Adam Isaacson wrote:
> Hi Amit,
>
> Yes, I can confirm that no porting has been done regarding the SKARAB
> ADC here at SKA-SA. We are planning on holding a yellow block creation
> workshop here at SKA some time later this year - date TBC.  The user
> can bring their hardware with firmware and get it running during the
> workshop. 
>
> I can confirm that the rest of the SKARAB is fully supported using the
> CASPER tools. The only other limitation, is that the CASPER tools are
> supporting only one 40GbE TX/RX link on the SKARAB. If you desire more
> than one link then it should not require much effort to update. We are
> chasing deadlines at the moment, so it is not possible for us to
> address the above at this time.
>
> Kind regards,
>
> Adam
>
>   
>
> On Mon, Jan 8, 2018 at 12:16 PM, Clifford van Dyk
> <cliffordvan...@gmail.com <mailto:cliffordvan...@gmail.com>> wrote:
>
> Hello Amit
>
> Thanks, and Happy New Year to you too!
>
> I am fairly certain that no one has started porting the SKARAB ADC
> firmware into a CASPER "yellow block" just yet. I would be happy
> to support you on this. I don't see any limitations due to the new
> ADC interface.
>
> The Peralex-supplied JESD receiver core (included in the BSP) may
> need to be adapted depending on your application (how the ADC is
> configured) - the Peralex core is not currently a "generic" JESD
> core, rather it is designed to receive JESD packets from the
> specific ADC configured with specific mode/options (most notably
> output bandwidth). It may be easiest to start porting this to
> yellow block directly first, and then parameterise/extend the
> firmware/yellow block to support other ADC modes (decimation
> rates, DDC bypass, etc) as needed.
>
> There are a few restrictions that you need to be aware of in terms
> of bandwidth/resolution trade-off if you change the ADC modes,
> particularly when bypassing the ADC's built-in DDCs. If you can
> give me an idea of how you specifically intend to use the ADC
> (mode/bandwidth/frequency band), I can perhaps offer you some
> further advice.
>
> Kind regards,
> Clifford
>
>
>
> On 1/8/2018 10:30 AM, Amit Bansod wrote:
>> Hi Clifford,
>>
>> Happy New Year!
>>
>> Thanks a lot for the BSP Package. I am going through the
>> documentation now and have one SKARAB with casper firmware and
>> one with Peralex.
>>
>> I would be interested to develop a Casper "yellow block" for
>> SKARAB since most of our development is using CASPER toolflow. Do
>> you know if anybody is already working on it or if there are any
>> limitations due to the new ADC interface ?
>>
>> Regards,
>> Amit
>>
>>
>> On 20-Dec-17 7:15 PM, Clifford van Dyk wrote:
>>>
>>> Hi Amit
>>>
>>> Your Skarab would have been shipped with a firmware that
>>> supports DHCP on all GbE interfaces and bootloading over 1GbE
>>> (only). It includes support for the ADC mezzanine. You will
>>> probably need to use the Peralex BSP tools to access and boot
>>> the Skarab over 1GbE, rather than the CASPER toolflow.
>>>
>>> If you would like to work with the CASPER tools, then you will
>>> need to overwrite the Peralex boot image with the CASPER boot
>>> image. This will provide additional support for booting the
>>> Skarab over 40GbE, but you will loose support for the ADC. The
>>> ADC firmware is currently provided as HDL code only-it has yet
>>> to be ported into a CASPER yellow block.
>>>
>>> I will pop by the office tomorrow to provide you with a link
>>> where you can download the Peralex BSP.
>>>
>>> Kind regards,
>>> Clifford
>>>
>>>
>>> On 20 Dec 2017 6:05 PM, "Amit Bansod" <aban...@mpifr-bonn.mpg

Re: [casper] Booting SKARAB

[Amit Bansod]

Hi Clifford,

Happy New Year!

Thanks a lot for the BSP Package. I am going through the documentation
now and have one SKARAB with casper firmware and one with Peralex.

I would be interested to develop a Casper "yellow block" for SKARAB
since most of our development is using CASPER toolflow. Do you know if
anybody is already working on it or if there are any limitations due to
the new ADC interface ?

Regards,
Amit


On 20-Dec-17 7:15 PM, Clifford van Dyk wrote:
>
> Hi Amit
>
> Your Skarab would have been shipped with a firmware that supports DHCP
> on all GbE interfaces and bootloading over 1GbE (only). It includes
> support for the ADC mezzanine. You will probably need to use the
> Peralex BSP tools to access and boot the Skarab over 1GbE, rather than
> the CASPER toolflow.
>
> If you would like to work with the CASPER tools, then you will need to
> overwrite the Peralex boot image with the CASPER boot image. This will
> provide additional support for booting the Skarab over 40GbE, but you
> will loose support for the ADC. The ADC firmware is currently provided
> as HDL code only-it has yet to be ported into a CASPER yellow block.
>
> I will pop by the office tomorrow to provide you with a link where you
> can download the Peralex BSP.
>
> Kind regards,
> Clifford
>
>
> On 20 Dec 2017 6:05 PM, "Amit Bansod" <aban...@mpifr-bonn.mpg.de
> <mailto:aban...@mpifr-bonn.mpg.de>> wrote:
>
> Dear All,
>
> I am trying to boot SKARAB and the it gets stuck at "ARP ENTRY ID:0
> IP:". Is there any way to force a static ip address or boot
> via 1GbE
> interface as well ?
>
> Many Thanks!
>
> Regards,
> Amit
>
> --
> You received this message because you are subscribed to the Google
> Groups "casper@lists.berkeley.edu
> <mailto:casper@lists.berkeley.edu>" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to casper+unsubscr...@lists.berkeley.edu
> <mailto:casper%2bunsubscr...@lists.berkeley.edu>.
> To post to this group, send email to casper@lists.berkeley.edu
> <mailto:casper@lists.berkeley.edu>.
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to casper+unsubscr...@lists.berkeley.edu
> <mailto:casper+unsubscr...@lists.berkeley.edu>.
> To post to this group, send email to casper@lists.berkeley.edu
> <mailto:casper@lists.berkeley.edu>.

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

[casper] Booting SKARAB

[Amit Bansod]

Dear All,

I am trying to boot SKARAB and the it gets stuck at "ARP ENTRY ID:0
IP:". Is there any way to force a static ip address or boot via 1GbE
interface as well ?

Many Thanks!

Regards,
Amit

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] roach2 sensor-list

[Amit Bansod]

Dear All,

sorry for the incomplete mail.

I wanted to ask if the fan controller needs to be configured for the new
fans ? I am trying to use ebm-papst 8312/2HU fan unit.

Cheers,
Amit

On 28-Aug-17 11:54 AM, Amit Bansod wrote:
> Hi,
>
> I recently changed the fans on the roach2 board and the "?sensor-list"
> command is not showing any on-board sensors. It returns the following:
>
> ?sensor-list
> #sensor-list mode current\_mode none discrete raw
> !sensor-list ok 1
>
> Cheers,
> Amit
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

[casper] roach2 sensor-list

[Amit Bansod]

Hi,

I recently changed the fans on the roach2 board and the "?sensor-list"
command is not showing any on-board sensors. It returns the following:

?sensor-list
#sensor-list mode current\_mode none discrete raw
!sensor-list ok 1

Cheers,
Amit

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] gen_xps fails

[Amit Bansod]

Hi,

Can you try to update design (ctrl + D) to see if you get more information on 
the error?
Cheers,
Amit

On 28 August 2017 09:10:56 CEST, Heystek Grobler  
wrote:
>Hi Jack
>
>I have tried that but it still does not work. I have tried it with all
>casper tutorials. The file “gen_xps_files.m” gives the problem. It is
>this
>three veriables
>
>xps_objs
>custom_xps_objs
>core_types
>
>[image: Inline image 1]
>
>It breaks at line 255
>
>I cant figure out what is causing it.
>
>Heystek
>
>On Fri, Aug 25, 2017 at 6:45 PM, Jack Hickish 
>wrote:
>
>> Weird. I'm guessing that is a software register? if you select the
>block
>> that's throwing the error, then in matlab type
>"update_casper_block(gcb)"
>> (which will delete that block and replace it with a fresh copy from
>the
>> library) does that help at all.
>>
>> Cheers
>> Jack
>>
>> On Fri, 25 Aug 2017 at 04:21 Heystek Grobler
>
>> wrote:
>>
>>> Good day everyone!
>>>
>>> I have one more weird problem. If I run casper_xps and start the
>>> compilation, everything works until the file creation part. I keep
>getting
>>> this error:
>>>
>>>  casper_xps
>>> Detected Linux OS#
>>> ##  System Update  ##
>>> #
>>> Warning: The model 'tutorial1' does not have continuous states,
>hence
>>> Simulink is
>>> using the solver 'VariableStepDiscrete' instead of solver 'ode45'.
>You
>>> can disable
>>> this diagnostic by explicitly specifying a discrete solver in the
>solver
>>> tab of the
>>> Configuration Parameters dialog, or by setting the 'Automatic solver
>>> parameter
>>> selection' diagnostic to 'none' in the Diagnostics tab of the
>>> Configuration
>>> Parameters dialog
>>> > In gen_xps_files at 202
>>>   In casper_xps>run_Callback at 155
>>>   In casper_xps at 88
>>>   In @(hObject,eventdata)casper_xps('run_Callback',hObject,
>>> eventdata,guidata(hObject))
>>> Warning: Using a default value of 0.2 for maximum step size.  The
>>> simulation step
>>> size will be equal to or less than this value.  You can disable this
>>> diagnostic by
>>> setting 'Automatic solver parameter selection' diagnostic to 'none'
>in the
>>> Diagnostics page of the configuration parameters dialog
>>> > In gen_xps_files at 202
>>>   In casper_xps>run_Callback at 155
>>>   In casper_xps at 88
>>>   In @(hObject,eventdata)casper_xps('run_Callback',hObject,
>>> eventdata,guidata(hObject))
>>> #
>>> ## Block objects creation  ##
>>> #
>>> Problem with XPS: tag block: tutorial1/counter_value
>>>
>>> Error using gen_xps_files (line 255)
>>> Error found during Object creation.
>>>
>>> Do anyone perhaps know what is going on?
>>>
>>> Thanks for the help
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>Groups
>>> "casper@lists.berkeley.edu" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>send an
>>> email to casper+unsubscr...@lists.berkeley.edu.
>>> To post to this group, send email to casper@lists.berkeley.edu.
>>>
>>
>
>-- 
>You received this message because you are subscribed to the Google
>Groups "casper@lists.berkeley.edu" group.
>To unsubscribe from this group and stop receiving emails from it, send
>an email to casper+unsubscr...@lists.berkeley.edu.
>To post to this group, send email to casper@lists.berkeley.edu.

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

[casper] iADC & asiaa adc5g ROACH2 design

[Amit Bansod]

Dear All,

I am trying to compile design with the iADC and asiaa adc5g for ROACH2.
Is it possible to feed both ADCs separate clocks and derive the fpga
clock from one of the adc clocks ?

When I tried to compile a small design, I got "address overlap error":


ERROR:EDK - INST:opb_adc5g_controller_0 BASEADDR
HIGHADDR:0x0002-0x0002
   and INST:opb_adccontroller_0 BASEADDR-HIGHADDR:0x0002-0x0002 -
   address space overlap!
*

Regards,
Amit

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] [ROACH2] tap-start invalid

[Amit Bansod]

Hi Marc,

On "netstat -ng", it says "netstat: no support for 'AF INET (igmp)' on
this system. Can this be due to old version of tcpborphserver ?

Regards,
Amit

On 08-Jun-17 3:54 PM, Marc Welz wrote:
> You might be looking in /proc/sys/net, you want to be in /proc/net
>
> regards
>
> marc
>
>
> On Thu, Jun 8, 2017 at 1:51 PM, Amit Bansod <aban...@mpifr-bonn.mpg.de> wrote:
>> Hi Marc,
>>
>> Thanks, I changed the force_igmp_version to 2 however I do not see any
>> "igmp" entry in /proc/net directory.
>>
>> Regards,
>> Amit
>>
>> On 08-Jun-17 3:38 PM, Marc Welz wrote:
>>> Not 100% sure, but I think you might have to downgrade the linux igmp
>>> messages to version 2 to work with mellanox ? There is a
>>> force_igmp_version entry in /proc/sys/net ...
>>>
>>> regards
>>>
>>> marc
>>>
>>>
>>> On Thu, Jun 8, 2017 at 12:15 PM, Amit Bansod <aban...@mpifr-bonn.mpg.de> 
>>> wrote:
>>>> Hi Marc,
>>>>
>>>> I gave this a try:
>>>>
>>>> fpga.tap_start('tap0',gbe_core_name,mac_id,unicast_source_ip,fabric_port)
>>>> fpga.tap_multicast_add_recv('tap0',multicast_ip)
>>>>
>>>> I do see the log shows "multicast add" successful but we do not see any
>>>> membership reports from ROACH2. Is there a way to monitor IGMP requests
>>>> ? I am not sure if the IGMP version has to be same as the switch. We are
>>>> using the Mellanox SX1012.
>>>>
>>>> Thanks,
>>>> Amit
>>>>
>>>>
>>>> On 02-Jun-17 4:28 PM, Marc Welz wrote:
>>>>> On Fri, Jun 2, 2017 at 2:10 PM, Amit Bansod <aban...@mpifr-bonn.mpg.de> 
>>>>> wrote:
>>>>>> Hi Marc,
>>>>>>
>>>>>> I am trying to subscribe to a multicast group (receive data). How then
>>>>>> can I configure the core to send an IGMP request ?
>>>>> You are probably looking for ?tap-multicast-add. Note that you can
>>>>> only invoke that once
>>>>> you have brought up the tap interface with ?tap-start and related.
>>>>> There should be
>>>>> a ?help command which provides an overview.
>>>>>
>>>>> regards
>>>>>
>>>>> marc
>>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] [ROACH2] tap-start invalid

[Amit Bansod]

Hi Marc,

Thanks, I changed the force_igmp_version to 2 however I do not see any
"igmp" entry in /proc/net directory.

Regards,
Amit

On 08-Jun-17 3:38 PM, Marc Welz wrote:
> Not 100% sure, but I think you might have to downgrade the linux igmp
> messages to version 2 to work with mellanox ? There is a
> force_igmp_version entry in /proc/sys/net ...
>
> regards
>
> marc
>
>
> On Thu, Jun 8, 2017 at 12:15 PM, Amit Bansod <aban...@mpifr-bonn.mpg.de> 
> wrote:
>> Hi Marc,
>>
>> I gave this a try:
>>
>> fpga.tap_start('tap0',gbe_core_name,mac_id,unicast_source_ip,fabric_port)
>> fpga.tap_multicast_add_recv('tap0',multicast_ip)
>>
>> I do see the log shows "multicast add" successful but we do not see any
>> membership reports from ROACH2. Is there a way to monitor IGMP requests
>> ? I am not sure if the IGMP version has to be same as the switch. We are
>> using the Mellanox SX1012.
>>
>> Thanks,
>> Amit
>>
>>
>> On 02-Jun-17 4:28 PM, Marc Welz wrote:
>>> On Fri, Jun 2, 2017 at 2:10 PM, Amit Bansod <aban...@mpifr-bonn.mpg.de> 
>>> wrote:
>>>> Hi Marc,
>>>>
>>>> I am trying to subscribe to a multicast group (receive data). How then
>>>> can I configure the core to send an IGMP request ?
>>> You are probably looking for ?tap-multicast-add. Note that you can
>>> only invoke that once
>>> you have brought up the tap interface with ?tap-start and related.
>>> There should be
>>> a ?help command which provides an overview.
>>>
>>> regards
>>>
>>> marc
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] [ROACH2] tap-start invalid

[Amit Bansod]

Hi Marc,

I gave this a try:

fpga.tap_start('tap0',gbe_core_name,mac_id,unicast_source_ip,fabric_port)
fpga.tap_multicast_add_recv('tap0',multicast_ip)

I do see the log shows "multicast add" successful but we do not see any
membership reports from ROACH2. Is there a way to monitor IGMP requests 
? I am not sure if the IGMP version has to be same as the switch. We are
using the Mellanox SX1012.

Thanks,
Amit


On 02-Jun-17 4:28 PM, Marc Welz wrote:
> On Fri, Jun 2, 2017 at 2:10 PM, Amit Bansod <aban...@mpifr-bonn.mpg.de> wrote:
>> Hi Marc,
>>
>> I am trying to subscribe to a multicast group (receive data). How then
>> can I configure the core to send an IGMP request ?
> You are probably looking for ?tap-multicast-add. Note that you can
> only invoke that once
> you have brought up the tap interface with ?tap-start and related.
> There should be
> a ?help command which provides an overview.
>
> regards
>
> marc
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

[casper] [ROACH2] tap-start invalid

[Amit Bansod]

Dear All,

I am getting this message on giving tap-start on ROACH2:

?tap-start tap0 gbe0 239.10.1.64 7148 01:00:5E:0A:01:40
#log error 1496397035379 raw unable\_to\_configure\_tap\_device
#log error 1496397035381 raw
failed\_to\_set\_up\_tap\_devices\_tap0\_on\_register\_gbe0
#log error 1496397035381 raw unable\_to\_initialise\_tap\_component
!tap-start invalid

tap-info does not give any information on the same.

The manual configuration works fine but "tap-start" now failing even for
the older working configuration. Anybody faced this issue before ?

Cheers,
Amit



-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

[casper] ROACH2 ADC5g MMCM Dual Channel Mode

[Amit Bansod]

Hello,

I am running the ADC5g in dual channel mode (2 Gsps). The MMCM routine
fails to find a glitch free zone. The routine works when I use them in
single channel mode. Do I need to modify the routine for the same ?

Thanks,
Amit

Re: [casper] ADC 5g testing

[Amit Bansod]

Hi Jack,

Thanks for the input. Actually that's what I am doing. I am taking every 4th 
output to get Nyquist bw of 320MHz. 

Is this clock rate is too low for the FPGA? 
Cheers,
Amit

On 19 June 2016 00:35:25 CEST, Jack Hickish <jackhick...@gmail.com> wrote:
>Hi Amit,
>
>For what it's worth, you can always just run the ADC faster, but only
>use a
>subset of the yellow block outputs. Eg., clock the ADC at 1280MHz, and
>use
>every 8th yellow block output. This can be handy because
>1. You get to avoid whatever edge cases exist which cause various
>blocks to
>break at super-low clock speeds.
>2. You avoid interleaving ADC cores.
>3. Your FPGA design will use far less logic and DSP since it will be
>running at a higher clock rate.
>
>I guess the downside is that if you already have a design built which
>expects 16 parallel inputs from the ADC block you'll have to do some
>redesigning
>
>Just my $0.02
>
>Jack
>
>
>
>On Fri, 17 Jun 2016 at 00:18 Amit Bansod <aban...@mpifr-bonn.mpg.de>
>wrote:
>
>> Hi Rurik,
>>
>> Sorry for opening an old thread.
>>
>> I am trying to run fpga on ROACH2 board (we have 2 ADC5g with 1:1
>DEMUX
>> mode) at 160 MHz. I see the zdok1 snapshot data shows no data
>whatsoever
>> while snapshot from zdok0 is fine. The MMCM also fails for zdok1.
>>
>> Have you successfully ran fpga at lower frequencies ?
>>
>> Cheers,
>> Amit
>>
>> On 17-Jun-15 1:32 PM, Primiani, Rurik wrote:
>>
>> Hi Amit,
>>
>> The range of frequencies you are trying, is this a test tone going
>into
>> the IF? The MMCM calibration should be done using the ADC's test ramp
>> output mode not an external IF input. Are you setting both ADC's into
>test
>> ramp output mode before attempting the calibration? The procedure for
>> calibrating the ADC's should go like this in Python:
>>
>> from adc5g import *
>> set_test_mode(roach, 0)
>> set_test_mode(roach, 1)
>> sync_adc(roach)
>> opt0, glitches0 = calibrate_mmcm_phase(roach, 0,
>['scope_raw_0_snap',])
>> opt1, glitches1 = calibrate_mmcm_phase(roach, 1,
>['scope_raw_1_snap',])
>> unset_test_mode(roach, 0)
>> unset_test_mode(roach, 1)
>>
>> Best,
>> Rurik
>>
>>
>> On Wed, Jun 17, 2015 at 5:09 AM, Amit Bansod
><aban...@mpifr-bonn.mpg.de>
>> wrote:
>>
>>> Hi Rurik,
>>>
>>> Thanks a lot for useful inputs on the adc calibration.
>>>
>>> We tried MMCM calibration for zdock=0,1 for a few range of
>frequencies
>>> (100 MHz, 150 Mhz, 187.5 MHz,200 MHz) and we observed that the MMCM
>>> fails for zdock=1 for frequencies: 100 & 150 MHz.
>>>
>>> I looked at the glitch profile for these two frequencies and there
>was
>>> no region with zero glitches. What would be a good strategy to debug
>>> this issue ? I can send you the glitch profiles and bit code if that
>is
>>> useful.
>>>
>>> Best Regards,
>>> Amit
>>>
>>>
>>>
>>> On 12-Jan-15 5:13 PM, Primiani, Rurik wrote:
>>> > Hi Amit,
>>> >
>>> > That sadly looks nothing like a sine wave.
>>> >
>>> > The adc5g package is some Python code I developed to operate the
>ADC5g.
>>> > Please see the Github link below:
>>> >
>>> > https://github.com/sma-wideband/adc_tests/
>>> >
>>> > It is important to calibrate the MMCM clk-to-out phase using the
>>> > procedure outlined below. I think this may be why your output
>looks so
>>> > strange.
>>> >
>>> > Are familiar with Python and the corr package?
>>> >
>>> > Thanks,
>>> > Rurik
>>> >
>>> >
>>> > On Mon, Jan 12, 2015 at 10:51 AM, Amit Bansod <
>>> aban...@mpifr-bonn.mpg.de
>>> > <mailto:aban...@mpifr-bonn.mpg.de>> wrote:
>>> >
>>> > Hi Rurik,
>>> >
>>> > I am not using the ADC5g package. The fpga is running at 150
>MHz.
>>> >
>>> > Earlier, I did not take care of offset binary output but it
>did not
>>> > solve the problem.
>>> >
>>> > By "not consistent with expected results", I mean some data
>points
>>> > were offset by large amount. I have attached the plot (first
>128
>>> > data-points) for reference.
>>> >
>>> > I have not done any core-to-core mismatch corrections. 

[casper] ASIAA adc5g downsampling

[Amit Bansod]

Hello,

We are trying to sample a signal 100 MHz to 270 MHz with fpga running at
250MHz.

To downsample by 4, I simply take every 4th output of the 16 outputs
available from the yellow block of asiaa adc5g. We do have an
anti-aliasing filter for the desired 500MHz bw.

Is this correct or am I missing something obvious ?


Cheers,
Amit

[casper] ROACH2 romfs upgrade

[Amit Bansod]

Hello,

I am trying to upgrade romfs on ROACH2 via "run tftproot".

https://github.com/ska-sa/roach2_nfs_uboot/blob/master/boot/roach2-root-phyprog-release-2015-04-01.romfs

The process seems to work but it stops after

"Copy to Flash...done" with a prompt.

After entering => boot, the romfs doesn't seem to be upgraded.

Do I need to change any other options for the upgrade ?

Cheers,
Amit

Re: [casper] upload_program_bof error

[Amit Bansod]

Hi Marc,

I tried as root as well but I get the same error.

Cheers,
Amit

On 28-Apr-16 10:57 AM, Marc Welz wrote:
> unix systems do not let unpriviledged users bind ports under 1024
> 
> On Wed, Apr 27, 2016 at 6:08 PM, Amit Bansod <aban...@mpifr-bonn.mpg.de> 
> wrote:
>> Hello,
>>
>> I am using upload_program_bof to upload the bof file and I get following
>> errors:
>>
>> Programming FPGA... 
>> ('Error: request(Request to client failed.), upload(Could not connect to
>> upload port.)',)
>> Error: request(Request to client failed.), upload(Could not connect to
>> upload port.)
>> FAILURE DETECTED. Log entries:
>> 192.168.2.102: Starting thread Thread-1
>> 192.168.2.102: #version 62baddd-dirty
>> 192.168.2.102: #build-state 2015-03-25T11:27:47
>> 192.168.2.102: ?upload 30 3000
>>
>> 192.168.2.102: #log error 1015543619345 raw
>> unwilling\_to\_bind\_reserved\_port\_30
>> 192.168.2.102: !upload invalid
>> 192.168.2.102: Request upload failed.
>>   Request: ?upload 30 3000
>>   Reply: !upload invalid.
>> None
>>
>> Do I need to update the corr/katcp library or this has to do with the
>> reserved port particular to this system as I did not observe this before
>> with other systems ?
>>
>> Cheers,
>> Amit
>>

Re: [casper] arp: unknown or malformed arp packet

[Amit Bansod]

Hi Marc,

In our setup, we had the 10GbE network and one of the Ethernet
interfaces on the same subnet. Probably this caused the problem as I do
not see this any more.

Thanks,
Amit

On 01-Apr-16 2:38 PM, Marc Welz wrote:
> On Fri, Apr 1, 2016 at 10:05 AM, Amit Bansod <aban...@mpifr-bonn.mpg.de> 
> wrote:
>> Hi Marc,
>>
>> Unfortunately ?tap-info does not show any information like "announce" or
>> "query".
> 
> That probably means you are running an earlier version of tcpborphserver
> 
>> I do see lot of messages like
>>
>> #log warn raw discarding frame of unknown type 0x808 and length 72
>> #log warn raw discarding frame of unknown type 0x808 and length 600
>> #log warn raw write to tap device tap3 failed: Invalid argument
> 
> 
> Type 0x800 is IP, 0x806 is arp. But 0x808 it seems to be frame relay
> arp !? That seems a bit weird.
> 
> Maybe you have trunking vlan enabled on those ports ? I would have
> guessed IPv6 (which the roaches don't do) but that seems to be 86dd.
> Maybe check your switch configuration ?
> 
> regards
> 
> marc
> 

[casper] upload_program_bof error

[Amit Bansod]

Hello,

I am using upload_program_bof to upload the bof file and I get following
errors:

Programming FPGA... 
('Error: request(Request to client failed.), upload(Could not connect to
upload port.)',)
Error: request(Request to client failed.), upload(Could not connect to
upload port.)
FAILURE DETECTED. Log entries:
192.168.2.102: Starting thread Thread-1
192.168.2.102: #version 62baddd-dirty
192.168.2.102: #build-state 2015-03-25T11:27:47
192.168.2.102: ?upload 30 3000

192.168.2.102: #log error 1015543619345 raw
unwilling\_to\_bind\_reserved\_port\_30
192.168.2.102: !upload invalid
192.168.2.102: Request upload failed.
  Request: ?upload 30 3000
  Reply: !upload invalid.
None

Do I need to update the corr/katcp library or this has to do with the
reserved port particular to this system as I did not observe this before
with other systems ?

Cheers,
Amit

Re: [casper] arp: unknown or malformed arp packet

[Amit Bansod]

Hi Marc,

Unfortunately ?tap-info does not show any information like "announce" or
"query".

I do see lot of messages like

#log warn raw discarding frame of unknown type 0x808 and length 72
#log warn raw discarding frame of unknown type 0x808 and length 600
#log warn raw write to tap device tap3 failed: Invalid argument
and so on...

Best Regards,
Amit




On 01-Apr-16 10:14 AM, Marc Welz wrote:
> On Thu, Mar 31, 2016 at 2:23 PM, Amit Bansod <aban...@mpifr-bonn.mpg.de> 
> wrote:
> 
>> In our setup, we have ROACH2 board sending data out via a  40G switch.
>> Sometimes the data is broadcast from ROACH2 boards instead of sending to
>> a particular ip address.
> 
> Some more information on this: If the roach can't resolve and IP
> address to a MAC address on the network, it defaults to broadcasting.
> This is not ideal, but makes it possible to have extraordinarily dumb
> receivers. However, it of course does consume bandwidth...
> 
> Newer tcpborphservers have various tunable parameters to control the
> rate at which the network is queried - see ?tap-arp-config, and
> ?tap-info to display this - note the "announce" and "query" lines in
> the latter. It might be useful to run tap-info after a tap-start to
> count the number of detected stations/peers and only then start
> transmission of the data streams, to limit the amount of broadcasting
> (and thus not flood other roaches, which might still be resolving
> their peers).
> 
> ARP on the roaches is a bit unusual, as the gateware data streams
> can't be paused/buffered while a peer is resolved - instead the full
> subnet is pre-populated, and then continuously queried at a lower
> rate.
> 
> The source for all this is in
> github.com/ska-sa/katcp_devel/tcpborphserver, let me know if you spot
> something which doesn't look correct.
> 
> regards
> 
> marc
> 

[casper] arp: unknown or malformed arp packet

[Amit Bansod]

Hi All,

We are seeing, "arp: unknown or malformed arp packet" messages on ROACH2
board, quite frequently.

In our setup, we have ROACH2 board sending data out via a  40G switch.
Sometimes the data is broadcast from ROACH2 boards instead of sending to
a particular ip address.

The 10GbE core details show ARP table having unknown MAC addresses tied
to unused IP addresses. Is this usual ? We do not have anything else
connected in this closed network.

We are trying to figure out if the above message is related to this issue.

How can we debug the root of this message ?

Thanks,
Amit

Re: [casper] Weird FFT Output

[Amit Bansod]

Hi Jack,

I finally got hold of this issue.

The problem was in the pfb_fir_generic block. After replacing it, the
fft output was as expected.


Cheers,
Amit

On 06-Nov-15 5:04 PM, Jack Hickish wrote:
> Hi Amit,
> 
> I've hastily fixed that error regarding bram latency -- it's pushed to
> the master casper branch at https://github.com/casper-astro/mlib_devel.git
> 
> You should be able to cherry pick that commit into your repository, but
> I recommend just using the casper-astro master branch rather than the
> SMA branch you're currently working with. The SMA code was merged into
> casper-astro more recently than the commit you are currently at anyway.
> 
> As for your spectra, I'd suggest seeing if the problem persists with the
> latest casper-astro master branch and then investigating further from there.
> 
> Cheers,
> Jack
> 
> 
> On Fri, 6 Nov 2015 at 11:14 Amit Bansod <aban...@mpifr-bonn.mpg.de
> <mailto:aban...@mpifr-bonn.mpg.de>> wrote:
> 
> Dear All,
> 
> I am trying to extract 1 channel/band using PFB/FFT (pfb_fir_generic &
> fft_wideband_real blocks from casper library) and I am getting
> inconsistent result from a 64 channel PFB/FFT.
> 
> I also found that the for 64 channel FFT, the fft_wideband_real block
> breaks at fft_wideband_real/fft_biplex_real_4x/bi_real_unscr_4x/delay0
> (or ../bi_real_unscr_4x/delay1) for BRAM latency > 2. Can this be also a
> cause for concern ?
> 
> I have enclosed the plots of the same band for the 64 & 128 channel
> FFTs. The BW of 1 band is 12.5 MHz for 128 channels and 25 MHz for 64
> channels FFT.
> 
> The design has ASIAA 5g ADCs with fpga running at 200 MHz and same noise
>     source is feeding both ADCs.
> 
> I am using the sma-wideband repository with commit : ecab6f5
> 
> 
> Regards,
> Amit Bansod
> 

Re: [casper] Timing Errors ROACH2

[Amit Bansod]

Hi Ryan,

I could get rid of those errors but the tool had hard time in placing
with huge setup timing errors. How much utilization is good to set on
p-blocks ?

Currently, I had 60-70% for different components.

Cheers,
Amit

On 05-Nov-15 9:46 AM, Ryan Monroe wrote:
> Hi Amit,
> 
> FYI, I am CC'ing the CASPER list on all of these emails, so that they
> can be searchable for people in the future.
> 
> The placements I gave you were for my personal design, and may not work
> for yours.  When choosing pblock size, be sure to look at the pblock
> utilization in planahead.  odds are that you had either
> 1. a pblock which was outright too small for the components placed
> within (tools error out almost instantly)
> 2. multiple overlapping pblocks, in such a way that it's impossible to
> satisfy both constraints simultaneously (tools error out after much
> longer).  pblock statistics don't help with this one, but you can bash
> it out by hand with more difficulty.
> 
> look at the error from line 327-561 on your report.  this indicates the
> constraints which caused the issue, as well as some of the components
> involved.  that's a good place to start!
> 
> --Ryan
> 
> On 11/05/2015 12:20 AM, aban...@mpifr-bonn.mpg.de wrote:
>> Hi Ryan,
>>
>> I tried to place the 10gbe pblocks as you suggested. Unfortunately,
>> the tool was unable to place all components. The pblock statistics
>> were more than enough. Do you know how to avoid this problem ? The
>> tool took long time to give out errors (~11 hrs).
>>
>> I have enclosed the map report.
>>
>> Regards,
>> Amit
>>
>> On 04.11.2015 09:37, Ryan Monroe wrote:
>>> np!  the 10gbe core wasn't really intended to run at fast clock
>>> rates.  Be sure to constrain it to the east-ish side of the chip, this
>>> is almost either a
>>> 1. device utilization issue (you are trying to do too much stuff on
>>> the chip), or
>>> 2. placement issue (probably this)-- the tools are terrible at
>>> placing things in the right spots
>>>
>>> Send me any questions you have, but I'm pretty busy and reserve the
>>> right to be bad about answering ;-)
>>>
>>> --Ryan
>>>
>>>
>>>
>>> On 11/04/2015 12:32 AM, Amit Bansod wrote:
>>>> Hi Ryan,
>>>>
>>>> Thanks a lot! I will give this a try!
>>>>
>>>> Cheers,
>>>> Amit
>>>>
>>>> On 04-Nov-15 9:31 AM, Ryan Monroe wrote:
>>>>> Dear Amit,
>>>>>
>>>>> Please consider my memo 50 on the CASPER list: "Performance
>>>>> optimization
>>>>> for Virtex 6 CASPER designs" [1]
>>>>>
>>>>> As it turns out, I have a design open right now, which must close 8
>>>>> 10gbe cores at 312.5 mhz.  Attached is an image of where I placed my
>>>>> tge_tx_inst and tge_rx_inst pblocks, which I hope will be helpful for
>>>>> you.  Wish I had time to do more for you, but such is life :-/
>>>>>
>>>>> Cheers!
>>>>>
>>>>> --Ryan Monroe
>>>>>
>>>>> [1] https://casper.berkeley.edu/wiki/Memos
>>>>>
>>>>> On 11/04/2015 12:17 AM, aban...@mpifr-bonn.mpg.de wrote:
>>>>>> Dear All,
>>>>>>
>>>>>> I am getting following timing errors on 10GbE yellow blocks which
>>>>>> I am
>>>>>> finding it hard to get rid off. I am running my design at 200 MHz. I
>>>>>> have given the device utilization summary if it is useful. I have
>>>>>> also
>>>>>> enclosed the files.
>>>>>>
>>>>>> Best Regards,
>>>>>> Amit
>>>>>>
>>>>>> Timing Errors:
>>>>>> Timing constraint: PERIOD analysis for net
>>>>>> "d_codd_64ch_2_P0_ADC_asiaa_adc5g/d_codd_64ch_2_P0_ADC_asiaa_adc5g/
>>>>>>   mmcm_clkout1" derived from  PERIOD analysis for net
>>>>>> "d_codd_64ch_2_P0_ADC_asiaa_adc5g/d_codd_64ch_2_P0_ADC_asiaa_adc5g/
>>>>>>   adc_clk_div" derived from NET
>>>>>>
>>>>>>
>>>>>> "d_codd_64ch_2_P0_ADC_asiaa_adc5g/d_codd_64ch_2_P0_ADC_asiaa_adc5g/adc_clk"
>>>>>>
>>>>>>
>>>>>>  PERIOD = 2.5 ns HIGH 50%; multiplied by 2.00 to 5 nS and duty
>>>>>> cycle
>>>>>>   corrected to HIGH 2.5

[casper] ADC 5g testing

[Amit Bansod]

Dear All,

I am trying to test the ADC output for a simple sinusoid input signal 
(75 MHz, -6dBm) with the snapshot block.


Many of the output values are not consistent with the expected results. 
Do I need to do any post-processing on data after reading from Bram ?


Regards,
Amit

Re: [casper] ADC 5g Errors

[Amit Bansod]

Hi,

the version is last_ibob_ee_support-739-ge865c4b .

The last commit is:

commit e865c4bca52cc3bf14f290f46eca6351cdf17d30
Merge: 75426d6 896ce5b
Author: Wesley wesley@..
Date:   Wed Jun 11 07:37:54 2014 +0200

Merge branch 'master' of github.com:ska-sa/mlib_devel

Regards,
Amit


On 21-Oct-14 11:01 PM, Primiani, Rurik wrote:

What version of mlib_devel are you using?

On Tue, Oct 21, 2014 at 4:56 PM, Amit Bansod aban...@mpifr-bonn.mpg.de
mailto:aban...@mpifr-bonn.mpg.de wrote:

Dear All,

While testing the design from 5g ADC clock (adc0_clk) at 100 MHz, I am
getting the following errors:

Constructing platform-level connectivity ...
ERROR:EDK:4072 - INSTANCE: opb_adc5g_controller_0, PORT: adc0_dcm_locked
- port
is driven by a sourceless connector -
/.../.../.../projects/counter___led/XPS_ROACH2_base/system.mhs
line 54
Completion time: 0.00 seconds
ERROR:EDK:440 - platgen failed with errors!
gmake: *** [implementation/system.bmm] Error 2
ERROR:EDK -
Error while running gmake -f system.make bits.
Error using gen_xps_files (line 684)
XPS failed.



While comparing the system.mhs file with one on

https://github.com/sma-__wideband/mlib_devel/blob/__master/xps_base/XPS_ROACH2___base/system.mhs

https://github.com/sma-wideband/mlib_devel/blob/master/xps_base/XPS_ROACH2_base/system.mhs,

there are some differences. Is this file modified for each design ?
Any ideas on the error above ?

Thanks in Advance.

- Amit

Re: [casper] ADC 5g Errors

[Amit Bansod]

Hi,


Have you instantiated an asiaa_adc5g block in your design? Is it set to
zdok0?

Yes.


Please send the MHS file from your design's output directory, i.e.
./projects/
counter_led/XPS_ROACH2_base/system.mhs.


I have attached the system.mhs file.

Regards,
Amit
# ##
# Target Board:  ROACH v2.0
# Family:virtex6
# Device:xc6vsx475t
# Package:   ff1759
# Speed Grade:   -1
# Processor: None
# System clock frequency: 100.00 MHz
# ##

 PARAMETER VERSION = 2.1.0


# Clock Ports
 PORT sys_clk_n = sys_clk_n, DIR = I, SIGIS = CLK, CLK_FREQ = 1
 PORT sys_clk_p = sys_clk_p, DIR = I, SIGIS = CLK, CLK_FREQ = 1
 #PORT aux_clk_n = aux_clk_n, DIR = I, SIGIS = CLK, CLK_FREQ = 1
 #PORT aux_clk_p = aux_clk_p, DIR = I, SIGIS = CLK, CLK_FREQ = 1
PORT aux_clk_n  = aux_clk_n,  DIR = I, SIGIS = CLK, CLK_FREQ = 1
PORT aux_clk_p  = aux_clk_p,  DIR = I, SIGIS = CLK, CLK_FREQ = 1
# PORT aux_synci_n = aux_synci_n,   DIR = I, SIGIS = CLK, CLK_FREQ = 2
# PORT aux_synci_p = aux_synci_p,   DIR = I, SIGIS = CLK, CLK_FREQ = 2
# PORT aux_synco_n = aux_synco_n,   DIR = I, SIGIS = CLK, CLK_FREQ = 2
# PORT aux_synco_p = aux_synco_p,   DIR = I, SIGIS = CLK, CLK_FREQ = 2
# EPB Ports
 PORT epb_clk_in = epb_clk_in, DIR = I
 PORT epb_data = epb_data, DIR = IO, VEC = [0:31]
 PORT epb_addr = epb_addr, DIR = I, VEC = [5:29]
 PORT epb_cs_n = epb_cs_n, DIR = I
 PORT epb_be_n = epb_be_n, DIR = I, VEC = [0:3]
 PORT epb_r_w_n = epb_r_w_n, DIR = I
 PORT epb_oe_n = epb_oe_n, DIR = I
 PORT epb_doe_n = epb_doe_n, DIR = O
 PORT epb_rdy = epb_rdy, DIR = O
 PORT ppc_irq_n = ppc_irq_n, DIR = O





### added 2011-05-05 kim.guzzino (copy of Homin's with name change)
### changed 2011-08-04 rurik to adc5g
#
# control wires for adc0
PORT adc0_adc3wire_clk = adc0_adc3wire_clk, DIR = O
PORT adc0_adc3wire_data = adc0_adc3wire_data, DIR = O
PORT adc0_adc3wire_data_o = adc0_adc3wire_data_o, DIR = I
PORT adc0_adc3wire_spi_rst= adc0_adc3wire_spi_rst, DIR = O
PORT adc0_modepin = adc0_modepin, DIR = O
PORT adc0_reset = adc0_reset, DIR = O
### added 2011-05-05 kim.guzzino same interface as adc_5g
### changed 2011-08-04 rurik to adc5g
#
BEGIN opb_adc5g_controller
 #
 PARAMETER INSTANCE = opb_adc5g_controller_0
 PARAMETER HW_VER   = 1.00.a
 PARAMETER C_BASEADDR   = 0x0002
 PARAMETER C_HIGHADDR   = 0x0002
 BUS_INTERFACE SOPB = opb0
 PARAMETER INITIAL_CONFIG_MODE_0 = 0
 # 
 # misc ports
 PORT OPB_Clk = epb_clk
 #
 # control signals for adc0
 PORT adc0_adc3wire_clk = adc0_adc3wire_clk
 PORT adc0_adc3wire_data= adc0_adc3wire_data
 PORT adc0_adc3wire_data_o  = adc0_adc3wire_data_o
 PORT adc0_adc3wire_spi_rst = adc0_adc3wire_spi_rst
 PORT adc0_modepin  = adc0_modepin
 PORT adc0_reset= adc0_reset
 PORT adc0_dcm_reset= adc0_dcm_reset
 PORT adc0_dcm_locked   = adc0_dcm_locked
 PORT adc0_fifo_full_cnt= adc0_fifo_full_cnt
 PORT adc0_fifo_empty_cnt   = adc0_fifo_empty_cnt
 PORT adc0_psclk= adc0_psclk
 PORT adc0_psen = adc0_psen
 PORT adc0_psincdec = adc0_psincdec
 PORT adc0_psdone   = adc0_psdone
 PORT adc0_clk  = adc0_clk
 #
 # IDELAY control signals for adc0
 PORT adc0_tap_rst  = adc0_tap_rst
 PORT adc0_datain_pin   = adc0_datain_pin
 PORT adc0_datain_tap   = adc0_datain_tap
 #
 # control signals for adc1
 #
 # IDELAY control signals for adc1
 PORT adc1_tap_rst  = adc1_tap_rst
 PORT adc1_datain_pin   = adc1_datain_pin
 PORT adc1_datain_tap   = adc1_datain_tap
 #
END




BEGIN roach_infrastructure
 PARAMETER INSTANCE = infrastructure_inst
 PARAMETER HW_VER = 1.00.a
  PARAMETER CLK_FREQ = 100
  PARAMETER CLK_HIGH_LOW = low
  PARAMETER MULTIPLY = 8
  PARAMETER DIVIDE   = 8
  PARAMETER DIVCLK   = 1
 #PARAMETER CLK_FREQ = 100
 PORT sys_clk_n = sys_clk_n
 PORT sys_clk_p = sys_clk_p
 PORT aux_clk_n = aux_clk_n
 PORT aux_clk_p = aux_clk_p
# PORT aux_synci_n   = aux1_clk_n
# PORT aux_synci_p   = aux1_clk_p
# PORT aux_synco_n   = aux1_clk_n
# PORT aux_synco_p   = aux1_clk_p
 PORT epb_clk_in = epb_clk_in
 PORT sys_clk = sys_clk
 PORT sys_clk90 = sys_clk90
 PORT sys_clk180 = sys_clk180
 PORT sys_clk270 = sys_clk270
 PORT sys_clk_lock = sys_clk_lock
 PORT sys_clk2x = sys_clk2x
 PORT sys_clk2x90 = sys_clk2x90
 PORT sys_clk2x180 = sys_clk2x180
 PORT sys_clk2x270 = sys_clk2x270
 PORT aux_clk   = aux_clk
 PORT aux_clk90 = aux_clk90
 PORT aux_clk180= aux_clk180
 PORT aux_clk270= aux_clk270
 PORT aux_clk2x = aux_clk2x
 PORT aux_clk2x90   = aux_clk2x90
 PORT aux_clk2x180  = aux_clk2x180
 PORT aux_clk2x270  = aux_clk2x270
 PORT epb_clk = epb_clk
 PORT idelay_rst = power_on_rst
 PORT idelay_rdy = idelay_rdy
 PORT op_power_on_rst  = power_on_rst
 PORT clk_100 = 

Re: [casper] ADC 5g Errors

[Amit Bansod]

Thanks! It worked after using the the sma-wideband repo.

Regards,
Amit

On 22-Oct-14 3:23 PM, Primiani, Rurik wrote:

This line is causing your problem:

PORT ctrl_dcm_locked = adc0_clk_lock

For some reason this signal is getting renamed to 'adc0_clk_lock' when
it should be named 'adc0_dcm_locked'. This should not be happening with
the version you said you were using. Do you have local modifications to
your clone of mlib_devel?

I also noticed that your version of mlib_devel has a bug that was fixed
in sma-wideband/mlib_devel@d4954fd. I'm assuming you're using the ska-sa
fork of mlib_devel which has not yet pulled this fix. If you plan to use
the adc5g, I would recommend either updating your local ska-sa checkout
and cherry-picking the above commit or switching to use the sma-wideband
fork which has the latest code for the adc5g.

The easiest method would be a clean checkout of sma-wideband.


On Wed, Oct 22, 2014 at 9:03 AM, Amit Bansod aban...@mpifr-bonn.mpg.de
mailto:aban...@mpifr-bonn.mpg.de wrote:

Hi,

Have you instantiated an asiaa_adc5g block in your design? Is it
set to
zdok0?

Yes.

Please send the MHS file from your design's output directory, i.e.
./projects/
counter_led/XPS_ROACH2_base/__system.mhs.


I have attached the system.mhs file.

Regards,
Amit