Drasko DRASKOVIC wrote:
On Thu, Apr 7, 2011 at 1:09 PM, Laurent Gauch <laurent.ga...@amontec.com> wrote:
/ <drasko.draskovic at gmail.com
<https://lists.berlios.de/mailman/listinfo/openocd-development>> wrote:
/>>/ Hi all,
/>>/ I have one general question regarding OpenOCD scans.
/>>/
/>>/ What happens when we set some field.in_value = NULL, and in reality
/>>/ there are some bits that re shifted out on the scan chain ? Are they
/>>/ just ignored ? Does that pose the problem ?
/>/
/>/ This tells the JTAG drivers to throw away the bits that are clocked in
/>/ (read from the TAP). The target hardware/TAP does not see a
difference.
/>/
/>>/ To give a concrete example, in the mips_ejtag.c we have something
like :
/>>/
/>>/ /* fastdata 1-bit register */
/>>/ fields[0].num_bits = 1;
/>>/ fields[0].out_value = &spracc;
/>>/ fields[0].in_value = NULL;
/>>/
/>>/ /* processor access data register 32 bit */
/>>/ fields[1].num_bits = 32;
/>>/ fields[1].out_value = t;
/>>/
/>>/ if (write_t)
/>>/ {
/>>/ fields[1].in_value = NULL;
/>>/ buf_set_u32(t, 0, 32, *data);
/>>/ }
/>>/ else
/>>/ {
/>>/ fields[1].in_value = (uint8_t *) data;
/>>/ }
/>>/
/>>/ So, no values are received (because fields[0].in_value = NULL and
/>>/ fields[1].in_value = NULL), but in reality MIPS EJTAG shifts out 33
/>>/ bits (one SPrAcc and 32 bits of DATA) upon this operation.
/>>/
/>>/ My question is, in general, could not accepting these bits lead to
/>>/ some problems or collisions on data lines (or USB bus) ?
/>/
/>/ The bits are simply ignored rather than stored in memory. The
/>/ protocol or target hardware is not affected as such.
/
Thanks Øyvind,
this is what I thougth...
Is there a special reason why not ignoring one bit, like :
fields[0].in_value = &spracc_in instead fields[0].in_value = NULL in
previos example gives :
downloaded 361540 bytes in 182.220215s (1.938 KiB/s) in the place of
previous downloaded 361540 bytes in 182.220215s (1.938 KiB/s) when
fields[0].in_value was ignored (NULL) ?
both 361540 bytes in 182.220215s ??? please correct.
Whoops, sorry...
Without reading in SPrAcc bit (fields[0].in_value = NULL) I can obtain
up to : 182.220215s (1.938 KiB/s).
However, when I read it in (fields[0].in_value = &spracc_in) I get :
downloaded 361540 bytes in 12.489729s (28.269 KiB/s)
without reading 182s, you sure ???
Note that jtag_execute_queue() is called in both cases.
And the same number of time ?
Not calling jtag_execute_queue() (which also implies ignoring the
SPrAcc bit) get us bigger throughput (but this is expected and no
surprise :
downloaded 361540 bytes in 4.989900s (70.756 KiB/s)
So, as you see, my main interest is the difference between 12.489729s
when in_value ignored and 182.220215s when it is clocked in memory.
This difference is way too big.
Now it is ok.
While jtag_execute_queue() latency can not be avoided if we want to do
the status check on the shifted-out bit, this additional latency just
to write shifted-out bit in memory is really suprising for me...
If you do not need to read TDO please use fields[0].in_value = NULL , ever !
Yes, off course. It can prevent segfaults, unless you correctly
allocated placeholder in the moment of queue execution. I just tried
here to do the tests. BTW. SPrAcc bit should be read, if we want
robust implementation.
If you use fields[0].in_value = &spracc_in instead fields[0].in_value =
NULL, the communication USB to Amontec JTAGkey dongles could be slower,
because the TDO must be returned back to host computer, and more USB access
will be generated.
Difference is pretty big - 12s versus 182s. Is this normal and expected ?
Right, 15x slower is really surprising -> I would say 3x to 5x could be
understandable .
Regards,
Laurent
http://www.amontec.com
BR,
Drasko
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
