#74 Adding parts manually without "detect"

Ville Voipio

This patch adds support for manually adding parts to a chain. The command "addpart" takes the instruction register length as a parameter. BYPASS instruction (all ones) and BR register (length 1) are defined. The part id is a single zero.

After adding parts, the chain is run into BYPASS.

This patch is experimental. It allows, for example, the use of SVF files without running "detect". For example, the following magic programs a CPLD from a SVF file:

cable jtagkey ftdi-mpsse 0403:cff8
addpart 8
svf myfile.svf svf

The patch has been tested with Xilinx XC2C64A and Amontec JTAGkey. It has not been tested with a chain of more than one device.Any testing is highly appreciated!

The theory is that this command should allow adding any JTAG-compliant unknown device into the chain if its IR is known. After that all register and instruction descriptions can be added by hand, if required.


  • Ville Voipio
    Ville Voipio

    "addpart" command for UrJTAG

  • Arnim Läuger
    Arnim Läuger

    Logged In: YES
    Originator: NO

    How about having a variant of the addpart command that gets a filename parameter instead of an IR length? The file would be read via 'include' functionality so the user can add a part and load a script or BSDL file to configure it in one go.
    addpart should avoid creating the BYPASS instruction and BR register in this case, though. Clashes with existing part scripts and BSDL files would occur otherwise.

  • Ville Voipio
    Ville Voipio

    Logged In: YES
    Originator: YES

    I have been thinking a bit on the same lines. I think that "detect" does now a bit too much. There are three different tasks:

    1. detection of number of parts in the chain and the IR lengths
    2. reading the IDCODEs (requires the number of parts)
    3. loading of part parameters from the database by the IDCODE (requires the IDCODEs)

    It could be useful to separate these three. Not only because it would make code management easier, but also because the users may not need or even have all information on all parts in the chain.

    I think this would nicely split into separate functions:

    FINDCHAIN : find the chain length (parts, IRs), set BYPASS and BR

    ADDPART <n> : add a part to the end of the chain with IR length n
    ADDPART <file> : add a part to the chain and read the description from <file>

    GETIDS : find the IDCODEs for the chain

    SETID <ID> : set the IDCODE of the active part
    SETID <ID> <n> : as above but for the nth part in the chain

    GETDESC : include the file for current part (by IDCODE)
    GETDESC <n> : as above but for nth part in the chain
    GETDESC ALL : as above but for all parts

    I think these commands would cover most needs. Current "detect" would be "findparts :: getids :: getdesc all" (and of course would be left as a shorthand).

  • Kolja Waschk
    Kolja Waschk

    Logged In: YES
    Originator: NO

    Looks really good. The addpart command has a constant number of arguments, which is preferable, compared to a possible derivative of "detect" with IR lengths as arguments. That's perfect for the future API.

    Additionally, there could be functions for resetting the chain description, and verification whether the current description matches the actual connected chain. For verification, the SETID could take another argument with a mask of bits to compare (e.g. to mask out die revision numbers).