Hi Nidhi,
In the YML file you have the same clock input on the FFT block driven from
three sources.
- { srcblk: _device_, srcport: ce, dstblk: fft0, dstport: ce }
- { srcblk: _device_, srcport: rfnoc_chdr, dstblk: fft0, dstport: ce }
- { srcblk: _device_, srcport: radio, dstblk: fft0,
Q1) Yes, only one channel is required. Each channel has both send and
receive capabilities and you can use both simultaneously. However, note
that sending and receiving between host and replay block, and between
replay block and radio, simultaneously, would require two channels. For
example, one ch
I don't have any data on what the expected spread is. But I suggest you
double check that the fans are operating similarly to the other units and
that air flow around the unit is not blocked in any way.
Wade
On Tue, Oct 1, 2024 at 4:14 AM wrote:
> Hi Ettus Team
>
> I have a couple of USRP-2974
Hi Andrew,
This is true of all RFNoC images. The "ctrl" setting refers to whether or
not that endpoint has a connection to the control crossbar, which is used
for sending control packets (e.g., register reads/writes) to/from RFNoC
blocks. Because you can send control packets to any RFNoC block fro
With this FFT block, you need to set the SPP to match the FFT size for it
to work correctly. I'm not very familiar with GNU Radio but I think there
is an SPP parameter on the RX radio. I don't know how to set it for TX.
Wade
On Wed, Oct 23, 2024 at 5:45 AM Nidhi Panda
wrote:
> Hello,
>
> I am
You have to specify context_fifo_depthwhen using axis_pyld_ctxt. See, for
example, the addsub block.
On Tue, Mar 16, 2021 at 11:56 AM Julian Casallas
wrote:
> Jonathon,
>
> Based on the specification I tried the following options using the same
> gain.yml created according to the RFNoC 4 video
Hi Oscar,
The drawing revision isn't the same thing as a hardware revision. I can
confirm that the posted schematic is compatible with the current UHD source
code.
Thanks,
Wade
On Mon, Mar 22, 2021 at 10:48 AM Marcus D Leech
wrote:
> Code sees like this, that support hardware must necessarily
If I remember correctly, there's currently no easy way for you to trigger
the ctrlport_rst manually. That reset is only asserted during RFNoC block
initialization. If you want to reset something at other times on demand
then I suggest creating a separate register for that purpose.
Thanks,
Wade
O
It's based on AXI4-Stream, so you might look into that protocol for a
deeper understanding. Here's a link to the relevant section of the spec
(Section 2.2.1: Handshake process)
HTML Doc:
https://developer.arm.com/documentation/ihi0051/a/Interface-Signals/Transfer-signaling/Handshake-process
PDF
Hi Berkay,
I also had a lot of trouble getting DPDK to be recognized. It could be a
lot of things, so I can only speculate what the problem is in your case. In
my case, I had hyphens instead of underscores in my uhd.conf file. I think
I also had some issues with specifying the correct location of
Rob,
The "buff_size" parameter controls the "INGRESS_BUFF_SIZE" Verilog
parameter used in the stream endpoint. It has a significant effect on
streaming performance in the TX direction (host to USRP). A practical lower
limit is two MTU-sized packets, and the rfnoc_image_builder will coerce it
to at
Also useful:
https://files.ettus.com/manual/page_logging.html
Wade
On Fri, Jun 4, 2021 at 8:54 AM Wade Fife wrote:
> The documentation for the C API log function is here:
>
>
> https://files.ettus.com/manual/log_8h.html#a970e4c6a2fbc9761fd1a4d26dce81544
>
> I haven't us
Hi Jeff,
You've got these two lines in your YAML:
- { srcblk: radio1, srcport: out_0, dstblk: split2, dstport: in_0 }
...
- { srcblk: radio1, srcport: out_0, dstblk: split3, dstport: in_0 }
So you've got radio1(out_0) driving two different blocks, which isn't
allowed. I'm a little surprised
Jeff,
I would think you could use size 0, even for ep0, if you're really not
doing any TX streaming from the host. A size of 0 gets coerced to the
minimum size, which I think is 32. I might set it to something a bit larger
to be on the safe side, maybe 512.
Wade
On Mon, Jun 21, 2021 at 9:04 AM J
Hi Dario,
Could you share the YAML description of the FPGA and your block with me,
and maybe the generated rfnoc_image_core Verilog file? I'd like to
understand what's going on.
Thanks,
Wade
On Thu, Jun 24, 2021 at 8:50 AM Dario Pennisi wrote:
> Hi,
> i developed a rfnoc block based on uhd 4.
Hi Dario,
The FPGA code has the max MTU hard-coded to 10, which matches your block,
so that's good. That's the hard limit on CHDR packet size. You also need
some headroom for header information, so the limit is less than 8192 bytes
of payload. Make sure the MTU for your Ethernet interface is set t
Hi Ming,
For static coefficients, try setting RELOADABLE_COEFFS = 0 and
USE_EMBEDDED_REGS_COEFFS = 0. I did a quick simulation and it seemed to
work, but I didn't spend much time checking it. Make sure you also set
NUM_COEFFS and COEFFS_VEC correctly where the rfnoc_block_fir_filter is
instantiate
In UHD 4, rfnoc_replay_samples_from file is built along with all the other
examples by default when you build UHD (it will be in the build/examples
directory). If you want to build just the example, then you could do
something like what's described in
https://kb.ettus.com/Using_the_RFNoC_Replay_Blo
PHY_CTRL_STATUS is for the SFP port, so not what you're looking for.
You can look at the schematic for the E320 here:
https://kb.ettus.com/images/6/65/Neon_Public.pdf
There is a watchdog built into the E320 that I think is on by default. It's
on page 16 (the Real Time Clock).
Are you referring
Hi Jeff,
I agree with Rob that "=" should be "<=" but I don't think that's causing
any harm here. I copied and pasted your code into the gain example and
tested it, and it seems to work as I expected. So there's probably
something wrong that's unrelated to that code snippet. Take a look at the
gai
d/write from any of the registers. All of it simulates
> fine but after building and testing, I get ACK timeouts on the controlport
> bus.
>
>
>
> Jeff
>
>
>
> *From:* Hodges, Jeff via USRP-users
> *Sent:* Monday, September 20, 2021 3:09 PM
> *To:* Wade Fife ; Rob Kos
You might need to also clear the "build-ip" folder. Can you try running
"make cleanall" then try to build it again? I think I saw that error once
when I neglected to clean everything. Let me know if that doesn't work.
Also, the default X410 images don't actually use that IP, so you can remove
it f
This means there's a file that set default_nettype to none somewhere. That
setting will affect the files that get compiled after it, and in your case
gray2bin.v doesn't like it.
Like Rob said, you can add "`default_nettype wire" to the top of the file
that's having issues and it should compile aft
e gray2bin.v file (even though modifying the UHD code didn’t seem like
> the best approach) and that had no effect either.
>
>
>
> Any other suggestions?
>
>
>
> Thank you,
>
>
>
> *Michael H. Rich*
>
> *Electronic Systems Laboratory*
>
> *Geo
The build process for the FPGA generates a report with those numbers. If
you built the FPGA, look for a file named usrp_b210_fpga.syr and search for
"Device utilization summary" in that file.
Wade
On Sat, Jan 8, 2022 at 2:04 PM Marcus D. Leech
wrote:
> On 2022-01-08 15:00, page heller wrote:
>
Hi Maria,
The addsub block is an example with two inputs and two outputs.
https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/lib/rfnoc/blocks/rfnoc_block_addsub/rfnoc_block_addsub.v
https://github.com/EttusResearch/uhd/blob/master/host/include/uhd/rfnoc/blocks/addsub.yml
Moving Average
Hi Camille,
Maybe you could share your RFNoC YML file and someone could take a look?
There might be something wrong there.
Wade
On Thu, Jan 13, 2022 at 8:32 AM Camille Moniere
wrote:
> Hello everyone,
>
> I unsuccessfully try to use the FIR Filter RFNoC block in reception, in
> an USRP X310 wi
In particular, make sure you have a clock connected to the CE input of the
FIR filter. Something like this in your clk_domains section:
clk_domains:
- { srcblk: _device_, srcport: ce, dstblk: fir0, dstport: ce }
Wade
On Thu, Jan 13, 2022 at 10:04 AM Wade Fife wrote:
> Hi Cami
# 1 MB of data, be aware.
> data = np.empty((num_samps), dtype=np.complex64)
> md = uhd.types.RXMetadata()
> stream_cmd = uhd.types.StreamCMD(uhd.types.StreamMode.num_done)
> stream_cmd.stream_now = True
> stream_cmd.num_samps = num_samps
> stream_cmd.time_spec = uhd.types.TimeSpec(1, 0) # W
ctrlport_radio0 }
>> - { srcblk: _device_, srcport: x300_radio0, dstblk: radio0, dstport:
>> x300_radio }
>> - { srcblk: _device_, srcport: time_keeper, dstblk: radio0, dstport:
>> time_keeper }
>> # A list of all clock domain connections in design
>> # -
Hi,
The line "EN_FFT_SHIFT: 1" needs to be indented. It's supposed to be part
of the "parameters:" block.
If you have jsonschema installed then the error messages are a bit more
useful: "Additional properties are not allowed ('EN_FFT_SHIFT' was
unexpected)"
Thanks,
Wade
On Fri, Jan 28, 2022 a
I know this can happen if the number of samples per packet (SPP) is too
large for your configuration. You could try manually setting a smaller SPP
value, say 300, and see if that works. More information about your setup
would be helpful.
Wade
On Sun, Jan 30, 2022 at 11:02 AM Marcus D. Leech
wro
Hi Ofer,
1. It is bidirectional. You can think of the "record" and the "play"
components as independent, but connected to the same memory. So be careful
not to read/write to the same memory space and be aware that reading and
writing simultaneously slows down the DRAM making under/overflow more
li
Hi Lautaro,
The clocks section lists the clock ports you want to have on a block. The
rfnoc_chdr and rfnoc_ctrl clocks are required for all blocks. In the
block's YAML, they must be provided in the list of clocks (see other blocks
for example in
https://github.com/EttusResearch/uhd/tree/master/hos
You mentioned the log file. Did you check build-X300_HG/build.log or just
the console? In addition to that, you could look at the other files
generated in the build-X300_HG directory. Sometimes they have information
that the console doesn't show.
If Vivado didn't output a useful error message, the
The BSP (board support package) connections are the product-specific ports,
like the radio, timekeeper, DRAM, etc. You can identify them because they
always go to or from the "_device_". Clocks also come from the _device_.
You can see a list of ports on each product by looking at the BSP YAML
files
message I attached the YAML
> RFNOC image core...( x300_with_fft.yml )
>
>
> On Sat, Feb 5, 2022 at 1:48 AM Wade Fife wrote:
>
>> You mentioned the log file. Did you check build-X300_HG/build.log or just
>> the console? In addition to that, you could look at the
Hi sp,
Regarding the error message about Vivado not being found. You need to set
up your environment before building an FPGA. rfnoc_image_builder does this
automatically for you. But if you run make directly then you need to source
setupenv.sh manually. For example:
source uhd/fpga/usrp3/top/x300
That error means the source code for your gain block wasn't included. My
guess is that the include path was wrong, so your Makefile.srcs wasn't
added. If you're coping the rfnoc-example, here's how to build it (I've
attempted to use your file paths in this example):
cd /home/sp/Documents/rfnoc-tut
The E320's DRAM is pretty fast. It should have no problem keeping up for
your use case.
Wade
On Thu, Feb 10, 2022 at 1:56 AM Jonathon Pendlum
wrote:
> Hi Rob,
>
> As long as the DRAM can keep up throughput wise, you should be fine in
> that configuration. I think the E320 has a BIST you can run
Hi Tobias,
Sorry for the confusion. To get the full 491.520 MS/s you have to use a
bitstream that supports it, and it requires the 100 GbE interface to stream
at that rate. It looks like you're using the default bitstream that
supports 250 MS/s (called X4_200) and 10 GbE. The initial release of X4
1 work fine but ports 2 and 3 do not.
>
> Anyway, if you have any suggestions, I'd love to hear them.
> Rob
>
>
> On Thu, Feb 10, 2022 at 11:17 AM Wade Fife wrote:
>
>> The E320's DRAM is pretty fast. It should have no problem keeping up for
>> your use ca
Hi Ofer,
I think MEM_ADDR_W should be 31 for E320. Other than that everything looks
correct.
Wade
On Thu, Feb 10, 2022 at 2:20 PM Ofer Saferman wrote:
> Hello,
>
> I am working on a USRP E320 unit using UHD 4.1.0.5.
> I have made an FPGA image containing a radio, a 4-port replay block and a
>
k that this is the reason that ports 2,3 don't work?
>> I can try to rebuild the image and see what happens. I will update.
>>
>> Regards,
>> Ofer Saferman
>>
>> On Thu, Feb 10, 2022 at 10:36 PM Wade Fife wrote:
>>
>>> Hi Ofer,
>>>
t 10:47 PM sp h wrote:
> Thanks, I checked your guidance. I am sure that everything is true but I
> faced past errors:
> module 'rfnoc_block_gain' not found
>
> On Wed, Feb 9, 2022 at 10:52 PM Wade Fife wrote:
>
>> That error means the source code for your ga
Hi Rob,
RFNoC doesn't support generating user clocks for you yet (the range value
is not currently used). You could use the `dram` clock on N310 and connect
that to the `ce` inputs of your blocks. That should be about 300 MHz. The
`rfnoc_chdr` clock is 200 MHz on N310.
If it won't close timing wi
| 66878 | 69350 | 96.44
> |
> | SLICEL | 40816 | | |
> | SLICEM | 26062 | | |
>
> On Thu, Feb 24, 2022 at 9:25 PM Rob Kossler wrote:
>
>> Thanks for
That port contains signals that can be useful for debugging (fixing
problems with the code). Currently it outputs the states of the
axi_dma_master's state machines. Normally it would be disconnected, but if
you were trying to understand a problem with that code then looking at the
signals on that p
I looked at the generated DDC/DUC code again and that looks like a typo in
the YAML. It should really be `2**MTU`, which is 1024, instead of just
`MTU` (which is 10). So if you want a larger buffer on your block, try
2**MTU or some other power of 2.
Wade
On Sat, Feb 26, 2022 at 5:01 PM Wade Fife
> want an input buffer of 1024 at the DDC? If the concept is to buffer 1
> full packet, shouldn't it be twice that value (assuming 1 sample per clock)?
> Rob
>
> On Mon, Feb 28, 2022 at 3:36 PM Wade Fife wrote:
>
>> I looked at the generated DDC/DUC code again and th
Hi Yuriy,
The Dual 100 Gigabit Ethernet PCIe Interface Kit (PN 788216-01) includes an
NVIDIA MCX516A-CCAT card and one QSFP28 cable for 100 GbE.
The QSFP28 to 4xSFP28 Breakout Cable (PN 788214-01) has one QSFP28 on one
end and four SFP28 cables on the other end. It is for connecting up to four
10
Hi Jeff,
Can you describe the dataflow of your RFNoC graph (which blocks you're
using and how they're connected)? For example, is it: host -> SEP -> Your
Block -> Radio?
Could you try the latest version of UHD (v4.1.0.5)? There were many bug
fixes since the initial release of 4.0. You may also wa
ion on each send whether to send a packet
> or go to sleep for a cycle based on keeping it near this halfway point.
> This keeps me from ever losing packets and works like a charm but should
> not be needed. This points to a backup issue upstream somewhere.
>
>
>
> Once I switch to
The default generated code has the NoC shell, an example register, and a
data path that simply passes the data through. So the block only passes the
input data to the output and has a register that software can read/write.
The noc shell is the component that allows you to connect to RFNoC. You can
The max CHDR_W allowed is 512 (per the specification). But only the X410
device supports this. For all other USRPs, you should use 64 bits. This is
because 64-bit is enough for all the supported rates on other USRPs. This
parameter is set by the rfnoc_image_core, since blocks need to agree on the
C
Hi,
It looks like you're using Vivado 2019.2, but 2019.1 is expected. With the
wrong Vivado version, you'll have IP version problems. Make sure you run
"source setupenv.sh" prior to running "make" and make sure it completes
successfully. I also suggest running "make cleanall" to clear out any bad
Hi Maurizio,
Yes, building all the FPGAs from scratch in a single run takes a long time.
But maybe that's not needed. Let's start with your questions:
- Are you referring to X3xx? I don't know how to build the FW for the
embedded CPU but you should not have to rebuild it unless you're chang
Hi all,
You can change the hostname by creating a file /data/network/hostname with
the desired hostname.
On boot, systemd runs /sbin/usrp_hostname to configure the hostname. It
looks for the /data/network/hostname file. If it doesn't find it, then it
uses a default with the serial number.
Thanks
till point to config
> files in `/etc/systemd/network/`.
>
> Cheers
> Johannes
>
> On 21.03.22 23:44, Wade Fife wrote:
> > Hi all,
> >
> > You can change the hostname by creating a file /data/network/hostname
> > with the desired hostname.
> >
> > On b
The unmodified gain example should work, so I assume you modified it or are
trying your own version. I suggest you look at the example to see what you
did differently.
https://github.com/EttusResearch/uhddev/tree/master/host/examples/rfnoc-example/fpga/rfnoc_block_gain
The simulator is the tool d
Hi sp,
You can include files. It looks like you misspelled "correlate" (the error
says 'corrleate.vh'). Also, if the file is not in the same folder as
rfnoc_block_correlate.v, then you may need to provide a relative path to
the file.
Thanks,
Wade
On Mon, Apr 18, 2022 at 4:56 AM sp h wrote:
>
UHD 3.15 is stable. rc1 and rc2 refer to "release candidates". They are not
the final released version.
My machine also has Ubuntu 20.04 and UHD-3.15.LTS compiles for me. I did
not test older versions.
Wade
On Thu, Apr 21, 2022 at 10:46 AM Nikos Balkanas wrote:
> What do the rc1, rc2 mean in t
Hi David,
I think the Kycon KPPX-4P is compatible, but I've never used it myself. Let
me know if that works for you.
Wade
On Wed, Apr 20, 2022 at 6:41 AM David Raeman
wrote:
> Hi all, I need to build a custom power cable to an E320. The radio’s
> hardware page lists the plug p/n as CUI PDP-40.
If there's no error message, that usually means Vivado crashed. The last
time I saw this happen, it was because Vivado ran out of memory, which it
does not handle gracefully. I've also seen this happen because of a mistake
in the code that Vivado doesn't expect (something like double driving a
sign
Hi David,
I'm not super familiar with the software, but get_tick_rate() returning 0
might be because something's not implemented in the block controller
software. You could look at some other blocks to see how that's handled
(maybe the DDC/DUC). But I would expect get_tick_rate() to return the
sam
Hi Martin,
I'm sorry for the confusion. The maximum rate for E320 is 61.44 Msps, so
when you do dual channel, the maximum rate per channel is 30.72 Msps. You
can do 61.44 Msps with a single channel. The fact that you don't see an
error message when setting it too high is a known issue.
Wade
On W
tself or in the way in which Ettus is using it?
> Rob
>
> On Wed, May 4, 2022 at 2:24 PM Wade Fife wrote:
>
>> Hi Martin,
>>
>> I'm sorry for the confusion. The maximum rate for E320 is 61.44 Msps, so
>> when you do dual channel, the maximum rate per channel is
nment
techniques tend to be used instead. So it's certainly possible to create
LVDS interfaces that run at this rate, but the current design of the FPGA
interface doesn't.
Wade
On Thu, May 5, 2022 at 12:28 PM Brian Padalino wrote:
> On Thu, May 5, 2022 at 11:45 AM Wade Fife wrote:
>
Hi Jeffrey,
Very curious that you're getting that CTRL_STS_OKAY error, since it looks
like you're not using the status. I assume ctrlport:has_status is set to
False in your block's YAML? In that case the status should always be OK.
1) For different input/output packet sizes, you need to modify th
Hi sp,
The critical warning you mention means that the clock constraints created a
new clock constraint that replaces another one. I think this is expected
and is not related to your code.
The ValueError means it received a packet with a bad header or a bad length
field in the header. Most likely
.v and .sv files that I modified based on your guidance in your
> first response, as well as the updated xsim.log. Please let me know if
> there are any additional things I may need to change such as sizes and what
> not - thanks!
>
> -Jeff
>
> On Mon, May 9, 2022 at 3:12 PM
ached. Thanks!
>
> -Jeff
>
>
>
>
> On May 11, 2022, at 08:42, Wade Fife wrote:
>
>
> Can you also share your block's YML and the noc_shell you generated?
>
> Wade
>
> On Wed, May 11, 2022 at 4:27 AM Jeffrey Cuenco wrote:
>
>> Hi Wade,
>>
you suggested.
>
> For using ce_clk, does it suffice for me to create a wire for ce_clk in
> the .v file and then reference it from the yaml? Is ordering important or
> just ensuring the name matches the wire? Thanks!
>
> -Jeff
>
>
> On May 12, 2022, at 10:29, Wade Fife
gt;>> ce_rst wires aren't present in the template code and the yaml files get
>>> overwritten - is there another command for rfnocmodtool that I should be
>>> using to regenerate after customizing the yaml? Thanks!
>>>
>>> -Jeff
>>>
>>> On Mon
gt; -Jeff
>
> On May 18, 2022, at 19:59, Wade Fife wrote:
>
>
> If you want to customize the YAML and regenerate from your modified YAML,
> then I think you need to use rfnoc_create_verilog (part of UHD). So you
> could do something like:
>
> python3 uhd/host/ut
I think I had this problem when I installed UHD to a non-standard location.
I did this to my PYTHONPATH variable:
export
PYTHONPATH=$PYTHONPATH:/lib/python3.8/site-packages
Where is the location where I had UHD installed.
Also the Python version (3.8) in that path might be different for you.
Wa
ed in so that it knows when things
> finish? Thanks!
>
> -Jeff
>
> On Thu, May 19, 2022 at 12:23 Wade Fife wrote:
>
>> I think those versions are fine, but your gr-ettus might be out of date.
>> I'm not very familiar with the GNU Radio integration. You could try
but wanted to clarify that there aren't any additional
> changes I would need to do aside from adjusting MAX_M, MAX_N, and ensuring
> the input/output wire names match what are in my signal declarations
> section? Thanks!
>
> -Jeff
>
>
>
>
>
>
>
> On Thu,
> miss anything in terms of clocks, data widths, etc. thanks!
>
> -Jeff
>
>
>
> On Thu, May 19, 2022 at 3:13 PM Wade Fife wrote:
>
>> Regarding the payload/context change, it looks like the modtool sets the
>> fpga_iface to axis_pyld_ctxt, but in conv.yml you ch
I'm not sure which firmware you're interested in, but much of the firmware
is loaded from the SD card. There are instructions for updating the SD card
with the latest image in the user manual.
https://files.ettus.com/manual/page_usrp_e3xx.html#update_sdcard
Wade
On Tue, May 24, 2022 at 11:03 AM
If you prefer the coefficients in decimal, they are pulled from this file
for the first and second stage:
https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/top/x300/coregen_dsp/hb47.coe
And this file for the third stage:
https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/top/
You do not need to recompile GNURadio and UHD from scratch each time you
build an FPGA bitstream.
'O' means overflow (the data is coming in from the radio faster than you
are streaming it to the host). Did you also test that it still works
without FFT block in the RFNoC graph while keeping everyth
Hi Maria,
You have the right idea. You should be able to change the srcport from "ce"
to "rfnoc_chdr" in the line for your block in the clk_domains section. If
that doesn't work, share your YML file and maybe someone can spot the
problem.
Wade
On Tue, May 31, 2022 at 3:47 AM Maria Muñoz wrote:
Hi all,
I was also refreshing my memory on how this works. dds_timed is used by the
DUC. For the DDC, I think the line you need is here:
https://github.com/EttusResearch/uhd/blob/5333d3d12ffc21229ec4203a9ea1c7f68d82e57f/fpga/usrp3/lib/rfnoc/ddc.v#L115
Also, I think you need to change this line t
.500}5.000 200.000
> radio_clk
>
> {0.000 2.500}5.000 200.000
> radio_clk_2x
>
> {-0.312 0.937} 2.500 400.000
>
> How do I know which clock of those is going to my design?
>
> Kind Regards,
> Maria
&
Hi Maria,
Which IP are you trying to include? And is it failing when trying to
simulate or only when building the FPGA? Some IP are easier to include than
others. From your examples, it looked like you were trying to include the
clock wizard. For that IP I usually just copy the MMCM or PLL code th
ith other IP but there were so many
> missing sources... So I will also check the other way you propose to
> include the .xci source.
> Again many thanks for your answer!
>
> Kind Regards,
> Maria
>
> El lun, 6 jun 2022 a las 15:45, Wade Fife ()
> escribió:
>
>> Hi
I'm not very familiar with how those tune commands get translated into
register transactions, but one thought I had is that it may also be issuing
timed commands to the radio. If so, you also might need to make the radio's
control FIFO deeper by updating the "512" number to the depth you need. It
ote:
> On 2022-06-07 11:24, ri28...@mit.edu wrote:
>
> Wade Fife wrote:
>
> I'm not very familiar with how those tune commands get translated into
> register transactions, but one thought I had is that it may also be issuing
> timed commands to the radio. If so, you
Hi Bob,
This is expected with the CG_400 because it does not have the DDC/DUC
blocks due to the high resource requirements for handling 500 Msps. If you
want 500 Msps, use CG_400. If you want 250 Msps or lower, use X4_200 (or
another _200 variant). Take a look at the FPGA image flavors in the X410
Hi sp,
It is possible to use incremental implementation using the checkpoints
generated by the build flow, but I've never tried it with USRPs. This is an
advanced Vivado feature so you would need to write your own TCL code to use
that feature. See the Xilinx documentation for details. Keep in mind
> Do you include this file on the rfnoc framework when using this ip? Where
> should I include this file?
>
> Kind Regards,
>
> Maria
>
> El lun., 6 jun. 2022 21:50, Wade Fife escribió:
>
>> You're right. It really depends on the IP. Some are very complicated
&
Sadly, I don't think there is one in the UHD repo. I don't know of anyone
who has written one.
Wade
On Wed, Jun 15, 2022 at 6:19 AM Florent Allard <
florent.all...@telecom-paris.fr> wrote:
> Hello,
>
> After having implemented into a RFNoC block the Xilinx IP LDPC Decoder and
> Encoder for 5G,
Hi Bob,
Question 1:
With the x4 bitstream, the X410 puts a separate 10 GbE interface on each
lane of its QSFP28 port 0 (the QSFP port has four lanes). There are
breakout cables that go from one QSFP to four SFPs if you have cards with
SFP ports, or, if your card supports four 10 GbE ports on a sin
Hi sp,
Simulation is the best way to debug issues like this. I suggest you modify
the provided gain testbench to test your block. That's the best way to
debug HDL code. After it's working in simulation, then you should try
running it on the FPGA.
Looking at your noc_shell_gain.v, it looks like yo
Hi Rylee,
Some blocks do use NIPC = 1, but those blocks need to use a faster clock
for the internal processing. For example, on X310, the DDC and DUC use a
separate CE clock that is connected to 214.286 MHz. The radio block uses
radio_clk for this purpose. For the parts of the logic that use the 1
ils down to:
>
> Should custom RFNoC blocks that expect to operate at 200 MS/s expect a
> NIPC of 2 from the upstream blocks.
>
> Does the streamers understand if it is expecting 2 samples per clock or 1
> sample per clock?
>
>
>
> Rylee
>
>
>
> *From: *W
Hi Lorenzo,
I don't know of any examples of RFNoC blocks that use block designs, but in
principle using a BD is similar to using any other Xilinx IP. If you search
for *.bd files or *_bd.tcl in the UHD repository, you'll find several
examples of IP that is pulled into the USRP code as a block desi
Hi Kevin,
I assume the xml you're referring to is the component description so that
it can be recognized by Vivado IP integrator. In that case, you need to
create an instance of the IP in Vivado, which will create an XCI file for
it. You can then include that in the design similar to how other xci
main
>>> > tb = top_block_cls()
>>> > File
>>> >
>>> "/home/integrasys/rfnoc/src/uhd/fpga/usrp3/top/e320/build/untitled.py",
>>> > line 76, in __init__
>>> > self.rfnoc_graph = ettus_rfnoc_graph_0 =
>>&
1 - 100 of 266 matches
Mail list logo
