[USRP-users] Re: set_command_time() question

[Marcus D. Leech]

On 2022-08-31 14:34, ri28...@mit.edu wrote:


I found the following lines in the Synchronizing USRP Events app note 
:


When commands enter the command queue, their timestamp is compared
against the command queue's sense of time and the commands are
executed when Queue Time >= Command Time. Commands without
timestamps are executed immediately when they're at the front of
the queue. Command queues in the USRP do not support on-the-fly
reordering, meaning a command at the front of the queue will block
subsequent commands from executing even if their timestamp has passed.

How does it work if a command arrives “late” to the USRP? For 
instance, I set_command_time(t1), then issue a tx_set_freq(), but the 
USRP doesn’t get the command until t1 + X, does the tx_set_freq 
immediately issue, or is it dropped? The language implies it would 
immediately issue, which is opposite the behavior of a timed tx/rx 
command.


I’ve attached an image of a spectrogram. The x axis is time, y 
frequency. I have some code that repeatedly issues tx_set_freq() 
between two frequencies on a fixed time interval. In the image, the 
fourth slot does not alternate frequency, while the fifth and sixth 
slots appear to be a time shifted glimpse of how the fourth and fifth 
slots should appear.


Is this likely an instance of the USRP not receiving the scheduled 
command fast enough, and immediately issuing several commands upon 
getting them?



I don't think any of the USRPs drop commands that are late, but rather, 
they get executed immediately.


What is the hardware we're talking about, and what is your cadence?

___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: set_command_time() question

[ri28856]

This is a USRP x310, and I’m issuing a command every \~150 us. I increased the 
size of the timed command FIFO in the FPGA to 64.

Over long periods of time, I have hiccups like shown above on the order of 
every 20 ms or so. I think what’s happening is I’m not quite keeping the USRP 
queue full when the OS interrupts the thread, but I’m having trouble 
diagnosing. There doesn’t appear to be a back pressure mechanism for timed 
commands in the same way there is for the tx_streamer, so I have to track by 
elapsed time how full I think the USRP queue is.
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: set_command_time() question

[Marcus D. Leech]

On 2022-08-31 14:49, ri28...@mit.edu wrote:


This is a USRP x310, and I’m issuing a command every ~150 us. I 
increased the size of the timed command FIFO in the FPGA to 64.


That may be a fairly ambitous cadence for the RF PLL on the 
daughtercard, depending on the card.   Certainly Linux sustaining
  that kind of cadence in scheduling is unlikely to be long-term 
sustainable.


Over long periods of time, I have hiccups like shown above on the 
order of every 20 ms or so. I think what’s happening is I’m not quite 
keeping the USRP queue full when the OS interrupts the thread, but I’m 
having trouble diagnosing. There doesn’t appear to be a back pressure 
mechanism for timed commands in the same way there is for the 
tx_streamer, so I have to track by elapsed time how full I think the 
USRP queue is.



___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: importing ip cores generated by Simulink

[Kevin Williams]

Hi Wade,

Thanks! I came right by including the generated files but did struggle with
the folder structures and makefiles. However, it is working nicely now,
with a complete RFNoC OOT module in bitbucket which gets mounted as a user
folder in a docker container which holds all the UHD sources, Vivado, and
so on. HDL is generated in the appropriate place, with all makefiles
configured for that.

I think the rfnoc-example and the template folder tree created by
rfnocmodtool differ, especially in the way the makefiles are set up.

My next step is to extract data types, IO registers, etc. from the Simulink
models, and generate the YAML files for the IP core.

Kind regards, Kevin


On Tue, 30 Aug 2022 at 18:02, Wade Fife  wrote:

> 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 files
> are included in the build. Ettus has several IP components that get used
> this way (usually as part of a BD) which are located in
> fpga/usrp3/lib/vivado_ipi. This might serve as a reference.
>
> If the code generated includes standard HDL (Verilog or VHDL) then you
> might also be able to include those as source in the design as another
> option.
>
> Wade
>
> On Tue, Aug 30, 2022 at 3:55 AM Kevin Williams  wrote:
>
>> Hi Everyone,
>>
>>
>>
>> I’m a model-based firmware designer generating IP cores from Matlab and
>> Simulink.
>>
>>
>>
>> I see from one of the Ettus tutorials that it is easy to include a core
>> defined by an “xci” file, but not the “xml” descriptions from Simulink.
>> (This was the rfnoc_block_gain exercise.)
>>
>>
>> The folder in which those xml files live can be added as user repo's in
>> Vivado, and the core is recognised, but I have issues trying to use that IP
>> in the main design.
>>
>>
>>
>> Is this possible using the existing Ettus scripts?
>>
>>
>> Many thanks, Kevin
>>
>> ___
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>
>

-- 
Kevin Williams
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com