Как стать автором
Обновить

Комментарии 31

Простите, но совершенно невозможно же читать и смотреть, просто кровь из глаз.

Для логических вентилей существуют стандартные обозначения, которые в любой версии (ANSI, IEC, ГОСТ – на выбор) гораздо лучше ваших самопальных, которые сплошь визуальный мусор.

Двоичные числа не обозначают кавычками, их пишут как 11101₂. С другими обозначениями та же история. С читаемостью формул – та же.

UPD. Для примера – как нужно записывать доказательство существование двоичного представления https://math.stackexchange.com/a/1966217/647986, просто сравните читаемость.

Со стандартами дело спорное - в книге будет не так много стандартных вентелей. В то же время, если кастомные по стилю окажуться сильно отличными от стандартных, глазу тоже нездобровать.

С читаемостью доказательств проблему признаю. Надо будет над ней поработать. Легко писать доказательство одному математику для другого, можно много деталей опускать. Здесь все таки обстоятельства другие и задача подачи материала во всех подробностях может трудней решаться.

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

не так много стандартных

Пока не было ни одного нестандартного, и я уверен на 100%, что и не будет, в логических вентилях что-то новое выдумать сложно.

Легко писать доказательство одному математику

Я не математик, но то, что в примере читаю без запинок, а то, что у вас... Вы же не в Труды Стекловки пишете, правда? )

Я собираюсь комбинировать простые блоки в более сложные. Затем что получилось еще и еще раз. Для каждого кастомного блока свою иконку не придумаешь, а использовать для одних одно, для других другое - тоже не лучшее решение.

В идеологических спорах трудно найти "правильную" точку зрения.

В идеологических спорах трудно найти "правильную" точку зрения.

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

Ну и до кучи - а почему бы не сократить подачу и не написать просто формулу для вашего устройства из примера? Отображение схемы на формулу объяснить очень просто, знаки "и", "или" можно даже на "*", "+" заменить, что бы максимально просто было. И краткость получится, не нужно отслеживать лабиринт из проводов на схеме.

ЗЫ. Вчера смотрел новые посты, ваш сначала был, потом исчез. Хотел написать комментарий, а вы "сбежали", вместе с текстом в черновики. Хотя в результате обнаружил возможность постоянно держаться в топе списка - прячем в черновики и выкладываем снова раз в несколько часов. Вы так намеренно делали? Или стесняетесь критики и прячетесь в черновиках? Стесняться не надо, ошибки нужно признавать и исправлять, а прятаться постоянно - выглядит не очень.

С исчезновением статьи - это хабр немножко глючил, или я. Дело тенмое. Опубликовал в 18.49 в том виде, как вы ее видите, но время прошло как 10.21. Пришлось старую скрыть в черновики и перевыпустить из под нового шаблона. Плюсы и добавление избранное были утеряны, но зато статья не на ночь и утро, а сутки, как и должно провесит.

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

И очень не удобно читать схемы справа на лево, когда ничего не мешает сделать слева на право как читает почти весь мир?

Внутри компаратора по каскаду ячеек сигнал распостраняется слева на право: во всех ячейках копаратора составляющие их элементарные блоки имею ориентацию слева на право.

Внутри схем каскадного сумматора, каскадного умножителя, каскадного счетсчика слова-команды относительно слов-аргументов распостраняютя справа налево. Ориентировать слева направо элементарные блоки в ячейках перечисленных схем было бы соблюдением правил ради соблюдения правил.

Я предпочитаю придерживаться логики и соображений удобства. Надеюсь, вскоре и вы полюбите фристайл.

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

А если миллион разных сценариев, но все их можно коротко описать словами. У стека даже конечной длинны бесконечно много непериодических сценарием поведения на множестве тактов [0, infinity). Как описать их все с помощью временных диаграмм?

Зачем описывать все? Нужно обеспечить начальное базовое понимание. А дальше человек может сам хоть во временной области рисовать, хоть схемой, хоть словами, хоть математическим эквивалентом. Тут… все зависит от того на кого статья ориентирована. Я, например, и так разберусь. А вот для новичков будет тяжело.

Не находимся ли мы оба в плену профессионального искажения восприятия мира?). Если запросов на диаграммы будет много, я их обязательно включу. Для меня лично они так же непонятны и трудно воспринимаемы, как для кого-то непонятны словесные описания.

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

Принашу извинения за свои ошибки в словах.
В остальном: мир не постоянен - все меняется.

Полностью поддерживаю критику авторских графических обозначений для блоков:

  1. Функциональность блока обозначается отдельным словом внизу, в отдельной рамке, да ещё и курсивом. На схемах ближе к концу статьи эти обозначения разглядеть невозможно. Обозначения в виде формы блока гораздо нагляднее

  2. Подпись внизу у автора не только указывает на функциональность блока, но также является его идентификатором, при помощи нижнего индекса. Это ещё менее читаемо, не надо так. Базовый блок проще идентифицировать просто номером.

  3. Подписи для входов и выходов базовых блоков в большинстве случаев можно опустить

  4. Убивает то, что у автора для базовых блоков входные параметры незакрашенные, а выходные - закрашенные. А для схемы - наоборот.

Я так понимаю, что та рисовалка, где автор делает свои схемы, просто копипастит шаблон, а дальше автору лень.

Насчёт общего порядка изложения материала: автор сначала описывает, что схема составляется из блоков, затем зачем-то упоминает такты, потом описывает, как работает комбинаторно-логическая схема, потом вводит регистры, чтобы сразу после этого забыть про них и описать сложную комбинаторно-логическую (безрегистровую) схему. Я бы предложил тактирование и регистры убрать сильно на потом.

Спасибо за критику. Буду думать как улучшить.

1)Да, внешняя форма неплохо кодирует тип блока, если вы собираетесь использовать только конечное число типов. Начиная со следующей статьи я буду с помощью кобинации старых определять все новые и новые типы блоков, как программисты в обычных языках программирования определяют новые функции. Если использовать для идентификации форму, то очень скоро придется рисовать звездочки и сердечки.

2) Я подумаю на этим.

3) Подписи портов логических блоков опустить не получится, если есть желание менять местоположение портов относительно иконки блока.

4)Насчет визуальной путанницы между входными/выходными портами схемы и ее блоков я дал подробное объяснение с начале статьи "Быстродействие элементарных схем", надеюсь, прочитав его, вы поймете мои мотивы и их логику.

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

  1. У вас какая-то непонятная принципиальность: или только внешняя форма, или только подписи. В стандартной системе отображения, на которую вам уже указывали, применяется внешняя форма для базовых блоков и прямоугольники для сложных блоков. Базовые блоки должны отображаться максимально просто и наглядно, чтобы восприниматься спинным мозгом. В математике, к примеру, для простейших операций применяются наглядные символы, а для синусов и логарифмов - имена

  1. Аналогично предыдущему, я не утверждал, что для всех случаев нужно убрать подписи, а для тех, где назначение порта очевидно. Это так, например, для всех стандартных блоков. У вас же входные и выходные порты различаются цветом, так зачем на базовом блоке "not" ещё что-то подписывать?

  2. Открыл предыдущую статью, охренел от её размера, на глаз не нашёл, где там это написано. Если логика "по проводкам сигнал идёт от чёрного к белому", то меня бы устроил такой ответ

Вы спрашивали на кого рассчитана книга. Книга рассчитана не только на инженеров микроэлектроньщиков, интересующихся возможностью реализации в железе тех или иных алгоритмов. Она в том числе должна быть мостом "с другой стороны". Я год как математик помогал проектировать устройство на кристалле и мне очень трудно было поместить в свою картину мира все эти треугольнички и полумесяцы с черточкой. До сих пор не смог запомнить, что они означают. Да, наверное этот иероглифический язык удобен при работе на уровне аналоговых сигналов, так как напоминает инженеру физические чертежи схем. Однако зачем тащить весь этот рудимент к абстрактным математикам и людям, занимающимся теорией вычислений?

Насчет портов. Если меня кто нибудь научит, как в редакторе хабра ставить якоря - буду благодарен. Пока привожу выдержку полностью:

Пояснения, касающиеся понятия внешних входных и внешних выходных портов на схеме

Да, наверное, это сбивает столку. Если слышишь две фразы: «внешний выходной порт схемы» и «выходной порт логического блока», то интуитивно проводишь между ними параллель. Кажется очевидными, что назначение, которому служит внешний выходной порт на схеме, должно быть аналогично роли, которую играет выходной порт у логического блока.

Однако, это не так. Наши формальные определения с такой аналогией идут в разрез.

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

Согласно этой точке зрения, дистанционно вынесенные на материнскую плату компьютера входные порты принтера, монитора, и аудиосистемы – являются для платы внешними входными, то есть физически присутствующими на ней входными портами тех устройств, которые сами размещены за ее пределами. С другой стороны, так же дистанционно размещенные на плате выходные порты мыши, клавиатуры и сканера – являются по отношению к плате внешними выходными портами.

Указанная интерпретация на первый взгляд противоречит тому обстоятельству, что разъемы на плате, куда подключаются кабели от принтера, монитора и аудиосистемы, по своему смыслу являются выходными портами самой материнской платы, рассматриваемой как единое устройство, а разъемы, куда подключаются клавиатура и мышь – ее входными портами.

В действительности между обеими трактовками никаких противоречий нет. Все зависит от выбранной точки зрения.

Если вы рассматриваете материнскую плату как обособленное цельное устройство, то расположенные на ней разъемы для клавиатуры и мыши имеют смысл входных портов, то есть тех, на которые должны быть поданы электрические импульсы в процессе работы, а разъемы для монитора и принтера – как выходные порты, поскольку последние сами являются источниками цифрового сигнала.

В то же время, если плату рассматривать «изнутри»: как собранную из отдельных устройств логическую схему, то «обратная» стороны разъема для клавиатуры будет выглядеть, как дистанционно вынесенный порт выхода (клавиатура порождает импульсы), а обратная сторона разъема для монитора – как типичный порт входа (на него нужно отправлять импульсы).

Книга действительно рассчитана непонятно на кого, она плоха для всех. В ней нет ничего нового, значит не на электронщиков. Она плохо подходит для обучения, значит не на новичков. Для инженеров она слишком формалистична и непрактична. Если на математиков - нафига городить схемы вообще, достаточно сказать, что есть функции and, or, not, и всё, дальше достаточно любого математического формализма. Вы оправдываетесь, что вы математик, я верю плохо, как раз математикам свойственно делать всё максимально компактно и использовать иероглифы для выразительности.

Я правильно понял вашу логику: "Внешний порт платы обозначим вот так, потому что это внутренний порт для внешнего устройства"? Вы штаны случайно не наизнанку носите?

Все мы хороши на словах пока дела не коснемся.
Уважающий себя джентльмен, когда он пишет, что у автора такой-то книги нет ничего нового, обычно приводит ссылки на те же самые главы или темы в других источниках. Вот примерное олавление книги, которую я собираюсь написать. Я буду только рад, если мою работу уже кто-то сделал до меня.

https://eccc.weizmann.ac.il/resources/pdf/OBDD-Book.pdf

Понятно, что соответствие даже близко не 1:1, но имеет смысл хотя бы посмотреть на стиль и структуру. И на графический формализм, не подходящий явно ни под один стандарт, но всем понятный сразу.

http://www.ime.cas.cn/icac/learning/learning_3/201909/P020190909561648570397.pdf тут немного про другое, гораздо ближе к реализации, но кое-где с вашими предыдущими публикациями отчасти пересекается. Подача очень формальная местами, но, кажется, вам так нравится.

Эта книга может быть полезна в том смысле, что вы на свои примеры станете смотреть более критично и возможно перерисуете в общем-то стандартный XNOR, который у вас получился с несимметричными по задержке плечами. С тз логики всё ок, но в реальности так, вроде, никто не делает (пусть спецы поправят если я не прав).

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

То есть да, технология строительства накладывает ограничение на способы решить задачу, которыми располагает архитекторское бюро, но не более чем.

Математика начинается с определений и формализмов. В других дисциплинах всё примерно так же.

Вы насколько всерьёз будете относиться к выкладкам человека, который напишет что-нибудь типа «абазначем за ℂ множество вещественных чисел»? А ваша работа пока именно так выглядит.

