abs-tudelft / fletcher-oc-accel Goto Github PK

This platform is called "snap", but this collides with the original fletcher-snap for capi1.0/2.0.
It should be called "oc-accel"

The available address range on the AXI4 lite bus for actions has been increased in oc-accel w.r.t. snap.
In Snap we only had 8 bits, now we have 21 bits.
Also see: https://opencapi.github.io/oc-accel-doc/deep-dive/registers/#hdl-design

Setting these pins outside of a process:

  snap_regs(SNAP_REG_CONTROL)(1) <= '1'; -- dirty hack to always be done.
  snap_regs(SNAP_REG_CONTROL)(2) <= '1'; -- dirty hack to always be idle.
  snap_regs(SNAP_REG_CONTROL)(3) <= '1'; -- dirty hack to always be ready.

and also resetting them in a clocked process:

      -- Reset
      if action_rst_n = '0' then
        snap_regs(SNAP_REG_CONTROL) <= (others => '0');
      end if;

causes a critical warning for multiple drivers.

The scripts in oc-accel generate a simulation project without the needed flags to support vhdl2008.
We should try to add this flag, while making sure this does not create compatibility issues.

Right now, the workaround is to replace a process sensitivity list (all) with all the actual signals.

The runtime code expects the fletcher submodule to be checked out. However, the demo code expects FLETCHER_DIR to be set. This should be streamlined (preferably with it integrates with the oc-accel flow ).

oc-accel does not assert reset from the very beginning. That causes some stuff to be in an undefined state for a little while, which causes some assertions in fletcher to trigger a failure. These need to be converted into warnings for a fletcher design to work in oc-accel (see the patch in the README). I want to automate that.

If the data width differs between the config of oc-accel (the option in the menuconfig to select between 1024 and 512 bits) and the C_M_AXI_HOST_MEM_DATA_WIDTH generic in action_types.vhd, there is no error or warning, the simulation will start (seemingly without problems), but the application will just not work.