Migrating from corr to casperfpga

So, you've been using corr to communicate and reconfigure your ROACH/2 with .bof files, when suddenly fpga.progdev('file.bof') doesn't work anymore. Well, this page aims to help migrate you and your existing system to using casperfpga and use .fpg files to reconfigure your CASPER Hardware.

Let's first start with some common commands used when communicating with your ROACH/2 in an ipython session using corr.

1. Instantiating your ROACH object

The old way

In [1]: import corr
In [2]: fpga = corr.katcp_wrapper.FpgaClient('hostname')

The new way

In [1]: import casperfpga
In [2]: fpga = casperfpga.CasperFpga('hostname')

2. Estimating the board's clock speed in MHz

The old way

In [3]: fpga.est_brd_clk()

The new way

In [3]: fpga.estimate_board_clock()

3. Reconfiguring your board's firmware

The old way

In [4]: fpga.progdev('design_file.bof')

The new way

casperfpga has moved towards utilising the fpg files that are generated by the toolflow as its header contains much more information about the design. This information is then parsed and is used to create instances of objects such as the communication interface (e.g. 10GbE, 40GbE) and snapshot blocks - both of which are discussed later. This information is taken from, but not limited to, the following sources:

1. core_info.tab
2. design_info.tab
3. git_info.tab

In [4]: fpga.upload_to_ram_and_program('design_file.fpg')

It is also worth noting at this moment that existing corr users will most likely be interfacing with ROACH/2 boards, where the usual .bof files are stored on the ROACH's Network File System (NFS). This however is not the case with SKARAB, where an fpg file is stored on and programmed/uploaded from the client-side.

This in turn means that if you connect to a board and want to find out what registers are available to you, you would need the fpg file that was written to it in order to parse the information again (and access via fpga.listdev()). This is because the Register-Memory Mapping is not stored on the SKARAB, and is kept local to the ipython session in which it was last programmed/reconfigured.

This is not to say progdev has been deprecated... but it has.

4. Accessing 10GbE core(s) and snapshot blocks

The old way

corr users will be familiar with

1. Being able to manually configure a 10GbE Core with a name, MAC, IP, port, etc
2. tap_start to program a 10GbE device and start the TAP driver
3. snapshot_get

The new way

casperfpga has moved towards creating separate classes for objects such as GbE interfaces, snapshots, among others. As a result, casperfpga creates instances of these objects using the information on your design provided as part of the header in the fpg file. i.e. There is now a snap class and tengbe and fortygbe classes.

1. The snap class still has methods such as print_snap(), which prints out a spreadsheet-style list of all values of the snapshot block to the screen
2. The tengbe class is not as intuitive with manually configuring 10GbE cores, however you are still able to:
   1. get_10gbe_core_details()
   2. print_10gbe_core_details()
   3. get_arp_details()
   4. print_arp_details()