nedoPC.org

Что-то я не могу понять, в чем именно вопрос ? Ну начала эта CPLD работать, так пускай и работает, пока команда по JTAG не придет - после этого перейдет в нужный режим (программирования, отладки или еще чего)...


На всякий случай - если говорить об Altera (просто не знаю, как у других), то конфигурационная память FPGA - это RAM. Т.е. при выключении питания она пропадает. У CPLD - это уже flash (кроме последней серии - Max 10), т.е. после включения питания они сразу готовы к работе, если были ранее прошиты.

Кстати, поэтому я предпочитаю использовать аббревиатуры CPLD и FPGA вместо ПЛИС - иногда эти нюансы существенны.

В этом именно и есть вопрос: как ПЛИС распознает, что её сейчас будут программировать.

Ну и согласно таблице сигналов интефейса JTAG:

я думаю, что TMS тут ключевой сигнал. Если он не активен, ПЛИС работает, если прошита программой.
Если TMS активен, ПЛИС начинает "слушать" и выполнять команды JTAG.

Я не понимаю, почему эти вещи противопоставляются друг другу...Ведь FPGA/CPLD вполне успешно может работать, параллельно взаимодействуя по JTAG - например, для отладки. А вообще работе с JTAG и разным видам программирования посвящено ОЧЕНЬ много страниц в handbook - наверное, стоит там прочитать, если какие-то тонкости интересуют...

А кто сказал, что "эти вещи противопоставляются друг другу"?

Возможно, это Вам так показалось, но я этого не говорил.
Вопрос:
На мой взгляд, даже в двоичной логике "или" никогда не было противопоставлением...

Почитал несколько твоих постов по JTAG... я в недоумении, зачем ты придумываешь себе все эти заморочки ?? Нужно запрограммировать плисину ? - ну дык и в чем проблема-то: по JTAG-у, по PS (passive serial) или AS (active serial). Программирование по JTAG-у имеет наивысший приоритет перед PS или AS. CPLD прошивается один раз и просто работает с текущей прошивкой. FPGA надо прошивать каждый раз при включении ее питания. Как войти в режим прошивки (конфигурирования) плиса - почитай в даташите (хэндбуке) данной плисины по теме конфигурирования (может быть отдельная pdf-ка). Подробней, чем описано в хэндбуке, тебе никто ничего не скажет.

Я сам в недоумении, почему "всё это заморочки" ?? Мне просто интересно, как это действительно работает.
Ну и я вижу, что есть линия передачи данных в ПЛИС, есть линия приёма данных из ПЛИС,
тактовый сигнал задается внешним устройством, отсюда - только сигнал TMS определяет
режим работы ПЛИС.

А что, "ОЧЕНЬ много страниц в handbook" - против такого "разбора полётов"?

И я почему-то думаю, что ЧиД будет быстрее китайцев, так что паять вот это всё мне придется самому.

Поэтому я тщательно готовлюсь, чтобы не напартачить лишнего...

Ну, для надежности можно взять готовую схему (хотя там все примитивно), например http://www.pyroelectro.com/tutorials/cp ... ematic.gif

Только в данной схеме я не понимаю, почему оставили в воздухе global clear - наводки реально мешают. Если этот вывод посадить, куда надо (не помню, что какой уровень там активен), то схема полностью рабочая.

Спасибо большое - схема очень кстати!

Я еще ориентируюсь на построение Макетки для CPLD.



А вот тут Вы очень вовремя затронули этот вопрос, я как раз спросить собирался про 4 этих "глобальных пина"...
Ну я из всех мануалов понял что:



А вот когда смотришь практические схемы, то с этими сигналами - полный разнобой!
Чаще всего - кварцевый генератор 20...50 МГц вешают на GCLK1, при этом 3 остальных пина висят в воздухе.
Видел схему, где все 4 dedicated pins висят в воздухе, но её раскритиковали:

Значит, хотя бы один сигнал GCLK обязательно нужен?
Внесите ясность, по возможности, с этими dedicated pins?

Если начать с конца, то я не понимаю, как можно оставить тот же global clear в воздухе (именно совсем в воздухе, а не выведенным на разъем, как в приведенной Вами схеме отладочной платки, для последующего подключения). В свое время этот вывод чуть не свел меня с ума - оказалось, что он реагировал на наводки с руки, когда она оказывалась ближе определенного расстояния. В результате, получился не Орион, а терменвокс какой-то. Подтяжка вывода моментально решила проблему, над которой я бился несколько часов.

