Hello Wade,
I did not realise that I had removed usrp-users mail ID. Now I am able to
add "FFT and Stream splitter" RFNoC core in the design making changes to
the "x3xx_radio_base.yml" script. However, even now I am getting error
*[WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping.[ERROR]
[RFNOC::GRAPH::DETAIL] The following properties could not be
resolved:[ERROR] [RFNOC::GRAPH::DETAIL] Dirty: RxStreamer#2[INPUT_EDGE:0
atomic_item_size]Traceback (most recent call last): File
"/home/quasar/gnuradio/gr-uhd/examples/grc/rfnoc_split_stream.py", line
434, in <module> main() File
"/home/quasar/gnuradio/gr-uhd/examples/grc/rfnoc_split_stream.py", line
413, in main tb.start() File
"/usr/local/lib/python3.8/dist-packages/gnuradio/gr/top_block.py", line
116, in start top_block_start_unlocked(self._impl,
max_noutput_items)RuntimeError: RfnocError: ResolveError: Could not resolve
properties.*
How to solve it? I checked previous replies and tried to reduce FFT size
upto 256 which did not help. What else may cause this error? Following is
the new connection I have used.
* - { srcblk: _device_, srcport: _none_, dstblk: radio0, dstport: in_1 }
- { srcblk: _device_, srcport: _none_, dstblk: radio0, dstport: in_0 } -
{ srcblk: radio0, srcport: out_0, dstblk: ddc0, dstport: in_0 } - {
srcblk: radio0, srcport: out_1, dstblk: ddc0, dstport: in_1 } - {
srcblk: ddc0, srcport: out_0, dstblk: ep0, dstport: in0 } - {
srcblk: ddc0, srcport: out_1, dstblk: Spltr0,dstport: in_0 } - {
srcblk: Spltr0, srcport: out_0, dstblk: fft0, dstport: in_0 } - {
srcblk: Spltr0, srcport: out_1, dstblk: ep3, dstport: in0 } - {
srcblk: fft0, srcport: out_0, dstblk: ep1, dstport: in0 }*
On Sun, Oct 20, 2024 at 5:29 AM Wade Fife <wade.f...@ettus.com> wrote:
> Hi Nidhi,
>
> I don't see anything obviously wrong with the YAML that would prevent it
> from being detected. I assume you were able to detect it before with the
> old bitstream? Can you put the default X300_HG bitstream back on using JTAG
> and confirm it's working again? This will confirm if it's an issue with the
> bitstream and not some other issue.
>
> Take a look at the KB article that discusses this issue:
> https://kb.ettus.com/Troubleshooting_X300/X310_Device_Discovery_Issues
>
> By the way, I see you removed the mailing list. You may get more help if
> you keep the mailing list in your replies. I'm not part of the support team.
>
> Thanks,
>
> Wade
>
> On Sat, Oct 19, 2024 at 5:29 AM Nidhi Panda <nidhi.pa...@cyronics.com>
> wrote:
>
>> Hi Wade,
>>
>> I am able to generate a .bit file without any error now. I reinstalled
>> the uhd and it worked. But when I program it using JTAG, It is not
>> detecting any device. Any suggestions on what can cause it.? I have
>> reattached my yml script files for your reference.
>>
>> On Wed, Oct 16, 2024 at 7:02 PM Wade Fife <wade.f...@ettus.com> wrote:
>>
>>> To get around the fatal exception, you can try a different build seed as
>>> described in:
>>>
>>>
>>> https://kb.ettus.com/RFNoC_Frequently_Asked_Questions#Why_did_my_FPGA_build_fail_to_meet_timing_constraints.3F
>>>
>>> You should probably also read that section to understand what could be
>>> causing the timing error. The timing report might give a clue.
>>>
>>> Wade
>>>
>>> On Wed, Oct 16, 2024 at 4:16 AM Nidhi Panda <nidhi.pa...@cyronics.com>
>>> wrote:
>>>
>>>> Hi Wade,
>>>>
>>>> Thank you for your reply. Yes I had checked the FAQ section and removed
>>>> the replay block. Still I get the same timing constraint error. I want to
>>>> use 2-twinRX daughter cards with both the channels. Therefore, I also
>>>> removed the DUC block and created a fake connection instead of using TX,
>>>> same as done for other input ports of the radio. I have also reduced
>>>> buffer size. Now I am getting following routing error:
>>>>
>>>> ERROR: [Route 35-9] Router encountered a fatal exception of type
>>>> 'N2rt13HDRTExceptionE' - 'Trying to tool lock on already tool locked arc
>>>> '.
>>>> Resolution: For technical support on this issue, please visit
>>>> http://www.xilinx.com/support
>>>>
>>>>
>>>> This error is also mentioned in
>>>> *"https://files.ettus.com/manual/md_usrp3_build_instructions.html
>>>> <https://files.ettus.com/manual/md_usrp3_build_instructions.html>", *which
>>>> gives two options as solution
>>>> *1.* *Use a different Git hash* -
>>>> $ git log
>>>> commit bdada1ed4837e6076a707d0cb62ad4b0a792c7fd (HEAD -> master,
>>>> origin/master, origin/HEAD)
>>>> and
>>>> $ git checkout bdada1ed4837e6076a707d0cb62ad4b0a792c7fd
>>>>
>>>> rerun the rfnoc_image_builder command. Ended up with the same routing
>>>> error.
>>>>
>>>>
>>>> *2. make a non-functional source code change to the HDL to rebuild the
>>>> design.*
>>>> Does it mean adding a space or something in any of the vhdl/verilog
>>>> files.
>>>>
>>>> Is there any other way to resolve this error? I have attached updated
>>>> yml scripts for your reference.
>>>>
>>>> Regards
>>>> Nidhi
>>>>
>>>> On Tue, Oct 15, 2024 at 6:23 PM Wade Fife <wade.f...@ettus.com> wrote:
>>>>
>>>>> The X300 has a smaller FPGA. It could be that the tools are struggling
>>>>> to meet timing because the design has become crowded. This FAQ has some
>>>>> information on why designs can fail to meet timing.
>>>>>
>>>>>
>>>>> https://kb.ettus.com/RFNoC_Frequently_Asked_Questions#Why_did_my_FPGA_build_fail_to_meet_timing_constraints.3F
>>>>>
>>>>> You may need to remove something to make room. For example, are you
>>>>> planning to use the replay block? If not, I suggest removing it. Or
>>>>> perhaps
>>>>> you only need one channel, or it's RX only, etc. In these cases you can
>>>>> remove the unused blocks and connections to reduce the amount of logic on
>>>>> the FPGA, making it easier for the tools to place and route the design.
>>>>>
>>>>> Wade
>>>>>
>>>>> On Tue, Oct 15, 2024 at 4:04 AM Nidhi Panda <nidhi.pa...@cyronics.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Wade,
>>>>>>
>>>>>> Thank you for your response. Using only one clock source for FFT
>>>>>> solved the multiple driven clock error, however now I am receiving
>>>>>> following error with timing constraint file:
>>>>>>
>>>>>> ERROR: [Builder 0-0] *The design did not satisfy timing constraints.
>>>>>> (*Implementation outputs were still generated)
>>>>>> ERROR: [Common 17-39] 'send_msg_id' failed due to earlier errors.
>>>>>>
>>>>>> while executing
>>>>>> "send_msg_id {Builder 0-0} error "The design did not satisfy timing
>>>>>> constraints. ${s}""
>>>>>> invoked from within
>>>>>> "if {! [string match -nocase {*timing constraints are met*} [read
>>>>>> [open $g_output_dir/build.rpt]]]} {
>>>>>> send_msg_id {Builder 0-0} error "The desi..."
>>>>>> (procedure "vivado_utils::check_timing_report" line 5)
>>>>>> invoked from within
>>>>>> "vivado_utils::check_timing_report"
>>>>>> (procedure "vivado_utils::write_implementation_outputs" line 21)
>>>>>> invoked from within
>>>>>> "vivado_utils::write_implementation_outputs"
>>>>>>
>>>>>> I have attached an updated yml script file for your reference. Please
>>>>>> help me with this error.
>>>>>>
>>>>>> Regards,
>>>>>> Nidhi
>>>>>>
>>>>>> On Tue, Oct 15, 2024 at 3:59 AM Wade Fife <wade.f...@ettus.com>
>>>>>> wrote:
>>>>>>
>>>>>>> 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, dstport: ce }
>>>>>>>
>>>>>>>
>>>>>>> You should only have one clock driving it. Most likely you want the
>>>>>>> first one (i.e., use the ce clock to drive the ce input of the FFT).
>>>>>>>
>>>>>>> Wade
>>>>>>>
>>>>>>> On Mon, Oct 14, 2024 at 7:46 AM Nidhi Panda <
>>>>>>> nidhi.pa...@cyronics.com> wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I am having USRP X300 device with following tool versions:
>>>>>>>>
>>>>>>>> Vivado 2021.1 - AR76780n,
>>>>>>>> GNU radio version - v3.11.0.0git-820-g2adbd4ea
>>>>>>>> UHD version - UHD_4.7.0.0-84-gbdada1ed
>>>>>>>>
>>>>>>>> By using the
>>>>>>>> *"**https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0
>>>>>>>> <https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0>**"*
>>>>>>>> guide, I am trying to add FFT IP in my design. THis gives following
>>>>>>>> error:
>>>>>>>>
>>>>>>>> Starting DRC Task
>>>>>>>> INFO: [DRC 23-27] Running DRC with 8 threads
>>>>>>>> ERROR: [DRC MDRV-1] Multiple Driver Nets: Net
>>>>>>>> bus_clk_gen/inst/CLK_OUT4 has multiple drivers:
>>>>>>>> bus_clk_gen/inst/clkout1_buf/O, bus_clk_gen/inst/clkout4_buf/O, and
>>>>>>>> radio_clk_gen/inst/clkout1_buf/O.
>>>>>>>> INFO: [Project 1-461] DRC finished with 1 Errors
>>>>>>>>
>>>>>>>>
>>>>>>>> I have attached a .yml script file for your reference. Please guide
>>>>>>>> me with the process of adding RFNoC blocks..
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> NIdhi
>>>>>>>> _______________________________________________
>>>>>>>> USRP-users mailing list -- usrp-users@lists.ettus.com
>>>>>>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> *Nidhi Panda*
>>>>>>
>>>>>> *Cyronics Innovation Labs Pvt Ltd*
>>>>>> #11, Electronics Co-op Estate
>>>>>> Satara Road, Pune - 411009
>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Regards,
>>>> *Nidhi Panda*
>>>>
>>>> *Cyronics Innovation Labs Pvt Ltd*
>>>> #11, Electronics Co-op Estate
>>>> Satara Road, Pune - 411009
>>>>
>>>>
>>
>> --
>> Regards,
>> *Nidhi Panda*
>>
>> *Cyronics Innovation Labs Pvt Ltd*
>> #11, Electronics Co-op Estate
>> Satara Road, Pune - 411009
>>
>>
--
Regards,
*Nidhi Panda*
*Cyronics Innovation Labs Pvt Ltd*
#11, Electronics Co-op Estate
Satara Road, Pune - 411009
--
Regards,
*Nidhi Panda*
*Cyronics Innovation Labs Pvt Ltd*
#11, Electronics Co-op Estate
Satara Road, Pune - 411009
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
