Ø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 >>> - 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.
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. Regards Magnus _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
