tproc64x32 Number of Output Channels Configurable #55
Comments
|
Hi, good question - I don't see an obvious problem with just leaving the excess tProc outputs disconnected. You would need to make sure never to write to those open ports, because writes will block. We also have an axis_terminator block that you could connect to the unused ports, which will swallow any writes you make to those ports. Will that work? |
|
Hi there,
The set commands are non-blocking. So even if the ready signal of the port
is low, it should not block the processor. The best way however is to
connect an axis terminator to be sure this is an "always ready" port and no
warnings are issued by the synthesis tool. The block should be part of the
IPs so you can just instantiate it and set the number of bits to match the
output port of the tProc.
Hope this helps.
Leo
…On Fri, Jul 8, 2022 at 10:36 AM Sho Uemura ***@***.***> wrote:
Hi, good question - I don't see an obvious problem with just leaving the
excess tProc outputs disconnected. You would need to make sure never to
write to those open ports, because writes will block. We also have an
axis_terminator block that you could connect to the unused ports, which
will swallow any writes you make to those ports. Will that work?
—
Reply to this email directly, view it on GitHub
<#55 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKIMULNTJW7FFNGPN4QFNKLVTBDIRANCNFSM526FQICQ>
.
You are receiving this because you were assigned.Message ID:
***@***.***>
|
|
Leaving the ports disconnected will cause issues with the Python code when it searches for port connections; at least that’s what I’ve seen. I’ll add the AXIS Terminator IP (three instances), set the data bits to 160 to match the tProc output and remove the IP chains for three of the AXIS Signal Generators so the 208 configuration matches the 216 without adding more DACs, which I don’t need. If I need more generators later, I’ll reconfigure the design and deal with the additional DAC clock domains. |
|
Sure just add a clock crossing after the tproc. By the way, I've played
around with the rfsoc and if you have DACs on different tiles with the same
clock, you can use a unique clock for the s_axis_* port of the DAC. That
won't overflow the internal dac's fifo as everything is locked to the same
base PLL in the board. This could eliminate more domain crossings at the
logic level. Just commenting in case is useful for you.
…On Fri, Jul 8, 2022 at 12:05 PM Jeff Ramsey ***@***.***> wrote:
Leaving the ports disconnected will cause issues with the Python code when
it searches for port connections; at least that’s what I’ve seen. I’ll add
the AXIS Terminator IP (three instances), set the data bits to 160 to match
the tProc output and remove the IP chains for three of the AXIS Signal
Generators so the 208 configuration matches the 216 without adding more
DACs, which I don’t need. If I need more generators later, I’ll reconfigure
the design and deal with the additional DAC clock domains.
Thank you both for your responses.
—
Reply to this email directly, view it on GitHub
<#55 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKIMULNSQF6KSJUOPG7CKKDVTBNWPANCNFSM526FQICQ>
.
You are receiving this because you were assigned.Message ID:
***@***.***>
|
|
A “clock crossing”? Sorry that’s not a term I recall. Thanks for the note about the common DAC clock. |
|
A quick question you might be able to help me with. I added three AXIS Terminator IP blocks for the three output ports from the tproc that I don't need, and I get the following errors: [BD 41-237] Bus Interface property FREQ_HZ does not match between /axis_terminator_2/s_axis(99999985) and /axis_tproc64x32_x8_0/m3_axis(430080000) Do I need to do something with the clocks (like adding an ASI4_Stream Clock Converter)? I don't see any option to set the clock frequency on the AXIS Terminator blocks. Here's an excerpt of the block diagram, if this helps (I know it's out of context). Thanks. Jeff
|
|
That’s what I was saying today about clock domain crossing. To avoid that error connect the clock of the terminators to the aclk of the tproc.
… On Jul 8, 2022, at 4:26 PM, Jeff Ramsey ***@***.***> wrote:
A quick question you might be able to help me with. I added three AXIS Terminator IP blocks for the three output ports from the tproc that I don't need, and I get the following errors:
[BD 41-237] Bus Interface property FREQ_HZ does not match between /axis_terminator_2/s_axis(99999985) and /axis_tproc64x32_x8_0/m3_axis(430080000)
[BD 41-237] Bus Interface property CLK_DOMAIN does not match between /axis_terminator_2/s_axis(d_1_zynq_ultra_ps_e_0_0_pl_clk0) and /axis_tproc64x32_x8_0/m3_axis(d_1_usp_rf_data_converter_0_0_clk_dac2)
[BD 41-237] Bus Interface property FREQ_HZ does not match between /axis_terminator_3/s_axis(99999985) and /axis_tproc64x32_x8_0/m5_axis(430080000)
[BD 41-237] Bus Interface property CLK_DOMAIN does not match between /axis_terminator_3/s_axis(d_1_zynq_ultra_ps_e_0_0_pl_clk0) and /axis_tproc64x32_x8_0/m5_axis(d_1_usp_rf_data_converter_0_0_clk_dac2)
[BD 41-237] Bus Interface property FREQ_HZ does not match between /axis_terminator_4/s_axis(99999985) and /axis_tproc64x32_x8_0/m7_axis(430080000)
[BD 41-237] Bus Interface property CLK_DOMAIN does not match between /axis_terminator_4/s_axis(d_1_zynq_ultra_ps_e_0_0_pl_clk0) and /axis_tproc64x32_x8_0/m7_axis(d_1_usp_rf_data_converter_0_0_clk_dac2)
Do I need to do something with the clocks (like adding an ASI4_Stream Clock Converter)? I don't see any option to set the clock frequency on the AXIS Terminator blocks. Here's an excerpt of the block diagram, if this helps (I know it's out of context). Thanks.
Jeff
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were assigned.
|
|
Leo, the design changes are done and the bit file is built. I have one quick question: with the removal of three of the signal generators and the addition of axis terminators on the tproc and the axi4 stream switch, there are three ports (3, 5, 12) left unconnected on the axi interconnect (see pic below). I was going to leave those alone. Do you see any issue with leaving those three ports disconnected? How would you handle it? Thanks, again. Jeff
|
|
The easiest is to just leave it unconnected. Otherwise you will have to shift all connections and it’s not easy…
… On Jul 9, 2022, at 8:33 AM, Jeff Ramsey ***@***.***> wrote:
Leo, the design changes are done and the bit file is built. I have one quick question: with the removal of three of the signal generators and the addition of axis terminators on the tproc and the axi4 stream switch, there are three ports (3, 5, 12) left unconnected on the axi interconnect (see pic below). I was going to leave those alone. Do you see any issue with leaving those three ports disconnected? How would you handle it? Thanks, again.
Jeff
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were assigned.
|
|
I looked at the register mappings of all the ports on the interconnect and figured it wasn't easy to change, so I'll leave them as it. If the Python code has issues when it traverses the netlist looking for ports, I'll look at it again. One more thing; I see the following three warnings when I build the bit file. The bit file was originally done for a ZCU111, then ported to a ZCU216 and I'm porting that model to a ZCU208. I assume the ZCU111 warning has been in the ZCU216 port for a while and hasn't caused issues. I'd like to clean up the warnings, but I don't see how to change the configuration in Vivado. Where is that done? Thanks again for your help. [IP_Flow 19-4965] IP fir_compiler_0 was packaged with board value 'xilinx.com:zcu216:part0:2.0'. Current project's board value is 'xilinx.com:zcu208:part0:2.0'. Please update the project settings to match the packaged IP. |
|
Yes most of the times those warnings are not harmful. I even have them when I switch boards…
Hope all this works!! Good luck!!
… On Jul 9, 2022, at 1:16 PM, Jeff Ramsey ***@***.***> wrote:
I looked at the register mappings of all the ports on the interconnect and figured it wasn't easy to change, so I'll leave them as it. If the Python code has issues when it traverses the netlist looking for ports, I'll look at it again. One more thing; I see the following three warnings when I build the bit file. The bit file was originally done for a ZCU111, then ported to a ZCU216 and I'm porting that model to a ZCU208. I assume the ZCU111 warning has been in the ZCU216 port for a while and hasn't caused issues. I'd like to clean up the warnings, but I don't see how to change the configuration in Vivado. Where is that done? Thanks again for your help.
[IP_Flow 19-4965] IP fir_compiler_0 was packaged with board value 'xilinx.com:zcu216:part0:2.0'. Current project's board value is 'xilinx.com:zcu208:part0:2.0'. Please update the project settings to match the packaged IP.
[IP_Flow 19-4965] IP dds_compiler_0 was packaged with board value 'xilinx.com:zcu216:part0:2.0'. Current project's board value is 'xilinx.com:zcu208:part0:2.0'. Please update the project settings to match the packaged IP.
[IP_Flow 19-4965] IP dds_compiler_0 was packaged with board value 'xilinx.com:zcu111:part0:1.1'. Current project's board value is 'xilinx.com:zcu208:part0:2.0'. Please update the project settings to match the packaged IP.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were assigned.
|
|
I'm past the issue with unconnected outputs, and the bit file is built and running (but not yet quite working). I've a DAC clock issue that's preventing the Send_receive_pulse demo from working, and I'll post that in a new thread since it's a different issue. Thanks again for your help. |
Has there been any consideration given to making the tproc64x32 IP have a configurable number of output channels instead of fixed at eight, so that the number can be set in Vivado? The reason I ask is, that it appears as though it would be simpler to reduce the number of output channels on the tproc IP with my ZCU208 port than add more DACs with two more clock domains to make up the difference between the ZCU216 and ZCU208 DAC configuration.
The text was updated successfully, but these errors were encountered: