Это мы не проходили, это нам не задавали...(асихронный счётчик с управляющим сигналом зад
Асинхронный счётчик на сумматорах (шестиразрядный по числу диодов на плате, но наверное разрядов будет больше - восемь или шестнадцать, а диоды на старшие), так как триггеры прошли тестирование и нужно подтвердить их быстродействие, или выяснить фактическое - отличное от показаний осцилоскопа Gowin. Поэтому будет сделан асинхронный счётчик на базе сумматоров и регистров, и цепи задержки, задержка которой будет равна времени срабатывания одного сумматора. Тут в общем-то число будет складываеться само с собой, и только в один разряд будет постоянно подаваться единица, все переносы соответственно будет передаваться по разрядам. На каждый сумматор получается будет приходится по регистру для записи значения и по регистру для записи значения переноса. Операция сложения будет считаться выполненной тогда, когда после срабатывания сигнала задержки все выходы переноса всех сумматоров будут выдавать сигнал нуля. Понятное дело, что не всегда число переносов будет одинаковое и стало быть скорость у такого счётчика тоже не всегда стабильная, но цикл от нуля до единиц во всех разрядах, само собою, будет выполняться всегда за одно время. На схеме пока нет цепи задержки. Теперь прикрепляю файл проекта в Logisim Evolution (скачивал вроде как с офсайта и ставил на убунту), и небольшую анимацию общей схемы с сумматорами, регистрами и стартером регистров (изначально регистры дают сигнал ошибки и его надо сбрасывать стартером, разумеется это всё автоматически делается). Это начало работы, постепенно буду всё добавлять в эту запись и сделаю новую по окончанию работ с счётчиком. Все схемы с внутренней синхронизацией (глобально асинхронны) и глобальной синхронизации не будет, будет только согласование. Всё это в качестве эксперимента, так как получилось две успешные альтернативы по коду, и решил, на фоне пропаганд идеального кода - копнуть в сторону идеальных архитектур, а потом уже и кода, только уже без идеальных понтов, слюней и соплей из рупора пропаганды. Так-то вроде получается, что асинхронная (не тактируемая) логика в краты быстрее, но это требует проверок и поэтому процесс движется. "Краткая единица и продолжительный ноль". Для функционирования такого счётчика нужен генератор импульса кратких единиц и продолжительного нуля, в объединении в цикле Cicle = A∪B = {unit|1}+{null|3}, как минимум, если меньшее объединение, то наверное 1∪2, но скорее всего столько не надо. Схема так-же со стартом, после старта отключение и согласно логике она должна генерировать кратковременные сигналы единицы. Система с стартом (по умолчанию сигнал ошибки, в прошлой записи есть схема, в которой сигнал ошибки исключается автоматически, но тут я так пока не настроил). Led Bar и буферы тут только для того, чтобы показать синхронизацию наглядно, в системе контакт, два ИЛИ и один ИЛИ-НЕ. На плате это требует дополнительных работ с формированием внутреннего тайминга, но это выполнимо и вопрос получения системного подхода - временнный. Вообще работы предстоит очень много конечно, и проблема в том, что по асинхронной логике очень мало литературы, поэтому в терминологии я могу немного ошибаться, как и в описании математической логики, которую вероятно прийдётся освоить по необходимости. Система проверется на плате с помощью двух триггеров. Условно асинхронные мной применяемые триггеры я делю на три типа : 1- синтезируемый средой (практически не применяю), 2 -полученный на базе синтезируемого средой, но упрощённый и описанный в структурном виде, 3 - фаст (предположительно) триггеры (которые ещё требуют небольшой доработки, но в принципе вполне функциональны, скорость работы которых планируется подтвердить или выяснить в ближайшем будущем, так как регистрируемая слишком высокая вроде как, чтобы быть фактической). Доработан сумматор. Дело в том, что в его работе проскакивал сигнал ошибки - результат отсутствия согласования тайминга между логическими элементами и буферами. Исправлено посредством введения двух буферов BUF для создания небольшой задержки и исключения сигнала ошибки Доделан счётчик из четырёх сумматоров. Некоторые схемы немного переделаны в связи с особенностью симулятора (на плате несколько иначе, и там тайминг прийдётся по новой "репитировать", такие реалии). Важно отметить, что в режиме симуляции работать не будет, так как симулятор не определяет свой тактовый генератор. Кроме того, допустимо, что это ещё требует отладки в том плане, что тактовый генератор свой может иметь смещение по фронту, но в прицнипе это не должно быть критично, согласно его устройству. Файл прилагаю - запускать в пошаговой симуляции, единицу подавать на нижний сумматор после того, как плата полностью прогрузит сигналы после запуска. Главная схема - схема depth. https://www.cyberforum.ru/blog... 1736158690 Хотя наблюдается ещё рассогласование - нет варианта со всеми четырьмя битами для нижнего LED Bara,. но это скорее ошибка с распиновкой его подключения, потому что на двух битах всё получается. Хотя это ещё надо изучить - например допустимость операции во время переноса. Пока есть перенос - так то полностью число не сложено...Разумеется, что речь идёт о счётчике, а не о сумматоре. Ещё много чего поправлено, в общем проблема бита переноса ломает всё. https://www.cyberforum.ru/blog... 1736235923 Нужно посмотреть как устроены многоразрядные сумматоры. Файл приложен, при открытии сделать сброс, отжать CTRL+I количество раз чтобы в регистры записались нули, подать на самый нижний в схеме сумматор один сигнал единицы и тогда можно увидеть проблему текущую. Либо создавать цепь задержки на срабатывание всех сумматоров кроме последующих, причём цепь задержки должна быть тогда ещё и вариабельной. В общем это проблема, надо посмотреть как её решали, если решали. Вёл в модуль тактирования GenTact ещё один елемент ИЛИ увеличив задержку на время срабатывания и тогда согласно отсчёту, через шестнадцать циклов получается результат F. Сам порядок счёта при этом разумеется весь ломается, а сам размер цикла до отсчёта - остаётся. Тут я задумываюсь уже - на что потратить время, то-ли на городило абстрактного счётчика, который ни на кой не нужен кроме как скорость сумматора подсчитать, то-ли на поделку нормального многоразрядного сумматора. Поделка по крайней мере до 16 считает исправно цикл в цикл... . И если нагородить гордулину из многа таких поделок, где для каждой последующей сигнал татирования будет исходить от результата счёта до 16 каждой предыдущей, то получается, что каждая следующая будет считать с задержкой равной квадрату времени работы предыдущей...или не так...нет не так, время цикла предыдущей умноженное на 16. Я думаю, что при условиии требовании проверки всего - сначала сгородить городулину, и проверить что она работает, а далее уже утончаться и практиковаться. |
Всего комментариев 8
Комментарии
-
Запись от Hrethgir размещена 05.01.2025 в 22:25 -
Запись от Hrethgir размещена 06.01.2025 в 12:10 -
Запись от Hrethgir размещена 06.01.2025 в 13:09 -
Запись от Hrethgir размещена Вчера в 08:59
Обновил(-а) Hrethgir Вчера в 09:13 -
Ценой вопроса был примитив bufif1 в регистре, для осуществления запуска, очень хотелось общий bufif1 на все регистры, и на плате это сработает, в отличии от этого полупьяного симулятора, обидно что это съест дополнительное время. Пока не выкладываю зиппапку, так как надо согласование на поразрядный счёт, шестнадцатиричный счётчик, и тактовы генератор средствами Logisim, пусть хоть как -то отрабатывает своё. Ага - фиг там, он обнаруживает "возбуждение", с тактовым генератором ничего не получится. Прийдётся совй ставить.
Запись от Hrethgir размещена Вчера в 09:32
Обновил(-а) Hrethgir Вчера в 09:36 -
Ещё много чего поправлено, в общем проблема бита переноса ломает всё. Нужно посмотреть как устроены многоразрядные сумматоры. Файл приложен, при открытии сделать сброс, отжать CTRL+I количество раз чтобы в регистры записались нули, подать на самый нижний в схеме сумматор один сигнал единицы и тогда можно увидеть проблему текущую. Либо создавать цепь задержки на срабатывание всех сумматоров кроме последующих, причём цепь задержки должна быть тогда ещё и вариабельной. В общем это проблема, надо посмотреть как её решали, если решали.
Запись от Hrethgir размещена Вчера в 10:44 -
Посмотрел сумматоры с параллельным переносом - это трэш, если учесть что мои регистры вполне себе работают, и работают не медленнее самого сумматора, то проще решить задачу в лоб - складывая два числа через распространение тактов только в старших разрядах от возникновения переноса. Если далее переносов не возникло - разрешать дальнейшее сложение чисел. Такой подход тоже имеет недостаток, но тем не менее других вариантов вроде как нет.
Запись от Hrethgir размещена Вчера в 12:23
Обновил(-а) Hrethgir Вчера в 13:25 -
Вёл в модуль тактирования GenTact ещё один елемент ИЛИ увеличив задержку на время срабатывания и тогда согласно отсчёту, через шестнадцать циклов получается результат F. Сам порядок счёта при этом разумеется весь ломается, а сам размер цикла до отсчёта - остаётся. Тут я задумываюсь уже - на что потратить время, то-ли на городило абстрактного счётчика, который ни на кой не нужен кроме как скорость сумматора подсчитать, то-ли на поделку нормального сумматора.
Запись от Hrethgir размещена Вчера в 13:32
Обновил(-а) Hrethgir Вчера в 13:46