Насчет GCLK - в общем случае, однозначной необходимости в нем нет. Ведь никто не запрещает делать схемы асинхронными даже на CPLD/FPGA. Только, как уже было написано, это чревато. В принципе, даже в тех же Орионе/Специалисте асинхронное построение вызывало кучу проблем и шаманства на уровне куда-нибудь прицепить какой-нибудь конденсатор, авось заработает. Но там проблема слегка сглаживалась относительно низким быстродействием микросхем, что не позволяло тем же иголкам творить свои грязные дела. А вот быстродействие CPLD/FPGA, особенно современных, такое, что вся эта грязь напрочь убивает работоспособность. Из того же Ориона на CPLD пример - один из узлов сброса счетчика работал по разному после очередной перекомпиляции проекта, даже если изменения были совсем в другой части. Просто где-то слегка менялись пути прохождения сигнала, и этого было достаточно.
Сейчас же все заточено под синхронную схемотехнику - экономить аппаратные ресурсы особо не нужно, а вот получить предсказуемый вариант намного проще. Тот же Quartus прямо заточен под синхронные схемы - только так можно провести полный временной анализ проекта и заранее убедиться, что все задержки будут в пределах допустимого для данной части проекта.
При этом в качестве синхросигнала не обязательно использовать выделенный пин - в принципе, никто не мешает сделать синхронную схему, но при этом подать внешний синхросигнал на обычный GPIO. Однако выделенные пины для синхронизации имеют оптимизированный роутинг, позволяющий доставить тактовый сигнал ко всем (или к четко определенным) частям CPLD/FPGA в пределах предсказуемых задержки/смещения. Без этого, опять таки, произвести полноценный временной анализ проекта либо сложно, либо вообще невозможно.
Правда, для частот уровня Ориона, думаю, разницы особой нет, какой пин выбирать для тактовой частоты.

Это актуально, если надо заливать конфу в режиме PS или AS. Если по JTAG-у, то собрал схему и вперед программить. Или тебе надо писать софт, работающий по JTAG-протоколу с плисиной ?. Тогда другое дело. А схемы (обвязка плиса + порт подключения программатора) лучше брать из даташитов девборд, там они проверенные и "железно" работают. Наверняка есть CPLD борда от Терасик-а, воспользуйся ее даташитом .


P.S. А неиспользуемые выводы плиса, как правило, надо ставить (в настройках проекта) как "входы с Z-состоянием" и больше не заморачиваться, что с ними надо делать и куда подтягивать.

Согласен. И более того, делают ассинхронщину, чаще, чем того хотелось бы.


То же самое можно сказать про Спринтер. Там у Ивана тоже хватает ассинхронщины, из-за чего он по нескольку раз компилил проект, пока получится более/менее рабочая прошивка. С его скандаблером та же песня - как он писал, что искал причину, почему после ~двух часов работы у скандаблера сносило крышу. Теперь мне понятно "почему".

Это я усвоил сразу... Во всех "пошаговых руководствах для чайников" сразу однозначно указывают: неиспользуемые выводы в проекте обозначить как "входы с Z-состоянием"



То есть просто использовать этот внешний синхросигнал с обычного IO в качестве синхронизирующего
и во всей разрабатываемой по синхронному принципу схеме самому использовать для синхронизации именно его?

А то встречалась рекомендация (если я правильно её понял), что внешний синхросигнал с обычного
GPIO можно мультиплексором перенаправить на ту же самую линию GCLK внутри ПЛИС ?


То есть, правильно ли я понимаю мысль? --- Подача внешних 20...50МГц на вход, скажем, GCLK1
ещё не делает разрабатываемую тобой схему синхронной?

Чтобы разрабатываемая схема была синхронной - надо самому строить её так, чтобы после некоторого
асинхронного участка результаты защелкивались бы в регистры по этому самому GCLK1 или его произодным?
(к примеру - сделанному внутри ПЛИС GCLK1/2)

Я не уверен, что, например, вход global clear можно настройками проекта притянуть куда-то - скорее всего, придется использовать внешнее подключение


Можно, но зачем ? Как я уже говорил, GCLK оптимизирован для использования в качестве тактового, не вижу причин использовать для этого обычные GPIO - и времянки хуже, и универсальные ноги впустую тратятся, которых всегда не хватает...


Думаю, там о чем-то другом шла речь - потому что в таком виде это ОЧЕНЬ странная рекомендация. Не только не понятен ее смысл, но еще я не уверен, что на вход GCLK можно что-то подать изнутри самой микросхемы - как правило, весь смысл этого входа в подаче на него внешнего тактового сигнала.


Наверное, ранее я не совсем четко выразил мысль - сам по себе GCLK ВООБЩЕ никакого отношения к синхронности/асинхронности не имеет. Синхронной схему делает дизайн, а чем тактировать - дело вторичное (думаю, сами это знаете).


Ну, это уж совсем упрощенный подход, да и тактировать, как раньше сказал, не обязательно от GCLK или его производных.

А вообще настоятельно рекомендую почитать приложенный файл:

Я исходил из вот этой схемы, задавая этот вопрос:

На выходе каждого LAB есть возможность подключить D-триггер, "защелкивающий" по GCLK.
Если разрешить этот триггер и подачу на него GCLK, то в некотором смысле результат работы
узла будет синхронным, и подавит всякие иголки и прочие "неприятности", возникшие в части
комбинационной логики.



Ну я вот просто пытаюсь проанализировать Ваш же дизайн (чисто в учебных целях):

Я вижу на нём:
1. Вы поставили разъём для JTAG (ну как и положено).
2. Вы сделали из +5В пониженное питание для ПЛИС.
3. Вы прицепили внешний задающий генератор (возможно, 50МГц ? )

Но при этом сами говорили, что дизайн изначально был у Вас полностью асинхронным,
т.е. сигнал с внешнего задающего генератора был для него не нужен?

А потом - Вы ввели в свой дизайн некие элементы синхронности, или прицепить генератор
потребовали всякие добавки в проект типа внутреннего встроенного контроллера и т.п. ?

Иногда нужно следовать самому простому объяснению Генератор там на 12 или сколько там нужно Ориону МГц. Внешний - потому что внутреннего у CPLD (да и у FPGA) нет.