Øyvind Harboe wrote:
> On Tue, Apr 28, 2009 at 10:48 PM, Dick Hollenbeck <d...@softplc.com> wrote:
>   
>> Michael Bruck wrote:
>>     
>>> So my question would be: does anyone know if the drivers produce
>>> different state transitions (except for idling on stable states) for
>>> the jtag_* calls, including more complex stuff that involves
>>> jtag_add_ir_scan etc. ?
>>>
>>>       
>> This is a superbly excellent question.
>>     
>
> To which the application code should assume "yes". Different drivers
> *will* do different things. Use jtag_add_pathmove() when specific
> behaviour is required.
>
> I've updated the documentation of jtag_add_pathmove() to
> explain this a bit.
>
>   
>>  One that is related to my question
>> about WTF is the tap machine even doing while I am programming an FPGA.
>>  This is precisely why I felt it absolutely necessary to implement state
>> transition logging.  That exists in its earliest form on the ft2232.c patch
>> I just submitted.  Once we have this in place for *all* drivers, then it
>> might actually be possible to ANSWER your most excellent question, which is
>> related to mine.
>>
>> You could then compare the paths taken between two cables.
>>     
>
> So each interface driver must be responsible for logging transitions as
> only the interface driver could possibly know(even the driver might not
> actually know the precise path if this is somehow implemented by
> lower level hardware/firmware).
>   

If question, yes.  tap_set_state() is in the "Cable helper API" and 
anything in there is thought to be callable (only) from cable drivers.   
An aid to implementing this is to figure out where clock cycles are 
being issued.  On any such clock output issuance, there is potential for 
a state transition and a need for the call to tap_set_state().  That is 
a recipe for a rigorous state tracker.

I guess it is the notion that the cable drivers have the most knowledge 
of the clock cycles that gives this justification.

Dick

_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to