Я долго живу и видел много разных людей. Если у человека есть мотивы ввести свои обозначения, он их объяснил и хотя бы примерно обозначил финальный результат, я буду его слушать.

Большое спасибо за интересный материал и что не бросаете писать!

Вы не планируете разбавлять абстрактные построения конкретными примерами кода с которыми можно было бы поэкспериментировать и поиграться? То есть пробросить мостик с теории к практическому применению.

С верилогом, наверное, много возни, но тоже не фатально. Например в известной книжке "Designing Video Game Hardware in Verilog" это решено через web-среду со всеми примерами.

Да и на верилоге свет клином не сошелся, сейчас есть, например, migen, на котором можно было бы реализовать все примеры.

Спасибо за добрые слова и снисходительность к моему мышлению позапрошлого века. Да было бы здорово поэкспериментировать, - правда я в делах написания непосредственно HDL-программ не сведущ как первокурсник. Думаю, в каких-то азах недолго разобраться: концепция мне ясна. Я анализировал как синтаксис, так и семантику Verilog и VHDL, когда продумывал свой упрощенный язык. У меня была мечта, что кто-то среди нынешних студентов поможет мне сделать эксперименты. Это было бы полезно для такого человека, я думаю, Плюс возможность получать консультации по реализации тех или иных алгоритмов. Если вы можете меня порекомендовать кому-нибудь, буду благодарен.

Книгу "Designing Video Game Hardware in Verilog" не видел, но обязательно посмотрю.

Предложение

  1. Ввести понятие памяти, бита - это про rs и t триггеры и как строится ячейка памяти и из чего она состоит. Просто на одной булевой логике не уедешь, т.к. не понятно как эта логика может содержать вычисления. Тот же вопрос сумматора необходимо понятие бита переноса. Я может плохо смотрел, его не увидел по биты памяти.

  2. Само понятие булевой логики, надо расширить, для взрослых читателей до вопросов физики и понятия фронта волны и устойчивой и не устойчивой системы, просто из самих логических высказываний не вытекает что в пределах логики есть память (бит информации)

  3. Не плохо бы посвятить главу вопросу булевой логики при реализации ее в физике, те же диоды, транзисторы и т.д. в качестве примера физических воплощений привести примеры "домино" компьютер и компьютеры основанные на водных устройствах и та же машина Тюнинга в биологической клетке, не стандартные виды компьютеров это интересно. Можно отдельно разобрать логику "домино" компьютера, т.к. она на прямую не содержит И,ИЛИ,НЕ, но к ней сводиться через другие операции. Можно ещё вспомнить про компьютерные схемы из красной пыли/песка в Minecraft.

  4. В последних главах не плохо бы разобрать заблуждения по поводу язык программирования - что они могут быть похожи на естественные языки. Пример , что язык sql, задумывался как дружественный язык для домохозяек

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

То же применение, это не обязательно только специализированные языки проектирования схем/ПЛИС или как их там... А те же симуляторы микро-схем, коих много, да хоть Minecraft.

Взять и предоставить ту же схему не в стандартном виде, а виде Minecraft блоков, потом в виде схемы пайки транзисторов или фотографии сборки схемы на монтажной плате

Можно ещё вспомнить, что многие схемы были готовы и печатались в отдельных журнал в период позднего СССР

1) Среди элементарных блоков присутствую однобитные регистры с/без портом "enable" и "reset" во всех комбинациях.

2) Об этом есть немного в предыдущей статье "быстродействие элементарных схем", но понятие бистабильности как таковое не затрагивается, поскольку намеренно выбран более высокий уровень абстракции.

3) Есть некоторая цель и лимит страниц средней книги. Не получится написать обо всем.

4) Формальные языки в этой книге всего лишь средство, не цель исследования.

Извините, прострел предыдущую статью по фронт сигнала там есть.

Да извинятся в общем-то не за что. Спрашивайте - если смогу, постараюсь ответить.

Столько текста для описания простейших по существу действий никто читать не будет. Это сколько же томов получиться, если дойти до SRAM-based FIFO или там алгоритма Томасуло? Типа стотомник?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории