- 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
Rename the BIST image cores to match the default image core names. This
eliminates the need to provide special arguments to build these images.
Original-commit: aae712c2eafe3f78ba8ed553190f7010a2d17c57
It is, in principle, possible to use an external clock to synchronize
N3x0 devices in frequency, and then use a GPSDO for a coarse time
synchronization. This use case is deliberately not supported, as the
GPSDO PPS signal and the external clock signal are by definition not
matched, which will remove any guarantees on time/phase alignment.
Because there are certain, niche use cases where the lack of phase
alignment is acceptable, but only an external clock is available (no
shared external PPS), usage of GPS for generating a PPS signal may be
fine. This patch does not enable the usage of this combination out of
the box, but adds comments and an update to the manual to explain the
risks of this combination, and how to enable it (by patching MPM).
Original-commit: 76e004db07a3714139e64ff396a81b90c372b2bb
This removes a duplicate code section that causes build warnings. It
also references a wire that gets declared further down and the removed
and remaining code sections were incorrectly indented.
Original-commit: e8084eb4cb4ec6ff6476feb6e77ab3ea45dd969e
In several cases, we call `python` explicitly. On many modern operating
systems (e.g., Ubuntu 22.04), this command no longer exists, and if it
does, it's often an alias to python3.
Because the python3 executable has been around for so long, simply
using that directly (instead of, e.g., autodetecting the OS preferences)
is a simple fix that immediately allows building bitfiles, e.g. for the
B2xx series, on more recent OSes.
Original-commit: 356cd172bb5ae0d043825bd1f4dffbd6646ec3d2
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
- Update X410 and X440 BSP YAML files to properly index clocks
- Update image core files to declare clock indices
- Update get_clocks() in MPM to return the correct values
This does not include changes to the x400_radio_control block registry.
This change by itself will thus not change behaviour.
Original-commit: f215af2ccde6420b685b4ca493c8bd71d28781cb
This adds support for the X440_X4_200 variant which supports up to
200 MHz bandwidth (250 Msps), has a DDC and DUC on each channel,
4 x 10 GbE interfaces, and no DRAM.
Original-commit: bdaba58750ce0c2ccc58769936c3c5c4a6b2d2cf
Adds a 266.667 MHz compute engine clock and uses it instead of the
radio clock for the DDC and DUC. Using a faster clock than the radio
allows the DDC and DUC to drain after a stall in the data flow.
Original-commit: ab93cb0929b9536b6d6cbfdc4813e6ba169053ae
Adds a 266.667 MHz compute engine clock and uses it instead of the
radio clock for the DDC and DUC. Using a faster clock than the radio
allows the DDC and DUC to drain after a stall in the data flow.
Original-commit: ff55d406a02cc934a5c238d22c836bea08ade3d1
FPGA:
- Split up MB registers that control daughterboard specific settings so
that daughterboards 0 and 1 could have different setings, in
preparation for future devices that require different settings.
This requires a compat number bump to 8.0.
- Add registers for additional RFDC information, including the
block/tile mapping of the individual channels, and information about
resampling capabilities
- Identify sections of code that would be specific to X410/ZBX and move
them to their own headers, so it's trivial to add device-specific
sections of code instead for other devices in the future.
- This includes constraints for clocks and I/O pins.
- Remove ability to do timed ctrlport transactions to the MB CPLD, this
was unused and possibly broken.
- Move daughterboard-specific code into its own code location
(dboards/zbx)
- Move X410-specific register documentation to its own location
(doc/X410)
- Refactor Makefiles to split out X410/ZBX specific components and allow
switching between device types
- Add 512-bit AXI interconnects
- Make number of timekeepers configurable (X410 keeps the single
timekeeper)
MPM:
- Required compat is bumped to 8.0
- Now supports new registers for detecting DSP capabilities and
multi-rate settings for the daughterboards
- Adds MMCM controls (currently unused)
Co-authored-by: Wade Fife <wade.fife@ni.com>
Co-authored-by: Ryan Marlow <ryan@lmarlow.com>
Co-authored-by: Martin Braun <martin.braun@ettus.com>
Co-authored-by: Humberto Jimenez <humberto.jimenez@ni.com>
Original-commit: c1d268917ea65dd9c5a42366014cb96d3c025223
The frontend synchronization upon time change was removed, but is
required to synchronize the RX frontend modules when sharing LOs on
TwinRX. This change restores the behavior.
Signed-off-by: michael-west <michael.west@ettus.com>
Original-commit: c70b479007ab9f578577dfb5c2de6660e877d9a3
Martin Braun