Непонятки с конфигурацией Циклона Опции

[okela]

Добрый день.

Воюю с заливкой конфигурации в CycloneV E. Есть две схемы конфигурирования: JTAG и FPPx8. Пока могу пользоваться только JTAG-ом. Циклон включен в цепочку еще с МАХII. Все входы MSEL[4..0] притянуты к общему проводу через 1,5КОм резюки с возможностью подключить напрямую VCC_3.3V, но пока все в нуле. Пробую заливать конфигурацию через JTAG - вроде все идет гладко, INIT_DONE включен и сразу падает в ноль пока идет процесс конфигурации. По окончании конфигурирования программатор говорит что все ОК, INIT_DONE подскакивает в "1", а вот nSTATUS и CONF_DONE как были в состоянии "0" при подаче питания так и не шелохнулись даже... Но самое интересное, что в реальности похоже не происходит переход в user mode, т.к. в проекте включаю светодиод без всяких клоков и условий, а он никак не реагирует на это после заливки конфигурации. Не пойму что происходит, третий день бьюсь уже...
Сигналы nSTATUS, CONF_DONE, nCONFIG подтянуты к VCC_3.3V. Питание VCCPGM и VCCPD также 3,3В. Поискал немного в разделе, нашел что пишут о том, что обязательно нужно входы MSEL[4..0] непосредственно притягивать к земле (без резюков). Насколько это критично для JTAG-конфигурации ?

[doom13]

Уверены, что с питанием всё нормально? Были проблемы с конфигурацией, во всём оказались виноваты источники питания.

что обязательно нужно входы MSEL[4..0] непосредственно притягивать к земле (без резюков). Насколько это критично для JTAG-конфигурации ?

На наших платах без резаков.

[okela]

Уверены, что с питанием всё нормально? Были проблемы с конфигурацией, во всём оказались виноваты источники питания.

Дык, по питанию вроде и придраться особо некчему... :

VCC_1.1 = 1.09 V
VCC_2.5 = 2.45 V
VCC_3.3 = 3.28 V

[iosifk]

Пока могу пользоваться только JTAG-ом. Циклон включен в цепочку еще с МАХII.

Сигналы JTAG смотрели? Клоки чистые? Все остальные чистые? Обе микросхемы определяются?
Частоту снижать пробовали?

[doom13]

Дык, по питанию вроде и придраться особо некчему... :
VCC_1.1 = 1.09 V
VCC_2.5 = 2.45 V
VCC_3.3 = 3.28 V

То, с чем столкнулись - обвязка для импульсников была плохо подобрана, скважность ШИМ плавала и уровни питания "немного" шумели (мультиметром нормальный уровень показывало), устранили и сразу всё запустилось.
Резисторы с MSEL убирайте, не нужны они там.
Раз есть возможность, поставте конфигурацию в AS. FPGA должна будет пробовать грузится по SPI постоянно. На nSTATUS и nCONFIG будет наблюдаться импульсный сигнал с каким-то там периодом, что означает - с FPGA всё гуд, она пробует грузиться. Если так, дальше с JTAG будете разбираться.
Ваш CONF_DONE = 0 означает, что конфигурация не произошла.

[jks]

Проверьте значения MSEL[4..0].

Конфигурация MSEL[4..0] = 00000 только для режима FPPX16.

Для FPPx8 допустимые значения MSEL[4..0]
10100/11000 - без сжатия и шифрования
10101/11001 - без сжатия и с шифрованием
10110/11010 - с сжатием и с шифрованием / с сжатием и без шифрования

JTAG работает всегда независимо от значений MSEL.

Да еще добавлю.

Если MAXII и FPGA в одной цепочке и nCONFIG заведен на MAXII то его надо отвязать от него или отключить питание ядра MAXII.

[okela]

Сигналы JTAG смотрели? Клоки чистые? Все остальные чистые? Обе микросхемы определяются?
Частоту снижать пробовали?

