GitLab

Addition of mpsoc configs for each platform. Tested at least up toRFDC tutorial
with these. Completed the zcu208 (mostly been complete but not built out). Updated rfsoc2x2.
Fixed axi gpio to have an address assigned

Tested associated platform, rfdc, and onehundred gbe tutorial all working well

The rfsoc4x2 port here uses the new vivado block design toolflow feature to
build a block design instead of sosurcing an exported tcl script. The intention
(hope) being that this is more forward and backward compatible with vivado
versions. The rfsoc4x2 platform file here is rather messy now but demonstrates
using the yellow blocks that are based in vivado block designs (mpsoc, xilinx
axi interconnect, protocol converter) to place and wire those connections up.

Here, the creation of a vivado block design inserts itself as a
`create_bd` stage. This is done during the `add_compile_cmds` of the backend
with each yellow block implementing a `modify_bd` method.

Considering that the generation of a block design is a list of tcl cmds it would
be possible to have this functionality be contained within the `gen_tcl_cmds`.
However, the idea here is to provide an infrastructure with the block design
(.bd) file treated more as a source like the top module being a Verilog class.
To do keep this in `gen_tcl_cmds` as it is implemented now would require a
modification to that structure, or to have the block design more amorphous to
the process.

However, considering this, and that the rfdc still uses `gen_tcl_cmds` that is
accomodated here by waiting until all yellow blocks have a chance to modify
block design and using the save/validate as part of a pre-synth stage. The idea
is to migrate the rfdc to use a `modify_bd` unless otherwise reverting back to
`gen_tcl_cmds` for everything.

there are still assumptions that need to be made regarding the connections and
how to wire them up. This needs to be worked out next.

Also the approach to adding a block design to the `VivadoBackend` class requires
that it doesn't break the flow for designs that do not use a board design. This
needs to be tested.

For the rfsoc, lays out a similar board design. Missing the GPIO,
AXI addressing and actually finishing the project flow

Loader (or UnsafeLoader) is the 'backwards compatability' option and at the
moment SafeLoader should work, but something like castro.yaml might break
something so downgrade and test first

  * 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