Имеем девайс на основе EP3C40F484. Интерфес программирования был слизан с девайса на основе EP3C25F324. Используются два JTAG-разъема - один для программирования EPROM, а другой - для доступа непосредственно к ПЛИС. Естественно, при слизывании номера контактов проставлены в соответствии с документацией. Отличие от хэндбука состоит лишь в том, что сигналы TMS и TDI подтянуты к VCCA через 10кОм. В старом девайсе это работало...

А вот в новом возникли проблемы - при попытке достучаться непосредственно к ПЛИС выдается сообщение (JTAG отладчиком):
При исследовании вопроса действительно цепь TDO выглядит висящей в воздухе (судя по поведению луча осциллографа - цепь в третьем состоянии и чувствительна к наводкам), хотя разъем звонится нормально до последнего доступного переходного отверстия.

При этом второй JTAG нормально пишет данные в EPROM, откуда они успешно попадают по включению питания в FPGA.

В чем может быть проблема? Не хочется верить, что все дело в величине резисторов.. Ну - или из-за плохой пайки FPGA

Какой хендбук и какой номер схемы взят за основу?

Зачем два разъема JTAG, может достаточно одного?
Есть же JTAG и Serial FlashLoader (SFL), хватает одного разъема и двух файлов *.sof и *.jic... Все описано в AN 370 «Using the Serial FlashLoader with the Quartus II Software».

Такое подключение использовалось как-то исторически.. Возможно, что оно неверно - почитаю, посмотрю.. Главное, чтобы принцип не изменился - бо документацию никто переделывать не будет для завода..

Как я понял, за основу взята схема, аналогичная представленной в Fig 10-24 (JTAG Configuration of a Single-Device Using a Download Cable) Cyclone III Device Handbook от октября 2008 (CIII5V1-2.1).
Второй JTAG (который и работает сейчас) подключен по схеме 10-7 (In-System Programming of Serial Configuration Devices) из того же хендбука.

P.S. Возможно ли, чтобы ПЛИС выдавала на свою ногу TDO неопределенность в штатном режиме? Если да - то что именно должно заставить эту ногу стать активной? Может я ищу не там - вдруг TDO не активируется из-за того, что ПЛИС не получает что-то с JTAG-разъема? Ведь до сих пор такая схема работала!..

Возможно, пайка... Иначе, еще раз перепроверить цепи и условия под рисунком ...

Использовал один разъем, как на Figure 9-30, этого достаточно.

ну - схема абсолютно идентичная.. Даже подтягивающие резисторы именно по 10кОм... Хотя в хендбуке они стоят по 1 кОм.. И - самое обидное - интерфес к SEPROM работает и плисина грузится.. Но на прямую (через основной разъем) не хочет..

Как-то надо поисследовать сигналы от ПЛИС.. Пошел звонить все ноги разъема..

ЗЫ. Как я понял - через один разъем можно программировать SEPROM нограми ПЛИС при загрузке специализированного проект.. Хитро.. Надо попробовать определенно.. Но документацию менять очень не хочется..

Возможно, не верные параметры программатора для JTAG при загрузке и программировании через USB Blaster с *.sof и *.jic...

В приложении картинки программатора от нормально работавших случаев для JTAG.

В моем случае корпус PQFP-240, но это ничего не меняет...

На форуме матом можно ругаться? Кажется нашел причину..

В общем так. Я ж сигналы на разъеме все-все проверил - но(!) кроме одного. Самого главного.. GND называется.. А наши конструктора умудрились подвести к контактным площадкам разъема землю по внутреннему слою. И нету земли на разъеме JTAG!!! А теперь оправдываются, что, типа, PCAD не ругался почему-то.. В общем - с нетерпением жду конца обеда - и в цех..


Можно еще один вопрос - по ходу но не совсем в тему. Я тут сваял цепь перезагрузки ПЛИС при обнаружении сбоя (используется внутренний контроль). В связи с отсутствием опыта в данном деле - хочу спросить 1. Какую скорость (какой делитель для 80 МГц) надо устанавливаться в проекте и на что этот самый делитель влияет (ну - кроме собственно скорости проверки).. и 2. - Как можно проиммитрировать появление сбоя в ПЛИС? Чтобы вот эта собранная схемка сработала?

Спасибо.

Все, основной вопрос снят, тема закрыта, всем огромное спасибо!