The image builder will currently emit a warning if a NoC-block has
unconnected ports. This requires specifying `-W` to continue building,
which is the intended behaviour.
However, there are cases where there are legitimate reasons to not
connect a block, e.g., in the X310, where the radio block has 2x2 ports,
but we only connect 2 RX ports, and 1 TX port.
This adds a way to declare a "null" connection, which makes it explicit
in the image core YAML that a connection was deliberately omitted. Such
connections are created by connecting to a port called "_none_", e.g.:
```
connections:
- { srcblk: _device_, srcport: _none_, dstblk: radio0, dstport: in_1 }
```
The block name is irrelevant, but the schema requires providing a block
name.
This commit also amends the x3xx_radio_base.yml to avoid warnings when
building X3x0 bitfiles.
Original-commit: 6758966a5ac127a396e8b3b39f96aa484098e50f
- 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
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 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
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
Adds a BUILD_BASE_DIR makefile variable that allows you to specify the
base directory for FPGA build outputs. This allows you to put the
output from each run of make into a unique directory, or to run
multiple instances of make in parallel with each build's output being
put in a different directory. For example:
make X310_XG BUILD_BASE_DIR=/path/to/builds
Original-commit: bc6db8409ba756bbad0d0c158ffb00c614b58fd9
Adds a BUILD_SEED make variable that can be set to a 32-bit integer,
and adds an FPGA read-only register initialized by this variable.
Changing this variable will randomly affect the FPGA build results.
This can be useful when your build fails timing by a small amount,
allowing you to build again and get different results with the same
code.
For example, you could run the following to produce an FPGA build with
different timing results from the default build:
make X310_XG BUILD_SEED=123
Original-commit: 3a3a03486f9221c2e59fa6d0826c23d17730956d
The FIR filter applied gain. Removing it caused incorrect scaling and
signals where every other sample was zero. Also parameterized heterodyne
frontend processing so it would not use resources in images not
requiring it.
Signed-off-by: michael-west <michael.west@ettus.com>
Original-commit: c27519624ec0f3a44ac1130635a03dafcf2e7f13
- Bump firmware compat to 6.1
- Remove crossbar counter logic (the FPGA does *not* support crossbar
counters anymore, so we remove it from the firmware as well)
- Remove crossbar programming control (this is now provided by RFNoC
management packets)
- Remove UDP framing control (this is also provided by RFNoC management
packets)
- Remove Ethernet link/activity LED control (this has been handled by
the FPGA directly for years now)
- Add functionality to program transport adapter. The TA is programmed
directly on the settings bus, so for the most part, this is already
possible from the firmware. The only exception is the 'virtual'
register to program IP address and MAC at the same time. In the
firmware, it will perform an ARP lookup of the MAC address, and then
write the "normal" IPv4 address register in the TA, as well as the MAC
address registers.
- Updated bootram.coe
Original-commit: 89fb75288e151cd1e43af765618c0665e79801f9
Patch AR76780 was already listed as a requirement for X4xx and N3xx,
but was not listed as a requirement for X3xx and E3xx. This change
makes it required for all Vivado-based USRPs.
Original-commit: 5aa6bc4418a30d6e6fde80b80632f9f9115ea5c4
This adds the ability to do IP generation and FPGA builds using the
--jobs (-j) option with Make. For example, rather than generating each
IP one after another, you can generate up to N at a time using N Vivado
instances. This greatly reduces the IP generation time. Similarly,
parallel jobs can be used to easily build different FPGA variants
simultaneously.
Because FPGA builds can consume a lot of memory, care must be taken to
ensure that the number of jobs is not too high for the amount of memory
available.
New IP make targets were added for each USRP so that IP can be built
separately from the FPGA. The IP targets are now a dependency on each
FPGA target.
For example, you can generate the IP for X310 using 4 parallel jobs
using the following command:
make -j4 X310_IP
Or, build two X310 bitstreams simultaneously:
make -j2 X310_XG X310_HG
Original-commit: 4b03e237a96ee277eefff257d65b08708c38662c
This causes the latest RFNoC protocol version to be used by default
and avoids the need to update YAML files every time the RFNoC
protocol version gets bumped.
Original-commit: 92016a585a5223a9a7678134e318e412875b64c2
Update USRP RFNoC iamge core YAML files to use the more consistent
device port names. Clean up the formatting and make the files more
consistent.
Original-commit: 6318eaeff548f760056af7c8172937a296409d25
This updates all RFNoC devices so that they get the RFNoC protocol
version and CHDR width in the same way, from the output generated by
the RFNoC image builder.
Original-commit: 6f038dc2f69b38e715206b2e700fdd3a1bbc638e
Before this change, only the channel 0 ATR state was sent to the
db_control module. For TwinRX, this had the disadvantage that when only
Channel 1 was used, the FP- and LED-GPIOs could not track the radio's
ATR state (e.g., no LED would light up in this case).
Note that unlike UHD 3, there is only one db_control module per slot.
There are therefore no options to map GPIOs to track the ATR state of an
individual channel.
Original-commit: f23ab72129041777bcd3357a1f4e37b29e62dd86
This sets the ARCH and PART_ID environment variables so that the
selected part family is used for simulations by default. This can be
overridden by changing them in the Makefile for the testbench if a
testbench requires a specific part family. Prior to this change, the
default was always ARCH=kintex7, PART_ID=xc7k410t/ffg900/-2, which
required support for that part to be installed.
Original-commit: c176046dff4941bcec27b0b72e5a68264c4808e5
Update rfnoc_image_core.v to take into account the new image_core_name
fields and version strings. Add new rfnoc_image_core.vh. Update YAML
where needed.
Original-commit: b0033158a4c520063540881451d8daac91e98714
Change version from a numeric to a string, in order to
differentiate between versions like "1.1" and "1.10".
Original-commit: ca21048bd2f832b20bb36763f76d46b861b697a5
Add the Replay RFNoC block to the RFNoC core image for x300, x310, n300,
n310, n320/n321, and e320. The Replay block is contained within its own
static connection, so previous default behavior is still supported.
Signed-off-by: mattprost <matt.prost@ni.com>
Original-commit: 437381bd2cfe137c5e7e2a70aab8226bfb1c70cd
This updates the IO signatures so that all devices and RFNoC blocks use
the same IO signature for the DRAM. This is needed because the IO
signatures must match between the RFNoC blocks and the devices. This
means that some devices have extra bits in the IO signature for the
address, but the extra bits will simply be ignored.
Original-commit: 8f09caaa06725d2364c63ac7cff02f3298895f4a
The address ranges configured for the AXI interconnect IP limited the
amount of accessible DRAM to two 32 MB regions. This change makes the
full 1G available to all DRAM ports.
Original-commit: bba0cddfadcb744e8a6fae27d57ba8d3995eaf64
Make timekeeper tick on every cycle of the radio clock.
Signed-off-by: Michael West <michael.west@ettus.com>
Original-commit: 7886b71f13e9f6e5786c95286ef98f49ab716119
Adds a ZPU register to control the FP GPIO source. These are 2bits
per GPIO pin, totalling 24 bits. 0 corresponds to RF-A, 1 corresponds
to RF-B. The following Python code will control the upper 6 bits of the
front-panel GPIO from the B-side radio on an X300:
>>> import uhd
>>> U = uhd.usrp.MultiUSRP("type=x300")
>>> U.get_gpio_src_banks()
['FP0']
>>> U.get_gpio_src("FP0")
['RFA', 'RFA', 'RFA', 'RFA', 'RFA', 'RFA', 'RFA', 'RFA', 'RFA', 'RFA',
'RFA', 'RFA']
>>> U.set_gpio_src("FP0", ['RFA', 'RFA', 'RFA', 'RFA', 'RFA', 'RFA',
'RFB', 'RFB', 'RFB', 'RFB', 'RFB', 'RFB'])
>>> U.get_gpio_src("FP0")
['RFA', 'RFA', 'RFA', 'RFA', 'RFA', 'RFA', 'RFB', 'RFB', 'RFB', 'RFB',
'RFB', 'RFB']
>>> # Make all GPIOs outputs:
>>> U.set_gpio_attr("FP0A", "DDR", 0xFFF)
>>> U.set_gpio_attr("FP0B", "DDR", 0xFFF)
>>> # Control all GPIOs from software (not ATR):
>>> U.set_gpio_attr("FP0A", "CTRL", 0x000)
>>> U.set_gpio_attr("FP0B", "CTRL", 0x000)
>>> # Bottom 3 pins go high from radio A
>>> U.set_gpio_attr("FP0A", "OUT", 0x007)
>>> # Top 3 pins go high from radio B
>>> U.set_gpio_attr("FP0B", "OUT", 0xE00)
Amends the gpio.cpp example to allow switching the source.
Co-authored-by: Brent Stapleton <brent.stapleton@ettus.com>
Original-commit: d7304cc724de43b0d61d5b9d61a528d58898f004
Martin Braun