GitLab

  * phase alignment of the clock driving the logic with the input reference
    clock to the MMCM. Done with an additional BUFG used on the clock out
    feedback path
  * additional gpio pins and sync inputs

  * fix gateway bitwidth and drawing update
  * fixes mixer/output configurations for both ADCs and DACs on both DT and QT.
slices within a tile can propely be configured differently
  * system clocking is now hidden for DT parts where the DT platform file is
used to pass along the clocking information like previously done (this needs to be
updated and improved since 3rd gen DT parts can support clock forwarding)

  * fixes on mask configuration for data port widths
  * fixes for dt/qt differences and mask enable/disable sequences
  * implement validation of analog data configurations for the dac, duc fixes

  * The previous rfdc applied same adc slice configuration to all enabled tiles. Now can configure independently.
  * Add support for DAC and tested on 49dr parts. Needs to be abstracted to
  * generic rfsoc parts to work on DT and first gen parts
  * Still need to validate DAC output configurations
  * The mask does take a long time to load, working on ways to improve response
  * There is a bug with adc port configuration may not have the correct width,
    Disable slice, apply, re-open and re-enable slice
  * Change tile clocking to move it out of yaml and into a clocking tile tab.
    There is no real check on validation, vivado will fail for invalid clocking
    setup

add cdc synchronizer module to do the pl capture. Only for adc, would need to be
extended like rest of the toolflow for dacs.

add port number to mmap register names to give them a unique for when multiple
cores exist in the design

Bring rfsoc up to date with m2019a. Development was originally from `master` but
using m2019/m2020 and as code added was isolated to developing the yb/hdl
support needed for other blocks was not needed and affected.

Notes on from about resolution to some of what were the conflicts shown below:
with 100g, preference was given to keep the rfsoc development branch work as it
incorporates on top what m2019a would have supported but now is more general by
supporting zcu216/208 where gtys are split between quads.

For the 40g commits, those were discrepancies in the diverging development of
master and m2019 with preference to adopt all of m2019a

Conflicts:
	.gitmodules
	jasper_library/constraints.py
	jasper_library/hdl_sources/forty_gbe/SKA_40GBE_MAC/ska_forty_gb_eth.vhd
	jasper_library/hdl_sources/forty_gbe/SKA_40GBE_PHY/IEEE802_3_XL_PHY_top/IEEE802_3_XL_PHY_top.vhd
	jasper_library/hdl_sources/forty_gbe/SKA_40GBE_PHY/IEEE802_3_XL_PMA/ip/XLAUI/xlaui_us.xci
	jasper_library/hdl_sources/onehundred_gbe/casper100g_noaxi.v
	jasper_library/hdl_sources/onehundred_gbe/cmac_shared/gtwizard_ultrascale_v1_7_gtye4_common.v
	jasper_library/hdl_sources/onehundred_gbe/ip/EthMACPHY100GQSFP4x/EthMACPHY100GQSFP4x.xci
	jasper_library/hdl_sources/onehundred_gbe/kutleng_skarab2_bsp_firmware
	jasper_library/hdl_sources/skarab_infr/WISHBONE/wishbone_forty_gb_eth_attach.vhd
	jasper_library/hdl_sources/utils/cdc_synchroniser.vhd
	jasper_library/memory.py
	jasper_library/toolflow.py
	jasper_library/yellow_blocks/forty_gbe.py
	jasper_library/yellow_blocks/onehundred_gbe.py
	jasper_library/yellow_blocks/sys_block.py
	startup.m
	xps_library/xps_library.slx

Rework of previous commit to add the new VitisBackend class. The flow can
be ran with --vitis switch along side the --backend command or standalone
with a valid `.xsa` with the --xsa switch.

This somewhat marks a milestone in supporting rfsoc/rfdc within the toolflow.
Because with these changes here in addition with supporting software from
casperfpga/tcpborphserver a design can be created from simulink and loaded with
casperfpga and functionality of the rfdc and board can be done without any other
manual bootstrapping.

