| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note that the default MTU forwarding policy is ONE_TO_ONE, therefore,
it is only strictly necessary to modify the MTU forwarding policy for
blocks that route data in a different manner. However, it may be nice to
explicitly state the forwarding policy for the benefit of the reader.
The following blocks had their policies updated:
- addsub: ONE_TO_FAN
- duc: ONE_TO_ONE
- dmafifo: ONE_TO_ONE
- null block: DROP
- replay block: DROP
- split stream: ONE_TO_FAN
- switchboard: ONE_TO_FAN
|
| |
|
|
|
|
|
|
|
|
| |
The host code was calculating and programming a 32-bit value for the DSP
frequency, but the DDS modules in the FPGA only use the upper 24-bits.
This led to inaccurate frequency values being returned. This change
corrects the resolution of the value on the host side so an accurate
value is returned.
Signed-off-by: michael-west <michael.west@ettus.com>
|
| |
|
|
|
|
|
|
| |
As Github user johnwstanford points out, the DUC calls the argument
'input_rate', which is wrong (and was copy/pasted from the DDC code). By
calling it dds_rate in both cases, we avoid such confusion.
This commit only renames a variable. No changes whatsoever.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The tuning range of the DUC depends on the output sample rate (which is
larger), but it was using the input sample rate. This was causing a bug
where for Tx, the DSP tuning range was limited when using multi_usrp API,
and thus would not allow to DSP-tune beyond the current sampling rate.
In this patch, we also re-use the existing calculation of the sampling
rate, and harmonize that code between duc_block_control and
ddc_block_control.
Consider the following Python REPL code:
>>> import uhd
>>> U = uhd.usrp.MultiUSRP('type=x300')
>>> U.set_rx_rate(10e6)
>>> U.set_tx_rate(10e6)
>>> # Creating a streaming is required, or the input rate will not be
>>> # set:
>>> S = U.get_tx_stream(uhd.usrp.StreamArgs("fc32", "sc16"))
>>> treq = uhd.types.TuneRequest(1e9)
>>> treq.rf_freq = 1e9
>>> treq.dsp_freq = 50e6
>>> treq.dsp_freq_policy = uhd.types.TuneRequestPolicy.manual
>>> treq.rf_freq_policy = uhd.types.TuneRequestPolicy.manual
>>> tres = U.set_rx_freq(treq, 0)
>>> print(str(tres))
Tune Result:
Target RF Freq: 1000.000000 (MHz)
Actual RF Freq: 1000.000000 (MHz)
Target DSP Freq: 50.000000 (MHz)
Actual DSP Freq: 5.000000 (MHz)
>>> # Note the last two lines: The *target* DSP freq was already clipped
>>> # to 5 MHz. These lines show 50.0 MHz when this patch is applied.
This bugfix is accompanied some related changes:
- The unit test is amended to verify the behaviour
- The API documentation is amended with details on its behaviour
|
| |
|
|
|
|
|
| |
Its behaviour is almost identical to std::lround, which we use instead.
The only downside of std::lround is that it always returns a long, which
we don't always need. We thus add some casts for those cases to make the
compiler happy.
|
| |
|
|
|
|
|
|
|
| |
The checks from the new clang-tidy file are applied to the source tree
using:
$ find . -name "*.cpp" | sort -u | xargs \
--max-procs 8 --max-args 1 clang-tidy --format-style=file \
--fix -p /path/to/compile_commands.json
|
| |
|
|
|
|
|
|
|
| |
Sets time increment based on tick rate and sample rate instead of
assuming one tick per sample. Defaults to legacy behavior.
Minor compat number bumped on DUC and DDC blocks.
Signed-off-by: Michael West <michael.west@ettus.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds (and calls) methods to manually pass radio block sample rate
to the input/output properties of the ddc/duc during creation of the
multi_usrp_rfnoc object. The ddc/duc require this information in order
to return valid, possible output/input sample rates in
get_rx_rates()/get_tx_rates().
Before, the ddc/duc wouldn't have this rate until the rfnoc_graph had
been connected and committed, which happens in
get_rx_stream()/get_tx_stream(). Thus, this fixes an issue where a user
was unable to query possible sample rates prior to specifying a sample
rate and creating a stream.
|
| | |
|
| |
|
|
|
|
|
|
| |
Allows RFNoC blocks to perform register peeks and pokes on blocks with
multiple channels without having to worry about handling register address
translation every time.
Signed-off-by: mattprost <matt.prost@ni.com>
|
| |
|
|
|
| |
Note: template_lvbitx.{cpp,hpp} need to be excluded from the list of
files that clang-format gets applied against.
|
| |
|
|
|
|
|
|
|
|
|
| |
This combines two intertwined changes:
- The scaling_in and scaling_out properties of the DDC now start off
uninitialized. This is to avoid invalid loops of property resolution:
When the block is first initialized in a graph context, the default
values for scaling over-constrain the resolution problem.
- The resolver for samp_rate_in used to prefer changing samp_rate_out,
it now prefers to modify the decimation. This is necessary to allow
calling set_output_rate() before the graph is committed.
|
| |
|
|
|
|
|
|
| |
- Use coerce_decim(), not int(), to coerce the decimation rate
- Fix typo
Fixes: a36fc4604f9b ("rfnoc: DDC: Fix property propagation")
Fixes: 36853315741a ("rfnoc: Add DDC block controller")
|
| |
|
|
|
|
| |
Only update DDC/DUC samp_rate properties if the number is substantially
different (don't update for sub-1Hz property calculations). This fixes
resolver exceptions for certain rates.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MTUs are now tracked through the framework for all childs of
noc_block_base. Every edge gets an 'mtu' property. MTU can be set and
get either through the prop API, or through new API calls (get_mtu(),
set_mtu()). It is also possible to create custom properties that depend
on the MTU by asking for a reference to the MTU property, and then
adding that to the input list of a property resolver.
The radio_control_impl includes a change in this commit where it sets
the spp based on the MTU.
Blocks can also set an MTU forwarding policy. The DDC block includes a
change in this commit that sets a forwarding policy of ONE_TO_ONE,
meaning that the MTU on an input edge is forwarded to the corresponding
output edge (but not the other edges, as with the tick rate).
|
| |
|
|
|
|
|
|
|
| |
- Combine scaling and samp_rate resolvers
- Prioritize decim when user has set it for DDC:
When samp_rate_in changes, either the samp_rate_out or the decim
values may change to accommodate it. If decim has been set by the
user (which can be determined by the valid flag), prefer changing
samp_rate_out over decim.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During registration, blocks must now specify which clock they are using
for the timebase (i.e., for timed commands) and for the ctrlport (this
is used to determine the length of sleeps and polls). For example, the
X300 provides bus_clk and radio_clk; typically, the former is used for
the control port, and the latter for the timebase clock.
Another virtual clock is called "__graph__", and it means the clock is
derived from property propagation via the graph.
The actual clocks are provided by the mb_iface. It has two new API
calls: get_timebase_clock() and get_ctrlport_clock(), which take an
argument as to which clock exactly is requested. On block
initialization, those clock_iface objects are copied into the block
controller.
The get_tick_rate() API call for blocks now exclusively checks the
timebase clock_iface, and will no longer cache the current tick rate in
a separate _tick_rate member variable. Block controllers can't manually
modify the clock_iface, unless they also have access to the
mb_controller (like the radio block), and that mb_controller has
provided said access.
This commit also adds the clock selection API changes to the DDC block,
the Null block, and the default block.
|
| |
|
|
|
|
|
|
|
|
|
| |
All noc_block_base derivatives are now plugged into the tick rate
system. Connected nodes can only have one tick rate among them. This
implies there is also only ever one tick rate per block.
set_tick_rate() is a protected API call which can be called by blocks
such as radio blocks to actually set a tick rate. Other blocks would
only ever read the tick rate, which is handled by the get_tick_rate()
API call.
|
| |
|
