Комментарии 45
Ваши отзывы и соображения помогут улучшить конечный вариант книги, особенно если Вы оставите вместе с этим отзывом какую-то информацию о своей категории как читателя, например: "я - студент", или "я - преподаватель этой дисциплины в университете", или "я - инженерный гений", или "да мне просто интересно стало". Можно писать очень плохие и даже самые ужасные отзывы, главное, чтобы развернуто и по делу.
> Впоследствии мы преодолеем проблему дублирования, добавив в нашу теорию возможность определять в ней новые составные блоки, что по духу аналогично переходу от ассемблера к процедурным языкам программирования.
если по духу, возможно лучше макро определения, а не процедуры, таки переиспользование кода процедур имеет динамический характер
ps
желаю успеха
Тут просто аналогия, вам программистам - виднее. Я имел в виду больше сам язык и его выразительную силу. Языки описания аппаратуры именно что описывают: их инструкции не призваны "исполнятся" на каких-либо машинах.
понимаю конечно, но аналогия не совсем, во всяком случае imho
Одно из двух открытий в универе для меня было понятие "модульности" (проговоренное в явном виде) - как вообще основа всех сложных систем.
Поэтому это возможно то место, в котором не стоит гнаться за упрощениями и аналогиями, и описать всё как есть?
Сугубо ИМХО, конечно.
ПС
Да большое спасибо за ваш труд.
Когда вышло оглавление (предыдущий пост) - я подумал, что оно настолько монументально, что реализации ожидать не стоит. Уже вижу что ошибся.
Буду рад продолжению.
Огромная благодарность от меня тем незримым редакторам хабра, которые всякий раз правят и аккуратно верстают мои неряшливые тексты. После ваших усилий статьи становятся куда более удобочитаемыми, чем до!
Я почитал в рамках ликбеза. Общие представления о теме были, но не более того.
Собственно, текст мне понравился. Читается хорошо, стиль хороший. Но его требуется вычитать с точки зрения читателя. Не всё в нём можно понять опираясь только на него. И есть просто несколько ляпов.
1. Не помешает во введении конкретное указание, о чём речь – о устройстве микросхем, о устройстве чипов и процессоров, или обо всём сразу.
«Современные цифровые схемы на кристалле концептуально представляют из себя примерно тоже самое, однако их строение не получится разглядеть без микроскопа»
Вот после этой фраз не хватает фразы, что далее речь идёт о «схемах на кристалле» (процессорах, чипах, …?). Или о том, что в книге будут рассмотрены принципы одинаково подходящие и к чипам, и к микросхемам.
2. Блочок – не очень удачный термин. Миниблок, базовый блок, логически блок, просто блок, элемент схемы - не так режет слух. Конечно, если это не общепринятый термин.
3. 5. и понятии дискретного времени.
"И" лишнее
4. всего 4возможных комбинации
пропущен пробел
5. P3) Свойство, обязывающие каждый входной порт быть присоединенным в точности к одной шине, а каждый выходной порт – не более чем к одной шине.
Сложно написано, приходится вчитываться. Может быть так: Входной порт всегда подсоединён к одной и только одной шине, а выходной либо к одной, либо ни к одной?
6. P6) В каждый из тактов значение всякого внешнего выходного порта должно быть задано вешними условиями.
Может быть входного, а не выходного? Иначе непонятно, почему выходное значение должно зависеть от внешних условий. Или значение выходного порта зависит от внешних значений на входных портах?
7. Чтобы назвать конкретный порт, мы будем указывать собственное имя блока, а затем через точку то универсальное имя, которое этот порт имеет во всех блоках данного типа (например, or_0.arg1)
Непонятно, что такое арг. Имя блока понятно, а далее какое-то универсальное имя, и какой-то этот (какой этот?) порт, суть которых не понять по данному тексту.
8. Когда это необходимо, сразу за именем в квадратных скобках мы будем указывать размерность порта.
Размерность – это количество бит, которое он передаёт?
Пусть Pname – имя конкретного порта, значение этого порта на временном шаге k мы будем обозначать как Pname(k), в свою очередь i-тый бит того же значения — как Pname[i](k), или просто Pname[i], если из контекста понятно, о каком именно шаге идет речь.
Из этого абзаца уже непонятно, что же в квадратных скобках – количество бит (размерность) или номер бита. Я бы оба абзаца переписал, более чётко, но просто указав что в квадратных скобках ,а что в круглых.
Если интересно, могу позже продолжить.
Спасибо, много дельных замечаний, вы дали мне пищу для ума.
Касательно цитата:
"Может быть входного, а не выходного? Иначе непонятно, почему выходное значение должно зависеть от внешних условий. Или значение выходного порта зависит от внешних значений на входных портах?"
6) Я тоже переживал, что будет сбивать с толку. Понимаете, выходные порты - это все те, на которые устройства подают сигнал. Сканер подает сигнал на свои выходные порты, если эти порты присутствуют на материнской плате компьютера, то в моем определении они являются внешними для платы, но выходными портами. Конечно в некотором смысле, это входные порты платы, как единого устройства, однако по своим свойствам, по их роли в правилах конструирования логической схемы и содержании теорем - по свойствам эти порты почти ни чем не отличаются от выходных портов блоков, расположенных внутри схемы. Я думал остановится и уделить внимание этому моменту в тесте, но почему-то так и не сумел найти нужных слов или не посчитал проблему достаточно важной.
7) Имена полей всех объектов класса устанавливаются в момент определения класса. У каждого экземпляра объекта класса будет то же самое именование его собственных полей, что и у всех других представителей класса. Теперь прямая аналогия: класс объектов-> тип логических блоков, конкретный объект класса -> конкретный блок своего типа, поле объекта -> порт блока. arg1 - это общее (универсальное) название одного из портов в типи блоков логического "ИЛИ", or_2 - какой-то конкретный блок этого типа, or_2 . arg1 - конкретный порт.
Не уверен, что смогу оперативно включить все Ваши замечания в текст (текст с учтёнными замечаниями - это новая статья), но в конечной редакции книги я постараюсь все исправить. Так что, да, я буду благодарен за ту обратную связь, которую Вы даете.
Про входы и выходы спорить не буду. Я не знаю, как принято. Интуитивно мне кажется, что, если есть шина, то один её конец будет входным для одного блока, а другой выходным для другого. Если какой-то внешний блок (схема, или группа блоков, или устройство) подаёт по шине сигнал в рассматриваемый блок (схему), то, то для внешнего блока это будет выходной порт, а для рассматриваемого входной. Но это моя логика. Если это не так, то надо всё же объяснить, ибо это, как я понимаю, базовые термины и принципы.
Про arg1. Может, я упрощу, но, мне кажется, тут слишком усложнено. Вот суть, которую и надо отразить в книге: or_2 - имя конкретного блока, arg1 - имя порта, который может (не может) быть в разных блока, or_2 . arg1 - имя конкретного порта в конкретном блоке. По идее этого будет достаточно для начала. Дополнительно можно (но не обязательно) что-нибудь пояснить про то, что клон arg1 может быть портом в or_3. А может ли быть в and_1.
И я бы не привязывал это к классам из программирования. Иначе получится, что для чтения книги нужно будет знать программирование на весьма неплохом уровне. Я бы постарался сделать книгу такой, чтобы было достаточно школьных знаний (логику И, ИЛИ человек знает, но ассемблер и классы не полностью или вовсе только слышал).
Гениально! Я пол часа голову ломал, как вот об этом всем написать, и не додумался - пришлось через аналогию выпутываться. Ваша версия несравненно лучше, она и войдет в конечный вариант текста.
Про порты - да, вы правы. К тем же самым соображениям я прибегну, когда буду строить понятие составного логического блока. В теории элементарных схем, к сожалению такой подход делает все громоздким и запутанным. Вот и приходится идти отчасти против интуиции и традиций.
Если бы я избрал "традиционны" вариант, то во всех аксиомах, теоремах, доказательствах теорем вместо "для всякого выходного порта" мне пришлось бы писать "для всякого внутреннего выходного либо внешнего входного", то же самое для нынешней "для всякого входного". Мне показалось меньшим злом избрать тот вариант, который вы собственно и видите в статье.
не туда
Заинтересовало желание автора "отрефакторить" проектирование логических схем. По сути автор решил начать почти с нуля и протянуть привычные ему математические подходы до некого практически полезного завершения. Но есть проблема. Она состоит в том, что методов проектирования логических схем создано к настоящему моменту немало, и созданы они чаще всего практиками, или с тесной привязкой к практике. Привязка эта отражается в связности изложения при обучении инженера электронщика. Сначала даётся некая база, основные понятия котрой в дальнейшем используются, в том числе в таких дисциплинах, как проектирование логических схем. То есть подход автора не то что бы совсем отрован от этой базы, но всё же предполагает значительный разрыв между базой и предложенным подходом.
Дополнительно подход автора несёт на себе явный отпечаток математичности. Это неплохо, но внутри такого подхода заложены неустранимые проблемы. Иначе было бы странным, почему бы за сотню лет никто не сподобился начать использовать математику в проектировании настолько глубоко, как предлагает автор. А не сподобились они по простой причине - аксиоматизация реального мира нереальна для смертных. Затраты стремятся к бесконечности. Практический результат - к нулю. Поэтому автор вынужден ограничиться неким базовым набором аксиом, от которого далее строит своё изложение.
Но базовый набор аксиом, как известно на примерах из той же математики, хорош для исключительно математических построений, когда соответствие реальности является практически ненужным качеством построения. Но в электронике на первом месте стоит всё же именно соответствие реальности. Как добивается автор такого соответствия? Он намеренно ограничивает сложность построения, вводя ограничения на составляющие предложенной теории. Что из этого получилось, ещё предстоит оценить, но тем не менее уже появились вопросы.
Было бы интересно узнать мнение автора по проблеме выбора минимального набора аксиом. Почему именно такой набор? Что вы думаете о его минимальности? А о непротиворечивости? Последнее вы, видимо, сами обнаружили при попытке описать схемы с внутренними циклами, и в результате ввели дополнительные ограничений (аксиомы), препятствующие появлению таких циклов. Но правильно ли это с практической точки зрения?
На практике разного рода ухищрения с зацикливанием приводят к некоторым полезным эффектам (мультивибратор, например), а намеренное исключение таких эффектов ведёт к уменьшению "силы теории" (если выражаться в математических терминах). На практике же это означает меньшую свободу действий проектировщика, худший результат на выходе.
Собственно, привычные в электронике методы проектирования потому и не берутся доходить до самых основ, ведь это приведёт к наличию ограничений. Предполагается, что лучше иметь возможность делать всё, не накладывая на себя запретов, а моделировать такие вседозволенности по частям, в рамках которых некие ограничения всё же соблюдаются (но часто наборы ограничений сильно отличаются от модуля к модулю).
Так же, как важная часть математичности, в подходе присутствует возможность почти один-в-один переложить его на любой язык логического программирования (с точностью до обозначений). Не думал ли автор сходить и в эту сторону? Лёгкость моделирования мне представляется важным достоинством подхода.
Ещё есть моменты "мелкого характера". В вашем определении шина - это просто провод, связь, и более ничего. Зачем тогда слово "шина"? В компьютерах шина является довольно сложным изделием, предполагающим коммутацию поставщиков/потребителей двольно сложным образом. В вашем ограниченном случае этим могут заниматься входящие в вашу теорию мультиплксоры. Но выбор был сделан в пользу простого провода. Почему?
Термин "фронт распространения" мне кажется неудачным. Вы рассматриваете статическую картину, когда все значения напряжений на всех выходах полностью определены. Фронт же предполагает различные значения на элементах, находящихся до него и после него. Это непривычное использование термина может привести к плохим последствиям.
Ну и по побозначениям. Например - or_0 - зачем связка в виде "_"? А если без неё? Что тогда ухудшится? Зачем вводить лишнюю сущность?
Так же я бы сделал преобразование: pname[i](k) -> pname(k)[i]. Потому что сначала идёт такт, а уже потом идёт значение бита на данном такте. У вас же первично значение, а такт появляется позднее.
Итог: хотя бы отличие от существующих методов всё же стоит пояснить - зачем, почему именно так, чем лучше, чем хуже. Ну и на все остальные впросы ответить, заодно :)
Спасибо, я должен вас порадовать, вы почти везде правильно догадались до моих задумок и с большинством ваших посылок я согласен. Результат анализа этих посылок у меня правда отличается, во многом по этому и появилась идея написать книгу.
Одна из сверх идей, которые прячутся за содержанием: время для обучения и развития навыков у каждого человека конечны. Если бы я потратил так много времени на изучение всего того, что должен знать мало-мальски квалифицированный инженер-электронщик и еще столько же, чтобы эти знания превратить в рабочий навык, то мне некогда было бы изучать математику, практиковаться в исследованиях и я не смог бы изобрести те несколько, как мне кажется, интересных алгоритмов и общих концепций о которых собираюсь рассказать.
Я готов высказать гипотезу, что в среде людей, которые занимаются проектированием сложной микроэлектроники существует дефицит знаний и навыков в области более абстрактной математики и теории алгоритмов. У меня есть уверенность, что проектирование микросхем, как ремесло и область знания усложнилась в той мере, когда должно произойти очередное "разделение труда". Стиль и содержание книги задумывались мной с той целью, чтобы сблизить людей с абстрактно-математическим и инженерно-прикладным стилем мышления, нащупать очертания возможного языка коммуникации между ними. Это ответ на главные ваши вопросы и догадки.
Те следующие сомнения, которые вы высказываете наверное могли бы быть применены и к обычному программированию в каких-нибудь 60-тых годах. Поверьте, RAM-модель, на основе которой построены все книги и все обучение современных программистов бесконечно далека от реального устройства процессора, памяти и конкретной реализации вычислений. Однако именно изобретение RAM-модели позволило привлечь к исследования алгоритмов широкий круг ученых, которые без нее и носа бы не сунули в непроходимые закоулки логики существовавших на тот момент машин. Универсальность и доступность их теорий стало основой для лучшей подготовки "специалистов на местах". Все-таки разница между программистом, который знает быструю сортировку и программистом, который выполняет сортировку исключительно пузырьком, разница существенна.
Набор аксиом непротиворечив, если непротиворечива арифметика (аксиома T), поскольку в таком случае логическая схема не содержащая ни одного блока, шины или порта является его моделью. Теория обладающая моделью не может быть противоречивой.
Насчет переименования pname[i](k) -> pname(k)[i] - полностью с вами согласен, хотя так как есть моему взгляду нравится больше. Не знаю, что победит, чувство эстетики или здравый смысл. Подожду еще мнений.
У меня есть уверенность, что проектирование микросхем, как ремесло и
область знания усложнилась в той мере, когда должно произойти очередное
"разделение труда".
Разделение нужно для повышения эффективности en mass, но для повышения качества понимания, являющегося основой повышения возможностей по проектированию, разделение вредно. Отсюда цель вашего труда - предложения по массовому обучению (ибо только тогда есть эффект). Если же на самом деле цель - углубление понимания, то не нужно говорить о разделении. Или вообще мысль не донесена (либо мной не понята).
RAM-модель
Это модель абстрактной нерпрерывной адресуемой памяти или что-то ещё? Если память, то там давно все сложности работы учитываются. Вспомним хотя бы количество уровней промежуточных кэшей в современном компьютере. Эти знания активно используются при написании эффективных программ.
Теория обладающая моделью не может быть противоречивой.
Исключите требование ацикличности и тогда на пустой схеме вы тоже построите модель. Но результат-то противоречивый.
Насчет непротиворечивости вы не совсем правы. Если некоторая теория непротиворечива, то есть из всех ее аксиом нельзя вывести противоречие, то и из любого подмножества аксиом тоже нельзя вывести противоречия.
Исключение из списка аксиомы ацикличности просто не позволит доказать, что из соответствия схемы логических блоков конструкционной группе аксиом, следует, что портам, шинам и состояниям блоков на каждом такте можно приписать такие значения, так чтобы все вместе они удовлетворяли всем аксиомам теории.
Разделение труда как раз и происходит, либо если вы делаете что-то массовое (упрощение ради эффективности), либо что-то очень сложное (ограничение необходимого объема и сложности знаний каждого сотрудника). БАК, ИТЕР, "Джеймс Вэб" не делаются "моноспециалистами".
RAM-модель - это не совсем про память, скорее, это такая абстрактная вычислительная машина, вроде машины Тьюринга, только каретка куда угодно может за один шаг прыгать и ячейка на ленте может сколь угодно большое натуральное числа содержать.
снова не туда
Если порты, на которые извне приходят сигналы на рассматриваемую схему, Вы на рисунках помечаете как внешние выходные, и порты, из которых сигнал уходит во вне - как внешние входные, то может быть хотя бы их рисовать полукругами не внутрь нашей схемы, а наружу? Так ведь логично будет и понятнее.
Да я об этом тоже подумал. Правда не очень красиво получается и не много не логично. Следующая статья (я планирую опубликовать ее через неделю снова в среду) начнется с "дополнений и исправлений". Одно из исправлений будет касаться графического языка. Я решил рисовать полукруги, обозначающие порты блоков, наружу от них.
При таком подходе все логично получается: внешние порты, то есть порты тех устройств, которые сами не попали на схему, как бы отрезаются от последних рамкой схемы, и поэтому обращены во внутрь.
Еще одна хорошая новость - я освоился с io.draw, так что новые схемы будут красивыми и разборчивыми. Старые тоже собираюсь перерисовать.
Отличное начало! С нетерпением ждем продолжения!
Ознакомился с Вашей публикацией. Прочел несколько раз, меняя отношение в лучшую сторону. Дополнительно ознакомился и с начальной публикацией. В общем понравилось. Необходимо несколько уточнений, что вызвано определенной «заковыренностью» Ваших выражений.
Первое, и, наверное, главное для моего понимания. Вы хотите проанализировать возможность реализации на микросхемном уровне реализацию разных «наработок», которые были найдены при программировании «серьёзных» задач? Наверное, это правильно. Сейчас микросхемотехника крутится вокруг вычислительных проблем. А то освоили булеву алгебру и её взаимодействие с десятичной системой на уровне близком к арифметике.
Если я Вас правильно понял, то вперед! Но невероятно трудная задача.
Ну, а теперь некоторые замечания, относящиеся к Гл. 1, названной «Вычислительная модель». По наименованию в ней вопросы сегодняшнего воплощения цифровой схемотехники. А в ней Буль. И надо ему воздать должное, а не сразу оперировать положениями, взятыми, на мой взгляд, из программирования. Да еще и это демонстрировать на разных парадоксах. Их и в булевых преподнесениях предостаточно и отработаны методы их устранения при практических реализациях.
Второе. Определенная сложность, я бы даже сказал, вычурность Вашего письма при описании простых вещей. Например, Вы описываете подсоединение (порты) линий связи к вычислительным блокам, обеспечивающим подвод и снятие сигналов, называя их аксиомами. Для меня аксиома – это какое-либо исходное положение какой-то теории, принятое без доказательств. А что здесь надо доказывать? Что сигналы на входе блока, принятые по проводам, будут совпадать с сигналами на выходе источника?
Да, еще и определенная вычурность в написании. Например, аксиома: «P3) Свойство, обязывающие каждый входной порт быть присоединенным в точности к одной шине, а каждый выходной порт – не более чем к одной шине.» Из этого разве не следует, что некоторые из выходных портов могут не иметь подсоединений? Так зачем он?
Сложность и вычурность письма- это профессиональное смещение плюс академический стиль. Слышали анекдот про по крайней мере одного барана черного по крайней мере с одной стороны - это оттуда? Иногда, правда, и такой способ подачи мысли имеет свои положительные черты - вот, ваше внимание, будь текст написан обыденно, бегло бы по нему скользнуло и не заметило всех обстоятельств, а так - оно встретило что-то необычное, остановилось, все взвесило, устранило возникшие видимые противоречия, пришло к правильному пониманию.
Аксиомы не надо доказывать. Аксиомы - это способ выделить главные черты описываемого явления, заменить требование "являться чем-то" на требование "обладать какими-то свойствами". Вот, скажем, хочу я доказать какое-нибудь утверждение о всех в мире кошках, тогда я аксиоматически прежде должен описать, какими важными для моего утверждения свойствами кошки обладают. Если вдруг вам попадется кресло, всем этим свойствам удовлетворяющее, то и для кресла доказанное мною утверждение, казалось бы, о кошках, тоже будет верным.
На практике у разработчика железа может быть готовый библиотечный блок, не все порты выхода которого ему понадобятся. Стоит ли позаботится о том, чтобы этот разработчик мог такой блок использовать в своей схеме?
Промахнулся.
Спасибо за два ответа на мой комментарий. Первый, односложный «Промахнулся», очевидно, относится к той части комментария, где я вопрошаю: «А правильно ли я Вас понял?» Мне, кажется, ответ «не очень». Поживем, увидим. Вы похоже не остановитесь. И не так уж важно мое непонимание.
Относительно аксиом. Во всех вики и прочих педиях – это утверждение в теориях не требующее доказательств. Ваши материалы касаются вещей, в которых (по крайней мере в некоторых) могут быть сформулированы математические теоремы (утверждения), которые нужно будет доказывать. Там, возможно, появятся и аксиомы. Поэтому Ваше многократное не по делу использование слова «аксиомы» звучит нарочито («Смотрите, какой я крутой»), а не для привлечения внимания к какому-то вопросу. Судя по карме и рейтингу Вы не заслуживаете такого мнения. Так что будьте осторожны в высказываниях.
Ну а теперь по существу Вашего ответа.
Первый аспект я изложил вначале.
Ваша вторая публикация отличается от первой, в которой первую главу Вы назвали «Знакомство и базовые принципы.» Для такой грандиозной задачи, на которую Вы замахнулись, первый подход более правильный. Хотя, конечно, и отдельный вычислительный блок во всей структуре должен присутствовать. Поэтому я промолчал по этому вопросу. Сейчас считаю, что структура, функциональный состав и назначения основных блоков должен быть разработан и обсужден. И возглавить этот процесс, по крайней мере на начальном этапе, должен автор.
Промахнулся - это когда пишешь ответ в окошке для нового комментария. Удалить совсем комментарий на хабре нельзя (ну, или я не знаю как это сделать), дублировать - плохо, а оставить в неподходящем окошке - значит не дать автору исходного получить уведомление об ответе. Приходится редактировать на какой-нибудь текст вроде "мимо", или "не туда", или "промахнулся".
По поводу аксиом - да, для моего изложения важно разграничить, где я говорю о формальных понятиях и свойствах формальных объектов, а где - о том, как все на самом деле. Аксиоматическая теория намного грубее реальности. Перекладывая реальность на на язык формальной теории некоторые черты явления сильно искажаются, другие - попросту игнорируются, как ненужные.
Завтра я надеюсь опубликовать следующую часть. Быть может ее содержание пояснит вам мой замысел.
Добрый день! Пропустил статью, поэтому комментирую с опозданием.
В целом фундамент заложен, но IMHO частично перегружен. Не уверен, что можно короче, если всё формально описывать. Но главное, чтобы хочется чтобы за этим обилием аксиом увидеть главные места и теорию.
В частности, зачем так много аксиом E*? Вполне можно обойтись E1 (константы), E2 (элементарные функции) и E8 (простой регистры). Если про остальные хочется упомянуть, то можно в качестве примера простых схем, которые можно построить из этих трех. Или (если встать на подготовленный математический фундамент) вместо E1-7 сказать, что внутри блока может быть любая булева функция (даже функция [0,1]ⁿ → [0,1]ᵐ). Аналогично более сложные регистры с синхронным сбросом/установкой/enable'ом описываются через простой (элементарный?). Тогда будет две аксиомы, каждая из которых свой краеугольный камень схем.
Конечно жизнь сложнее, и в библиотеках стандартных элементов любой фабрики сотни чуть отличающихся элементов. Но не думаю что эту сложность надо переносить в теорию / математическое описание. А достаточно двух базисных, из которых в качестве упражнений построить чуть более сложные.
P.S. Разработчик микросхем.
Спасибо за развернутый отзыв.
Да, формализмом я перегрузил немного. Уже после понял как проще все объяснить, скорее всего использую его в следующей статье. "Хорошая мысля приходит опосля"
По аксиомам группы Е: не требовалось минимальности набора, требовалось удобство. Сам набор выбирался так, чтобы прогнозируемая площадь кристалла для каждого из них была маленькой и одного порядка для вех. Включить произвольные булевы функции - значит сделать прогнозируемую площадь неограниченной. В таком случае нельзя будет оценить площадь просто пересчитав число элементарных блоков.
С уваженим.
Про минимальность. Про произвольные булевы функции - понятно. Тогда предлагаю сократить до AND, OR, NOT - пусть тоже излишнего, но всё же достаточно фундаментального. И будет правильная ассоциация с булевыми формулами в алгебре высказываний. И, наверное, какие-нибудь теоремы/факты из этой алгебры будут красиво перекликаться с Вашими рассуждениями.
Оценка площади будет тоже плюс-минус адекватна. Например, площадь одного MUX - как два элемента AND/OR. Да, не три, но в одном порядке. Для оценки тоже сгодится.
Для регистров - аналогично.
Просто мне (наверное испорченному математическим образованием ;)) понятно, когда берется минимальный набор. Когда нет, то возникает вопрос: почему именно этот, а не какой-то другой. И может надо что-то еще добавить? А что будет если убрать? И критерий выбора мне надо понять как можно раньше (даже до аксиом). Минимальность - понятный критерий. Взять все схемы с двумя входами и одним выходом - понятный. А взять мультиплексор и не взять трехвходовой OR - мне не понятно.
P.S. Можно зайти в объяснении со стороны транзисторов и построении элементарных схем из них, тогда за основу придется взять NOT, NAND, NOR (они и раза в 2 меньше, чем AND/OR). Но, это, видимо, совсем в сторону.
Скрытая логика была тпкой: "каждой твари по пере" для каждой видимой в начале фундаментальной задачи. Скажем, есть задача "управлять потоками" - возмем прямой обратный мультиплексоры, есть задача строть логику - традиционный для логики набор функций "и" "или" "не" "истина/ложь", для арифметики - очевидно нужен "+", "0" и "1", чтобы помнить - какие-то регистры. Да, наверное стоили сказать чуть больше про выразимость одних другими.
Понятно. Тогда вопрос: на какого читателя рассчитана книга? С каким научным багажом? Если считать, что на студентов 1-2 курса, только освоивших логику, то задачи "управлять потоками" им еще не понятны. В общем, IMHO перебор сложности на начальном этапе погружения в материал. И, главное, он для дальнейшего понимания материала не нужен.
P.S. Если считать, что читатель уже освоил языки программирования и компиляторы, то, наверное, можно говорить, что арифметические операции будут отображены в такие-то схемы, if-конструкции - в другие. Т.е. описывать одновременно и схемы, и язык программирования/описания схем (а-ля VHDL/Verilog). Только тогда не забыть четко проговорить отличие в семантики таких схем от принятых логических выражений и if-ов в обычных языках (C, Java, Python и т.п.). Но IMHO это более трудный путь.
P.P.S. В общем, я, наверное, повторюсь. По своему опыту не надо стараться внести всё в книгу/статью/диссертацию. Это утяжеляет книгу, не дает неподготовленному читателю понять суть, которая оказывается скрыта за многими деталями. IMHO.
В моем воображении книга должна быть понятна студентам начиная со второго курса и всем, кто не ниже их по бэкграунду. Про разный уровень для разных читателей мне теперь видится так: максимально просто основную часть каждой главы в виде идей и нестрогих формулировок без доказательств, чтобы заинтересовать незнакомых с темой и дать почувствовать вкус проблемы + дополнения в конце каждой главы с пометкой "можно пропустить при первом прочтении" для где все строго и математизировано.
Не туда
Многа букаф, а кристалл где?
1. В предшествующем комментарии я коснулся аксиом, которые представляют собой утверждения в теории, не требующие доказательств. Но чтобы доказывать теорию только на основе введенных аксиом – это что-то новое. При этом даже не сформулировав, что же предполагается доказать, т.е. не сформулировав саму теорию. Что рассматривается? Микроэлектронное устройство, на которое с помощью шин, портов подаются входные сигналы. Совершенно естественно ожидать, что если не будет поломок (дефектов) в вышеперечисленных элементах, то выходные сигналы МЭ прибора будут соответствовать ожидаемым. Какие здесь аксиомы? Какая теория доказывается?
Давайте я, следуя Вашей логике, на основе введенных аксиом попытаюсь доказать одно утверждение из теории познания. Будем считать, что если выполняются Ваши аксиомы Р1 – Р7, то это значит, что Бог есть. Все было хорошо, я даже собрался запустить проверку микроэлектронного устройства как сосед, сидящий справа от меня, предложил считать, что выполнение других аксиом (В1 –В5) должно соответствовать теории, что Бога нет. Исследовался элементарный двухвходовой логический элемент И-НЕ, функционирование которого совпало с его таблице истинности. Я был в шоке. Какая из теорий верна? Спасибо соседу слева, который сказал, что таким образом было доказано одно из утверждений диалектики Гегеля о «Борьбе и единстве противоположностей» (раз есть Бог, то должен быть и Сатана). Это несколько успокоило. А Вы как думаете? Аксиомы то у Вас есть, а где теория, к которой они принадлежат? Я её не нашёл.
В следующей публикации от 18.05 «здешние соединительные» аксиомы также используются, но для «теоретического» расчета времени задержек распространения сигнала. Даже приведены формулы (не очень понятно на основе чего полученные). Это уже кое-что. А то придется удовлетворяться Гегелем, который очевидно не был силен в математике.
2. Вводится в рассмотрение регистр. Это элемент последовательностного типа, имеющий в своем составе элементы памяти, основой которых являются триггеры. А их классификация обширна, количество типов еще больше (а может быть и меньше, в зависимости от точек зрения). При использовании триггеров в качестве элементов памяти (или Вы память не собираетесь рассматривать в «Алгоритмах на кристаллах"?) также достаточно много модификаций. Ну пусть это будет регистр – по одной из классификаций относящийся к функциональным узлам последовательностных устройств, а более точно – к так называемым цифровым автоматам. И как применить приведенные у Вас выражения к объяснению работы используемого, например, 4- разрядного параллельного регистра с однофазным входом и выходом типа 555ИР15?
Микроэлектронное устройство, на которое с помощью шин, портов подаются входные сигналы. Совершенно естественно ожидать, что если не будет поломок (дефектов) в вышеперечисленных элементах, то выходные сигналы МЭ прибора будут соответствовать ожидаемым. Какие здесь аксиомы? Какая теория доказывается?
1)Ваше предположение ошибочно: правильно (в соответствии с требованием размерностей и не более одного порта выхода на шину) соединив безошибочно работающие блоки можно добиться того, чтобы сигнал на выходе схемы не был 0 или 1, а сама схема сгорела ими потребляла электроэнергию как чайник (пример: закольцованный на себя блок "не"). Развитая в статьях теория дает четкие рекомендации насчет того, как не попасть в описанную ситуацию.
2) четырехбитный регистр (с/без портом синхронного сброса, с/без портом разрешения записи) - будет типичным составным блоком. Составные блоки появятся в ближайшей статье.
я не понял до конца.
четырехбитный регистр (с/без портом синхронного сброса, с/без портом разрешения записи) - будет типичным составным блоком. Составные блоки появятся в ближайшей статье.
к черту редактор комментарий хабра. Как выйти из списка?
САПРы проверяют схемы на функциональную ацикличность, сами они тоже генерируют приемущественно функционально-ациклические схемы. Свойство функциональной ацикличности позволяет дать оценки латентности схемы и связать латентность с глубиной.
Когда вы создаете новую схему под какой-то алгоритм, то наличие аксиоматической теории позволяет вам провести строгое математическое доказательство корректности и соответствия ее работы предполагаемому алгоритму. Без какой-либо, не обязательно моей, формализации такие рассуждения чреваты ошибками.
Аксиоматика позволяет расщепить проблемы на составляющие, ответь на вопрос какие предположения или технические решения к каким последствиям ведут. Теории универсальны: они не говорят чем должны являются вещи, они говорят, какими взаимными свойствами должны эти вещи обладать. Потенциально под одну теорию подпадает много разных физических (материальных) моделей. Например транзистор - это транзистор, а логический блок с функцией транзистора может описывать и транзистор, и лампу, и электромагнитное реле, и пневматический ключ. Теория логических схем обслуживает все эти случаи вплоть до проектирования схемы взаимосвязанных автоматических конвейерных линий на большом заводе.
Алгоритмы на кристалле. Глава 1: Вычислительная модель