Посмотреть сигналы JTAG пока нет возможности - нет под рукой подходящего осцила. Оба чипа в цепочке определяются с первого пинка. Частоту снижать не пробовал - пока не чем это сделать. Скачал UniversalScan, но там нужно пробную лицензию получить. Пока жду ответа. Установил пока программулину TopJTAG Probe, пробовал поиграться с ней. В Циклоне есть пара юзер-выводов, подключенных к светодиодам - оба врукопашную отлично управляются через инструкции EXTEST ! Т.е. можно предположить что с JTAG все в порядке ? Тем более что и процесс программируования как бы визуально проходит без ругательств Квартуса...

То, с чем столкнулись - обвязка для импульсников была плохо подобрана, скважность ШИМ плавала и уровни питания "немного" шумели (мультиметром нормальный уровень показывало), устранили и сразу всё запустилось.
Резисторы с MSEL убирайте, не нужны они там.
Раз есть возможность, поставте конфигурацию в AS. FPGA должна будет пробовать грузится по SPI постоянно. На nSTATUS и nCONFIG будет наблюдаться импульсный сигнал с каким-то там периодом, что означает - с FPGA всё гуд, она пробует грузиться. Если так, дальше с JTAG будете разбираться.
Ваш CONF_DONE = 0 означает, что конфигурация не произошла.

Аналогично - посмотреть на питание осцилом пока не могу... С CONF_DONE = 0 понятно, что шось не тоё, но сбивает с толку нормальная отработка сигнала INIT_DONE. Буду разбираться дальше.

[jks]

А NCONFIG в каком состоянии после INIT_DONE?

Если в "1", то возможно просто не хватает тактов для завершения перехода в USER_MODE.

[okela]

Проверьте значения MSEL[4..0].

Конфигурация MSEL[4..0] = 00000 только для режима FPPX16.

Для FPPx8 допустимые значения MSEL[4..0]
10100/11000 - без сжатия и шифрования
10101/11001 - без сжатия и с шифрованием
10110/11010 - с сжатием и с шифрованием / с сжатием и без шифрования

JTAG работает всегда независимо от значений MSEL.

Да еще добавлю.

Если MAXII и FPGA в одной цепочке и nCONFIG заведен на MAXII то его надо отвязать от него или отключить питание ядра MAXII.

Судя по докам от Альтеры, то состояние MSEL[4..0] мало влияет на режим JTAG-конфигурирования, хотя с другой стороны они пишут что надо установить валидное значение из таблицы возможных состояний. Вход nCONFIG подтянут к '1', вход nCE - на земле.

А NCONFIG в каком состоянии после INIT_DONE?

Если в "1", то возможно просто не хватает тактов для завершения перехода в USER_MODE.

Ээээ... Не совсем понлял: nCONFIG, насколько я разбираюсь в медицине, - это вход управления конфигурацией и как он может изменить самостоятельно свое логическое состояние ?

[doom13]

но сбивает с толку нормальная отработка сигнала INIT_DONE

Если смотреть на последовательность конфигурации, то вообще не понятно, каким образом Ваш INIT_DONE установился в 1, это могло произойти только после установки в 1 CONF_DONE. На наших платах INIT_DONE никогда не использовали.

[jks]

Судя по докам от Альтеры, то состояние MSEL[4..0] мало влияет на режим JTAG-конфигурирования, хотя с другой стороны они пишут что надо установить валидное значение из таблицы возможных состояний. Вход nCONFIG подтянут к '1', вход nCE - на земле.

Ээээ... Не совсем понлял: nCONFIG, насколько я разбираюсь в медицине, - это вход управления конфигурацией и как он может изменить самостоятельно свое логическое состояние ?

Это я уточнить хотел куда подключен вывод nCONFIG и не может ли его извне что-то сажать в "0".
У меня была похожая проблема с CyclonеIV и MAXII.
CyclonеIV и MAXII также были подключены по цепочке JTAG.
У меня конфигурация шла через MAXII и выводы программирования в режиме PS (NCONFIG, NSTATUS, CONFDONE, DCLK, DATA0 были подключены к MAXII).
Так вот при конфигурации весь битстрим записывался, после этого CONFDONE устанавливался в "1", а потом через 50-100мс сбрасывался в "0".
Я долго немог понять в чем дело. Заметил что NCONFIG падает в "0" после установки CONFDONE в "1".
Думал проблема в питании. Отключил питание (VCCIO) MAXII, при этом питание ядра MAXII осталось.
Так вот пока полностью не отрубил MAXII прошить через JTAG не удалось.

