[prev in list] [next in list] [prev in thread] [next in thread]
List: usrp-users
Subject: [USRP-users] Re: Debugging E320 with JTAG causes a problem
From: Wade Fife <wade.fife () ettus ! com>
Date: 2022-10-24 15:18:33
Message-ID: CAFche=ju+DH0aN-mX5YNgpVud7nQ3pa94AU5w7FVdFC19H+XBw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
The NoC Shell is configurable for different use cases. You can read about
the differences in the RFNoC Specification.
https://files.ettus.com/app_notes/RFNoC_Specification.pdf
I suppose in your case, I would use the axis_data interface type (what the
DDC block uses).
What is the source of your trigger? How important is it that you sample at
the time your trigger occurs? If the timing of the trigger is important,
then you might need to look at the radio_time to figure out at what time
the trigger occurred, then put logic in your block to capture two samples
starting at that time. Otherwise, your trigger will be off due to the delay
for the transfer of data from the radio to your block. But maybe the
precision of the trigger isn't important and you can ignore that delay.
In an RFNoC block, the data will come in on AXI-Stream (tdata, tlast,
tavlid, tready). You need to follow the protocol of that bus to capture the
data. The data won't be valid on every clock cycle because the data bus
runs on a different clock rate from the ADC. It will only be valid when
tvalid is high, and you must acknowledge the data by asserting tready. If
this isn't clear, then I suggest you read up on how AXI-Stream works.
Wade
On Mon, Oct 24, 2022 at 12:35 AM Yasir =C3=96z=C3=A7al=C4=B1k <simultaneous=
11@gmail.com>
wrote:
> Hi Wade,
> thank you very much for your answer. I have successfully debugged it. Can
> you also help me with my original problem?
> I am using the E320 and UHD 4.0 version. I want to save 2 ADC samples int=
o
> block ram and read them later. For that reason, I have a trigger which
> starts the saving process. When I saved 2 ADC samples into block ram and
> read them later, I realized that some samples are zero. I debugged it and=
I
> saw that valid signals of ADCs are not always 1. They sometimes switch ba=
ck
> to 0. While doing that, I have used the RFNoC-example as a starting point=
.
> I don't know what the real problem is, but I examined different examples
> and I realized that they used different files in their noc_shell files. F=
or
> example, the gain example used chdr_to_axis_pyld_ctxt which generates
> payload and context data. But, ddc example used chdr_to_axis_data which
> generates only axis datas. Therefore; I have tried different files in
> noc_shell, but none of them worked as I expected. I don't want to take a=
ll
> the examples to the host or anywhere else. I just want all ADC samples to
> go into my custom RFNoC-block. I don't want any other datas such as
> metadatas or anything else, but only ADC samples.
>
> My System:
> Device : E320
> OS : Ubuntu 20.04.4
> UHD: 4.0
>
> Kind Regards,
> Yasir.
>
> Wade Fife <wade.fife@ettus.com>, 21 Eki 2022 Cum, 20:34 tarihinde =C5=9Fu=
nu
> yazd=C4=B1:
>
>> Hi Yasir,
>>
>> The E320 runs Linux on the SoC of FPGA. There are devices in the FPGA
>> which are visible to the Linux kernel, so updating the FPGA without firs=
t
>> bringing down those devices causes problems. uhd_image_loader takes care=
of
>> all this for you. You can use uhd_image_loader to first load your bitstr=
eam
>> (the one you want to debug over JTAG), then use the Vivado hardware mana=
ger
>> to connect to that bitstream via JTAG after it is already loaded.
>>
>> Wade
>>
>> On Thu, Oct 20, 2022 at 3:31 AM Yasir =C3=96z=C3=A7al=C4=B1k <simultaneo=
us11@gmail.com>
>> wrote:
>>
>>> Hi everyone,
>>> I am trying to debug E320 with JTAG. I connected to the E320 JTAG
>>> console with Vivado 2019.1 hardware manager. Vivado successfully
>>> recognized E320. Then, I loaded my custom bitfile. The problem is E320
>>> started to give me errors saying that "IO Error during GSM initializati=
on."
>>> I thought that might be because of the bit file. Therefore; I tried to =
load
>>> the default bit file, but the same problem occurred again. When I use
>>> uhd_image_loader, bitfiles work without problem. But when I wanted to d=
ebug
>>> it with JTAG and loaded the bit file with jtag, uhd_usrp_probe gave me =
an
>>> error message. Can anyone help me with this, please? What might be the
>>> problem?
>>>
>>> Kind Regards,
>>> Yasir.
>>> _______________________________________________
>>> USRP-users mailing list -- usrp-users@lists.ettus.com
>>> To unsubscribe send an email to usrp-users-leave@lists.ettus.com
>>>
>>
[Attachment #5 (text/html)]
<div dir="ltr"><div>The NoC Shell is configurable for different use cases. You can \
read about the differences in the RFNoC Specification. <a \
href="https://files.ettus.com/app_notes/RFNoC_Specification.pdf">https://files.ettus.com/app_notes/RFNoC_Specification.pdf</a></div><div><br></div><div>I \
suppose in your case, I would use the axis_data interface type (what the DDC block \
uses).</div><div><br></div><div>What is the source of your trigger? How important is \
it that you sample at the time your trigger occurs? If the timing of the trigger is \
important, then you might need to look at the radio_time to figure out at what time \
the trigger occurred, then put logic in your block to capture two samples starting at \
that time. Otherwise, your trigger will be off due to the delay for the transfer of \
data from the radio to your block. But maybe the precision of the trigger isn't \
important and you can ignore that delay.</div><div><br></div><div>In an RFNoC block, \
the data will come in on AXI-Stream (tdata, tlast, tavlid, tready). You need to \
follow the protocol of that bus to capture the data. The data won't be valid on \
every clock cycle because the data bus runs on a different clock rate from the ADC. \
It will only be valid when tvalid is high, and you must acknowledge the data by \
asserting tready. If this isn't clear, then I suggest you read up on how \
AXI-Stream works.<br></div><div><br></div><div>Wade<br></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 24, 2022 at 12:35 \
AM Yasir Özçalık <<a \
href="mailto:simultaneous11@gmail.com">simultaneous11@gmail.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi \
Wade,<div>thank you very much for your answer. I have successfully debugged it. Can \
you also help me with my original problem?</div><div>I am using the E320 and UHD 4.0 \
version. I want to save 2 ADC samples into block ram and read them later. For that \
reason, I have a trigger which starts the saving process. When I saved 2 ADC samples \
into block ram and read them later, I realized that some samples are zero. I debugged \
it and I saw that valid signals of ADCs are not always 1. They sometimes switch back \
to 0. While doing that, I have used the RFNoC-example as a starting point. I \
don't know what the real problem is, but I examined different examples and I \
realized that they used different files in their noc_shell files. For example, the \
gain example used chdr_to_axis_pyld_ctxt which generates payload and context data. \
But, ddc example used chdr_to_axis_data which generates only axis datas. \
Therefore; I have tried different files in noc_shell, but none of them worked as I \
expected. I don't want to take all the examples to the host or anywhere else. I \
just want all ADC samples to go into my custom RFNoC-block. I don't want any \
other datas such as metadatas or anything else, but only ADC \
samples.</div><div><br></div><div>My System:</div><div>Device : E320</div><div>OS : \
Ubuntu 20.04.4</div><div>UHD: 4.0</div><div><br></div><div>Kind \
Regards,</div><div>Yasir.</div></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">Wade Fife <<a href="mailto:wade.fife@ettus.com" \
target="_blank">wade.fife@ettus.com</a>>, 21 Eki 2022 Cum, 20:34 tarihinde şunu \
yazdı:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi \
Yasir,</div><div><br></div><div>The E320 runs Linux on the SoC of FPGA. There are \
devices in the FPGA which are visible to the Linux kernel, so updating the FPGA \
without first bringing down those devices causes problems. uhd_image_loader takes \
care of all this for you. You can use uhd_image_loader to first load your bitstream \
(the one you want to debug over JTAG), then use the Vivado hardware manager to \
connect to that bitstream via JTAG after it is already \
loaded.<br></div><div><br></div><div>Wade<br></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 20, 2022 at 3:31 AM \
Yasir Özçalık <<a href="mailto:simultaneous11@gmail.com" \
target="_blank">simultaneous11@gmail.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi everyone, <div>I am trying to \
debug E320 with JTAG. I connected to the E320 JTAG console with Vivado 2019.1 \
hardware manager. Vivado successfully recognized E320. Then, I loaded my custom \
bitfile. The problem is E320 started to give me errors saying that "IO Error \
during GSM initialization." I thought that might be because of the bit file. \
Therefore; I tried to load the default bit file, but the same problem occurred \
again. When I use uhd_image_loader, bitfiles work without problem. But when I wanted \
to debug it with JTAG and loaded the bit file with jtag, uhd_usrp_probe gave me an \
error message. Can anyone help me with this, please? What might be the \
problem?</div><div><br></div><div>Kind Regards,</div><div>Yasir.</div></div> \
_______________________________________________<br> USRP-users mailing list -- <a \
href="mailto:usrp-users@lists.ettus.com" \
target="_blank">usrp-users@lists.ettus.com</a><br> To unsubscribe send an email to <a \
href="mailto:usrp-users-leave@lists.ettus.com" \
target="_blank">usrp-users-leave@lists.ettus.com</a><br> </blockquote></div>
</blockquote></div>
</blockquote></div>
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic