ipbus / ipbus-firmware

Firmware that implements a reliable high-performance control link for particle physics electronics, based on the IPbus protocol
https://ipbus.web.cern.ch
Other
39 stars 31 forks source link

IPBus on a Zynq FPGA #209

Open andrea-celentano opened 2 years ago

andrea-celentano commented 2 years ago

Dear all, I am Andrea Celentano, staff scientist at INFN Genova, currently working in the NA64 experiment at CERN.

We are developing a new DAQ board for the experiment. This is a 12 ch, 250 MHz digitizer, based on the “Waveboard” device developed by INFN (https://www.sciencedirect.com/science/article/pii/S0168900218310684?via%3Dihub). This board is equipped with a Zynq 7030 device, featuring a dual-core ARM integrated with a Xintex7 FPGA.

The new board has to be integrated in the existing NA64 DAQ system, based on the UCF protocol (https://indico.cern.ch/event/390748/contributions/1825135/attachments/1281396/1903787/crx_upgrades2_207.pdf) developed for COMPASS experiment. UCF provides 64 “virtual” communication channels, based on the AXI-Stream protocol. One of these is used for the slow controls system, based on the IPbus protocol (in COMPASS, this is referred to as “IPBus over UCF”).

The NA64 DAQ responsible provided us the source code of an example firmware for a “generic” DAQ board, implementing “IPbus over UCF”.

In this design, there is an entity “ipbuswrapper” that is responsible of connecting UCF to IPBUS, providing us with the signals “IPB_OUT” (type ipb_wbus) and “IPB_IN” (type ipb_rbus).

In the design, there is also a slaves entity example (see below), that we should in principle modify to interface with the registers and the other resources on the DAQ board.

Inst_IPBus_Slaves : entity work.slaves
generic map
    (
      NSLV           => 2+2*CONF_STATIC_IN_NR,
      STATIC_NR   => CONF_STATIC_IN_NR
      )
    port map
    (
      dbg_o => open,
      rst_i => '0',
      --
      ipb_clk => IPB_CLK,
      --       
      IPB_OUT => IPB_IN,
      IPB_IN  => IPB_OUT,
      --
      static_in      => static_in,
      static_out     => static_out
      );

In the current DAQ board design, however, all the slow-controls operations are handled via the ZYNQ CPU, via software. Therefore, it would be very convenient for us to keep the same approach. The reason why I write you, therefore, is to ask you if have any experience with this approach, or any suggestion regarding it.

For example, does an “IPBUS-to-AXI” interface exists, to connect the IPBus_Wrapper module to an ARM processor, including its Linux-OS driver?
Could the “axi4lite_interface” IPBus slave be used for this (https://github.com/ipbus/ipbus-firmware/blob/master/components/ipbus_slaves/firmware/hdl/axi4lite_interface.vhd)

Please note that I am not sure that the IPBus version used by our colleagues in the UCF-to-IPBUS project is the latest one, since, for example, I see the use of ipbus_reg entities, that is now replaced by ipbus_reg_v. However, any hint or suggestion would be very appreciated!

Thanks, Bests, Andrea

tswilliams commented 2 years ago

Hi,

For example, does an “IPBUS-to-AXI” interface exists, to connect the IPBus_Wrapper module to an ARM processor, including its Linux-OS driver?

Indeed, we do have an interface which can be used to connect the IPbus transactor to a Zynq CPU - specifically the ipbus_transport_axi_if entity, which can be found at https://github.com/ipbus/ipbus-firmware/blob/v1.10/components/ipbus_transport_axi/firmware/hdl/ipbus_transport_axi_if.vhd . There is a corresponding example design for the ZCU102 under https://github.com/ipbus/ipbus-firmware/tree/v1.10/prototypes/zcu102/c2c_loopback/synth - and a short description of that design can be found at https://ipbus.web.cern.ch/doc/user/html/firmware/exampleDesigns.html#zcu102-axi-chip-to-chip-example-design

Cheers, Tom