Просмотр полной версии : Результаты сканирования шин Вектора
После сканирования шин Вектора на разъёме "ВУ", (графики сканов в другой теме):
https://zx-pk.ru/threads/22217-combodevice.html?p=1149543&viewfull=1#post1149543
пытался вычислить реальную частоту сканирования по полученным графикам сигналов, т.к. не сканировал ни какой несущей частоты, то вычислить не получалось.
В результате, завёл на сканер дополнительно частоту 6МГц, и по меандру подтвердились предполагаемые частоты сканирования 100МГц и 25МГц.
Сейчас немного размышлений о том, почему не получалось вычислить частоты по сигналам...
Я начал с предположения, что по длительности (количеству пикселей) между импульсами сигнала "Строб сост." (43 на ВУ) смогу измерить на графике длительности выполнения команд и по ним вычислить частоту...
Исходя из информации, что на Векторе длительность выполнения команд в тактах округляется до ближайшего значения кратного 4, ожидал, что команды PUSH, POP и JMP будут иметь на графике одинаковую длительность (в пикселях), т.к. PUSH и POP по справочнику выполняются 11 тактов, а JMP - 10 тактов, округляем до 12 тактов...
Но если POP и JMP длятся примерно 400 пикселей (на графике), то PUSH длится около 533 !!! и это даже не погрешность.
Далее, команды SHLD и LHLD по справочнику 16 тактов, на графике 668 пикселей.
Считаем для POP и JMP: 400(пикселей на графике) / 12(тактов по справочнику) = 33,33 пикселя/такт.
Для PUSH считаем в обратную сторону: 533(пикселя) / 33,33 = 16 тактов !!! а в справочнике 12 !!!
Для SHLD и LHLD: 668(пикселей) / 33,33 = 20 тактов !!! а в справочнике 16 !!!
Я в ауте... или у меня справочник кривой с ошибками и очепятками ?
Округляется вверх до кратности 4 тактам не вся команда, а каждый ее цикл с доступом к памяти. Классическая справка по растактовкам для вектора в Вектор-User 15 (но там есть ошибки). svofski выкладывал у себя (все время забываю - где) исправленную таблицу. Есть такая таблица (http://emuverse.ru/wiki/%D0%92%D0%B5%D0%BA%D1%82%D0%BE%D1%80-06%D0%A6/Instruction_Timings) (надо проверить, исправленная или нет). Или такая (https://www.sensi.org/~retrocomp/vector06c/v06cycl.html), где расписано по циклам.
Округляется вверх до кратности 4 тактам не вся команда, а каждый ее цикл с доступом к памяти. ...
Вот так и бывает, когда не сталкиваешься с реальной необходимостью экономить и считать каждый такт программы :)
Где-то в закоулках памяти конечно таилось, что округляются именно циклы с доступом к памяти, но игнорировалось при подсчетах... Всегда было достаточно приблизительных значений с округлением всей команды.
Отклоняясь от темы.
Снова сталкиваюсь с глюками. При минимальном изменении кода модуля для Альтеры, перестаёт корректно работать сканер. В данном случае ровно через один такт все 24 бита (или только 8 бит) имеют значение "0". Пока не выяснил сбрасываются они до записи в М9К, или коряво читаются, или ошибка появляется при передаче в комп.
Главное смущает, что к глюкам приводят изменения кода, которые вообще ни как не связаны с функциями сканера, процессами сканирования, чтения и передачи.
Главное, что с подобным уже сталкивался. Заподозрил, что глючит Альтера, купил новую плату, залил "глючный" код в новую плату, и на ней все глюки сразу пропали. Сейчас и эта плата похоже начала выёживаться... :(
При сравнительно высоких частотах проект может начать вести себя странно, начиная реагировать на изменения в казалось бы совершенно левых вещах. По хорошему надо пользоваться TimeQuestом.
HardWareMan
15.03.2022, 06:58
Главное смущает, что к глюкам приводят изменения кода, которые вообще ни как не связаны с функциями сканера, процессами сканирования, чтения и передачи.
Следует подучить теорию по ПЛИС. В отличии от программы, где не изменённый код в исходниках не поменяется и в бинаре, синтезатор xHDL пересоберёт всё, на это наложится оптимизация и полирнётся фиттером. Т.е., результат будет полностью новым артефактом без единого куска от старого. Чтобы на это повлиять, можно задать, какому модулю в каком регионе ПЛИС находится и это может положительно повлиять как на характеристики модуля, так и на стабильность сборки. Так что правильно вам советуют: смотрите в TimeQuest, забивайте туда свои требования и выучите уже настоящий синхронный дизайн.
На плату сопряжения допаял микросхем, расширил шину сканера до 36-ти бит.
Сейчас сканируется почти вся шина разъёма "ВУ". Не стал сканировать только один сигнал - "сбр.системы", т.к. это шина клавиши "СБР", и управлять сбросом Вектора со своего устройства я пока не собираюсь, а сброс Вектора можно отследить по сигналу "сброс" сформированному самим Вектором.
Девайс постепенно превращается из просто сканера, в борду для экспериментов с навесным оборудованием :)
Отсканил состояние сразу после перезапуска 02-го Вектора...
Как грустно, что шина данных "глушится" (FFh) на время активности сигнала "ЧТЗУ".
И пока нет активного "БЛК", на внешней шине не увидеть CAS. Хотя некоторые вроде-бы и без него пытались обойтись. ;)
Не знаю в какую тему лучше кинуть, в эту или в тему про подключение внешнего ПЗУ к шине разъёма "ВУ".
Но пока ситуация больше касается шины чем непосредственно ПЗУ на этой шине.
Итак, на основе сканера шины, начал тестировать схему подключения внешнего ПЗУ к разъёму "ВУ".
Ни чего особенно сложного, схема простая.
Механизм активации ПЗУ решил сделать следующим:
1. "тумблером" разрешаем работу схемы внешнего ПЗУ.
2. на Векторе жмём ВВОД + БЛК - схема внешнего ПЗУ "сбрасывается" в режим ожидания, работает штатное ПЗУ с загрузчиком.
3. на Векторе жмём БЛК + СБР - Вектор отключает своё ПЗУ, активируется внешнее ПЗУ - выполняется программа с внешнего ПЗУ.
4. на Векторе жмём БЛК + СБР - внешнее ПЗУ отключается и деактивируется до следующего ВВОД + БЛК, выполняется программа из памяти Вектора.
Так подробно написал алгоритм работы внешнего ПЗУ, для того, чтобы было понятно, что работа схемы зависит от сигнала "сброс" приходящего с Вектора.
Так вот... целый вечер бился, не мог понять, почему внешняя ПЗУ сначала начинает работать, а потом отключается, всегда в одном и том-же месте (с точностью до семпла), когда адрес программы добирается до 0005h.
Но так и не понял.
Анализ показал, что ПЗУ отключается именно сигналом "сброс". Но сканер, при частоте семплирования 100МГц, так ни разу и не зафиксировал импульса в этот момент на сигнале "сброс".
Каюсь конечно, что на сканер все сигналы с шин "ВУ" приходят через цепочку регистров, а вот на "модуль" ПЗУ завёл сразу со входа основного модуля проекта.
Вылечилось конечно регистрами. Когда прокинул сигналы на "модуль" ПЗУ через цепочку регистров, то "внешнее ПЗУ" сразу заработало.
Меня вот мучают жуткие сомнения, не могу понять, что за "шум" был на сигнале "сброс", которого не видел сканер... приходил он с Вектора, с платы конвертора 5В->3.3В, или это Альтера "шумела".
Я читал про метастабильность (если правильно термин помню), что может быть не определённое состояние регистра при фиксации в нём значения.
Просто схема использования сигнала "сброс" не предусматривает явной фиксации его значения в регистре, если только Альтера чего-то не вставляет, чего её не просили.
Да и я понял бы "метастабильность" этого сигнала в момент перехода его значения из 1 в 0 или из 0 в 1 - т.е. во время собственно Сброса Вектора.
А тут, так сказать "на ровном месте", когда сбросом и не пахнет, при гипотетически стабильном состоянии сигнала...
Альтера подбрасывает очередной сюрприз...
PS. а с работой внешнего ПЗУ, не долго радовался... когда увидел, что внешнее ПЗУ работает, подключил параллельно свой "бутерброд" из КД+HDD... и внешнее ПЗУ перестало работать... :( отключил "бутерброд", а ПЗУ так и не работает...
Что там в таких случаях говорят: "- как же так, ни чего ведь не делал, просто в сторонке стоял...".
Буду дальше разбираться, о результатах уже в соответствующей теме.
Тут было про странный невидимый сканером "шум" на шине.
svofski писал, что в лешадоке делал антидребезговую обработку для части (или для всех?) сигналов. Подробности лучше он сам расскажет.
svofski писал, что в лешадоке делал антидребезговую обработку для части (или для всех?) сигналов. Подробности лучше он сам расскажет.
Лешадок я когда-то изучал, возможно брожу по тем-же граблям.
Так подробно написал алгоритм работы внешнего ПЗУ, для того, чтобы было понятно, что работа схемы зависит от сигнала "сброс" приходящего с Вектора.
А зря. Всё твое сообщение можно свести к фразе "у меня ничего не работает, почему -- не знаю". Вместо расписывания нужно было выложить исходники проекта. Без них ничего сказать нельзя.
Альтера подбрасывает очередной сюрприз...
Альтера 100% тут не виновата. Ищи ошибки в проекте.
PS: Как легко понять, мифический "шум" тут ни при чём. Цифровая схема либо работает, либо нет. Если не работает, то она либо неправильно спроектирована, либо неправильно собрана, либо в ней есть негодные компоненты. Вариантов немного.
А зря. Всё твое сообщение можно свести к фразе "у меня ничего не работает, почему -- не знаю".
Именно так... Самую суть узрел...
Цель проекта на Альтере, изучить потенциальную возможность реализовать "в железе" идею подключения внешней ПЗУ к разъёму ВУ, используя минимальное количество простых цифровых микросхем логики, используя минимум регистров.
Именно по этой причине, экспериментирую исключительно с wire и assign. Так как есть у меня предположение, что любое использование конструкций типа "if" - приведёт к использованию компараторов, а конструкции типа reg и always - будут добавлять в схему дополнительные корпуса регистров.
Альтера 100% тут не виновата. Ищи ошибки в проекте.
...
Конечно железо не может быть виновато (если оно исправно).
Не может ошибаться тот кто слепо выполняет инструкции, даже если в результате выдаёт результат, не тот которого ждали. Ошибся тот кто написал инструкции.
KTSerg, повторюсь, ситуация с нечетким срабатыванием похожа на то, с чем сталкивался svofski в шадке. Можно попробовать полечить примерно аналогичным антидребезгом для сигналов с ВУ - детект первого изменения + некоторая задержка.
KTSerg, повторюсь, ситуация с нечетким срабатыванием похожа на то, с чем сталкивался svofski в шадке. Можно попробовать полечить примерно аналогичным антидребезгом для сигналов с ВУ - детект первого изменения + некоторая задержка.
Пытаюсь. Но попытка перейти (для эксперимента) на предварительную запись всех входных сигналов в регистры, а потом на синхронизацию всех процессов через always, приводили к запаздыванию формирования БЛК и хаотичному сбою записи в ОЗУ Вектора. Это проявлялось в рваной загрузочной сетке, отображаемой кусками. А на сканах видно, что отключение БЛК запаздывает, и успевает начаться CAS, а потом он обрывается запаздавшим отключением БЛК.
Так-что изучаю.
Скорее всего нужно частоту синхронизации процессов в разы увеличивать...
Скорее всего нужно частоту синхронизации процессов в разы увеличивать
В шадке 96 МГц, если не путаю
В шадке 96 МГц, если не путаю
Тут всё от оптимальности схемы зависит.
У меня и при 100МГц не поспевало :)
Спад CAS-а на 40-50нс опережал появление фронта отключения БЛК.
А БЛК отключается по результату анализа слова состояния процессора, т.е. во время строба состояния.
Но оптимизацией я и не занимался, накидал в кучу, поправил имена шин/регистров и в путь...
Спад CAS-а на 40-50нс опережал появление фронта отключения БЛК.
А БЛК отключается по результату анализа слова состояния процессора, т.е. во время строба состояния.
Такт проца со словом состояния предшествует тактам обращения к памяти и для меня странно, как может возникнуть описанная ситуация. Разве что обработка слова состояния очень-очень-очень долгая (по меркам ПЛИС на частоте 100 МГц).
- - - Добавлено - - -
Хотя я припоминаю, что svofski пришел к тому, что все было впритык, но это, как понимаю, с учетом антидребезговых задержек.
Цель проекта на Альтере, изучить потенциальную возможность реализовать "в железе" идею подключения внешней ПЗУ к разъёму ВУ, используя минимальное количество простых цифровых микросхем логики, используя минимум регистров.
Это понятно. Но, если ты не понимаешь, как кормпилируется верилог, то хотя бы код выложи, чтобы тебе показали основные проблемы. Иначе абсолютно непонятно, что сделано не так.
Именно по этой причине, экспериментирую исключительно с wire и assign. Так как есть у меня предположение, что любое использование конструкций типа "if" - приведёт к использованию компараторов, а конструкции типа reg и always - будут добавлять в схему дополнительные корпуса регистров.
Это неверно. В обе стороны. Даже в три, поскольку wire и reg -- вообще объявления проводов, а не логические конструкции. Триггер на assign делается, но так писать не принято. Хотя у новичков получаются паразитные триггеры в assign, бывает такое. If без компаратора -- без проблем. always без триггера -- пожалуйста.
Так что -- код в студию.
Конечно железо не может быть виновато (если оно исправно).
Не может ошибаться тот кто слепо выполняет инструкции, даже если в результате выдаёт результат, не тот которого ждали. Ошибся тот кто написал инструкции.
Код -- это и есть инструкции. Компилятору. Выкладывай код.
Если хочешь, чтобы тебе помогли -- выкладывай код, а не ной, что ничего не работает.
... поскольку wire и reg -- вообще объявления проводов,
...
Так что -- код в студию.
...
А какой смысл выкладывать код, если оказывается, что reg - это объявление провода, а не переменной (регистра) как я раньше думал.
После получения такой важной инфы, мне сначала нужно переосмыслить всю концепцию проекта...
Снова начну гуглить...
If без компаратора -- без проблем. always без триггера -- пожалуйста.
Мне известен и понятен факт, что одинаковый результат можно получить разными средствами/инструментами, и пользуясь одним инструментом можно получать разные результаты.
Был в моей жизни опыт сдачи контрольных работ по Прологу и Лиспу.
Препод дал задание, по его словам задача решалась вложенными циклами (инструментом данного языка программирования) программой в четыре строки.
Видя, что я не понимаю концепции, мне были даны готовые три строки, осталось дописать одну строку программы...
Я так и не понял кода программы, и написал свой код на три десятка строк, без вложенных циклов... Так как мой код выдавал правильный результат, то зачет я получил, хотя и не проникся прелестью инструментария этих языков.
Замечу, что данной историей я не горжусь. На месте препода, я бы в такой ситуации зачёт не поставил, так как контрольная была по программированию на Лиспе/Прологе (не помню уже точно которому из них), а не на линейном языке.
А какой смысл выкладывать код, если оказывается, что reg - это объявление провода, а не переменной (регистра) как я раньше думал.
Память, то есть все регистры, работает по клоку. Клок в ПЛИС принято делать синхронным, один общий клок на весь проект. Никакие делители клоков как в традиционных схемах на 155ла3 недопустимы. Переходы между разными клоками возможны, но это боль. Лучше оставить это крутым профессионалам. Если есть входящие сигналы типа как у Вектора, мы их фактически семплируем. Отсюда всякий антидребезг.
Что до регистров и проводов, то все просто на самом деле.
Если есть описание процесса на клоке (always @(posedge или negedge)), присваивания внутри этого процесса происходят по тактирующему сигналу, или асинхронному сбросу. Левая часть оператора присваивания синтезируется в настоящий железный регистр, а на вход CLK и nRESET ему подводятся сигналы из списка чувствительности оператора always.
Если сигнал объявлен как reg, но нету ни одного процесса, который бы его заклочил, получается, что и смысла превращать его в регистр нет. Правда, как упомянул Sandro, можно сделать защелку. Можно использовать always без клока для присваивания reg значения. Обычно в этом нет смысла, кроме может быть каких-то синтактических выкрутасов для совместимости.
Есть еще интересный момент, который лично мне помог с интуицией. Все, что находится в правой части присваивания в блоках always @(posedge/negedge), суть комбинаторика. То, что большие и сложные многоэтажные выражения можно писать прямо внутри блока always, это для удобства. А так их можно смело описывать как wire и размещать снаружи.
Во что именно синтезируются различные языковые конструкции - не так важно. Корни всего этого уходят в то, что изначально язык был предназначен не для описания синтезируемой логики, а для симуляции обычных схем. Чтобы не вляпыватся в ложных друзей лучше обходиться минимумом. Например, for не делает ничего напоминающего циклы в языках программирования.
P.S. Когда я разбирался с ПЛИС много лет назад, мне не попалось нигде простого и четкого объяснения того, что же мы собственно делаем. Были хорошие ресурсы с примерами, но не то я невнимательно читал, не то там тоже этому не уделялось достаточно внимания, но все время складывалось такое ощущение, что мы как будто пишем обычную программу, только вот как-то не совсем, потом какой-то пыщ-пыщ и все мигает. Это не совсем отягощалось мутной терминологией типа "верилог исполняет этот оператор" -- очевидно, авторы таких текстов либо где-то в академически-симуляционных облаках, либо просто нихрена не понимают (не хочу никого обидеть -- очень может быть, что на самом деле понимают, но не понимают, что их читатели не понимают). Путаница с тем, что в вызывающей доверие литературе Верилог очень часто вообще не упоминается в контексте синтеза, нисколечко не помогала. Интересно, что большое количество людей умудряются пользоваться ПЛИС явно не осознавая нескольких простых вещей. Я сам умудрился сделать свой первый Понг на ощупь, совершенно не врубаясь в то, как это работает. Продравшись же через завесу липкой мути, оказалось, что по крайней мере в рамках вполне достаточных для хобби все просто и магии даже как то почти и нет.
(На месте препода я бы тоже поставил зачет, потому что у него таких как ты было человек 30 небось)
... Если есть входящие сигналы типа как у Вектора, мы их фактически семплируем. Отсюда всякий антидребезг.
...
Сейчас вопрос появился...
А этот дребезг на сигнале какое значение имеет: "0", "1", "х" или "z" ?
Если какой-то из двух последних, может в верилоге есть инструмент для их вылавливания на сигналах, где они не предусмотрены и замены их в потоке на значение из предыдущего семпла...
А про определение reg... мне проще понять замечание, что не каждое объявление reg приводит к появлению регистра (т.к. можно что-то объявить, но использовать не стандартно, видимо это относится и к reg), чем высказывание, что wire и reg - объявление провода, т.к. последнее (с моей точки зрения) противоречит всем докам, что я прочитал про эту шнягу.
А этот дребезг на сигнале какое значение имеет: "0", "1", "х" или "z" ?
Отличие дребезга от метастабильности в том, что дребезг -- это то 0 то 1 -- как на выходе металлических контактов, или при гонках в комбинаторной логике. А метастабильность -- это переходный процесс, когда мы на входе имеем не то 0, не то 1 и не можем решить. С чем именно мы тут имеем дело я не знаю, это легко может быть и то и другое сразу, но лучше считать, что это метастабильность. Значений x или z не существует в реальном железе. x может использоваться для обозначения неопределенности в симуляции. Все реальные сигналы 0, или 1. Для этой проблемы есть классическое решение -- добавление ТШ. Но если ТШ нет, то можно попробовать выкрутиться поджидая, пока сигнал не устаканится. То есть пока несколько чтений подряд не дадут одно значение.
В обычном коде reg используется для регистров, а wire для комбинаторики. По клоку в reg записывается wire, или другой reg. Если придерживаться простых правил, то так всегда и будет. В Верилоге есть прорва оговорок и всяких не всегда, в них можно надолго погрязнуть и ничего полезного из этого не вынести. Этот язык правда древний, с ятями и твердыми знаками и самое смешное, что придуманный совсем не для того.
А метастабильность -- это
Пример.
Для TTL логики то, что меньше (могу ошибится в числах, но не в этом суть) 0,4 вольт - это 0, а то, что больше 2.4 в - это 1. А вот всё то, что больше 0.4 и меньше 2.4 - это она самая, родимая.
То есть если такой сигнал подать на вход логического элемента, скажем, НЕ - то на выходе может быть больше 2.4 В, а может быть меньше 0.4 В, а может плясать - то больше 2.4, то меньше 0,4. Всё зависит от входного значения и характеристик транзисторов внутри ЛЭ.
... Значений x или z не существует в реальном железе. ... Все реальные сигналы 0, или 1. ...
Но мы пока говорим о проекте на Альтере, и у меня срабатывает RS-триггер, на вход "С" которого заведён злополучный СБРОС.
И я всё больше склоняюсь к мнению, что параллельно подключенный сканер не видит ни чего из-за того, что сканер мне показывает чисто двоичное состояние сигнала, а там ловлю метастабильность "х".
Вот буквально на этой неделе штудировал (выдержки) :
Verilog обрабатывает всего четыре значения переменной:
1) “1” - логическая единица
2) “0” - логический ноль
3) “z” - состояние высокого импеданса
4) “x” - неизвестное логическое состояние
Далее:
Если хотя бы один операнд равен х, то и результат всего выражения х.
Далее:
- переходы posedge: 0->1, 0->x, 0->z, x->1, z->1
- переходы negedge: 1->0, 1->x, 1->z, x->0, z->0
Значит, если представить себе ситуацию, что я ловлю на шине 0->х а потом обратно х->0 , то сканер ни чего мне не покажет, а RS-триггер честно отработает так как получит на управляющий вход последовательность posedge, negedge.
Нужно детектор х-остояния придумать со счетчиком события, и смотреть, будут-ли сработки...
Хотя скорее всего я ошибаюсь, и метастабильность тут ни при чём, и вообще выглядит она совсем по другому.
Внутри возможны только 0 и 1, снаружи 0, 1 и z (только на выходном пине). x, по сути - когда нам наплевать на состоянии сигнала.
RS-триггер можно симулировать защелкой, но не надо так делать. В физической Альтере нет RS-триггеров. Есть блоки в которых реализуется небольшая табличка истинности + D-триггер с асинхронным сбросом (на самом деле конечно сложнее, но это вполне по-моему убедительная модель). Вся комбинаторика синтезируется через таблицы, результаты фиксируются в регистрах по клоку.
В дополнение к тому, что сказал Hunta - x бывает используется как состояние при сравнении и в case, тогда x -- это "наплевать". Но это не то же самое, что состояние x в симуляции. В симуляции x -- это заразная неопределенность, эквивалент NaN в плавающей точке. Фраза "Если хотя бы один операнд равен х, то и результат всего выражения х" имеет смысл только в симуляции. Так же как 155ла3 не может иметь состояние "х", так не могут иметь состояние "х" и сигналы в Альтере.
Пример семплера (со скидкой на то, что я не вериложил годы и не проверял)
reg [1:0] sample;
always @(posedge clk) // все записи внутри этого блока происходят залпом параллельно по фронту clk
begin
sample[0] <= sample[1]; // переписали последний семпл в первый
sample[1] <= metastable_input; // сохранили текущее состояние в последний
end
wire stable_input <= sample[0] & sample[1]; // этот сигнал будет 1 когда два clk подряд на metastable_input будет 1
RS-триггер можно симулировать защелкой, но не надо так делать. В физической Альтере нет RS-триггеров. Есть блоки в которых реализуется небольшая табличка истинности + D-триггер с асинхронным сбросом (на самом деле конечно сложнее, но это вполне по-моему убедительная модель). Вся комбинаторика синтезируется через таблицы, результаты фиксируются в регистрах по клоку.
В дополнение к тому, что сказал Hunta - x бывает используется как состояние при сравнении и в case, тогда x -- это "наплевать". Но это не то же самое, что состояние x в симуляции. В симуляции x -- это заразная неопределенность, эквивалент NaN в плавающей точке. Фраза "Если хотя бы один операнд равен х, то и результат всего выражения х" имеет смысл только в симуляции. Так же как 155ла3 не может иметь состояние "х", так не могут иметь состояние "х" и сигналы в Альтере.
...
То, что Альтера всё делает на ячейках/таблицах - я давно понял. Соответственно, я понимаю, что в Альтере нет физически (принимающих участие в генерации схемы) ни каких логических элементов или регистров, триггеров, и прочего в классическом понимании как в обычных микросхемах. Вся логика на ячейках памяти и таблицах истинности. Может только в интерфейсной части, но нас это на данный момент не интересует. Это всё мне понятно.
RS-триггер, уменя в принципе и есть D-триггер со сбросом, взят из примеров.
С "х" понятно... отловить метастабильность используя "х" не получится, а жаль, такая идея пропала ;)
Вообще идея и логика ПЛИС мне стала понятна практически сразу.
Она мне напомнила электронный конструктор, который был у меня в детстве. Он состоял из маленьких пластиковых кубиков, на которых сверху был нарисован элемент (резюк, кондёр, транзистор, ...), а по бокам контакты.
Собираешь эти кубика в коробке, получаешь схему.
Идея такая-же как и в верилоге/ПЛИС.
Есть "модули" у них есть входные/выходные параметры - боковые контакты кубиков, заполнил модули функциями, накидал модули, проследил, чтобы "контакты" совпадали - и получил "схему".
И по идее, что там в ПЛИСе негенерировалось внутри кубиков (модулей) - до лампочки, главное, что-бы "функция" правильно была написано. Такие себе "чёрные ящики" - не имеющие отношения к реальным микросхемам, т.к. вся логика функций генерируется на таблицах истинности в ячейках памяти.
Как-то так... с моей точки зрения.
Может это и не очень правильное сравнение, но у меня именно такие ассоциации.
Если вернуться к сканированию.
Не видел технического описания Альтеры на русском языке, на буржуйском могу только общий смысл и то со словарём :(
Мне интересно, есть ли у М9К ресурс циклов чтения/записи ?
Уперся на сканере в ситуацию, что нужно ловить "момент сбоя", и видеть, что ему предшествовало, а он (момент) может наступить когда угодно.
Соответственно, нужно делать как в обычных логгерах - начинать сканировать заранее, и закольцевать буфер записи, в момент наступления события - разрывать кольцо, и будем иметь семплы предшествующие интересующему событию - увидим ситуацию приведшую к сбою.
Но боюсь, что постоянная запись в М9К, в ожидании события, может сожрать ресурс циклов чтения/записи.
М9К - т.к. на борде нет внешней SRAM/SDRAM.
Так-что вопрос о наличии ресурса М9К, для меня - актуален.
M9K - это SRAM
Т.е. за ресурс циклов записи можно особо не беспокоиться?
За ресурс отдельно M9K я бы не беспокоился. Если поискать в даташитах, то возможно где-то есть официальная гарантированная длительность работы Циклона (десятки лет?).
В обычном Циклоне любого поколения по-моему нету вообще ничего энергонезависимого и ресурсоограниченного. В них все ячейки одного типа, просто в BRAM они организованы чтобы делать быструю память. И кстати иногда синтезатор задействует BRAM для совершенно небрамного вида исходников.
Ограничение ресурса было в серии MaxII или как их там, которые ни рыба ни мясо — внутри больше похоже на FPGA, но при этом со встроенным загрузчиком. Маленькое но, которое не писали крупными буквами на рекламных проспектах: ресурс был на 100 (сто) перезаписей.
Про кубики:
Электронные кубики это советский клон Gakken EX-System. У меня тоже такие были. Схемы из инструкции были интересные и работали хорошо и я его очень любил. Но в схемах при этом понимал мало, а сделать свою схему по книжке или еще откуда-нибудь в такой системе не сильно проще, чем вручную компилировать верилог в таблицы истинности и распихать по ячейкам в битстрим. Так что сравнение уместно. Хорошая идея для продвинутого хобби проекта — собрать верилог в кубики.
Еще у меня был конструктор с пружинками, где кроме всего прочего были светодиод и фоторезистор. В качестве жестокой издевки предлагалось собрать "светотир", в котором пестик был бы с дохлой лампочкой от фонарика и непонятно из чего собранным коллиматором. Как же я обламывался. Все выпавшие из бабушкиных очков линзы были не той системы.
Сейчас многие страдают мол вот было дааа, нонче то эх.. Но современная бредборда все равно лучше.
Пример семплера (со скидкой на то, что я не вериложил годы и не проверял)
Не надо так делать. Наличие элемента "И" порождает комбинаторный путь для потенциально метастабильного сигнала. Правильно так:
reg [1:0] sample;
wire stable_input;
...
always @(posedge clk)
begin
sample <= {sample[0], metastable_input};
end
assign stable_input = sample[1]; // пустышка чисто для наглядного оформления исходника; можно сразу использовать sample[1]
Sandro, так вроде просто задержка получается?
Sandro, так вроде просто задержка получается?
А мне кажется, при логическом "И" - будет задержка переднего фронта, а спад - без задержки.
Если сделать логическое "ИЛИ" - будет передний фронт вовремя, а спад с задержкой.
Мне так кажется...
С логическим "И" - для RAS/CAS подойдёт, т.к. актуален спад, а вот для "ЧТЗУ" задержка фронта может быть чревата последствиями, для него "ИЛИ" - безопаснее, т.к. фронт важен.
Хотя могу и ошибаться.
Вообще пока не могу понять как логическая операция может стать источником метастабильности...
Или имеется в виду, что метастабильный параметр в выражении, может "без мыла" дальше пролезть...
HardWareMan
10.04.2022, 21:29
Не надо так делать. Наличие элемента "И" порождает комбинаторный путь для потенциально метастабильного сигнала.
Если этот сигнал не является сигналом чувствительности другого always блока а используется внутри того же, то пофигу, это раз. Второе, лучше указывать полный вектор явно, чтобы потом не ловить граблей из-за обратного порядка или других проблем. Правильно писать вот так: sample[1:0] <= {sample[0], metastable_input}; Заодно синтезатор будет ругаться, если вдруг где-то ошибёшься с размерностью.
Sandro, так вроде просто задержка получается?
Не только. Это стандартная схема перевода сигнала из одного в другой тактовый домен. Так надо делать не только со внешними сигналами, но и со внутренними, которые идут между блоками с разным тактированием. А ещё, такая схема позволяет отлавливать перепад любой полярности, складывая по И оба регистра ((sample[1] & ~sample[0]) | (~sample[1] & sample[0])).
Вообще пока не могу понять как логическая операция может стать источником метастабильности...
Или имеется в виду, что метастабильный параметр в выражении, может "без мыла" дальше пролезть...
Чтобы это понять, нужно почитать буквари на ПЛИС. И осознать тот факт, что фиттер будет располагать элементы там, где ему вздумается (кроме случаев ручного раскроя - да, ПЛИСоводы 80 уровня и в такое умеют). А значит, пути прохождения сигналов по интерконнекту могут настолько отличаться, что задержка распространения одного сигнала относительно другого породит иголку. Когда всякие новички пишут без познания дзена по строго синхронному дизайну а потом жалуются, что их проект работал, а после добавления ещё одного кусочка перестал работать или стал сбоить, но после добавления ещё одного опять стал вроде как работать - это оно и есть. И так делать не надо.
Вообще пока не могу понять как логическая операция может стать источником метастабильности...
Или имеется в виду, что метастабильный параметр в выражении, может "без мыла" дальше пролезть...
В моем варианте логическая операция между двумя регистрами. Метастабильный сигнал переписывается в регистр по клоку. Чем опасна операция "И" между двумя регистрами без дополнительных комментариев пока не понятно.
- - - Добавлено - - -
Не только. Это стандартная схема перевода сигнала из одного в другой тактовый домен. Так надо делать не только со внешними сигналами, но и со внутренними, которые идут между блоками с разным тактированием. А ещё, такая схема позволяет отлавливать перепад любой полярности, складывая по И оба регистра ((sample[1] & ~sample[0]) | (~sample[1] & sample[0])).
Для перехода в другой клоковый домен понимаю, FIFO это хорошо. Для устранения метастабильного дребезга по-моему этого не будет достаточно.
(про запись сдвига в одну строку итд поддерживаю)
HardWareMan
11.04.2022, 06:59
Для устранения метастабильного дребезга по-моему этого не будет достаточно.
Выходной сигнал всегда можно синхронизировать, поставив ещё один регистр с тем же тактовым списком как у источников сигнала. Просто результат будет запаздывать ещё на 1 такт. И самое главное: всегда консультируйтесь с RTL, чтобы понять как именно понял вас синтезатор. Это самый мощный инструмент отладки и корректировки ошибок и/или узких мест. Ну и по традиции пример выше:
module test(
input Clk,
input InputStream,
output reg PosEdge,
output reg AnyEdge,
output reg NegEdge,
output reg FilteredOut
);
reg [1:0]FIFO;
always @(posedge Clk) begin
FIFO[1:0] <= {FIFO[0],InputStream};
PosEdge <= ~FIFO[1] & FIFO[0];
NegEdge <= FIFO[1] & ~FIFO[0];
AnyEdge <= ((~FIFO[1] & FIFO[0]) | (FIFO[1] & ~FIFO[0]));
FilteredOut <= FIFO[1] & FIFO[0];
end
endmodule
Схема:
https://i.ibb.co/nM3x7j7/image.png
Результат:
https://i.ibb.co/bXgQjL8/image.png (https://ibb.co/zZhQWb0)
Если этот сигнал не является сигналом чувствительности другого always блока а используется внутри того же, то пофигу, это раз.
Нихрена не пофигу. Метастабильность прекрасно распространяется сквозь комбинаторную логику. Особенно,через КМОП, поскольку она (почти) симметрична.
Мне как-то реально пришлось разгребать последствия такого вот заблуждения, когда разработчик не защитил от метастабильности вход UART, "поскольку метастабильность бывает только из-за медленно меняющихся сигналов, а у меня там триггер Шмитта!" Цитата дословная, запомнил ниазусть. Разумеется, это чушь, а ошибка вылазила совсем в другом месте, на шин процессора сыпался мусор. Метастабильность просачивалась через автомат состояния предатчика в автомат управления шиной, и привет.
Поэтому -- два триггера последовательно, стабильное значение брать с выхода второго. Выход первого нестабилен. Был бы он стабилен -- второй триггер был бы не нужен.
...
Ну и по традиции пример выше:
...
AnyEdge <= ((~FIFO[1] & FIFO[0]) | (FIFO[1] & ~FIFO[0]));
...
Сразу приношу извинения за глупый вопрос, возможно я ещё не проснулся, и не понимаю смысла этой конструкции...
Но разве процитированную функцию нельзя записать вот так:
AnyEdge <= (FIFO[1] ^ FIFO[0]);
Или просто схема сгенерируется более сложная?
В моем варианте логическая операция между двумя регистрами. Метастабильный сигнал переписывается в регистр по клоку.
Нет там логической операции, это иллюзия. Логические операции можно проводить только над логическими значениями. 0 и 1. Метастабильное сосотояние -- по определению переходное между ними. Ничего там не записывается, и никаких логических операций там не происходит. Там имеется неопределенноё поведение схемы, потенциально -- заразное. То есть, оно может от источника неопределённости распространяться очень далеко по схеме.
Чем опасна операция "И" между двумя регистрами без дополнительных комментариев пока не понятно.
Пока триггер находится в метастабильном состоянии, на его выходе нет логических значений. Вообще нет.
Операция "И" в этом случае невозможна. Реально у тебя логический элемент будет находиться в линейном режиме, то есть, работать, как аналоговый усилитель. И выдавать аналоговый сигнал, содержащий всё, что угодно. Включая сводку электрических помех на плате.
Для устранения метастабильного дребезга по-моему этого не будет достаточно.
Метастабильность -- это не дребезг. Это длительно устойчивое (откуда и название) состояние триггера между 0 и 1.
- - - Добавлено - - -
Сразу приношу извинения за глупый вопрос, возможно я ещё не проснулся, и не понимаю смысла этой конструкции...
Но разве процитированную функцию нельзя записать вот так:
Можно. Это то же самое. И скобки тогда ни к чему.
...
Метастабильное сосотояние -- по определению переходное между ними. Ничего там не записывается, и никаких логических операций там не происходит. Там имеется неопределенноё поведение схемы, потенциально -- заразное. То есть, оно может от источника неопределённости распространяться очень далеко по схеме.
...
Значит цитата из статьи, которую я ранее приводил:
Если хотя бы один операнд равен х, то и результат всего выражения х.
Так-же справедлива и для метастабильности, но при этом "х"- не является метастабильностью по определению?
Т.е. нет возможности детектировать метастабильность средствами верилога/Альтеры ?
HardWareMan
11.04.2022, 09:07
Нихрена не пофигу. Метастабильность прекрасно распространяется сквозь комбинаторную логику. Особенно,через КМОП, поскольку она (почти) симметрична.
Мне как-то реально пришлось разгребать последствия такого вот заблуждения, когда разработчик не защитил от метастабильности вход UART, "поскольку метастабильность бывает только из-за медленно меняющихся сигналов, а у меня там триггер Шмитта!" Цитата дословная, запомнил ниазусть. Разумеется, это чушь, а ошибка вылазила совсем в другом месте, на шин процессора сыпался мусор. Метастабильность просачивалась через автомат состояния предатчика в автомат управления шиной, и привет.
Поэтому -- два триггера последовательно, стабильное значение брать с выхода второго. Выход первого нестабилен. Был бы он стабилен -- второй триггер был бы не нужен.
Так, стоп. Речь шла за сигнал из #25 поста, который был раскритикован в #31 посту. Это суррогаты внутри ПЛИС, откуда тут про триггер Шмидта и вообще навесную логику? Давайте отделять мух от котлет: так как работает внутри ПЛИС нельзя делать логикой на россыпи. И это главная причина ошибок начинающих ПЛИСоводов, которые перешли с обычной логики.
Сразу приношу извинения за глупый вопрос, возможно я ещё не проснулся, и не понимаю смысла этой конструкции...
Но разве процитированную функцию нельзя записать вот так:
AnyEdge <= (FIFO[1] ^ FIFO[0]);
Или просто схема сгенерируется более сложная?
Можно, и схема будет вот такой:
https://i.ibb.co/ww6NYN2/image.png
Обратите внимание на различие в RTL: в первом случае есть оптимизация ресурсов синтезатором. Иногда, необходимо помогать синтезатору, причём следует всегда учитывать внутреннюю архитектуру выбранной FPGA/CPLD. У некоторых из них ограниченный набор логических функций и XOR им даётся труднее, нежели простые AND/OR. У последних циклопов там LUT, что делает накладные расходы элементов одинаковыми. Забавен тот факт, что оптимизированный верилог из моего примера из поста #36 конкретно для циклопа выглядит вот так:
https://i.ibb.co/f9fh3Ch/1.png
Т.е., фиттер сам распознал там XOR и сделал его в LUT.
Если проблема в оцифровке сигнала с ВУ в ПЛИС, то на практике у svofski и KTSerg там не некое абстрактное значение между 0 и 1. Когда на ВУ 0, то в ПЛИС с бОльшей вероятностью оцифруется 0, аналогично с 1 (если бы это было не так, то упоминаемые устройства бы совсем не работали). В этом случае (когда вероятности 0 ВУ->0 ПЛИС и 1 ВУ->1 ПЛИС больше 50%) голосование по нескольким оцифрованным отсчетам помогает более уверенно определить, что искомый уровень достигнут.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot