On Saturday 09 May 2009 12:19:24 Magnus Lundin wrote: > Øyvind Harboe wrote: > > On Sat, May 9, 2009 at 11:45 AM, Magnus Lundin <lun...@mlu.mine.nu> wrote: > >> Řyvind Harboe wrote: > >>> Does anyone have any objections to adding a command > >>> to disable jtag_check_value_mask()? > >>> > >>> This is along the lines of the existing verify_ircapture and > >>> could speed things up. > >>> > >>> Checking would be on by default just like verify_ircapture. > >>> > >>> Such a command would serve two purposes(just like > >>> verify_ircapture): > >>> > >>> - measure performance impact of these checks
The performance impact of IR scan checks should be minimal, unless reading back individual bits is an expensive operation, e.g. parallel port, where each IN8 takes 1+ microseconds. That is unless doing the check requires an extra roundtrip because of "you know what"... For the FT2232 based devices it merely increases the amount of data that's read back, but this isn't that much of a problem for USB. I remember reading something about a bug with the FT2232 TX buffer (FT->PC) growing full without being read back - not sure what percentage of the TX buffer the IR scan code uses for typical scans, but this can either be measure or calculated. > >>> - during development when things are stable, it > >>> could speed things up > >> > >> Is this not exactly the same as the verify_ircapture flag for dr scans, > >> so it would be verify_drcapture. ? > >> > >> Good for me. > > > > If I put the check inside jtag_check_value_mask() today, then > > the new option would disable verify_ircapture too. > > > > Any objections to making having only one "jtag_verify" and do > > away with verify_ircapture? > > > > What makes verify_ircapture special? Why would we want to > > be able to disable that verification specifically? Are there other > > verification sites that we would want to disable specifically? > > > > I'm kinda leaning towards a single jtag_verify unless someone > > feels strongly about verify_ircapture specifically... > > This is because we use verification of ir capture to check that the jtag > scan chain is working as expected, ir scans have much more predictable > results, so this is on by default. And this really cannot be done in > taget space. The IR check can be disabled because usually, the IR values are just fine, i.e. it's a pretty abnormal situation for an IR scan not to return b...01. Still, correctness of the debugger output should be paramount, so the check is on by default. > We use verification of theck the actual (dr)data, this is not of > interest for the jtag layer, but this is a service the jtag layer does > for the upper layers, this functionality can be placed in ktag as a > service and/or be done in target space. This is useful when the > scanchain contains a bot pure datafields, 32bit words, for target layer > and extra bits for low level debug communications. This is not a > hypothetical scenario. > > So they should be idependently controllable for every scan field. And > then there can be a global on/off flag used very sparingly, perhaps only > for debug. Now this has previously been done by checking the fields > in in the scan structure, and I still beleive this a very clean method > where we put everything controlling this process in one place, instead > of adding a lot of global on off flags. > > Clean up and instrumentation for profiling is good, but be very careful > with removals, it is usually not dead code, just slightly confused code. If the fast_memory_access isn't set, the DBGACK and SYSCOMP bits are checked for each access (14 register * 4 bytes), limiting performance to 56 bytes / roundtrip-time (>=2 ms for FT2232). The arm7_9 memory read code contains an option to defer this check to allow unlimited queing of memory read commands. This greatly improves performance when using USB devices. The fast memory access is safe unless the target is running from a extremely slow clock (like a 32kHz crystal), but the check verifies integrity of the received data. This is an example of "idependently controllable for every scan field", only achieved at a more explicit level - the code requests a readback of these bits, it might defer the check to the jtag layer, or it might simply ignore the bits. To me, IR check and DR check are thus two very distinct things, because the impact of a failed check usually can't be determined at a global level. > Regards > Magnus Regards, Dominic
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
