From: Arnim L. <arn...@gm...> - 2007-11-16 11:50:28
|
>> Some parts of existing code were modified. > > So far it looks very good, I endorse merging it into trunk. I made > some quick tests with an USB-Blaster attached, all fine. It's on trunk now. > We could introduce buffering replacements for "chain_clock", > "transfer", even "get_tdo" etc. Such replacement would just schedule > the actual operation for later in some static buffer. Execution of > the operations collected in the buffer would happen at a later time; > either whenever the caller asks for results, or with some kind of > flush() function. I was thinking about something similar but have no definite conclusion for it. In general, the chain functions can be split into two different classes. Control operations like chain_clock and chain_set_trst while chain_get_tdo, chain_get_trst and chain_shift_instructions / chain_shift_data_registers are observe operations. The chain_shift_data_registers is special as it can be either control-only or control&observe depending on the capture_output parameter. Finishing a command is also an observe task as the user can then observe the new state of the JTAG circuitry (LEDs, memory contents, FPGA function). Control operations can easily be buffered. As soon as an observe operation is scheduled, things become more complicated. Without any modifications to existing routines like flashing, writing, SVF etc., such an observe task must always flush previously buffered controls and it has to be executed immediately. The chain/cable code has to assume that the result is required in any case. > New version: > > ... other operations > (void)get_tdo_defer > ... other operations > x = get_tdo_result This would solve the problem that each get_tdo must flush the previously deferred operations. However, we need to have some stacking mechanism (at least for the transfer) where the cable driver retrieves TDI data (copied from the initial request), and adds TDO data afterwards once the operation yields result data. All higher level applications would need to follow such a deferred stacking somehow. I.e. they must know that result data is pending in a certain sequence. Cheers Arnim |