Схемотехника №1 - способы построения дешифраторов.
HTML-код
- Опубликовано: 5 окт 2024
- Группа в ВК : club195... телеграмме t.me/AlexRus12... канал : www.donational...
Доброго времени суток! В этом видео я расскажу, как можно построить десятичный дешифратор.
![Дешифратор, коротко и понятно! [Электроника для начинающих] DIY, Микросхема](http://i.ytimg.com/vi/N0qfQQiiCfw/mqdefault.jpg)
![Дешифратор, коротко и понятно! [Электроника для начинающих] DIY, Микросхема](/img/tr.png)
Добрый день! Недавно начал смотреть ваш канал! Очень интересно, а главное - все теоретически обоснованно!
Скачал себе LogiSim, собрал несколько простых схем (складывающие, вычитающие счетчики, дешифраторы для hex-индикатора). И тут возник вопрос. Надеюсь, вы поможете мне с ним разобраться (а то гугл не дал ответа).
Суть вопроса: допустим, у нас есть шина данных (например, 10 бит в коде: 512-256-128-64-...-4-2-1). Мы хотим подключить к ней четыре семисегментных индикатора (чтобы визуально наблюдать десятичные числа от 0 до 1023). Очевидно, нужен кодопреобразователь. В интернете и литературе очень много информации по поводу синтеза кодопреобращователя для одноразрядного семисегментного индикатора, а вот для четырехразрядного ничего нет.
Подскажите, пожалуйста, как вы бы решили эту проблему? А то я уже всю голову изломал!
Конечно, можно составить таблицу истинности на 10 бит и 8*4=32 значения индикаторов, и синтезировать по гигантской диаграмме Вейча😅, но должен же быть способ упростить задачу. Может, кодопреобразователи можно соединить каскадно?...
Заранее большое спасибо!
Прошу прощения. Почему то Ютуб не прислал уведомления.
Самый простой способ, если цифры идут по порядку, то это сделать дешевфратор на 16(один семисегметный индикатор отображает числа от 0 до 15 в шестнадцатиричной системе) для одного индикатора и просто подключить их по порядку к шине через эти дещевраторы . Вот и все.
С десятичной системой сложнее там у дешефратора будет выход сигнала переноса в следующий разряд, но думаю вы и так это знаете.
Есть ещё вопросы? )
@@AlexRUS1234 Добрый день!
По поводу скорости ответа - ничего страшного. Мы же не обязаны отвечать друг другу мгновенно)
За последние пару дней поразмыслил над этой задачей (к сожалению, Ютуб блокирует ссылки). Синтезировал обычный кодопреобразователь 4 бит - семисегментный индикатор (10 цифр + буквы). Добавил 4 семисегментных индикатора и 4 кодопреобразователя. Далее синтезировал счетчик на T-триггерах (4 бит, модуль счета 10) и добавил КЦУ с триггером для пятого разряда - Carry out. Последовательно соединив 4 таких счетчика, получил большой счетчик на 9999 значений с десятичной индикацией. В целом хотел сделать что-то такое.
Ваши советы, несомненно, тоже верны, но мне хочется, чтобы индикация чисел была в десятичном формате.
Сейчас раздумываю над созданием калькулятора (до такого компьютера как у вас мне еще далеко). Решаю задачу, как в общем случае вывести большое двоичное число (N > 4) из параллельного регистра на семисегментные индикаторы. Собственно, предыдущий мой вопрос относился к этой задаче: N бит в двоичном коде -> M шин по 8 бит для индикации десятичных значений. Очевидно, что синтезировать КЦУ графическими методами (картами Вейча или Карно) - безумие. Есть мысли попробовать отдать эту задачу на решение компьютеру, воспользовавшись методом Квайна Мак-Класки, который, в отличие от двух предыдущих, можно запрограммировать и автоматизировать. Однако, меня не покидает ощущение, что есть какой-то более простой каскадный способ сделать задуманное. Возможно, стоит решать вопрос не на уровне синтеза схемы, а на уровне архитектуры разрабатываемого устройства.
Еще раз большое спасибо за собрание ценных материалов на вашем канале! Подписался и на телеграмм-канал!
@@funtv3291 Хмм, а тут подумал и скорее всего сниму видео, на данную тему , ведь я совсем не затрагивал устройства ввода/вывода... Вот, повод начать)))
@@AlexRUS1234 Не думал, что наш диалог зайдет так далеко. Было бы здорово 😃
Добрый день, подскажите, что за элемент «>=1» в матричном дешифраторе?
Добрый день. Это везде элемент "ИЛИ", "OR"
как называется программа 1:08
Logisim. Но я советую Logisim evolution
О какой скорости выполнения может идти речь, если во всех примерах положительный и отрицательный фронта распространяются с около-световой скоростью? Разница от первой ко второй схемы аттосекунды (а может и того меньше)
И более того. Современные процессоры синхронны, и для синхронизации используют такт. Например при частоте процессора в 4ГГц период такта составит 0.25 наносекунд, а полупериод (время работы синхронного участка процессора) составит 0.125 наносекунд
И более того. В современных процессорах перевод в системы счисления осуществляется программами. И вот эти программы и влияют на производительность. Количество тактов исполнения перевода оказывает огромное влияние на скорость вычислений, так как сами по себе такты очень медленные.
Также стоит отметить, что при увеличении разрядности переводчика схема растет экспоненциально, и для 8 битных переводов еще может быть сойдет, но не более. Вы не назвали еще один переводчик, который уже менее расточителен с увеличение разрядности.
Суть этого переводчика заключается в том, что схема будет прибавлять к константе двойку в некоторой степени. Например для перевода числа 100110[2] необходимо сложить двойки в степени места, где находится единица, то есть 100110[2]=2^5+2^2+2^1=38.
Лично я использую в своем проекте 27 битный переводчик из десятичной в двоичную систему счисления (и наоборот), основанный именно на этом эффекте
Во первых, не околосветовая, а вполне реальные единицы. Если под первой и второй схемой вы подразумеваете линейный и матричный дешифратор, то их скорость выполнения различается в два раза, что очень существенно.
Во вторых, сами же приводите в пример частоту в 4ГГц. А вы знаете, почему не 40? Потому что из-за задержек схем невозможно увеличивать частоту выше определенного порога(физическое ограничение кремния мы не берём в расчет). Так же разница в в выполнении в два раза, при гораздо большем числе компанентов оправдана.
В-третьих, как "программа" способна физически, скажем выбрать 12 ячейку ССОЗУ без дешефратора? Очень интересно.
В четвёртых, а что останется делать с этим экспоненциальным ростом? Только уменьшать тех процесс или увеличить площадь кристалла.
В пятых, ваш переводчик требует сумматор, что по факту осложняет схему в сотни раз и делает её медленнее, зачем он нужен тогда, когда есть матричный дешифратор?
@@AlexRUS1234 Любая приведенная из ролика схема не имеет существенной разницы в скорости срабатывания из-за количества вентилей перед ней, ни одна сверх чувствительная техника не успеет засечь разницу во времени получения позитивного фронта от скажем переводчика на основе СДНФ/СКНФ и моего переводчика. Микросхемы памяти gddr6x уже преодолели планку в 20ГГц (эффективной частоты), сейчас для синхронных ЦП преградой во многом является синхронизация всех модулей схемы а также неидеальность слишком сложных схем (коими и являются современные ЦП, в отличии от gddr6x памяти).
Пока период такта не будет составлять аттосекунды - задержки асинхронных схем никак не будут создавать проблемы ЦП. За 15 лет эффективная частота схем памяти увеличилась с 1ГГц (ddr2/ddr3) до 20ГГЦ (gddr6x), так что развитие в данном направлении есть (в направлении DRAM ячеек памяти, по крайней мере). В то же время частоты ЦП за 15 лет почти не изменились (xeon x5470 спокойно брал 4.5ГГц еще в 2007 году, сейчас эта частота является штатной для современных cisc to risc процессоров)
Перевод из двоичной системы в десятичную в современных ЦП осуществляется программой потому, что по шине ввода/вывода и по шине данных идут именно двоичные сигналы. Каждая десятичная цифра от 0 до 9 в процессоре кодируется как ASCII текст, процессор не оперирует десятичными числами как числами, а как текстом. Для всех операций он сначала переводит ASCII в bin int и затем уже производятся вычисления, затем если нужен ответ в десятичном формате - процессор переводит полученное бинарное число в ASCII текст. И это логично, ведь для кодировки одной десятичной цифры надо выделить 10 бит данных (это занимает много места в памяти и на шине ввода/вывода), а ASCII является 8 битной кодировкой. По шине шириной 64 бит ASCII десятичное число пройдет без проблем (8 символов за такт), по той же шине но если кодировать каждую новую цифру как новый бит пройдет только 6 символов за такт (и еще проводка шины будут не понятно для чего выделены)
И программа в целом способна выполнить любой перевод.
К вопросу почему же я не пользуюсь матричным преобразователем:
Только что по вашей формуле прикинул сколько транзисторов задействует 27 битный переводчик и ужаснулся...
Мой переводчик использует 40000 транзисторов (считал очень лениво, но в любом случае там не больше 100000)
Для примера тот же xeon x5470 содержит около 720000000 транзисторов. Ваш же преобразователь немного не дотянул))
Ааа, я понял. Товарищ, вы попутали берега. Данные схемы служат не для ВЫВОДА десятичного сигнала(или преобразования, но не суть). Данные схемы используются для коммутации цепей, будь то выбор каналу мультиплексора/демультиплексора, выбор ячейки памяти, выборе блока инструкции и так далее. Не зря я назвал эту серию роликов - схемотехника.
А по поводу, что время срабатывания схемы не имеет значения вы ошибаетесь и у меня есть личный пример: вот возьмем микроархитектуру моей машины. Для записи в ССОЗУ требуется установить соответствующий сигнал разрешения записи и переключить демультиплексор на разряд. И тут возникает проблема: демультиплексор срабатывает позднее дешефратора разрешения записи и поэтому в ячейку записываться не число, а шум на с выхода демультиплексора. Решение : ускорить дешифратор демультиплексора, что я и сделал, заменив матричный дешифратор на линейный.
@@AlexRUS1234 Представим схему (a) and (not(b)). В данной схеме сигнал not b приходит очевидно позже сигнала а, т.к. not b необходимо преодолеть not вентиль перед входом в вентиль and. Теперь предположим входные данные будут таковыми: a=True, b=True
на выходе схемы будет короткий положительный всплеск из-за того, что сигнал not b идет дольше. Но в итоге, дойдя на выходе схемы стабилизируется False.
Это действительно так, но представьте какая разница по времени в нано уровне между сигналами not b и a. Держу пари оба сигнала сформируются с разницей, которую подсчитать то трудно, не говоря уже про хоть какое-то малейшее влияние на микропроцессор.
В вашем же случае вполне вероятно из-за того, что схема ни разу не нано и даже не микро могло такое произойти. И то мне слабо верится. Я бы подумал на любую другую причину, и на эту лишь в последнюю очередь.
Но тем не менее отметать мой вариант переводчика тоже нельзя. В конце концов 40000 транзисторов или 600000000? Также уверен, что для моей схемы в нано электронике все сигналы сформируются примерно одинаково, что самый первый, что последний. А даже если это не так, то процессор может прождать один такт, чтобы все сигналы уж точно сформировались.
Ждать один такт нельзя, потому что один такт сейчас, потом и общее быстродействие падает слишком сильно в общем плане. Вы не забывайте, что дешифратор использовать не в одиночку, а с нагрузкой на выходе. Общее быстродействие ограничивается суммой всех задержек. А если последовательно, друг за другом включено около тысячи таких дешефраторов? Тут тоже не будет решать разница в задержке в два раза? И опять, если вы так любите приводить в пример современные процессоры, то приведите хоть один такой процессор, где в качестве многобитного сумматора в АЛУ используется параллельный сумматор с последовательным переносом? Зачем было придумывать различные СУП и префексный перенос? По вашей логике - это излишнее.
И зачем вам вообще такой Дешефратор на 27 бит? Управлять 2^27 ячейками памяти? Так это не рационально, есть блочные структуры организации, которые в разы компактнее. Или у вас там мультиплексор на 2^27 каналов?
Не понимаю. Это кусок какого-то большого видео?
И что со звуком?
Нет, это отдельное видео, а звук такой потому что записывал части на разных неделях и в разных программах.