This was set to 1 in UHD 4.7, but it must be 2 for all channels to
have sufficient bandwidth.
Original-commit: b012c18fd653714e84b1d4a86e27ff90fe13ae04
Together with an update to the LMK04832 register config according to
TIs data sheet, all clock outputs are now aligned to SYSREF rising edge.
Therefore, I needed to adjust the SYSREF capture mechanism inside the
RFSoC and the SYSREF LMK Delay.
SYSREF is now captured first at the falling edge of PRC.
To be on the safe side, we are still double synchronizing SYSREF
afterwards on the rising edges of PRC.
As we are now independent of any MCR regarding timing constraints the
SYSREF Delay is also set to '0' for all X4xx devices.
Original-commit: b5cb4fac42ab530174e108455b730ffa1510d70a
This simplifies image core files by generating a RADIO_NIPC parameter
for the X410, X440 and E31x BSP files. The IO port widths for X410 are
now dynamically widened based on the NIPC value, which is a function of
the RF_BW parameter, and cannot be modified.
The radio block can now read the NIPC value from the BSP, and populate
its spc parameter dynamically. This avoids having to know the right spc
value when writing YAML image core files and reduces redundancy.
This also removes the RADIO_NIPC parameter entirely from all the image
core files. This parameter was fine, but it was a bit confusing because
it referenced a Verilog parameter, which you just had to know was there
in the generated Verilog. By referencing the BSP parameter instead, the
YAML files (BSP, radio.yml, and image core file) are now self-contained
regarding the RADIO_NIPC/spc information.
As a minor upside, the input wire widths for X410's and N310's
rfnoc_image_core.sv module are now generated with the correct widths,
and not, as before, with the worst-case width (and then we assume Vivado
will do the right thing).
Original-commit: 53b4d7a21018fe7aabf9f774260aefb41297a41b
... to support custom image core name, example:
rfnoc_image_builder -y n310_rfnoc_image_core.yml -n my_custom_name
The device tree source files were renamed to match the target
name used in the Makefile.
example:
old: dts/usrp_n310_fpga_hg.dts
new: dts/N310_HG.dts
The source file is used to compile the final .dts file in the BUILD_DIR.
example: build-my_custom_name/N310_HG.dts
The final .dts file is copied to the BUILD_OUTPUT_DIR as part of the
post build steps and renamed to the custom image core name.
example: build/my_custom_name.dts
This completes the change that was introduced with commit 2afc66f132.
Original-commit: d40db57f2e03c322ac6b0001e0a59d4a14a5a3b9
Not a functional change. The comments for the replay block in the
crossbar_routes reflect a single replay block, but the FPGA image
actually has two replay blocks with half the number of ports as the
single block design.
Original-commit: 32efa102ce592ff16204b67b9aeb244e9589166e
This file was repeating entries from x410_radio_base.yml, which none of
the other x410 image core YAML files do.
Original-commit: 1ba6fdaf9c3a17cbb46f976f9d4dd8349cf5adb7
- All RFNoC capable targets now require rfnoc_image_builder to be built
- `make help` is updated for all targets to provide more useful and
up-to-date information
- The FPGA manual is also updated
- All checked-in build artifacts are now removed from git
- axi_ram_fifo.yml is updated to provide include path information
(required for building N3xx BIST images, which use this)
Original-commit: 28b994406d4c9547b1e2add62781b6a8162fdb74
- Bumps FPGA compat from 8.2 to 8.3
- Adds three global motherboard registers to read the 96-bit device DNA
- MPM is updated to read these registers and update the device_info if
compat version 8.3 is available
Original-commit: ad5f97f8284057b85ca98f47365c2a321edf7ece
This creates an IO port `pps` for X410, and two IO ports (`pps0`, `pps1`)
for X440 which allows modules inside the RFNoC image core to access the
FPGA. Note that accessing the PPS signal is generally not required for
RFNoC blocks which require access to timing.
Co-authored-by: Martin Braun <martin.braun@ettus.com>
Original-commit: c3525362643b56910692ad8ddc5d0e8cedd1869c
Most important effect of this change: rfnoc_image_builder is now
required to build bitfiles, 'make' alone won't suffice any longer!
This is a huge changeset to the image builder that combines multiple new
features:
- There no longer is a separate edge file for the static router. The
static routes are generated as a Verilog parameter directly into the
rfnoc_core_kernel (which is also modified).
- image_builder.py is split up into several smaller files. Code is moved
into yaml_utils.py, and the new files grc.py, builder_config.py
- Generic module support is added. Aside from noc blocks and stream
endpoints, we can now instantiate arbitrary modules (they also require
a YAML description file).
- To enable such modules, resets are now also tracked the same way that
clock domains are.
- The ImageBuilderConfig config object now more closes matches the
original YAML file. The attributes 'clk_domain_con' and 'block_con' are
removed. Instead, the attributes 'connections' and 'clk_domains' are
sanitized and amended with extra annotations. The templates are
updated to reflect this change.
- IO ports can now carry parameters, e.g., to have variable wire widths
based on the configuration.
- Many Pylint warnings were resolved.
- Add inheritance support for image core YAML files.
This allows image core files to (recursively) inherit from other image
core files. To do so, simply put an 'inherit' entry at the top of the
file:
```yaml
inherit: 'x410_radio_base.yml'
```
- The inheritance feature is used as part of the image core files.
- Image core and DTS files are now generated as a build artefact into
the build directory. This requires the usage of rfnoc_image_builder to
build images. As a consequence, it is no longer required to check in
image core Verilog files.
- As another consequence, rfnoc_image_builder is required to build
bitfiles!
- Image flavours are no longer defined through Makefiles, but purely
from the image core YAML files.
- Remove all image core YAML files that do not generate a shipping
image. Because of the inheritance feature and the requirement to use
the image builder, it is trivial to add new YAML files.
- Add support for transport adapters through the YAML files. Before,
transport adapters were inferred from the make target (e.g.,
X410_X4_200 would have four 10GbE links based on the 'X4' substring).
Now, transport adapters are defined via the image core YAML.
- This feature is currently only used (or can be used) by the X4xx
series. Older devices may or may not be ported to allow custom
transport adapters in the future.
- Add parameters to the BSP YAMLs and the devices itself. This allows
setting global parameters in the image core files. For example, the
X4x0 devices use this to decide if they instantiate DRAM channels.
- DTS includes and constraint files can now be requested by
blocks/transport adapter through their YAML files. They do no longer
need to be listed in the Makefile.
- Support for secure image cores. These are image cores that allow
incorporating RFNoC blocks that require license keys and thus can't
live in an open-source environment. This solution adds the option for
secure image cores without touching the open source feature set.
- Add --reuse option to allow manual editing of generated artefacts
- Allow IO signatures from any module: until now IO signatures had to be
defined in a single file (io_signatures). This file will persist. In
addition each module can add its own IO signature as with the same
format the core IO signatures placed under the top level key
`io_signatures`. IO signatures are still maintained in a global
dictionary. The consequence is that they can be shared among
independent modules as well as they have to have a globally unique
name. The image builder will warn about detected name clashes for the
signatures.
- As a consequence, some less commonly used IO signatures were moved to
their corresponding module YAML files.
Co-authored-by: Wade Fife <wade.fife@ni.com>
Co-authored-by: Lars Amsel <lars.amsel@ni.com>
Original-commit: a98ce2621e2a2dc25535fc700b49bfcb00b8eb59
This updates the RFNoC image cores to separate the two DRAM banks on
X4xx by splitting them into "dram0" and "dram1". Previously, both DRAM
banks shared the same DRAM port, named "dram", which created some
confusion.
The Replay block has also been duplicated in the bitstreams that use
both banks, so we now have one Replay block per bank.
Original-commit: b5cfab8922e5b3f4ff13a8a64e8b0319876f13db
Friedrich Wenisch