Еще может быть проблема если банки конфигурации от разных напряжений запитаны.
Но у Вас похоже одинаковое.

А Вы состояние пинов MSEL[4..0], NCONFIG, NSTATUS, CONF_DONE по JTAG не можете прочитать?
Может не пропай на CONF_DONE или резистор слишком высокоомный.

[okela]

А Вы состояние пинов MSEL[4..0], NCONFIG, NSTATUS, CONF_DONE по JTAG не можете прочитать?
Может не пропай на CONF_DONE или резистор слишком высокоомный.

Могу прочитать только состояние пинов MSEL[4..0] - все в "0". Остальные не показываают свое состояние.

[doom13]

Могу прочитать только состояние пинов MSEL[4..0] - все в "0". Остальные не показываают свое состояние.

Если вы использовали Universal Scan, то там, по-моему, можно состояние всех пинов посмотреть.

[okela]

Если вы использовали Universal Scan, то там, по-моему, можно состояние всех пинов посмотреть.

Смотрел с помощью TopJTAG Probe. С Universal Scan пока не разобрался как читать состояние пинов.
Также пробовал установить на входах MSEL[4..0] комбинацию 10011, соответствующую режиму AS. Никакой разницы - на CONF_DONE и nSTATUS все по прежнему (голый "0")...

[jks]

Возможно PR_REQUEST и DCLK надо подтянуть к земле шоб не болтались.

[doom13]

Смотрел с помощью TopJTAG Probe. С Universal Scan пока не разобрался как читать состояние пинов.

Там же всё просто, лампочку на порт вешаете, если горит, значит подтянут к 1, если нет - к 0. А можно клок на порт выдать. Сам не так давно ею пользовался, плисина перестала грузиться после допайки парочки компонентов на плату, оказалось одно починили второе сломали, один из MSEL отвалился после таких манипуляций.
Что накопали при помощи TopJTAG Probe?

Также пробовал установить на входах MSEL[4..0] комбинацию 10011, соответствующую режиму AS. Никакой разницы - на CONF_DONE и nSTATUS все по прежнему (голый "0")...

Вот тут получается, что что-то не так, должно было бы циклически пробовать слить прошивку, и nSTATUS должен был бы периодически меняться с 0 на 1 (ну и ноги AS посмотреть, если есть возможность). Попробуйте всё же проверить питание, всё ли там нормально, как писал, у нас проблема была именно в этом.

[okela]

Покурив доки нашел такую зацепку: сигнал nSTATUS мониторится на стадии POR и если что-то с питающими напругами не так, то он не поднимется в исходную "1". Также обратил внимание на то, что рекомендуется последовательность подачи питания на кристалл: VCC_1.1V --> VCC_2.5V, VCC_3.3V. Я последний момент упустил при разработке схемы. У меня все преобразователи запускаются одновременно. Возможно из-за этого сигнал nSTATUS не устанaвливается в исходное состояние ?

[doom13]

Покурив доки нашел такую зацепку: сигнал nSTATUS мониторится на стадии POR и если что-то с питающими напругами не так, то он не поднимется в исходную "1". Также обратил внимание на то, что рекомендуется последовательность подачи питания на кристалл: VCC_1.1V --> VCC_2.5V, VCC_3.3V. Я последний момент упустил при разработке схемы. У меня все преобразователи запускаются одновременно. Возможно из-за этого сигнал nSTATUS не устанaвливается в исходное состояние ?

Вполне возможно, на наших платах так и сделано, источники запускаются последовательно, сначала подаётся 1.1 В на ядро, потом уже питание на банки. Сигнал Power Good источника 1.1 В разрешает запуск остальных.
Запитайте от внешнего источника питания, проверите - в этом ли причина.

[Raven]

Если мне не изменяет память, nSTATUS также может сбрасываться при ошибке в принимаемом битовом потоке. Есть ли у вас возможность провести конфигурирование на существенно более низкой частоте TCK? Скажем, вытащить из дальнего ящика ByteBlaster и попробовать с ним?

К сожалению, классический USB Blaster (тот, что первого поколения) не позволяет снижать fTCK, и это при том, что штатно она задрана высоковато (6 МГц).

[doom13]

Если мне не изменяет память, nSTATUS также может сбрасываться при ошибке в принимаемом битовом потоке.

Может, но тут, похоже, он и не поднимался.

[okela]

Вполне возможно, на наших платах так и сделано, источники запускаются последовательно, сначала подаётся 1.1 В на ядро, потом уже питание на банки. Сигнал Power Good источника 1.1 В разрешает запуск остальных.
Запитайте от внешнего источника питания, проверите - в этом ли причина.

Попробовал подавать напруги 2,5 В и 3,3 В после запуска источника 1,1 В. Сигнал nSTATUS попрежнему сидит в нуле сразу после включения всех напряжений ...

Если мне не изменяет память, nSTATUS также может сбрасываться при ошибке в принимаемом битовом потоке. Есть ли у вас возможность провести конфигурирование на существенно более низкой частоте TCK? Скажем, вытащить из дальнего ящика ByteBlaster и попробовать с ним?

К сожалению, классический USB Blaster (тот, что первого поколения) не позволяет снижать fTCK, и это при том, что штатно она задрана высоковато (6 МГц).

nSTATUS изначально притянут к нулю и не дрыгается в процессе. С ByteBlaster-ом несколько проблематично все - ввиду LPT-порта. Но судя по всему дело не в частоте JTAGa. т.к. сам он вполне нормально работает как я писал выше.

[doom13]

Ещё раз глянул на схему конфигурации FPP (у Вас всё, как на рисунке?), и возник вопрос: не может ли MAX II быть причиной данной проблемы?
И кстати, уже советовали:

Если MAXII и FPGA в одной цепочке и nCONFIG заведен на MAXII то его надо отвязать от него или отключить питание ядра MAXII.

Это Вы проверяли?

Эскизы прикрепленных изображений

 

[okela]

MAXII у меня в одной цепочке с Циулоном только по JTAG-порту. Управление закрузкой Цилона в режиме FPP заложено через дополнительный контроллер, который будет дергать nCONFIG и все остальное. Но до него я еще не добрался.

[doom13]

MAXII у меня в одной цепочке с Циулоном только по JTAG-порту. Управление закрузкой Цилона в режиме FPP заложено через дополнительный контроллер, который будет дергать nCONFIG и все остальное. Но до него я еще не добрался.

По схеме конфигурации nCONFIG подтянут к плюсу, не может ли то, к чему он у Вас подключен каким-то образом вешать его в ноль, что подтяжка к 1 не работает и на нём всегда 0?

[okela]

По схеме конфигурации nCONFIG подтянут к плюсу, не может ли то, к чему он у Вас подключен каким-то образом вешать его в ноль, что подтяжка к 1 не работает и на нём всегда 0?

Сигнал nCONFIG подтянут к "1" пока постоянно и никто его не дергает.

[doom13]

Сигнал nCONFIG подтянут к "1" пока постоянно и никто его не дергает.

Согласно схеме FPP он ещё и на MAX II идёт, или у Вас как-то по-другому?

[okela]

Согласно схеме FPP он ещё и на MAX II идёт, или у Вас как-то по-другому?

Нет - MAX II у меня для других целей используется, а схема загрузки в режиме FPP будет через дополнительный контроллер.

[doom13]

Нет - MAX II у меня для других целей используется, а схема загрузки в режиме FPP будет через дополнительный контроллер.

Тогда попробуйте сделать с этим контроллером то, что советовали Вам сделать с MAX II или прошивку в него какую залить, чтоб нога была входом и не могла влиять на nCONFIG.

[jks]

Надо в отладчике JTAG попробовать выдать команду
PULSE_NCONFIG = 10'b00_0000_0001
и посмотреть на реакцию nSTATUS.

Если nSTATUS не поднимается в "1", то тут вариантов несколько:
- резистор подтяжки не подключен к ноге
- нет нужного напряжения
- кто-то извне удерживает в 0
- пробит нижний транзистор I/O буффера (это можно проверить тестером).

Какой кстати чип у Вас?.



Если поможет я из Quartusa вычитывал состояние пинов таким образом.
Надо будет заменить индексы нужных Вам выводов и длину BSR регистра из BSD файла для Вашего чипа.

Сначала выполнить scan_jtag_chain для инициализации и поиска устройств.
потом sample_io для вывода состояния пинов.

CODE

set usbblaster_name ""
set test_device ""

proc scan_jtag_chain {} {
global usbblaster_name
global test_device

# List all available programming hardware, and select the USB-Blaster.
# (Note: this example assumes only one USB-Blaster is connected.)
puts "Programming Hardware:"
foreach hardware_name [get_hardware_names] {
puts $hardware_name
if { [string match "USB-Blaster*" $hardware_name] } {
set usbblaster_name $hardware_name
}
}
puts "\nSelect JTAG chain connected to $usbblaster_name.\n";

# List all devices on the chain, and select the first device on the chain.
puts "\nDevices on the JTAG chain:"
foreach device_name [get_device_names -hardware_name $usbblaster_name] {
puts $device_name
if { [string match "@1*" $device_name] } {
set test_device $device_name
}
}
puts "\nSelect device: $test_device.\n";

# Open device
open_device -hardware_name $usbblaster_name -device_name $test_device

# Retrieve device id code.
# IDCODE instruction value is 6; The ID code is 32 bits long.

# IR and DR shift should be locked together to ensure that other applications
# will not change the instruction register before the id code value is shifted
# out while the instruction register is still holding the IDCODE instruction.
device_lock -timeout 10000
device_ir_shift -ir_value 6 -no_captured_ir_value
puts "IDCODE: 0x[device_dr_shift -length 32 -value_in_hex]"
device_unlock

# Close device
close_device
}

proc pulse_nconfig { } {
global usbblaster_name
global test_device

set ir_nconfig 1 # JTAG PULSE_NCONFIG command

# Open device
open_device -hardware_name $usbblaster_name -device_name $test_device

device_lock -timeout 10000
# scan instruction
device_ir_shift -ir_value $ir_nconfig -no_captured_ir_value

device_unlock

# Close device
close_device
}

#
# read IO
proc sample_io { } {
global usbblaster_name
global test_device
set ir_sample 5 # JTAG sample command
set bsr_length 997 # BSR length

array set bsr_io {
NCE 0
NCONFIG 3
DCLK 6
NCSO 9
ASDO 12
DATA0 15
NSTATUS 939
CONF_DONE 942
MSEL0 945
MSEL1 948
MSEL2 951
MSEL3 954
}
# Open device
open_device -hardware_name $usbblaster_name -device_name $test_device

device_lock -timeout 10000
# scan instruction
device_ir_shift -ir_value $ir_sample -no_captured_ir_value

# scan data
#puts "Capture data: [device_dr_shift -length $bsr_length -value_in_hex]"
set bsr_data [ string reverse "[device_dr_shift -length $bsr_length]" ]

puts "Captured data = $bsr_data\n"

# dump MSEL data
set MSEL0 "[string index $bsr_data $bsr_io(MSEL0) ]"
set MSEL1 "[string index $bsr_data $bsr_io(MSEL1) ]"
set MSEL2 "[string index $bsr_data $bsr_io(MSEL2) ]"
set MSEL3 "[string index $bsr_data $bsr_io(MSEL3) ]"

puts "MSEL0, MSEL1, MSEL2, MSEL3 = $MSEL0:$MSEL1:$MSEL2:$MSEL3"

# dump CONFIG data
puts "nCE (D2) : [string index $bsr_data $bsr_io(NCE)]" # 0
puts "nCONFIG (H4) : [string index $bsr_data $bsr_io(NCONFIG)]" # 3
puts "DCLK (D3) : [string index $bsr_data $bsr_io(DCLK)]" # 6
puts "NCSO (J4) : [string index $bsr_data $bsr_io(NCSO)]" # 9
puts "ASDO (D1) : [string index $bsr_data $bsr_io(ASDO)]" # 12
puts "DATA0 (K4) : [string index $bsr_data $bsr_io(DATA0)]" # 15

#dump STATUS data
set nSTATUS "[string index $bsr_data $bsr_io(NSTATUS)]" # 939
puts "nSTATUS = $nSTATUS"

set CONF_DONE "[string index $bsr_data $bsr_io(CONF_DONE)]" # 942
puts "CONF_DONE = $CONF_DONE"

device_unlock

# Close device
close_device
}

[okela]

jks, спасибо за наводку. Попробую этим воспользоваться. Только пока не понял как квартусовскому (речь ведь о нем ?) отладчику JTAG скормить команду PULSE_NCONFIG = 10'b00_0000_0001. Там какбэ определенный набор команд используется и других никак не вставишь ...

[jks]

jks, спасибо за наводку. Попробую этим воспользоваться. Только пока не понял как квартусовскому (речь ведь о нем ?) отладчику JTAG скормить команду PULSE_NCONFIG = 10'b00_0000_0001. Там какбэ определенный набор команд используется и других никак не вставишь ...

Я возможно не совсем корректно выразился, но я имел ввиду Отладчик JTAG цепочки (JTAG Chain Debugger).
Там на вкладке JTAG Chain Debugging выбрать Scan Instruction Register или Shift IR в зависимости от версии Quartus-а.
В поле Clocks длина инструкции ( = 10 для устройств ALTER-ы)
В поле TDI собственно нужная инструкция JTAG в HEXе.

[okela]

Вот результат выполнения команды PULSE_NCONFIG:
Сигнал nSTATUS никак не реагирует.

Эскизы прикрепленных изображений

 

[jks]

Вот результат выполнения команды PULSE_NCONFIG:
Сигнал nSTATUS никак не реагирует.

Если в цепочке 5 устройств, то если мне не изменяет память надо сдвигать инструкцию на 50 тактов, чтобы инструкция попала в нужное устройство.
т.е. для выбора последнего устройства надо сдвинуть 0x0_0000_0000_0001,
чтобы сбросить все устройства надо сдвинуть 0x0_0000_4010_0401. (10'h000 , 10'h001, 10'h001, 10'h001, 10'h001 )

Если сдвигать только 10 тактов, то они повлияют только на первое устройство в цепочке т.е. на MAXII.

Либо исключить ненужные устройства из цепочки инструкцией BYPASS=0x3FF.
Либо сдвинуть последовательно 5 раз инструкцию 0x001 без перехода в состояние RTI.

А Вы исключить аппаратно перемычкой из цепочки остальные устройства кроме того, что не конфигурируется можете или у Вас ни одно в цепочке не конфигурируется?
И как У Вас соединены NSTATUS и CONF_DONE? У каждого своя независимая подтяжка или по цепочке?

Но чтобы не мудрить с отладчиком в Вашем случае проще будет использовать TCL скрипт.
Там конкретно можно указать с каким устройством в цепочке нужно работать.

Cкрипт запускается из модуля quartus_stp.

[okela]

Попробовал оставить в цепочки только МАХ и один Циклон. Выбрал 20 клоков и подал на вход команду 0х00001, получил на выходе цепочки 0х55555 и по-прежнему никаких изменений на выходе nSTATUS. Сигналы nSTATUS и CONF_DONE имеют общие подтяжки на все чипы, т.к. основная схема конфигурации предполагалась FPP.
Теперь вижу, что нужно было предусмотреть какие-то перемычки с индивидуальными подтяжками для этих сигналов...

[jks]

Попробуйте следующий SVF файл выполнить.
Это для цепочки из двух устройств.
Первое устройство MAX, второе Cyclone V.
На выходе TDO посмотреть состояние внутрених сигналов.

NSTATUS соответствеут ( BSC group 7: 21-23 разряд )
21 состояние входа
22 разрешение выхода (1 означает что выходной транзистор с ОС закрыт, т.е. на выходе Pull-Up)

тоже самое с CONF_DONE

ПС: возможно стоит попробовать запрограммировать все устройства последовательно, пока последнее не отпустит CONF_DONE?

CODE

!
!
FREQUENCY 1.0E+06 HZ;
!
!
!
TRST ABSENT;
ENDDR IDLE;
ENDIR IRPAUSE;
STATE IDLE;
! 1111 1111 1100 0000 0100
! BYPASS MAXII
SIR 20 TDI (FFC04);
!
RUNTEST 165 TCK;
! 1 + 1728
! BYPASS MAXII + BSD DATA C5EA9
! Only 49 bits shifted
SDR 49 TDI (000000000000);
! TDO (0000000080000) MASK (0000000080000);
RUNTEST 165 TCK;
RUNTEST 512 TCK;
! BYPASS
SIR 20 TDI (FFFFF);
RUNTEST 33000 TCK;
STATE IDLE;

CODE

--BSC group 0 for untestable Family-specific pin (nCSO R4)
"0 (BC_4, *, internal, X)," &
"1 (BC_4, *, internal, 1)," &
"2 (BC_4, *, internal, X)," &

--BSC group 1 for untestable Family-specific pin (AS_DATA3 T4)
"3 (BC_4, *, internal, X)," &
"4 (BC_4, *, internal, 1)," &
"5 (BC_4, *, internal, X)," &

--BSC group 2 for untestable Family-specific pin (AS_DATA2 AA5)
"6 (BC_4, *, internal, X)," &
"7 (BC_4, *, internal, 1)," &
"8 (BC_4, *, internal, X)," &

--BSC group 3 for untestable Family-specific pin (AS_DATA1 AB3)
"9 (BC_4, *, internal, X)," &
"10 (BC_4, *, internal, 1)," &
"11 (BC_4, *, internal, X)," &

--BSC group 4 for untestable Family-specific pin (AS_DATA0 AB4)
"12 (BC_4, *, internal, X)," &
"13 (BC_4, *, internal, 1)," &
"14 (BC_4, *, internal, X)," &

--BSC group 5 for untestable Family-specific pin (DCLK V3)
"15 (BC_4, *, internal, X)," &
"16 (BC_4, *, internal, 1)," &
"17 (BC_4, *, internal, X)," &

--BSC group 6 for untestable Family-specific pin (CONF_DONE K6)
"18 (BC_4, *, internal, X)," &
"19 (BC_4, *, internal, 1)," &
"20 (BC_4, *, internal, X)," &

--BSC group 7 for untestable Family-specific pin (nSTATUS H5)
"21 (BC_4, *, internal, X)," &
"22 (BC_4, *, internal, 1)," &
"23 (BC_4, *, internal, X)," &

--BSC group 8 for untestable Family-specific pin (nCE G5)
"24 (BC_4, *, internal, X)," &
"25 (BC_4, *, internal, 1)," &
"26 (BC_4, *, internal, X)," &

--BSC group 9 for untestable Family-specific pin (nCONFIG A4)
"27 (BC_4, *, internal, X)," &
"28 (BC_4, *, internal, 1)," &
"29 (BC_4, *, internal, X)," &

--BSC group 10 for unused pad
"30 (BC_4, *, internal, X)," &
"31 (BC_4, *, internal, 1)," &
"32 (BC_4, *, internal, X)," &

--BSC group 11 for Family-specific input pin F3
"33 (BC_4, MSEL4, input, X)," &
"34 (BC_4, *, internal, X)," &
"35 (BC_4, *, internal, X)," &

--BSC group 12 for Family-specific input pin E5
"36 (BC_4, MSEL3, input, X)," &
"37 (BC_4, *, internal, X)," &
"38 (BC_4, *, internal, X)," &

--BSC group 13 for Family-specific input pin A2
"39 (BC_4, MSEL2, input, X)," &
"40 (BC_4, *, internal, X)," &
"41 (BC_4, *, internal, X)," &

--BSC group 14 for Family-specific input pin J6
"42 (BC_4, MSEL1, input, X)," &
"43 (BC_4, *, internal, X)," &
"44 (BC_4, *, internal, X)," &

--BSC group 15 for Family-specific input pin L6
"45 (BC_4, MSEL0, input, X)," &
"46 (BC_4, *, internal, X)," &
"47 (BC_4, *, internal, X)," &