Strange JTAG Script Behaviour

General
,
1

HI all, I’ve come across a strange issue with the JTAG Support scripts where the commands given to Vivado via stdin (used in most of the existing OCPI JTAG related scripts) result in hardware manager being unable to find anything, yet if I convert them to get the same commands from a file it works properly.

For example this snippet from the jtagSupport_x310 script to find attached JTAG cables won’t find any thing:

$vivado -mode batch -source /dev/stdin > $temp.log <<EOF
open_hw_manager
connect_hw_server -allow_non_jtag
puts "BEGIN-TARGET-LIST"
puts [get_hw_targets]
puts "END-TARGET-LIST"
disconnect_hw_server
EOF
# Return the serial number (after final slash) separately as well as combined with the URL
CABLES=`grep -v "^#" < $temp.log | sed -n '/^BEGIN-TARGET-LIST$/,/^END-TARGET-LIST$/{//!p}' | \
    sed -e 's^/\([^/]*\)\$^/\1=\1~^'`
if test $? != 0 -o "$CABLES" = ""; then
    echo No Xilinx USB JTAG cables found using the Xilinx \"vivado\" tool. 1>&2
    bad
fi
good

Yet running this practically identical version does:

$vivado -mode batch -source cables.tcl > $temp.log
# Return the serial number (after final slash) separately as well as combined with the URL
CABLES=`grep -v "^#" < $temp.log | sed -n '/^BEGIN-TARGET-LIST$/,/^END-TARGET-LIST$/{//!p}' | \
    sed -e 's^/\([^/]*\)\$^/\1=\1~^'`
if test $? != 0 -o "$CABLES" = ""; then
    echo No Xilinx USB JTAG cables found using the Xilinx \"vivado\" tool. 1>&2
    bad
fi
good

Where cables.tcl is:

open_hw_manager
connect_hw_server -allow_non_jtag
puts "BEGIN-TARGET-LIST"
puts [get_hw_targets]
puts "END-TARGET-LIST"
disconnect_hw_server

This is on Ubuntu 22.04 and the script used in the example is from the ocpi.osp.ettus project

Has anyone else come across this or have a suggestions as to a cause?

2

To clarify, the first version runs but the puts [get_hw_targets] line outputs nothing?

Or is it actually exiting with an error?

Is $? meant to be testing the return value of the second sed invocation? Because that’s what I think it’s testing.

3

Yes puts [get_hw_targets] returns nothing but otherwise operates as would be expected.

The second sed invocation is performed on the first invocation so that does appear to be the intended action