Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: rfnoc-modtool cores (EJ Kreinar)
2. Re: Setting E310 time to GPS time (Philip Balister)
3. placement error due to large number of dsp slices (Oliver Wayne)
4. Re: RFNoC: Time Share a CE (Michael West)
5. Error with multiple block output ports (Barker, Douglas W.)
6. Re: X310 samples delay (Michael West)
7. Re: placement error due to large number of dsp slices
(Jonathon Pendlum)
8. Re: placement error due to large number of dsp slices
(Oliver Wayne)
9. Re: placement error due to large number of dsp slices
(Jonathon Pendlum)
10. Re: placement error due to large number of dsp slices
(Oliver Wayne)
----------------------------------------------------------------------
Message: 1
Date: Fri, 19 May 2017 12:08:21 -0400
From: EJ Kreinar <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] rfnoc-modtool cores
Message-ID:
<CADRnH236aHpPrp8Jd77x_i4Z2tT5Pp=YrPZc0cLtsw=cchu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Jason,
Sure, I'd say just clone my fpga repo and apply the patch for now. Quick
instructions:
1. In your uhd-fpga repo: `git remote add ejk
https://github.com/ejk43/fpga.git`
a. This now sets up a remote named "ejk" which points to my fork
2. Then: `git fetch ejk new_oot_includes`
3. Then you can either checkout this branch (if you have no other changes
on your uhd-fpga repo), or cherry-pick the commits from the
new_oot_includes branch.
In lieu of an example OOT repo, here's how I set up my "rfnoc" folder
structure in the OOT repo:
rfnoc:
+ Makefile.inc
+ blocks
+ testbenches
+ fpga-src
+ Makefile.inc
+ noc_block_testblock.v
+ ip
+ Makefile.inc
+ my_ip
+ my_ip.xci
+ Makefile.inc
Here's an example top-level Makefile.inc:
RFNOC_MYTEST_DIR := $(OOT_DIR)
include $(abspath $(RFNOC_MYTEST_DIR)/fpga-src/Makefile.inc)
include $(abspath $(RFNOC_MYTEST_DIR)/ip/Makefile.inc)
Then the fpga-src Makefile.inc:
RFNOC_OOT_SRCS += $(addprefix $(RFNOC_MYTEST_DIR)/fpga-src/, \
noc_block_testblock.v \
)
Then the IP Makefile.inc (modeled after the Makefile.inc in the
uhd-fpga/usrp3/lib/ip:
include $(RFNOC_MYTEST_DIR)/ip/my_ip/Makefile.inc
LIB_MYTEST_IP_XCI_SRCS = \
$(LIB_IP_MY_IP_SRCS)
LIB_MYTEST_IP_SYNTH_OUTPUTS = \
$(LIB_IP_MY_IP_OUTS)
LIB_IP_XCI_SRCS += $(LIB_MYTEST_IP_XCI_SRCS)
And finally, the Makefile.inc inside the my_ip directory (modeled after the
lib/ip/xxx Makefile.inc):
include $(TOOLS_DIR)/make/viv_ip_builder.mak
LIB_IP_MY_IP_SRCS = $(IP_BUILD_DIR)/my_ip/my_ip.xci
LIB_IP_MY_IP_OUTS = $(addprefix $(IP_BUILD_DIR)/my_ip/, \
my_ip.xci.out \
synth/my_ip.vhd \
)
$(LIB_IP_MY_IP_SRCS) $(LIB_IP_MY_IP_OUTS) : $(LIB_IP_DIR)/my_ip/my_ip.xci
$(call BUILD_VIVADO_IP,my_ip
,$(ARCH),$(PART_ID),$(LIB_IP_DIR),$(IP_BUILD_DIR),0)
It's also possible to rejigger the testbench makefiles to build the OOT IP
for your testbench.
Again, I should pull this into an example OOT repo sometime soon, which
would make it a bit easier to have an example. Let me know if you hit any
problems.
EJ
On Fri, May 19, 2017 at 8:38 AM, Jason Matusiak <
[email protected]> wrote:
> EJ, that looks exactly like what I need to do. Is there a way for me to
> patch in your changes so I can try to use them while we wait for Ettus to
> (dis)approve your PR?
>
> Thanks!
> ~Jason
>
>
>
> On 05/18/2017 04:11 PM, EJ Kreinar wrote:
>
> Hi Jason,
>
> I currently have a PR in to the fpga repo (https://github.com/EttusResea
> rch/fpga/pull/12) that adds support for linking Makefile.inc files in OOT
> repos. Your OOT Makefile can then build the Xilinx IP and append it to your
> build as needed. I've been using this approach for some time now with
> success for both Xilinx IP and HLS designs.
>
> I have an action to provide a sample "dummy" OOT repo with the correct
> Makefiles-- but I havent gotten to it yet, unfortunately-- Was waiting for
> confirmation if this approach will be supported in-tree in the future. I
> could put something together soon though if this would help.
>
> I'd also be interested in other good solutions, if anyone has an alternate
> approach :)
>
> EJ
>
> On Thu, May 18, 2017 at 2:22 PM, Jason Matusiak via USRP-users <
> [email protected]> wrote:
>
>> I wanted to create an RFNoC block that utilized some Xilinx cores. Where
>> do I need to put these cores in the rfnoc-modtool project created directory
>> structure, and how do I go about tying that into the Vivado GUI so I can
>> build them up (just use the GUI=1 CL argument and do the save-as project
>> approach?)?
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170519/361931c2/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 19 May 2017 12:09:31 -0400
From: Philip Balister <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Setting E310 time to GPS time
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 05/04/2017 03:07 PM, Jason Matusiak wrote:
> I'll give it a shot and let you know. Thanks!
One more thing I just ran across is I think we need to add a flag to the
ntp.conf file for the clock driver:
http://doc.ntp.org/current-stable/drivers/driver28.html
Change:
server 127.127.28.0 minpoll 4 maxpoll 4 prefer
fudge 127.127.28.0 time1 0.191 refid GPS
to:
server 127.127.28.0 minpoll 4 maxpoll 4 prefer
fudge 127.127.28.0 time1 0.191 flag1 1 refid GPS
This seems to help in the case where the E3XX rtc is set wildly wrong
(which is likely). I don't have a unit with me at the moment, and need
to investigate a little more, but wanted to make sure this thought was
documented.
Philip
>
> On 05/04/2017 02:58 PM, Philip Balister wrote:
>> On 05/04/2017 02:56 PM, Jason Matusiak wrote:
>>> OK, I will try that image. Do you think you have to modify any config
>>> files, or is it working out of the box now?
>> It should work out of the box. If it doesn't let us know.
>>
>> Philip
>>
>>>
>>> On 05/04/2017 02:37 PM, Philip Balister wrote:
>>>> On 05/04/2017 10:21 AM, Jason Matusiak wrote:
>>>>> Philip, I know that this thread is a year old (nearly exactly), but we
>>>>> got around the problem previously without ever fixing it. This
>>>>> week we
>>>>> ran into it again and tried to fix it the proper way (the way you
>>>>> recommended). I grabbed the image that you pointed to (the SG3
>>>>> version), put it onto my E312, then commented out the three lines that
>>>>> look like this in the ntp.conf:
>>>>> server 0.natinst.pool.ntp.org
>>>>> server 1.natinst.pool.ntp.org
>>>>> server 2.natinst.pool.ntp.org
>>>>> server 3.natinst.pool.ntp.org
>>>>>
>>>>> I made sure that my device could see GPS via cgps, rebooted the
>>>>> machine,
>>>>> and the time is still not being set.
>>>>>
>>>>> Have you been able to reliably get the E310/E312 to grab time from
>>>>> the GPS?
>>>> I took the E312 on my desk, pulled the network cable out and rebooted,
>>>> the time set from the gps.
>>>>
>>>> 99% sure the image is from here:
>>>>
>>>> http://files.ettus.com/e3xx_images/beta/jethro-test/
>>>>
>>>> I didn't reflash a card to check the /etc/build file though :) I really
>>>> should have put the contents of that file in the directory.
>>>>
>>>> Philip
>>>>
>>>>
>>>>> Thanks!!
>>>>>
>>>>>
>>>>>> On 05/16/2016 11:54 AM, Philip Balister via USRP-users wrote:
>>>>>>> /On 05/16/2016 11:49 AM, Jason Matusiak via USRP-users wrote:
>>>>>>> />>>/Once I have a GPS lock, I would like to set the E310's system
>>>>>>> time to the />>/ > current GPS fix. Is there a way to do that (I
>>>>>>> assume so, but haven't
>>>>> found the />>/ > right combination of commands)? />/ > />/ > With a
>>>>> recent image, it should just work. />/ > />/ > Look in
>>>>> /etc/ntp.conf />/
>>>>>> Try ntpq -p />/ > cgps should give state of gps. />
>>>>>> OK, I did some tests with the Release-4 image. It looks like you
>>>>>> need to
>>>>>> comment out the lines for the network based servers when you are
>>>>>> running
>>>>>> without a network connection for ntp to pick up the gps time. It
>>>>>> appears
>>>>>> to pick up the gps time if there is a network connection.
>>>>>>
>>>>>> The fido-test-2016.05 image has an updated version of ntp that
>>>>>> appears
>>>>>> to have resolved the problem. I have not studied the ntp changelog
>>>>>> closely though.
>>>>>>
>>>>>> https://github.com/openembedded/meta-openembedded/commit/c2107a12ab666117607507ce74ac6e89804ce69c
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Is the update in OpenEmbedded.
>>>>>>
>>>>>> I'd like to know if this information helps solve peoples problems.
>>>>>>
>>>>>> Philip
>>>
>
>
------------------------------
Message: 3
Date: Fri, 19 May 2017 13:53:31 -0400
From: Oliver Wayne <[email protected]>
To: [email protected]
Subject: [USRP-users] placement error due to large number of dsp
slices
Message-ID:
<CADueRbkYJT65G=x8r34m7wwf+amdi+hzgelkehthcrt0ftp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
hello,
I have some verilog code on a usrp b200 that involves summing a series of
multiplications. This occurs in a module my_module, and the input data is
passed via a register data. As in the below.
module mymodule(radio_clk, data1, data2, ...., data100);
input [20:0] data1, data2 .... ;
input radio_clk;
reg [31:0] sum;
reg [9:0] a1, a2, a3 ... a99, a100;
reg [10:0] b1, b2, b3, ..., b99, b100;
always @(posedge radio_clk) begin
a1 = data1[9:0];
b1 = data1[20:10];
... // likewise for other indices
// Now summing all of these
sum = a1*b1;
sum = sum + a2*b2;
sum = sum + a3*b3;
...
sum = sum + a100*b100;
end
endmodule
Now for only 50 terms in the sum, this compiles and works fine. I see
one dsp slice used for every multiplication. When I get to 65
multiplications (not exactly, it might be somwhere in between), I get
the following error. Note that helper is just a register I create to
access a lookup table.
-----
Phase 1.1 Initial Placement Analysis
ERROR:Place:1073 - Placer was unable to create RPM[DSP_Cascade_RPMs] for
the component
b200_core/radio_0/inp_sig/Maddsub_data23[23]_helper23[15]_MuLt_175_OUT of
type DSP48A1 for the following reason.
The reason for this issue: The logic does not fit onto the chip in this
form. Note that this logic had to be merged with an already existing RPM
which may have caused this issue. The following components are part of this
structure: DSP48A1
b200_core/radio_0/inp_sig/Maddsub_data23[23]_helper23[15]_MuLt_175_OUT
DSP48A1
b200_core/radio_0/inp_sig/Maddsub_data24[23]_helper24[15]_MuLt_179_OUT
b200_core/radio_0/my_module/Maddsub_data"IND"[20]_
-----
Apparently this is caused by using cascaded DSP slices, but I'm not
sure exactly how to avoid this, or how to use more, smaller DSP
slices. Any help would be appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170519/f78e0745/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 19 May 2017 11:07:06 -0700
From: Michael West <[email protected]>
To: Richard Mcallister <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoC: Time Share a CE
Message-ID:
<CAM4xKroLUGxcinSQFOxmR+TNV=sk3bddudno3bok5urjkzg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Richard,
I'm not sure if there is a block out there to demonstrate the principle,
but the idea is that the block can have multiple input and output ports on
a single block and the same logic inside the block can service all the
ports. In that case, the muxing/demuxing must be done in the
implementation of the block. The design of the block might look something
like this:
------- ---------
| | ---------- | |
Input Port 0 --> | | | | | | --> Output Port 0
| | | Shared | | |
| Mux | --> | Logic | --> | Demux |
| | | | | |
Input Port 1 --> | | | | | | --> Output Port 1
| | ---------- | |
------- ---------
This example allows for 2 streams to share the same logic, thereby reducing
the resource utilization on the FPGA. Of course, the trade-off is the
added logic to mux/demux.
Regards,
Michael
On Fri, May 19, 2017 at 8:55 AM, Richard Mcallister via USRP-users <
[email protected]> wrote:
> Hi all,
>
> I saw that on the presentation here on the Ettus site (
> https://www.ettus.com/content/files/RFNoC_Wireless_at_VT_FPGA.pdf), it
> mentions you can timeshare functions between multiple streams. I can't find
> any other documentation on that or examples, and I'm not exactly sure where
> to start with this. Does anyone have experience in this and can point me
> on the right direction?
>
> Thanks,
> Rich
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170519/425b3e4b/attachment-0001.html>
------------------------------
Message: 5
Date: Fri, 19 May 2017 18:17:17 +0000
From: "Barker, Douglas W." <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Error with multiple block output ports
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hello,
I'm starting a new thread for this problem. I get an error when trying to use
more than 2 output ports on a RFNoC block. I've designed a CE that has 9
output ports and when starting the gnuradio flowgraph it errors out. When I
reduce the ports to 2 it works. If I increase the ports to 3 it errors out.
I then made a simple modification to the 'noc_block_split_stream' block that is
provided to have three output ports (also modified the associated XML files).
It error out as well, in the same way. This test has
Radio->DDC-SplitStream->host. Below are the messages produced by gnuradio when
starting. Can the folks at Ettus please take a look as it appears to be a bug
in UHD. I've attached the modified 'noc_block_split_stream.v' file so you can
easily reproduce the error.
Thanks
Doug
Generating: '/home/dm/Documents/doug_rfnoc/top_block.py'
Executing: /usr/bin/python2 -u /home/dm/Documents/doug_rfnoc/top_block.py
[32;1m[INFO] [UHD] [39;0mlinux; GNU C++ version 5.4.0 20160609; Boost_106300;
UHD_4.0.0.rfnoc-devel-316-g24b98579
[32;1m[INFO] [X300] [39;0mX300 initialization sequence...
[32;1m[INFO] [X300] [39;0mDetermining maximum frame size...
[32;1m[INFO] [X300] [39;0mMaximum frame size: 1472 bytes.
[32;1m[INFO] [X300] [39;0mSetup basic communication...
[32;1m[INFO] [X300] [39;0mLoading values from EEPROM...
[32;1m[INFO] [X300] [39;0mSetup RF frontend clocking...
[32;1m[INFO] [X300] [39;0mRadio 1x clock:200
[32;1m[INFO] [RFNOC] [39;0m[DMA FIFO] Running BIST for FIFO 0...
[32;1m[INFO] [RFNOC] [39;0mpass (Throughput: 1305.2MB/s)
[32;1m[INFO] [RFNOC] [39;0m[DMA FIFO] Running BIST for FIFO 1...
[32;1m[INFO] [RFNOC] [39;0mpass (Throughput: 1302.5MB/s)
[32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed
[32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed
[32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed
[32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed
[33;1m[WARNING] [RFNOC] [39;0m[0/SplitStream_0] defines 3 input buffer sizes,
but 1 input ports
[32;1m[INFO] [CORES] [39;0mPerforming timer loopback test...
[32;1m[INFO] [CORES] [39;0mTimer loopback test passed
[32;1m[INFO] [CORES] [39;0mPerforming timer loopback test...
[32;1m[INFO] [CORES] [39;0mTimer loopback test passed
DEBUG: output item size: 8
[33;1m[WARNING] [X300 RADIO] [39;0mset_rx_gain: could not apply gain for this
daughterboard.
INFO: Setting args on 0/DDC_0
(input_rate=200000000,output_rate=1000000,fullscale=1.0,freq=1000000.0)
DEBUG: output item size: 8
INFO: Setting args on 0/SplitStream_0 (gr_vlen=1)
DEBUG: output item size: 8
[32;1m[INFO] [RFNOC] [39;0mAssuming max packet size for 0/DDC_0
[32;1m[INFO] [RFNOC] [39;0mAssuming max packet size for 0/Radio_0
DEBUG: check_topology()
DEBUG: RFNoC blocks with streaming ports: 1
DEBUG: start(): ninputs == 0 noutputs == 3
DEBUG: creating rx streamer with:
gr_vlen=1,block_id=0/SplitStream_0,block_port0=0,block_port1=1,block_port=0
DEBUG: creating rx streamer with:
gr_vlen=1,block_id=0/SplitStream_0,block_port0=0,block_port1=1,block_port=1
DEBUG: creating rx streamer with:
gr_vlen=1,block_id=0/SplitStream_0,block_port0=0,block_port1=1,block_port=2
thread[thread-per-block[0]: <block uhd_rfnoc_SplitStream (3)>]: LookupError:
KeyError: [0/Radio_0] sr_write(): No such port: 2
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170519/70914976/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: noc_block_split_stream.v
Type: application/octet-stream
Size: 4621 bytes
Desc: noc_block_split_stream.v
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170519/70914976/attachment-0001.v>
------------------------------
Message: 6
Date: Fri, 19 May 2017 11:37:48 -0700
From: Michael West <[email protected]>
To: Carlos Alberto Ruiz Naranjo <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 samples delay
Message-ID:
<CAM4xKrqqZZVa_6-5JPm=oi3ghvtbzvsyg5pdab48_gjpvqf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Carlos,
I'm sorry, but it is difficult to understand what you need to do. If you
just want to know how to delay samples on the FPGA, some type of buffering
will be needed. But that is costly in terms of FPGA resources and I don't
understand why you would want to do that. If you are trying to align data
streams, perhaps it would be more efficient to do it in post-processing on
the PC.
Regards,
Michael
On Thu, May 18, 2017 at 12:22 PM, Carlos Alberto Ruiz Naranjo via
USRP-users <[email protected]> wrote:
> Hello,
> we have an USRP-X310 and we want introduce a DDC,to commander it from the
> PC, and a delay in the samples (about 50ms) to be sure of process the
> correct DDC samples.
>
> How could be the better way? FPGA shift register, USRP DDR3...?
>
> Greetings.
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170519/36f91387/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 19 May 2017 15:47:20 -0400
From: Jonathon Pendlum <[email protected]>
To: Oliver Wayne <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] placement error due to large number of dsp
slices
Message-ID:
<cagdo0urt3nbpmhfw-jxsv_y96csu4roxpbvvlwmkrrvd2ob...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Oliver,
You ran out of DSP slices. Also, I am surprised with 50 terms you made
timing. You can attempt to force ISE to use LUTs in place of DSP48s with
the pragma (* use_dsp48 = "no" *), and you could selectively apply it to
some of the terms in your computation. There might be a better way to
structure your code to use fewer DSPs. Do you have to calculate all 100
terms and sum them in one clock cycle or can you spread the calculation out
across multiple clock cycles?
Jonathon
On Fri, May 19, 2017 at 1:53 PM, Oliver Wayne via USRP-users <
[email protected]> wrote:
> hello,
>
> I have some verilog code on a usrp b200 that involves summing a series of
> multiplications. This occurs in a module my_module, and the input data is
> passed via a register data. As in the below.
>
> module mymodule(radio_clk, data1, data2, ...., data100);
>
> input [20:0] data1, data2 .... ;
>
> input radio_clk;
>
> reg [31:0] sum;
>
> reg [9:0] a1, a2, a3 ... a99, a100;
>
> reg [10:0] b1, b2, b3, ..., b99, b100;
>
> always @(posedge radio_clk) begin
>
> a1 = data1[9:0];
>
> b1 = data1[20:10];
>
> ... // likewise for other indices
>
> // Now summing all of these
>
> sum = a1*b1;
>
> sum = sum + a2*b2;
>
> sum = sum + a3*b3;
>
> ...
>
> sum = sum + a100*b100;
>
> end
>
> endmodule
>
> Now for only 50 terms in the sum, this compiles and works fine. I see one dsp
> slice used for every multiplication. When I get to 65 multiplications (not
> exactly, it might be somwhere in between), I get the following error. Note
> that helper is just a register I create to access a lookup table.
>
> -----
>
> Phase 1.1 Initial Placement Analysis
>
> ERROR:Place:1073 - Placer was unable to create RPM[DSP_Cascade_RPMs] for
> the component
>
> b200_core/radio_0/inp_sig/Maddsub_data23[23]_helper23[15]_MuLt_175_OUT
> of type DSP48A1 for the following reason.
>
> The reason for this issue: The logic does not fit onto the chip in this
> form. Note that this logic had to be merged with an already existing RPM
> which may have caused this issue. The following components are part of this
> structure: DSP48A1
>
> b200_core/radio_0/inp_sig/Maddsub_data23[23]_helper23[15]_MuLt_175_OUT
>
> DSP48A1
>
> b200_core/radio_0/inp_sig/Maddsub_data24[23]_helper24[15]_MuLt_179_OUT
>
>
> b200_core/radio_0/my_module/Maddsub_data"IND"[20]_
>
> -----
>
> Apparently this is caused by using cascaded DSP slices, but I'm not sure
> exactly how to avoid this, or how to use more, smaller DSP slices. Any help
> would be appreciated.
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170519/278aecda/attachment-0001.html>
------------------------------
Message: 8
Date: Fri, 19 May 2017 15:55:51 -0400
From: Oliver Wayne <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] placement error due to large number of dsp
slices
Message-ID:
<CADueRb=yszk_jgx3+wadri1sugy1s_roxfs8ee4jfj2k89t...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
hi jonathon,
when I did the compilation at 50, it said that I was only using 99/132 DSP
slices. each multiplication took 1 slice, so why did I run out at 65? I can
definitely spread across multiple clock cycles, how would I do this?
thanks for your help
On Fri, May 19, 2017 at 3:47 PM, Jonathon Pendlum <
[email protected]> wrote:
> Hi Oliver,
>
> You ran out of DSP slices. Also, I am surprised with 50 terms you made
> timing. You can attempt to force ISE to use LUTs in place of DSP48s with
> the pragma (* use_dsp48 = "no" *), and you could selectively apply it to
> some of the terms in your computation. There might be a better way to
> structure your code to use fewer DSPs. Do you have to calculate all 100
> terms and sum them in one clock cycle or can you spread the calculation out
> across multiple clock cycles?
>
>
>
> Jonathon
>
> On Fri, May 19, 2017 at 1:53 PM, Oliver Wayne via USRP-users <
> [email protected]> wrote:
>
>> hello,
>>
>> I have some verilog code on a usrp b200 that involves summing a series of
>> multiplications. This occurs in a module my_module, and the input data is
>> passed via a register data. As in the below.
>>
>> module mymodule(radio_clk, data1, data2, ...., data100);
>>
>> input [20:0] data1, data2 .... ;
>>
>> input radio_clk;
>>
>> reg [31:0] sum;
>>
>> reg [9:0] a1, a2, a3 ... a99, a100;
>>
>> reg [10:0] b1, b2, b3, ..., b99, b100;
>>
>> always @(posedge radio_clk) begin
>>
>> a1 = data1[9:0];
>>
>> b1 = data1[20:10];
>>
>> ... // likewise for other indices
>>
>> // Now summing all of these
>>
>> sum = a1*b1;
>>
>> sum = sum + a2*b2;
>>
>> sum = sum + a3*b3;
>>
>> ...
>>
>> sum = sum + a100*b100;
>>
>> end
>>
>> endmodule
>>
>> Now for only 50 terms in the sum, this compiles and works fine. I see one
>> dsp slice used for every multiplication. When I get to 65 multiplications
>> (not exactly, it might be somwhere in between), I get the following error.
>> Note that helper is just a register I create to access a lookup table.
>>
>> -----
>>
>> Phase 1.1 Initial Placement Analysis
>>
>> ERROR:Place:1073 - Placer was unable to create RPM[DSP_Cascade_RPMs] for
>> the component
>>
>> b200_core/radio_0/inp_sig/Maddsub_data23[23]_helper23[15]_MuLt_175_OUT
>> of type DSP48A1 for the following reason.
>>
>> The reason for this issue: The logic does not fit onto the chip in this
>> form. Note that this logic had to be merged with an already existing RPM
>> which may have caused this issue. The following components are part of this
>> structure: DSP48A1
>>
>> b200_core/radio_0/inp_sig/Maddsub_data23[23]_helper23[15]_MuLt_175_OUT
>>
>> DSP48A1
>>
>> b200_core/radio_0/inp_sig/Maddsub_data24[23]_helper24[15]_MuLt_179_OUT
>>
>>
>> b200_core/radio_0/my_module/Maddsub_data"IND"[20]_
>>
>> -----
>>
>> Apparently this is caused by using cascaded DSP slices, but I'm not sure
>> exactly how to avoid this, or how to use more, smaller DSP slices. Any help
>> would be appreciated.
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170519/8c35fe69/attachment-0001.html>
------------------------------
Message: 9
Date: Sat, 20 May 2017 02:11:27 -0400
From: Jonathon Pendlum <[email protected]>
To: Oliver Wayne <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] placement error due to large number of dsp
slices
Message-ID:
<cagdo0ur7dt4to-fz+jt_p04kpmcb_2cjbn3sbhyl3o+0dut...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
To help you design a more efficient architecture, I need to know where the
data for data1-100 comes from. Is it sample data? Are they coefficients?
On Fri, May 19, 2017 at 3:55 PM, Oliver Wayne <[email protected]>
wrote:
> hi jonathon,
>
> when I did the compilation at 50, it said that I was only using 99/132 DSP
> slices. each multiplication took 1 slice, so why did I run out at 65? I can
> definitely spread across multiple clock cycles, how would I do this?
>
> thanks for your help
>
> On Fri, May 19, 2017 at 3:47 PM, Jonathon Pendlum <
> [email protected]> wrote:
>
>> Hi Oliver,
>>
>> You ran out of DSP slices. Also, I am surprised with 50 terms you made
>> timing. You can attempt to force ISE to use LUTs in place of DSP48s with
>> the pragma (* use_dsp48 = "no" *), and you could selectively apply it to
>> some of the terms in your computation. There might be a better way to
>> structure your code to use fewer DSPs. Do you have to calculate all 100
>> terms and sum them in one clock cycle or can you spread the calculation out
>> across multiple clock cycles?
>>
>>
>>
>> Jonathon
>>
>> On Fri, May 19, 2017 at 1:53 PM, Oliver Wayne via USRP-users <
>> [email protected]> wrote:
>>
>>> hello,
>>>
>>> I have some verilog code on a usrp b200 that involves summing a series
>>> of multiplications. This occurs in a module my_module, and the input data
>>> is passed via a register data. As in the below.
>>>
>>> module mymodule(radio_clk, data1, data2, ...., data100);
>>>
>>> input [20:0] data1, data2 .... ;
>>>
>>> input radio_clk;
>>>
>>> reg [31:0] sum;
>>>
>>> reg [9:0] a1, a2, a3 ... a99, a100;
>>>
>>> reg [10:0] b1, b2, b3, ..., b99, b100;
>>>
>>> always @(posedge radio_clk) begin
>>>
>>> a1 = data1[9:0];
>>>
>>> b1 = data1[20:10];
>>>
>>> ... // likewise for other indices
>>>
>>> // Now summing all of these
>>>
>>> sum = a1*b1;
>>>
>>> sum = sum + a2*b2;
>>>
>>> sum = sum + a3*b3;
>>>
>>> ...
>>>
>>> sum = sum + a100*b100;
>>>
>>> end
>>>
>>> endmodule
>>>
>>> Now for only 50 terms in the sum, this compiles and works fine. I see one
>>> dsp slice used for every multiplication. When I get to 65 multiplications
>>> (not exactly, it might be somwhere in between), I get the following error.
>>> Note that helper is just a register I create to access a lookup table.
>>>
>>> -----
>>>
>>> Phase 1.1 Initial Placement Analysis
>>>
>>> ERROR:Place:1073 - Placer was unable to create RPM[DSP_Cascade_RPMs] for
>>> the component
>>>
>>> b200_core/radio_0/inp_sig/Maddsub_data23[23]_helper23[15]_MuLt_175_OUT
>>> of type DSP48A1 for the following reason.
>>>
>>> The reason for this issue: The logic does not fit onto the chip in this
>>> form. Note that this logic had to be merged with an already existing RPM
>>> which may have caused this issue. The following components are part of this
>>> structure: DSP48A1
>>>
>>> b200_core/radio_0/inp_sig/Maddsub_data23[23]_helper23[15]_MuLt_175_OUT
>>>
>>> DSP48A1
>>>
>>> b200_core/radio_0/inp_sig/Maddsub_data24[23]_helper24[15]_Mu
>>> Lt_179_OUT
>>>
>>>
>>> b200_core/radio_0/my_module/Maddsub_data"IND"[20]_
>>>
>>> -----
>>>
>>> Apparently this is caused by using cascaded DSP slices, but I'm not sure
>>> exactly how to avoid this, or how to use more, smaller DSP slices. Any help
>>> would be appreciated.
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170520/ed81739f/attachment-0001.html>
------------------------------
Message: 10
Date: Sat, 20 May 2017 11:31:35 -0400
From: Oliver Wayne <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] placement error due to large number of dsp
slices
Message-ID:
<CADueRbkwERLBWQSUB9e609h0kwRYNk8V60Na=cdcmcpwfmj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
they are integers that are set by the host using the setting_reg module. on
the cpp side, i calculate the values that i need for each a and b, then
pack the bits together and use poke32.
On Sat, May 20, 2017 at 2:11 AM, Jonathon Pendlum <
[email protected]> wrote:
> To help you design a more efficient architecture, I need to know where the
> data for data1-100 comes from. Is it sample data? Are they coefficients?
>
> On Fri, May 19, 2017 at 3:55 PM, Oliver Wayne <[email protected]>
> wrote:
>
>> hi jonathon,
>>
>> when I did the compilation at 50, it said that I was only using 99/132
>> DSP slices. each multiplication took 1 slice, so why did I run out at 65? I
>> can definitely spread across multiple clock cycles, how would I do this?
>>
>> thanks for your help
>>
>> On Fri, May 19, 2017 at 3:47 PM, Jonathon Pendlum <
>> [email protected]> wrote:
>>
>>> Hi Oliver,
>>>
>>> You ran out of DSP slices. Also, I am surprised with 50 terms you made
>>> timing. You can attempt to force ISE to use LUTs in place of DSP48s with
>>> the pragma (* use_dsp48 = "no" *), and you could selectively apply it to
>>> some of the terms in your computation. There might be a better way to
>>> structure your code to use fewer DSPs. Do you have to calculate all 100
>>> terms and sum them in one clock cycle or can you spread the calculation out
>>> across multiple clock cycles?
>>>
>>>
>>>
>>> Jonathon
>>>
>>> On Fri, May 19, 2017 at 1:53 PM, Oliver Wayne via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> hello,
>>>>
>>>> I have some verilog code on a usrp b200 that involves summing a series
>>>> of multiplications. This occurs in a module my_module, and the input data
>>>> is passed via a register data. As in the below.
>>>>
>>>> module mymodule(radio_clk, data1, data2, ...., data100);
>>>>
>>>> input [20:0] data1, data2 .... ;
>>>>
>>>> input radio_clk;
>>>>
>>>> reg [31:0] sum;
>>>>
>>>> reg [9:0] a1, a2, a3 ... a99, a100;
>>>>
>>>> reg [10:0] b1, b2, b3, ..., b99, b100;
>>>>
>>>> always @(posedge radio_clk) begin
>>>>
>>>> a1 = data1[9:0];
>>>>
>>>> b1 = data1[20:10];
>>>>
>>>> ... // likewise for other indices
>>>>
>>>> // Now summing all of these
>>>>
>>>> sum = a1*b1;
>>>>
>>>> sum = sum + a2*b2;
>>>>
>>>> sum = sum + a3*b3;
>>>>
>>>> ...
>>>>
>>>> sum = sum + a100*b100;
>>>>
>>>> end
>>>>
>>>> endmodule
>>>>
>>>> Now for only 50 terms in the sum, this compiles and works fine. I see one
>>>> dsp slice used for every multiplication. When I get to 65 multiplications
>>>> (not exactly, it might be somwhere in between), I get the following error.
>>>> Note that helper is just a register I create to access a lookup table.
>>>>
>>>> -----
>>>>
>>>> Phase 1.1 Initial Placement Analysis
>>>>
>>>> ERROR:Place:1073 - Placer was unable to create RPM[DSP_Cascade_RPMs]
>>>> for the component
>>>>
>>>> b200_core/radio_0/inp_sig/Maddsub_data23[23]_helper23[15]_MuLt_175_OUT
>>>> of type DSP48A1 for the following reason.
>>>>
>>>> The reason for this issue: The logic does not fit onto the chip in this
>>>> form. Note that this logic had to be merged with an already existing RPM
>>>> which may have caused this issue. The following components are part of this
>>>> structure: DSP48A1
>>>>
>>>> b200_core/radio_0/inp_sig/Maddsub_data23[23]_helper23[15]_MuLt_175_OUT
>>>>
>>>> DSP48A1
>>>>
>>>> b200_core/radio_0/inp_sig/Maddsub_data24[23]_helper24[15]_Mu
>>>> Lt_179_OUT
>>>>
>>>>
>>>> b200_core/radio_0/my_module/Maddsub_data"IND"[20]_
>>>>
>>>> -----
>>>>
>>>> Apparently this is caused by using cascaded DSP slices, but I'm not sure
>>>> exactly how to avoid this, or how to use more, smaller DSP slices. Any
>>>> help would be appreciated.
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170520/ed2e5464/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 81, Issue 20
******************************************
