С чего стоит начать, с того, что IDE у меня пока Gowin 1.9.9.03 Education. Но если кто-то захочет посмотреть только файл Logisim Evolution, то для него это значения не имеет. Свободное время я как мог отдал этой работе, не забывая при этом отдыхать, без этого вообще никак. Исправил сделал доработку полного сумматора, отладил проект асинхронного счётчика в Logisim Evolution v3.9.0. Плата всё та же - Tang nano 9k. Все проекты в Zip папках. Это всё та-же асинхронная логика, тактирование тут применяется собственного изготовления и действует как замена сигнала согласования. И плюс своя версия языкового описания в структурном виде схем на базовых логических элементах (символы могут быть заменены на более визуабельные, просто на настоящий момент передать смысл описания и для чего оно такое и как это можно использовать). Всё ещё предположительно Fast триггеры и регистры (проект триггера архивирован). Если вам ещё не надоело читать - прошу далее, в конце ждёт видео (и ссылка на видео с рутуба) с работающим асинхронным шестнадцатиразрядным счётчиком на базе сумматоров и регистров. Если кому нужны доказательства, как оказалось, то все проекты в архивах по предоставленным в публикации ссылкам. Кроме того- публикация ничего не доказывает, это просто описание проделанных мною работ, часть которой является вполне успешной, а часть - не очень, но направление асинхронной логики интересное и мало исследованное.
Версия IDE важна, поскольку при смене результаты могут быть почти непредсказуемы. Итак что я смог выжать из версии для обучения - озадачить её непомерно, чтобы хоть как-то заставить её делать что-то похожее на требуемое. Далее сначала в Logisim Evolution - в порядке хронологии.
Доработка сумматора — добавление двух буферов, чтобы перекрыть промежуточный сигнал ошибки (в проекте верхний буфер buf я конечно поставил на управление bufif1, а не после него, но переделывать анимацию уже не стал).
И вот сразу хотелось-бы сказать о том, как можно было-бы представлять описание подобных схем, с видом на то, что оптимизация на самом деле может, например, не резать логику, считая её неэффективной, а переписать код в чистый - наиболее визуабельный и с отсутствием излишеств в описании, но не в схеме, в логику оптимизация вмешиваться не должна - это моё личное мнение. Вот как это можно было-бы описать, например (символы могут быть заменены на более практичные, они означают номер и роль сигнала, это просто пример)
module summator ();
input (0:term1, 1:term2, 2:itransfer);
output (result:0, outTransfer:1);
intermediate begin
.0 = not(2:);
.1 = xor(0:,1:);
.2 = not(.1);
end
:1=bufif1(2:,_.1);
bufif1(1:,.2);
:0=bufif1(.1,.0);
bufif1(.2,_.0);
endmoduleТут компилятору будет видно что есть что, и что можно упрощать или улучшать, для этого ему выделено три раздела в модуле: описание входов и выходов, промежуточная часть схемы и заключающая. Вот пожалуйста - всё есть для того, чтобы чистить код любителям чистоты, а не резать логику оптимизацией.
Предполагаемый fast триггер (RS).
Этот триггер требует запуска перед использованием, осуществляемого через сброс. Тестирование было произведено, да - это действительно быстро и оптимизация не режет триггеры в схеме, но в силу специфичности IDE этому не стоит доверять на все сто, но можно предположить что может быть так и есть, с единственным но - скорость сброса пока не измерена, потому чо в планах маячил уже асихронный счётчик на сумматорах и регистрах, а регистры будут иметь ту-же базу что и триггер.
С виду не рабочее, но на самом деле работает. Это иной архитектуры, в большей мере не логической, а архитектуры внутренней синхронизации. В общем не знаю как это назвать точно, но это работает, и вроде как достаточно быстро чтобы сделать из этого позднее регистры, если даже хотя-бы сравнивать с первыми моими триггерами, что на базе защёлок. Проверял на этом проекте. Оптимизация "не ест" такую логику, ну и хорошо.
https://www.cyberforum.ru/blog_attachment.php?attachmentid=9145&stc=1&d=1735939897
, скриншот
Сама первая публикация по этому триггеру https://www.cyberforum.ru/blogs/223907/8763.html . Небольшие расчёты:
Самое первое, что я смотрел материал, где наносекунда была равна милионной доле секунды, что не верно, оказывается миллирдной.
частота сигнала захвата 135 МГц. за 128 тактов почти 11 срабатываний цепи из 100 триггеров. Полный цикл срабатывания цепи проходит почти за 11 тактов. Разделить на 100 получится что один триггер срабатывает за 0,1163636363636364 такта сигнала захвата. Частота тактирования сигнала захвата 135 МГц .Если конечно верить замерам и документации платы. 1000÷135 = 7,407407 наносекунды на такт сигнала захвата. 7,407407×0,1163636363636364 = 0,861953 наносекунды на запись единицы в триггер. Выглядит , уже, не фантастически быстро (с учётом исправленной ошибки), но стоит учесть что сброс такого триггера будет намного медленнее, но и будущий регистр планируется без этого недостатка. В общем это немного лучше будет сетапа предоставляемого разработчиками платы. Хотя если честно, то я не могу найти теперь тот материал, где скорость установки и скорость сбарсывания триггера на плате была.
Пояснение к расчётам от 27.01 год публикации. По случаю https://habr.com/ru/articles/876786/#comment_27838232 - удалено. были не правильно конвертированы единицы времени.
Регистр
Далее, в рамках проекта, предстояла работа над регистром. Вот анимация пары регистров с их запуском. Всё в Logisim Evolution
. Можно было приступать к счётчику.
Счётчик в Logisim Evolution
https://www.cyberforum.ru/blog_attachment.php?attachmentid=9165&d=1736256071
Проект отлажен в программе Logisim Evolution, на плате возможны некоторые улучшения и сокращения, потому что виртуальный симулятор имеет специфику упрощения своей работы и пришлось усложнять некоторые модули чисто для него.Так как обработка знаков переноса практически не ведятся, и в задачу не входит вычисление числа, счётчик оставлен на этапе ведущего отсчёт до шестнадцати и возобновляющего его по новой. На FPGA планируется что генератором сигнала согласования для следующих по цепи счётчиков будет являться сигнал о том, что предыдущий отсчитал 16 своих рабочих опреаций сложения. Регистры, по замыслу, имеют такую-же скорость работы что и полный сумматор, возможно с небольшими отличиями. То-есть отсчёт происходит за две операции - сложение+ запись в регистр. Отсчёт до 16 происходит за 32 операции. Проект в зиппапке, анимация тут. Для запуска нужно отключить симуляцию CTRL+E , сбросить состояния CTRL+R, произвести нажатий CTRL+I (i заглавная) до тех пор, пока на выходах регистров не установятся нули, и потом на вход нижнего сумматора установить единицу, далее производить симуляцию в пошаговом режиме нажатиями CTRL+I , иначе симулятор обнаруживает цикл и отказывается выполнять его.
Счётчик
И в конце концов итог, приложил не мало усилий чтобы "обмануть" оптимизацию Gowin, на мой взгляд занимающуюся совсем не тем, что ей нужно делать (а именно ранее сказал - привести в порядок текст, вот её назначение, с логикой автор должен справляться самостоятельно и скорее всего это ему по плечу).
Для версии 1.9.9.03. Стоит воспользоваться осцилоскопом, а не загрузчиком, но не нажимать кнопку воспроизвдения захвата сигнала, только загрузить битстрим с осцилоскопа, иначе результат будет совсем иной. Только так я смог "обмануть" эту оптимизацию. Счётчик шестнадцатиразрядный, диоды подключены к старшим разрядам переноса бита.
https://rutube.ru/video/b9de332712e83c385fcc038f75d13e93/?r=wd
Мне скинули по просьбе ключи, но я не знаю точно что буду использовать далее, знаю точно - IDE нужно менять. Публикация сделана второпях немного, поэтому если какие-то несоответствия с ссылками или ошибками - прошу уведомить, я постараюсь исправить в ближайшее время (преимущественно после работы).
Спасибо за внимание. Будет интересно услышать не сильно строгое мнение в адрес моих деяний, отнюдь не лестных для традиционной схемотехники, архитектур, да и собственно кода теперь, алгоритмы мы уже проходили. Чего ожидаю я - пространство для продвижения вперёд (и в ракурсе асинхронной логики - оно огромно), и конечно результатов, может и не сильно впечатляющих, но надеюсь не бесполезных. Всего доброго, не судите строго.
