Hi Rob,
thank you very much for your answer. I used rx_streamer to check if my
block was working, it did not. Then, I found the problem on Verilog and
fixed it. After that I used rx_streamer to check my block and it worked.
Thank you for your advice, it was really helpful.

Rob Kossler <[email protected]>, 9 Ağu 2022 Sal, 16:38 tarihinde şunu yazdı:

> Also, have you tried your IP in a testbench?  If not, this is the first
> place to start.
>
> On Tue, Aug 9, 2022 at 9:34 AM Rob Kossler <[email protected]> wrote:
>
>> Hi Yasir,
>> One of the nice things about RFNoC graphs is the ability to connect at
>> runtime (at least for dynamically linked blocks). So, one test you can try
>> is to change your RFNoC graph as follows: DDS_block => rx_streamer (rather
>> than your existing DDS_block => DUC => Radio-Tx).  In this case you should
>> see your samples stream to the host.  If this works then you can add the
>> DUC/Radio and try other experiments. But, if not, then at least your
>> problem has been simplified. As a comparison you could build the siggen
>> block and try the graph siggen => rx_streamer, which I expect will work.
>>
>> Another relevant example that you might investigate is the Replay block.
>> This block has more functionality than yours because it can act as both a
>> sink and a source. But, when it is acting as a source, it is similar to
>> your block.  One test I tried with the Replay block was to send samples
>> from host (tx_streamer => Replay) and then later to send them back to host
>> (Replay => rx_streamer) to verify that the samples were equal.
>> Rob
>>
>> On Tue, Aug 9, 2022 at 4:53 AM Yasir Özçalık <[email protected]>
>> wrote:
>>
>>> Hi Jonathon,
>>> Thank you for the answer. For complex multiplier IP, I have already
>>> looked at it and used it as a reference point for my DDS IP. I have changed
>>> complex multiplier IP files with DDS IP files and implemented it. That's
>>> how I generated my bitstream. For Cpp file  rfnoc_siggen_example.cpp is
>>> what I was looking for. I changed my cpp code according to the siggen
>>> example. After that, I tried it on E320. The Error message is gone now, but
>>> the signal is still not generated. I expect at least a red light on TX/RX
>>> channel even if my DDS Block doesn't work properly, but this is not the
>>> case. There is no light on Radio channels. I don't know if this is because
>>> of my DDS block or because of the CPP file. I will try to make some changes
>>> on Verilog and generate new bitstream. After that, I will post the results
>>> here.
>>>
>>> While doing that, I will be glad for any more help.
>>>
>>> Sorry for the late answer, there is a 10 hours time zone difference
>>> between where I live and the US.
>>>
>>> Kind regards,
>>> Yasir
>>>
>>> Jonathon Pendlum <[email protected]>, 8 Ağu 2022 Pzt, 19:29
>>> tarihinde şunu yazdı:
>>>
>>>> Hi Yasir,
>>>>
>>>> I suggest taking a look at this example using the Siggen block:
>>>> https://github.com/EttusResearch/rfnoc-apps/blob/testing/master/apps/rfnoc_siggen_example.cpp.
>>>> As for adding IP, rfnoc-example has an example using a complex multiplier:
>>>> https://github.com/EttusResearch/uhd/tree/master/host/examples/rfnoc-example/fpga/ip/.
>>>> I also suggest updating your E320 and Host UHD version to 4.2 as there have
>>>> been several bug fixes since UHD 4.0.
>>>>
>>>> Jonathon
>>>>
>>>>
>>>> On Mon, Aug 8, 2022 at 2:50 AM Yasir Özçalık <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>>   I have a E320 device and I am trying to learn how to build my own
>>>>> custom IPs. The thing is that the IPs which were implemented by Ettus were
>>>>> not enough for me. Therefore; I need to build my own custom IPs. I have 
>>>>> all
>>>>> the HDL codes that I need to build on E320, but I am having a problem with
>>>>> E320 development flow.
>>>>>
>>>>>   To learn how to add my custom IPs, I have analyzed the Rfnoc-example
>>>>> in the uhd repository. In that example, they showed basic Gain IP (which
>>>>> uses multiply IP). Firstly, I have synthesized and implemented that
>>>>> example. After that, I loaded the bit file into USRP and tested it
>>>>> with a init_gain_block C++ file. I tried to write a value to register and
>>>>> read back from the same register. It worked fine. I also changed the
>>>>> default UHD C++ code and wrote a basic UHD C++ code to amplify a signal by
>>>>> looking at example UHD C++ codes. That worked fine, too. The Signal given
>>>>> from ADC is amplified and given back to DAC. After that I changed the
>>>>> multiply IP with DDS IP and tried to build it to generate a signal. The
>>>>> thing is that I implemented it successfully and the bit file was 
>>>>> generated,
>>>>> but it did not work after loading it into the device.
>>>>>
>>>>> There are 2 problems:
>>>>> 1 -) Since all the example UHD C++ codes are meant to transfer data
>>>>> between host and device, I do not know how to make it work. Because, my 
>>>>> DDS
>>>>> IP does not need to transfer data between host and device. I just need to
>>>>> write a frequency value to register and DDS will generate a signal. After
>>>>> that, I expect it to work fine. To do that, in UHD C++ code I have used
>>>>> rfnoc_graph and connected my block with the DUC block. Also I connected 
>>>>> the
>>>>> DUC block with the Radio block. I expect this to work seamlessly, but it
>>>>> did not. I could not figure out how to write a C++ code to make this work.
>>>>> The code gives an error which is "[ERROR] [RFNOC::GRAPH] Caught
>>>>> exception while initializing graph: Environment Error: IOError: Timed out
>>>>> getting recv buff for management transaction"
>>>>>
>>>>> 2 -) While building DDS IP, I have opened a Vivado 2019.1 and
>>>>> generated a DDS IP. Then, I used the .xci file in uhd. I do not know if
>>>>> this is the right way, but UHD gives no error while implementing it.
>>>>>
>>>>>
>>>>>
>>>>> USRP Device :E320
>>>>> UHD Version : 4.0.0.0
>>>>> Host OS : Ubuntu 20.04.4
>>>>>
>>>>> Kind Regards,
>>>>> Yasir
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list -- [email protected]
>>>>> To unsubscribe send an email to [email protected]
>>>>>
>>>> _______________________________________________
>>> USRP-users mailing list -- [email protected]
>>> To unsubscribe send an email to [email protected]
>>>
>>
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to