At least for some Xilinx parts, "detect" would automatically load a data file that contains package-specific data although it just knows the IDCODE (and there are parts with the same IDCODE but different packages).
Such data files should be split in a package-independent and a package-specific part. The latter should not be loaded automatically. "detect" could emit a list of known packages and how to load them manually, to assist the user during interactive sessions.
https://sourceforge.net/forum/forum.php?thread_id=2008553&forum_id=682993
Logged In: YES
user_id=59002
Originator: NO
I have the idea of porting XC3SPROGs basic chain handling to urjtag. XC3SPROG only depends on one single data file "devlist.txt" in the form:
# IDCODE IR Length Text
0140d093 6 XC3S50
01414093 6 XC3S200
0141c093 6 XC3S400
It matches the IDCODE to device and makes the IR Length know. This is all info needed to bypass the device in a chain. If further action is needed on a device, then more specialized knowledge is needed, like an implementation of the programming algorithme like in progalgxc3s or a BSDL file.
If time permits, I will try to add a "detectchain" to urjtag, like xc3sprogs detectchain.
Logged In: YES
user_id=478715
Originator: YES
The IR length is auto-detected during "detect". I haven't seen any report of misdetected IR length yet (except with broken chains or cable drivers). A part practically doesn't have to be described anywhere in order to be bypassed, does it?