This current commit will break for non zynq soc's. It merley is an intermediate
staging of complete and successful integration of the rfdc from platform, to yellow block,
to the linux software driver. The hsi/xsct/py scripts that were added have been
removed in favor of just tracking the required within the rfdc yellow block.
This was a choice made to just keep the required dt generation within the rfdc.
Because at this point, while any MPSoC with a board desgin can be used to create
a valid Vitis platform and software project we are really only using it within
the context of rfdc and rfsoc. However, the way it is implemented *does not*
limit the ability to extend further. Instead, it just provides a convenient way
to keep functionality where it needed most until (or maybe it never happens)
when more of this functionality wants to be extended. At that point perhaps a
more general implementation.

From here is to start a small Vitis back end class that will allow compatability
with all of the tools

Also more formally support the pynq rfsoc2x2 by finishing out its platform
definition, yellow block creatino and adding to the xps library

zrf16_29dr base board design updated to use the correct ddr for the board. It
had been working but noticed that the ddr was different than the original
schematic which is what the board design was set for.

most likely will remove these from the repo to implement
within the yellow block. Until much more of the Vitis/software/device
tree support is integrated it would make more sense for everything to
be local to within the rfdc. When more functionality is added for xsct
support it could be more advantages to have more scripts or structure

still not sure where the best place to add this yet, but it is atleast a
standalone method

still not sure where the best place to add this yet, but it is atleast a
standalone method

Add support for zcu216/208/111 zrf 29/49dr

Extends CMAC 100G IP sources to support instancing 2 COMMON primitives for GTYs
split between 2 MGTs. This is needed for platforms like ZCU216/208 that use
4xSFP28 but with 2 GTYs into bank 128 and the other 2 into bank 129. Out of the
box, the Ethernet 100G Subsystem IP does not support this configuration, only
supporting when all 4 lanes for CAUI-4 come into the same quad.

Changes here modify how the CMAC IP is instanced to not include `GTYE4_CHANNEL`
placement and shared resources like `GTYE4_COMMON` primitives within the core.
Instead these are instanced with other modules that allow for dynamic changes
based on platform layout to "unify" support across different platforms of the
two possible GT placements. The `gmacqsfptop` modle now instances one of the
`cmac_usplus_core_support` modules wrapping the CMAC IP to interface correctly
with these new modules common to different
implementations.

These changes depend on the changes made in the `kutleng 100G IP` repo by
modifying the `gmacqsfptop` module to now instance the correct support core and
use the generic to allow for placing additional COMMONs. The kutleng repo is to
be placed at `jasper_library/onehudred_gbe/`

Both the RS-FEC and non-RS-FEC (wrapped by `cmac_usplus_core_support_norsfec`)
version have been updated and was tested on a zcu21. Note, had to disable
RS-FEC on the receving switch/NIC when testing the non-RS-FEC over CR4.

remove current 100g sources

* Finish adding and testing having all rfdc ports in the block design external
and then using jasper to wire it all together. This gives us the advantage of
having the IP in the block design. We don't get everything we want with by
being able to use the full software project flow of hsi to generate the device
tree overlay. This is because vivado/hsi/vitis cannot resolve a clear memory
peripeheral path. There seems no way that I could see to declare that path by
declaring in vivado's memory spcae manager a specifc address space for the rfdc
within the `M_AXI` that was being used to connecet to the casper axi4-lite
interconnect. But we can export the hardware definition and the rfdc IP is
declared within the hardware project brining everything along with it so we can
use the `hsi` calls to build the device tree overlay ourselves and augment what
`hsi` outputs. This will be the next step, to automate this flow. But the main
components are in `hsi-plnx`.

* added pynq2x2 mask, platform definition, and yb. The yb is complete (as it is
similar to the zcu111) but the platform definition needs to be finished in order
to build out. Not going to be ready by conference as spent most time working on
tcpborphserver the last couple weeks.

Other last minute changes. Very likely more bugs introduced in doing this but at
the very least have tested rebuilding examples against the zcu111/zcu216/zrf16
and still works:
  * fix adc `clk_out` and pll `ref_clk` lists not updating in gui
  * fixed problem with disabled tiles still being editable
  * fixed not being able to get 8 samples w/ 1x dec at max fs on zcu111
  * add fine and coarse nco frequency options (simulink and rfdc yb)
  * add analog control settings - Nyquist zone/Calibration mode (simulink and yb)
  * update xps_library with rfdc changes to analog/nco freq controls
  * update xps_library to at least show the pynq2x2

The rfdc is still added to the block design but instead of enabling a seperate
AXI interface for interfacing with the rfdc AXI memory map it will still be
controlled by the CASPER AXI4-Lite interconnect block. This complicates a little
bit the expected software flow for the rfdc as the xilinx block design is used
to create the `.xsa` that will populate driver information for all slaves with a
`memory path` to the MPSoC. Since we are just adding the rfdc as a standalone
block with no connection to the MPSoC this path does not exist and therefore
the rfdc driver will not automatically be registered in the software design from
the `.xsa`.

All is not lost though. With the rfdc still in the block design its IP
configuration is still present in the hardware design. It just won't have a
software design component. So instead, we can still use the hardware design
information to manually create our own software output produts. Here we are only
really concerned with using the already builtin xilinx rfdc driver. So we only
need the device tree overlay as required by that driver. This process would be
the same though if CASPER were to wish to create more sophisticated drivers for
our IP (e.g., when we say port the tools to vitis this is what we would do).

This commit stages the new block designs and rfdc yellow block for this change.
The software part of creating the rfdc device tree overlay has been done. It
just needs to be wrapped into the tools (those files not added here yet).

Additionally, modified the `gen_xps_add_design_info` to include the rfdc in the
meta data infromation for use in caperfpga.

Misc. changes to rfdc for extending the NCO are also added here (just hard coded
and commented out though as I needed them to just test something in the lab --
need to extend to the simulink mask).

Adding new platforms and updating rfdc mask with DT and 1st gen support

The idea here is that on RFSoC platforms the LMK provides a `PL CLK` (different
net names on different platform schematics (`PL_CLK` on zcu216/208,
`FPGA_REFCLK` on HTG zrf16 and zcu111). The user is then expected to provide
their LMK clocking configuration here so that the platform clocking
infrastructure can generate the required user IP clock.

test designs both use the mask from zcu216 (as it still needs to be added to the
library) but does complete through the toolflow. Needs to be tested on the
hardware.

Simulink rfdc mask and rfdc yb extend support for both DT and 1st gen parts.
Simulink mask also now correctly adds/updates/draws ports nicely.

This has again made the mask slow and a little more urgent to resolve. The mask
also has a few configuration bugs such as the sample rate does not update the
pll ref clk list as expected.

The `test_htg` model is able to build out for the 49dr part. But fails for the
29dr version. This is most liekly due to the lack of implementing out support
for the gen 1 rfsocs in the xps library mask and rfdc yellow block. Need to
investigate. Will go back and extend/improve when also adding support for the
rfsocs on the zcu208/zcu111 as they are dual tile architectures that also needs
to be supported in addition to any gen 1 quirks in the xps library mask.

The zrf16 made by htg has two versions of the board. One with a 1st gen 29dr
rfsoc and the other that is a 3rd gen 49dr rfsoc. The boards I have worked on
are almost identical in layout except for the PS DDR4 configuration on the 49dr
is different.

The approach here is then to have a single zrf16 platform to instance that
selects between the two revisions of the board. This seemd to make the most
sense as to try to achieve a way to support to boards without maintaining two
separate y...

This requires that the platform using the rfdc has a specified name scheme for
the base block design