Комментарии 106
К сожалению общий уровень технического образования со времен СССР снизился. Вот на таких примерах это видно объективно...
Х&Х - это вводный курс, он не претендует на доведение студента до трудоустройства на RTL-дизайнера (см. более подробный коммент ниже).
А что касается СССР, то советские учебники цифровой электроники не разбирали конвейеры и FIFO, поэтому даже если их вызубрить и доучить синтаксис верилога, работать в группе проектирования современного процессора, GPU или сетевого чипа студент не сможет. И знание SR-зашелки ему никак на интервью не поможет.
И конвейеры, и FIFO я встречал именно в советской литературе -- только за давностью лет уже не скажу, в какой. Плюс, более-менее устройство конвейерного проца расписано, по меньшей мере, применительно к ЕС-1050/1052, о чём надеюсь как-нибудь написать серию статеек -- но это уже не учебник, конечно, был.
Именно - это не был учебник. То, что я видел в советской литературе, был научпоп о конвейерах, объяснить словами, но не показать как делать руками. Учебники в лучшем случае заканчивались на конечных автоматах и последовательных процессорах (на основе схематики, синтез был изобретен только в 1988 году), после чего шел разрыв и в учебнике говорили о программировании (не проектировании) процессоров типа 8080.
Кроме этого, конвейер - это гораздо более общая концепция, чем конвейер в execution unit процессора. Например, в сетевых устройствах пакеты обрабатываются конвейерами, которые принимают их трансферы. В GPU по конвейерам блоков фиксированных функций идут сначала треугольники с координатам, а потом фрагменты (это в дополнение к конвейерам шейдеров). Конвейеры используются вместе с контролем потока данных с помощью двойной буферизации (skid buffer) и кредитными счетчиками итд - короче там целая кухня.
Если эту кухню в вузе не учить, а выпускать только студентов, которые умеют построить конечный автомат, их придется учить на рабочем месте, в условиях жестких графиков на выход массовых чипов и занятости старших инженеров. То, что они разобрались в RS-триггерах и timing violations в защелках, никак этому не поможет, так как RS-триггер перед ними не появится, а в реальных static timing analysis reports, которые они будут разбирать, будут критические пути между D-триггерами, составляющими конвейер, которы они так и не научились строить.
Похоже, особенно если это касается современных технологий и их практического применения. У меня сын съездил в Зеленоград, на один семестр по Верилогу, оказался единственным из группы который смог сдать работающую на ПЛИС курсовую.
Если собрать схему, состоящую из трех инверторов, в ВКПа, то получим такую же диаграмму, но имеющую иной вид сигналов (см. рис.8).
В чем иной вид сигналов? В том, что в книге фронты сигналов показаны как имеющие время нарастания?
При двоичной кодировке сигнала времени нарастания нет. Или есть? Может, я что-то не догоняю? :)
Но в реальной-то схеме есть. И разработчик реальной схемы не может его не учитывать, от него максимально допустимая тактовая частота зависит.
В реальной, да, есть. Но пока речь не идет о максимальной частоте, а лишь о логических схемах, оперирующих двоичной логикой, то этих фронтов нет. Ими пренебрегают. И правильно делают. На этом уровне есть только 0 и 1 и ни каких (!) промежуточных значений - тех же фронтов.
Но если необходимо учитывать фронты, то это уже должна быть другая книжка и кодирование сигналов будет уже не двоичным. В упомянутом учебнике для техникумов этому как раз посвящена почти его половина, т.е. импульсной технике.
В учебнике по схемотехнике фронты нельзя не учитывать. Понятно, что это разные уровни абстракции, но разработчик должен иметь представление, что там внизу.
Реальные схемы теперь в ПЛИСах. И у разработчиков заливших битовый поток и наступает jitter. Конечно критерии синтеза проверяются на реализованность, но в сложных системах как цифровые радиочастотные трансиверы, воплощение на железе приходиться отлаживать и отлаживать.
Реальные схемы теперь в ПЛИСах...
И что в ПЛИСах учитывают фронты?
Средства синтеза учитывают. С большей или меньшей степенью успеха.
Не только учитывают, static timing analysis это вообще овнова основ в плисоводстве. Без STA вы сможете сделать схему простейшего дешифратора, но вот схему многобитового суммутора уже не получится - она у вас просто не заработает на более-менее приемлимых частотах. Фабрика ПЛИС это такой же неидеальный аналоговый мир, как и все вокруг нас.
Я небольшой специалист но можно сказать что фронты учитываются в виде setup и hold задержек.
К своему удивлению обнаружил, что в нашем ЖД вузе эти особенности поведения комбинационных схем (у нас они назывались "состязания") объяснялись на хорошем уровне при том, что до сих пор применение цифровой электроники для систем ЖАТ не сильно распространено - почти все системы построены на электромагнитных реле.
И правильно делали. Эти "состязания" есть и в схемах на электромагнитных реле. Ключ он и в Африке ключ - будь то на транзисторе или реле ;).
Конечно есть, но всё же релейные схемы проектируются не как схемы с логическими элементами. Никто на реле отдельные "И", "ИЛИ" и прочее делать не будет. Так что да, состязания есть, но есть и свои тонкости. Для анализа работы релейных схем с учётом всех замедлений используют вот такие диаграммы
![](https://habrastorage.org/getpro/habr/upload_files/db0/baa/de2/db0baade2ba800c78bc81093e59f9791.png)
Конечно есть, но всё же релейные схемы проектируются не как схемы с логическими элементами. Никто на реле отдельные "И", "ИЛИ" и прочее делать не будет.
Ну, это далеко не так. Возьмем теорию того же Гаврилова М.А. А нынешнее программирование для ПЛК? Там до сих пор один из базовых языков - язык релейных схем. Да, при реализации могут быть свои тонкости, но на уровне логики принятия решения все можно описать и описывают, используя понятие идеального реле.
Релейные схемы в ПЛК это всего лишь аналогия, причем не очень удачная, предназначенная для того, что бы электрик (не электроник и не программист) смог быстро "запрограммировать" простой алгоритм управления производственным процессом. К цифровым схемам и синтезу это не имеет ни какого отношения, как и к электромеханическому прибору который принято называть словом "реле". И тут уже было верно замечено, реле (прибор) это катастрофически нестабильный, ненадежных элемент, который когда-то по чистой случайности использовался в цифровых схемах и был быстро заменент электровакуумными приборами. Рассматривать реле как идеальный элемент с двумя состояниями просто глупо.
Как человек, принимающий участие в разработке МПЦ, позволю с вами не согласиться.
Приятно видеть специалиста по своему направлению! С чем конкретно вы не согласны? Как я понимаю, с моими словами про то что большинство ЭЦ у нас релейные?
Большинство ЭЦ у нас релейные. Это бесспорно и это еще надолго. Но новые объекты идут практически полностью на объектных контроллерах с минимумом релейной схемотехники.
Да, я имел ввиду соотношение МПЦ и РПЦ на существующих станциях. Конечно, сейчас условную МПЦ-ЭЛ действительно очень активно проектируют. А вы, кстати, к какой МПЦ причастны? Я - с МПЦ-МПК работаю, и, конечно, хочу верить что в обозримом будущем получится уйти от использования релейных ЭЦ
Но адаптироваться к ее поведению при программной реализации автоматов не
так уж сложно. Во-первых, нужно считывать входной сигнал только один
раз и строго после переднего фронта тактового сигнала, а, во-вторых, выходной сигнал, как реакция на входной, устанавливать также один раз и до наступления
очередного фронта тактового сигнала. Так мы исключим весьма вероятную
метастабильность поведения автомата в пределах одного такта.
Погодите, но при чём тут программная реализация? Это же учебник по цифровой схемотехнике, а не по программной реализации конечных автоматов.
Погодите, а Вы разве не в курсе, что, если создается формальная модель чего бы то ни было (в форме того же конечного автомата), то ее реализация должна в точности ей соотвествовать? А какой будет реализация - программной или аппаратной принципиального значения не имеет. Ну, аппаратная будет быстрее. И только.
Аппаратная реализация автомата никогда, запомните это, никогда не будет на 100% соответствовать формальной (и программной) модели, как модель атомного ядра на 100% не соответствует реальному мироустройству. Формальная модель это астракция, сущность в головах людей. А аппаратная реализация - все эти фронты, глитчи, пограничные случае, глюки вызванные нестабильностью линий питания, температрные эффекты и прочее, прочее... По этой же причине ни одна верификация не даст Вам стопроцентного ответа на вопрос "соответствует Ваш дизайн спецификации или нет" - пока "в натуре" не испытаешь - не поймешь. Но это не значит, что верификация не нужна, совсем на оборот!
Аппаратная реализация автомата никогда, запомните это, никогда не будет на 100% соответствовать формальной (и программной) модели
Ну это совсем не так. А потому не ставьте телегу впереди лошади. Реализация делает реальной ту модель, которую "в головах" создают люди в форме блок-схемы, автомата и т.п.. И искуство разработчика заключается в том, чтобы довести реализацию до того состояния, чтобы она на 100% соотвествовала задуманному "в голове". И верификация служит этому, чтобы выявить все косяки и довести реализацию до 100%-го совпадения. Чтобы в идеале, глядя на некий "черный ящик" нельзя было отличить аппаратную реализаци от программной. Вот что надо помнить и запомнить.
Так ведь подраздел 3.5 главы 3 посвящён не созданию формальных моделей в форме конечных автоматов, а особенностям реализации последовательностных схем на реальных D-триггерах, которые обладают реальными временными характеристиками. Получается, что претензия в основном к смешению уровней абстракции?
Реальные временные характеристики не должны влиять/искажать работу модели. В классике рассматривают реализацию не только на D-триггерах, но и на T- и RS- триггерах. И как-то временные свойства этих элементов не влияют на конечный результат. Или, скажем так, такого влияния быть не должно. А особенности могут быть.
Так вот чтобы этого влияния не было, необходимо понимать, насколько эта модель вообще реализуема на данных элементах с данными временными свойствами, а точнее - какие временные свойства будут у корректной реализации.
Вы это, безусловно, понимаете, но мне в таком случае непонятна претензия к конкретному подразделу книги. Ведь читатель тоже должен это понять.
Я претензий не предъявлял. Если реализация на D-триггера в точности соотвествует формальной модели автомата, то какие могут быть претензии. По мне спорны "терки" вокруг переднего фронта синхросигнала. Я согласен, что реальный сигнал должен быть стабильным в пределах апертурного времени. Но только как Вы сможете указать "обезъяне", чтобы она держала сигнал стабильным? Возьмем, например, дребезг кнопки. Как Вы сможете указать ей, чтобы она не дребезжала? ;) Вы можете только как-то изнутри игнорировать этот дребезг, например, поставив задержку, фильтр или что-то еще. И все! Изменение входного сигнала от Вас не зависит. Хоть трижды объявляйте необходимость стабилизации входного сигнала. Ей (кнопке, обезьяне и т.п.) плевать на Ваше желание - они будут себя вести как им заблагорассудится. Так что претензий к реализации модели нет. Пока нет :) А вот к пожеланию разработчика иметь стабильный сигнал в течение аппертурного времени - есть. Они необоснованны. Ишь чего захотел - чтобы "обезъяна" его слушалась! :).
Ни SR-зашелки / RS-триггеры, ни T-триггеры (за особым исключением очень редкого low-power счетчика, подтверждающим правило) не возникают в реальной жизни front-end RTL designer-а (проектировщика на уровне регистровых передач) в электронной компании, проектирующей ASIC-и. Тем более оно не возникает в жизни верификатора (Design Verification engineer).
Это все можно без потери для производства просто пропустить вместе с JK-триггерам или упомянуть в порядке научпопа. И сразу перейти к D-триггерам, из которых собственно и состоит 99% элементов состояния в ASIC и FPGA (остальной 1% идёт на D-защелки для экономии энергопотребления и особых случаев latch array и time borrowing которые первые 10 карьеры юному инженеру не понадобятся).
А вот с D-триггером нужно расписать детали timing analysis - его фронты, skew, slew (задержку изменения фронта), clk-to-q, setup, hold, метастабильности кратко итд).
Реальные временные характеристики разумеется необходимы и в Харрисах описаны (propagation delay, contamination delay, clk-to-q... ) В разделе "временная дисциплина".
Если слишком долго задерживаться на тайминге rs, t-триггерах и jk, то не останется времени семестра для конвейеров, контроля потока данных, очередей - и получится индивидуал, который сможет говорить , но не сможет работать в современных условиях, когда многие вещи абстрагированы с помощью использования библиотек стандартных ячеек (ASIC standard cell library) и автоматического статического анализа тайминга схем из d-триггеров и облаков комбинационной логики
Не надо долго. Надо правильно. Тут вскрикнули - триггер не генерит! Да, реальный не генерит. А почему, если формально он может генерить? А известно ли "студенту", что при переключении триггер обязательно перейдет через запрещенное состояние? Что нужно делать, чтобы эта помеха не привела к сбою. Все это можно объяснить просто, доходчиво и времени займет совсем немного. Но тогда "студент" не будет "голосить" - триггер ни когда не генерит! Генерит и еще как :)
Студента пока он студент надо учить. Учить думать. А не тупо его точить, как карандаш под конкретную тему для конкретных фирм. Кто умеет думать и "правильные книжки в детстве читал" быстро разберется с любой темой. Не надо только кричать - времени нет, денег нет, конкуренты душат! Мы под эти крики развалили всю нашу науку. А за наукой и практику. Но зато научились точить студентов для западных фирм. Тираж книжки, которую я купил - 40000 экз. Предыдущий вариант - еще 41000. А какой тираж у книги Х&X?
Сразу после того, как русский перевод X&X выложили на сайт Imagination Technologies в 2015 году, ее только официально с регистрациями скачали 10 тысяч человек. Реальная цифра гораздо больше, потому что в первые два дня регистрация была с глюком (из-за чего надо было регистрироваться два раза), после чего люди стали качать не с сайта Imagination, а с пиратских сайтов, которых уже в первый месяц было больше 30 сайтов (британский менеджер Imagination спрашивал у меня нельзя ли им разослать емейлы чтобы убрали, я ему объяснил что в России это не работает).
*** А известно ли "студенту", что при переключении триггер обязательно перейдет через запрещенное состояние? ***
Запрещенный уровень упомянут еще первой главе, и при описании работы D-триггера указывается, что он переключается не мгновенно, есть clock-to-q.
![](https://habrastorage.org/getpro/habr/upload_files/04b/eb4/68f/04beb468f37902b9b5fb4e12b8b8854b.png)
![](https://habrastorage.org/getpro/habr/upload_files/e4c/4e8/fc0/e4c4e8fc0aa53f9cfe27897edd3b766e.png)
*** Что нужно делать, чтобы эта помеха не привела к сбою. ***
Это гарантируется конструкцией ячейки standard cell library, на которые отображаются логические D-триггеры во время синтеза. Метастабильность может прийти только из двух источников: 1) внешние сигналы (это есть в X&X)
![](https://habrastorage.org/getpro/habr/upload_files/4ba/b71/5fe/4bab715fe0f2c1852ad99ecefc83ea24.png)
2) пересечение тактового домена (этого в X&X нет, но это более продвинутая тема, которую стоит рассмотреть уже после того, как студент существенно набьет руку на схемах с одним тактовым сигналом).
*** Кто умеет думать и "правильные книжки в детстве читал" быстро разберется с любой темой. ***
Что значить "быстро разобраться"? По-хорошему даже со студентом олимпиадного типа надо разбирать конвейеры, очереди, многобанковые памяти, арбитры и другие микроархитектурные темы месяцы. Причем сам он будет косячить - например делать дизайн с половинной пропускной способностью, потому что будет интуитивно думать, что в скажем в AXI stream сигнал ready возникает в ответ на valid.
*** Но зато научились точить студентов для западных фирм ***
Требования к инженерам обсуждаемых позиций (а значит и студентам) в российских компаниях Syntacore / Ядро, Байкал Электроникс, НПО Элвис, КМ211, МЦСТ, НИИСИ и других - не отличаются от требований к инженерам на таких же позициях в Apple, Samsung, NVidia, AMD итд. Они используют один и тот же синтез от Synopsys, Cadence, Xilinx, Altera, а в открытых проектах Open Lane.
Даже Вы меня не поняли, Юрий. А что тогда говорить о студентах? Речь совсем о другом "запрете". У триггера два выхода - прямой и обратный. И почти нигде не доводят, что при переключении из одного устойчивого состояние в другое на его выходах появляет кратковременно запретная комбинация - 1-1 (для триггера на И-НЕ) или 0-0 (для триггера на ИЛИ-НЕ). Кстати в Х&Х об этом тоже кажется ни слова?
У D-триггера мы смотрим только на один выход и этого запретного для RS-триггера состояния мы не видим.Т.е. проблема будет, если мы напрямую в схеме используем RS-триггер и оба его выхода.
И при переключении D-триггера, как его реакция на изменение входного сигнала, будет просто задержка на выходе, а не та "болтанка", которую, как понял, изобразили в книге, назвав ее метастабильностью. Это другое.
Понятно. Так как эти вещи все равно устаканиваются в течение такта, то к моменту апертуры записи в следующий D-триггер будет чистое значение. Если мы конечно используем стандартную методологию - использование RS-триггеров в нее не входит.
Для расжевывания таких эффектов есть более сфокусированые на физических эффектах книги, например https://www.amazon.com/CMOS-VLSI-Design-Perspective-Hardcover/dp/B011DAYZTC CMOS VLSI Design: A Circuits and Systems Perspective 4th edition by Weste, Neil, Harris, David (2010)
Про нее тоже была идея ее перевести, но у нее меньше возможный рынок.
Вячеслав, я в 2014 году начал эту тему с переводом Харрис & Харрис. Я заметил вашу статью пять минут назад, пока ждал Юбер, и мне ваш текст понравился (я его перечитаю внимательно). Но пока я еду в юбере, два кратких пояснения:
1.Харрис & Харрис - это вводный курс, если студент изучит только его, он интервью в крупную электронную компанию (Apple, NVidia, Samsung итд) не пройдет. Но не потому что он не знает деталей SR-защелки (это для реальной работы по ASIC дизайну чипа в телефоне не нужно), а потому что не знает FIFO и арбитров, которые в Харрисах не рассматриваются, но которые мы спрашиваем на интервью в Самсунге, как и другие электронные компании.
2. У меня только что вышла статья в https://fpga-systems.ru/fsm : Панчул Юрий. "Что умеют и не умеют писать на SystemVerilog для ASIC и FPGA американские студенты?" В ней более фундаментальные проблемы образования, чем то, что пишете вы. Студенты не умеют решать микроархитектурные задачки, и Х&Х им в этом не поможет.
Юрий, я зашел на этот горе журнал в поисках Вашей стетьи - там кроме заголовков ничего нет. Где статья ? Несите её к нам сюда скорей!
Студенты не умеют решать микроархитектурные задачки, и Х&Х им в этом не поможет.
Студент и не должен уметь решать все. Но он должен иметь базовое образование, которое затем ему поможет решать все и разобраться во всем. И главное поможет общаться с другими на общем и понятном им языке.
Вводный курс должен вводить студента в это самое базовое образование. А он в H&H видит пример на базе автоматной модели, но при этом ему не дают формального определения автомата. Дело доходит до того в книге граф автомата обзвали таблицей переходов. Может, правда, это опечатка? Но если специалист подобное пропускает, то ... куда он заведет студента? Правда потом называют диаграммой переходов. В правильных же книгах дают сначала определение автомата, потом рассматривают формы его описания - таблица, граф, матрица и т.д. Чтобы все это понять не нужно сверхзнаний. Это и есть вводный курс. В автоматы. А уж потом примеры - светофор и т.п.
В целом же подобный вводный курс (как бы выразиться помягче) все равно, что заниматься алгеброй, не освоив при этом арифметики... Это не значит, что в целом книга такая. Но некоторые ляпы явно "режут глаза".
Вы случайно не попутали два совершенно разных курса "теория формальных языков, грамматик и автоматов" и "цифровая схемотехника" ? Первый - сугубо териотический, больше с упором на академическую науку (пища для докторов и их аспирантов). Второй - чисто практический, для разработчиков.
Нет не попутал. Глушков, Баранов, Мелихов и особенно Майоров и Новиков тд. и т.п. - это все про синтез цифровых схем. Или Вам эти авторы не известны? Формальные языки - совсем другая тема.
Нет конечно, на кой мне этот шлак в голове, хватило ТФЯ в вузе. Но ради интереса я загуглил:
В. М. Глушков. "Синтех цифровых автоматов", физматиз. 1962.
Учитывая, что вся теория по синтезу была создана в 80-х с приходом программируемых матриц и изобретением HDL, мне даже стало любопытно о чем там мог писать товарищ Глушков в 1962 году. Я выкачал PDF и немного полистал. Короче, это теория абстрактных автоматов, причем книга написана в лучших советских традициях - куча формул без обьяснения назначения переменных, читать и воспринимать информацию крайне тяжело, более сложного и запутанного обьяснения атоматам Мура и Мили найти невозможно. Практическая ценность этих трудов - собирать пыль в музее.
Честно говоря, не совсем понимаю в чём состоят претензии автора статьи к материалу H&H. Особенно не понимаю пассаж про фронты сигналов. Ведь фронты это весьма важная часть даташитов на цифровые микросхемы, и если разработчик живет в своём сферическом вакууме где есть только "0" и "1" (т.е. игнорирует Tsetup и Thold), то гнать таких в шею.
Книгу H&H я прочитал по совету Юрия Панчула и у меня к ней есть своя претензия. Состоит она в том, что в книге не описаны базовые структуры которыми оперирует современный разработчик, как то: PLL, FIFO, сдвиговые регистры и конвейеры. Так же в книге нет ни слова про тактовые домены и проблемы связанные с переходами между ними. Редкое современное изделие (я имею в виду СБИС или изделие на ПЛИС) обходится без таких вещей. И да, в дедовские времена всего этого не было и в советских вузах не преподавалось никогда. Так, что тезис "в цифровой схемотехнике нет ничего нового" тоже очень сомнителен.
Тем не менее, книга Харрисов годная! Материал в ней подан пусть и кратко, но доходчиво, с примерами и заданиями. И иллюстрации очень даже правильные - с фронтами! Особенно книга полезна для программистов, которые хотят хоть на чуток вникнуть в происходящее под капотом их гоночного боллида.
PS: Простите мне моё невежество, но что такое "моделирование ВКПа" ?
Честно говоря, не совсем понимаю в чём состоят претензии автора статьи к материалу H&H.
Это нормально. Не все доходит с первого раза. Перечитайте и, возможно, понимание придет.
А по ВКПа см. в списке литературы [5].
В [5] находится ссылка на Вашу же статью, но про другое. В той статье термин ВКПа упоминается почти в самом её конце и толком не разьясняется. Но я догадался, что это какая-то среда визуального программирования FSM (конечных автоматов), а вся Ваша та статья про то, что программирование FSM нуждается в еще одном универсальном языке программирования (тушите свет!). От прочтения Ваших статей у меня возникло ощущение, что Вы слишком долго засиделись в академической среде и Вам срочно требуется свежий воздух.
Ну и коментарий к той статье, дух которого я полностью разделяю:
Понятно. Если применяется только в ваших игрушках, то к чему этот высокий штиль и академический формализм?! Ощущение от вашей статьи такое, как будто читаешь нормативно-правовой акт: хочется по-быстрее закрыть, чтобы не сойти с ума. Если хотите разжечь интерес к теории автоматов и практике, нужно проще излагать для широкой публики.
PS: Гипертекст придумали в том числе и для того, чтобы не морочить читателю голову длинным списком литературы. При чтении Вашей статьи я замаялся крутить ролик у мышки постоянно бегая в список и обратно.
Действительно, - генерит.
Нет, RS триггер не генерит.
Зря Вы так резко ;) Не верите мне - найдите хотя бы книжку Фрике К. Вводный курс цифровой электроники. Может он Вас переубедит. Такие вещи надо знать и понимать.
Я не читал книгу уважаемого Фрике К., но знаю, что, например RS триггер, созданный на элементах И-НЕ при подаче входных сигналов 1-1 будет сохранять предыдущее состояние, а при подаче на вход сигналов 0-0 на выходе даст 1-1 и никакой генерации не будет.
Забавно то, что автор статьи сначала пытается доказать, что переходные процессы в цифровых схема (фронты) это все туфта и их не нужно учитывать совсем. А потом вдруг вспоминает, что при определенных условиях и бистабильная ячейка - не ячейка, а генератор. Кино и немцы. :)
Мне кажется, что интересы автора лежат в области построения тех самых формальных автоматных моделей, в которых переходные процессы, присущие моделируемой системе, предлагается представлять в виде задержек (пример с RS-триггером), а вопросы физической реализации модели автора интересуют постольку-поскольку.
А Вы знаете, что переключении триггер переходит обязательно через запрещенное состояние? А это источник помех в схеме..
А Вы почитайте. Не помешает. Особенно обратите на комбинацию, когда после 0-0 на входы подается 1-1. Такая последовательность и провоцирует генерацию.
Что касается D-защелок / D-latch, то из педагогических соображений их стоит в вводном курсе вообще объявить ошибкой и просто объяснить как их избегать (не писать 'always_comb if (a) b = c" что порождает D-защелку, а всегда внутри always_comb или ставить 'b = d; if (a) b = c", или ставить 'if (a) b = c; else b = d".
По-хорошему, их стоит вводить при объяснении экономии динамического энергопотребления в контексте конструкции для генерации gated clock, уже после того, как студенты усвоят, как проектировать не только конечные автоматы и конвейеры, но и простые процессорные ядра.
То есть это следующая стадия, когда базовая методология проектирования с помощью d-триггеров и комбинационной логики у них в голове уже устаканится.
Если же вводить ее рано, то они эти D-защелки просто забудут (то есть бессмысленная трата времени семестра) или у них образуется каша в голове и им будет труднее усваивать те же конвейеры и другой непосредственно полезный материал.
Особые случаи использования защёлок (time borrowing, latch arrays вообще имхо должны быть вне базовой вузовской программы, так как они используются очень редко, но сбить фокус могут конкретно
Прочитал весь текст. Сухой остаток: если смотреть с позиции максимально эффективно натренировать молодого инженера для трудоустройства в ASIC или FPGA, то по моему мнению:
Бистабильные элементы и циклические генераторы можно пропустить.
D-защелки перенести в более продвинутый курс, где будет объяснение экономии динамического энергопотребления с помощью latch-and-gate примитива который генерит тактовый сигнал только когда блок чем-то занят. В вводном курсе про D-защелки говорить только как их избегать.
Метастабильности рассматривать только для D-триггера, сообщить как устранять метастабильность для сигнала из внешнего мира (пропуская его через два или три D-триггера ), показать формулу матожидания времени сбоя, потом вспомнить снова в курсе после вводного, когда речь зайдет о пересечении тактового домена.
Об rs-триггерах сказать вскользь в порядке научпопа.
Объяснить как работает алгоритм статического анализа тайминга
Упомянуть время фронта тактового сигнала (slew) в дополнение к задержке из-за разницы распространения тактового сигнала (skew).
Про inertial и transport delay можно объяснить факультативно, по статье о моделирования из от Cliff Cummings
Тренировать молодого инженера надо на предприятии. Там должна быть своя школа. В учебном заведении нереально натренировать практическим вещам, я бы сказал априори.
В современном мире на предприятии тренировать студентов некогда и некому - люди знающие и имеющие опыт заняты делом, любое отвлечение их от производственного процесса чревато проигрышем в жесткой конкурентной среде. Но многие крупные предприятия так и делают - строят свои учебные центры. Вопрос в том, что делать нам, тут и сейчас в условиях когда нет ни преподавателей, ни опытных наставников, а у выпускника в голове из арсенала в лучшем случае Булева алгебра и теория автоматов.
Тогда чем они занимаются в вузе? Учат только совсем какие-то простые вещи типа как спроектировать мультиплексор + случшают научпоп о сложном? Или полгода рассусоливают математику вычисления MTBF (среднестатистического времени между сбоями), при том, что про это две строчки в тысячестаничной спецификации на GPU?
Что за фигня, когда студентка-отличница у меня на интервью может поговорить словами про алгоритм Томасуло (структуру для конвейера суперскалярных процессоров), но ставится в тупик вопросом построить статический конвейер для вычисления формулы √(a + √b), если у нее есть в качестве черного ящика конвейерный подмодуль для вычисления квадратного корня. Почему они слышали про сдвиговые регистры и FIFO, но не знают зачем это нужно и все пытаются конечным автоматом делать?
Простым вещам можно научить за два месяца, а научпоп можно в отпуске на пляже читать. Что они делают остальные 4-5-6 лет?
Слава богу, бывают студенты, которые делают в вузе самостоятельные проекты, а также более качественные преподаватели, в штатах - в MIT на курсе 6.111, который уже много лет хороший а в России - МИЭТ, которые это улучшают с другими на Школе Синтеза Цифровых Схем.
Не важно чем занимаются, специфика возраста студента не позволит выйти в вузе на производственный уровень: этот уровень просто-напросто отфильтруется мозгом как что-то чужеродное. К производству надо привыкать, причем очень постепенно.
По моим ощущениям, отучись я сейчас в радиотехническом вузе по второму кругу, я бы по другому воспринимал ту же, например, схемотехнику, электронику или антенны и РРВ. Хотя мат. анализ, вероятно, пропускал бы либо ходил для галочки, потому что во время обучения у меня был перекос в математику. Опыт приходит с годами, и правы те, кто говорят что развитие идет по спирали. Кстати, то, что в советское время учились в вузах после армии, это было очень хорошо.
Теперешних выпускников вообще надо брать без особых собеседований: хочет работать, так надо с радостью брать и натаскивать специфическим вещам. Я помню как у меня спросили что-то типа ветровой нагрузки на параболические антенны... сейчас смешно, а тогда и не знал что ответить. Сотрудники компаний как бы витают в своих облаках, студенты - в своих и область пересечения довольно-таки мала. В вузах учимся 5 лет, в компаниях - всю оставшуюся жизнь :)
Да, конечно, есть студенты исключения, своего рода таланты. К преподавателям вузов (по крайней мере к взрослым и состоявшимся) я претензий не имею вообще - глядя ретроспективно понимаешь, что всё было очень даже ничего.
*** Теперешних выпускников вообще надо брать без особых собеседований ***
Даже если брать бесплатных интернов, то для получения от них толка нужно прикрепить к ним старшего инженера, который был их учил. И учить с нуля многим областям просто долго, а интерны - явление временное.
Что касается не интернов, а инженеров на джуниор позиции, то тут есть очевидное ограничение - деньги. Ему сразу надо платить более 10 тысяч долларов в месяц в американских условиях. Если он не знает ничего из того, что нужно для работы, и его учить год, то потом он просто уйдет на лучших условиях в другую компанию, где его уже ничему будет учить не нужно. Итого - компания теряет сто-двести тысяч долларов (вместе с бенефитами), время старших инженеров, и мало того что не получает ничего, так еще и не было возможности интервьировать других людей.
Держать богадельню на 100 человек на зарплатах, из которых какой-то толк будет от 10 и только 1 станет суперстар? С учителями для них из старших инженеров? Это очень неэффективно, лучше повысить эффективность вузовских программ, в которые включить обязательный опыт участия в открытых проектах, по которым видно способности человека.
Тогда чем они занимаются в вузе?
Признаюсь, что в нынешнее время и для меня это загадка ;)
Почему они слышали про сдвиговые регистры и FIFO, но не знают зачем это нужно и все пытаются конечным автоматом делать?
Вот тут тоже есть вопросы, а, может, и проблема. Я тоже слышал и про сдвиговын регистры и FIFO, но, чесслово, не могу представить, как бы я алгоритмы выражал через эти понятия. Вот с автоматами - проблем нет совсем. Нет, конечно, в каждой области есть своя специфика, но как-то я не могу представить синтез цифровых схем совсем без автоматов. Да и Х&Х им много внимания уделяют. Если бы не они (автоматы то есть) я бы и читать ее не начал.
Вы, Юрий, много внимания уделяете этим вещам, но к автоматам, как мне кажется, у Вас негативное что-то проскакивает :(
Еще раз. Нет, конечно, можно гипотетически представить, что можно алгоритмы выражать, используя FIFO и что-то еще. Но я проектированием процессоров не занимаюсь, я их использую, создавая алгоритмы. И тут без автоматов уже мне не прожить, а без FIFO - на раз :) Может, устарел, а, может, чего-то не понимаю... :(
Вот и сейчас, кровь из носу, мне очень бы хотелось увидеть автомат для упражнения 3.29 из книги и диаграмму. Вот какую бы студенку привлечь, чтобы помогла? Просто автомат и просто диаграмму. А потом уж думать, как приладить сюда сдвиговый регистр или FIFO. Хотя мне просто автомата - за глаза. Как той Вашей студентке. Тут я скорее на ее стороне.
Да, кстати. У меня был когда опыт написания конвейерной сортировки. Даже статья в журнале была на эту тему. Там же - сортировка на базе философов Дейкстры. Веселый был эксперимент, интересные результаты... ;) Давно только это было :(
Да, еще. А Школе Синтеза пользуются трудами Баранова С.И., Майоров-Новиков (Глушков или Мелихов, может, действительно будут чуть сложноваты для "школяров") или чем-то аналогичным? Но нашим - советским, российским. Или все это за пределами Школы?
С автоматом тут все банально. Они конечно применяются на каждом шагу, но если бы сделать весь дизайн только на конечных автоматах, без конвейерной обработки, то пропускная способность была бы в тысячу раз медленнее. Вместо того, чтобы роутер принимал бы смесь из трансферов кучи пакетов и обрабатывал бы их комбинацией конвейеров и FIFO, он бы их брал по одному и медленно ссначала брал один трансфер, потом другой, и только после окончания брал бы другой пакет. Это чисто как на конвейере автомобильного завода - новая машина сходила бы не каждые несколько минут, а каждые несколько дней.
То же самое с компьютерной графикой - в шутерах монстры отрисовывались бы медленно и печально.
Конечно конечные автоматы применяются - например если треугольник не влазит в экран и при этом большой, что его долго растеризовать и нельзя выбросить, то для этого есть несколько параллельно работающих конечных автоматов, которые его порежут, посчитают новые координаты осколков итд. Но это случается раз в тысячу треугольников.
То же самое что и сетевыми пакетами - большинство простых пакетов нужно обработать целой группой, но иногда бывает что-то нетривиальное, что нужно отдать большому конечному автомату или процессору.
На этом построены все современные дизайны, как скажем в 1970-е годы был широко распостранен микрокод (который, как выяснилось в 1980е, трудно конвейеризировать)
Про упражнение посмотрю потом
Юрий, получил уведомление о Вашем ответе на почту, но почему-то его нет здесь. Ни моего коммента, ни Вашего ответа к нему. Дикий какой-то случай. Первый раз с подобным сталкиваюсь.
Написал Вам в личку, но хочу подстраховаться и здесь. Ясно, что Вы покритиковали мою диаграмму и предложили свое решение. Но в автомат на Верилоге мне сложно вникнуть, да и наглядность не та. Хотелось бы попроще и понагляднее, чтобы избежать путаницы. Пусть это будет даже не граф автомата (но это был бы идеальный вариант), но хотя бы в форме таблиц переходов/выходов (типа табл. 3.1 в книге). Кодирование состояний и выходов не нужно.
*** Я тоже слышал и про сдвиговын регистры и FIFO, но, чесслово, не могу представить, как бы я алгоритмы выражал через эти понятия. Вот с автоматами - проблем нет совсем. ***
Вот только что вышла моя статья в сборнике, там про конвейерные вычислители, правда самое начало этого. И про студентов:
https://fpga-systems.ru/fs_fsm/state_0/fsm_state_0.pdf
Спасибо! Даже не вникая, а просто просмотрев материал, скажу одно - впечатлен!
На мой взгляд, именно подобные проекты должно обязательно поддерживать государство, а не просто, судя по последним заявлениям, вливая миллиарды в некие "генеративные нейронные сети". Хотя, как мне кажется, не факт, что и это произойдет, т.к. попахивает очередным "распилом" :(. У меня еще на памяти попытки создать "российскую операционку"...
Так что, еще раз большое спасибо за ссылку! Проштудирую обязательно :)
Спасибо, очень интересно. Я думаю это должно быть нормой в рамках курсового проектирования, тем более в топовых учебных заведениях.
Можно также заметить, что любая схема из нечетного числа инверторов представляет собой генератор прямоугольных импульсов. В том числе состоящая из одного инвертора.
В только одном инверторе будет генерировать в инверторах с триггером Шмитта, но не будет генерировать в простых линейных инверторах на 2-х КМОП-транзисторах (561лн2 или 4049/4069ube).
Также могут генерировать буферизованные 4049b.
Между прочим. На стр. 430 в книге прямоугольные (?) сигналы. У меня (я повторил схему) - тоже :)
Рис.4.1 (стр 430) в ВКПа
![](https://habrastorage.org/getpro/habr/upload_files/6b5/550/391/6b55503917ac6de43bf0867b1d699d29.png)
По ходу захотелось пройти собеседование и попытал на вскидку решить Упражнение 3.29 (стр. 409 в H&H). Привлек диаграммой сигналов. Быстренько набросал автомат и получил диаграмму.
Диаграмма для примера 3.29
![](https://habrastorage.org/getpro/habr/upload_files/e95/950/bed/e95950bed324392725728837af1f530d.png)
Даже не знаю - прошел ли тест?... :) Может тоже кто-то попробует? Особенно из фанатов H&H. Хотелось бы увидеть и автомат, и диаграмму. Свой автомат пока не буду показывать. Но обещаю не изменять. Покажу при сравнении. Пока стесняюсь :) А вам - слабо?
Вы говорите про это задачу?
![](https://habrastorage.org/getpro/habr/upload_files/ff1/ed6/fcb/ff1ed6fcbbae03cc9ff672b0f5e6d764.png)
Ваша диаграмма не выглядит верной.
Значение A в такте 1 (выделено синим) равно 0.
Оно записывается в D-триггер в момент 1-красный, CLK меняется с 0 в 1.
Значение A в такте 2 переходит из 0 в 1. Момент перехода я отметил как 2-красный.
Значение B весь 1-й и 2-й такт равно 0.
Поэтому Z (выход автомата Мили) будет равен A1 & A2 = 0 & 1 = 0.
Z станет 1 только в третьем такте, когда A2 & A3 = 1 & 1 = 1
![](https://habrastorage.org/getpro/habr/upload_files/6fc/349/79f/6fc34979f3ef2049e3a20a623761902f.png)
Здесь достаточно конечного автомата с двумя состояниями, который на верилоге описывается так:
module hh329
(
input clk,
input rst,
input a,
input b,
output z
);
logic a_r;
always_ff @ (posedge clk)
if (rst)
a_r <= '0;
else
a_r <= a;
assign z = b ? a_r | a: a_r & a;
endmodule
Который симулируется вот с такими диаграммами:
![](https://habrastorage.org/getpro/habr/upload_files/22f/f3b/a7c/22ff3ba7c53a0aff2801a3e1350db4b6.png)
На вот таком тесте:
module testbench;
logic clk, rst, a, b, z;
hh329 dut (.*);
initial
begin
clk = '0;
forever
# 500 clk = ~ clk;
end
initial
begin
$dumpvars;
rst <= '1; @ (posedge clk);
rst <= '0; a <= '0; b <= '0; @ (posedge clk);
a <= '1; b <= '0; @ (posedge clk);
a <= '1; b <= '0; @ (posedge clk);
a <= '0; b <= '0; @ (posedge clk);
a <= '0; b <= '1; @ (posedge clk);
a <= '1; b <= '1; @ (posedge clk);
a <= '1; b <= '1; @ (posedge clk);
a <= '1; b <= '1; @ (posedge clk);
$finish;
end
endmodule
Я попробовал диаграммы привести к такой же фрме как и у Вас, Юрий. Я только добавил в них диаграммы для состояний автомата. И Вот что получилось.
Даграммы сигналов
![](https://habrastorage.org/getpro/habr/upload_files/d2f/ad7/92f/d2fad792fc0b91aa764a2a93ea3daed3.png)
Автоматная модель в форме графа
![](https://habrastorage.org/getpro/habr/upload_files/53c/e72/061/53ce72061a0c43bf053b7eb29aff6bd3.png)
Формально работа автомата не привязывается к длительности дискретного такта (апертурному времени). Выше на диаграммах работает один и тот же автомат, но только в разном дискретном времени. Диаграммы, кажется отличаются, но на самом деле это диаграммы одной и той же модели, но в разном дискретном времени. Нижняя диаграмма - это максимально быстрая реализация. На верхней диаграмме - это результаты замедленной работы модели. Таким образом, обе диаграммы верны, хотя внешне и отличаются.
Если все же нужна привязка к синхросигналу, то его также нужно ввести в условия переходов автомата. Это приведет к тому, что на каждый переход нужно будет добавить логическую переменную, например, x3) CLK?. Но, кстати, на вид диаграмм это почти не скажется. Но, скорее всего, как показало тестирование, на виде диаграмм это не скажется. Так, быстрая (нижняя) такой же и останется.
Синхросигнал - это особенность выбранного подхода к аппаратной реализации. Думаю, вполне можно обойтись без него. Нужно только будет правильно кодировать состояния. Попробую это показать в обещанном продолжении. "Плюсов" набралось столько, что уже хочешь не хочешь, но писать придется :)
Да, синхросигнал приведенный на моих диаграммах - чисто декоративный (чтобы была визуальная привязка к дискретному времени). Нужное дискретное время модели задается средой.
Вы нарисовали апертуру как целый такт. Но апертура - это не такт. Это период вокруг фронта тактового сигнала - немного до (setup), немного после (hold). В это время данное на входе D у D-триггера должно быть стабильным - ta:
![](https://habrastorage.org/getpro/habr/upload_files/97c/062/3a1/97c0623a1e2d029c71a9e585e73a565f.png)
https://courses.cs.washington.edu/courses/cse467/11wi/lectures/RegisterTiming.pdf
Далее, две диаграммы, которые вы показали, не эквивалентны. Потому что на второй Z сдвинуто на целый такт. Это не простой сдвиг относительно clock edge для propagation delay.
Как clock может быть декоративным, если в условии задачи в явной форме прописано, что делается операция между A которое считано на clock cycle N и A которое считано на clock cycle N-1. Если поменять clock cycle, поменяется и поведение.
И как state может меняться посередине такта (clock cycle), если state записан в D-триггере? Или вы имеете в виду новый state?
Вы нарисовали апертуру как целый такт. Но апертура - это не такт...
Я сознательно пошел на это. Безусловно, по определению апертура - то, что Вы говорите. Мне удобно "сдвинуть" ее во внутрь такта. Так оно больше соотвествует и формальному определению автомата и программной реализации. Точнее так, мы должны следовать формальному определению. А формальное определение во внуть такта не заглядывает. Поэтому, с одной стороны, можно считать, что в пределах такта все стабильно (входные сигналы). А, с другой, стороны, поскольку нет от формальной модели каких-то указаний, то есть свобода для творчества :) Т.е. Вы стабилизируете сигнал в пределах аппертуры, а я - в пределах такта. И здесь главное, чтобы наше "творчество" не противоречило модели...
Например, возьмем нашу модель (упражнения 3.29). Смотрим на мой граф (см. выше). Модель работает только с входными сигналами, т. А и B. В задании на диаграмме, правда, есть синхросигнал. Но смотрим на ее законы работы, представленными формулами, там его нет. Т.е. синхросигнал привносит реализация. Аппаратная. Программная реализация также в синхросигнале не нуждается, но в ней, как и в модели есть дискретное время.
Но в любом случае. И схема и программа реализуют одно - модель/алгоритм, представленнный автоматом. Все остальное - синхросигнал, моменты установки текущего состояние, восприятие входных сигналов, установка выходных - не имеют отношения к самой модели. Если вопринимать реализацию, как "черный ящик", то не должно быть в идеале между ними разницы. Если, например, подавать сигалы и снимать результаты с "контактов" ящика. В этом случае, чем быстрее "ящик", тем лучше он отражает законы работы модели, т.к. быстрее реагирует на входные воздействия и быстрее выдает выходные сигналы. В схеме подобное достигается увеличением тактовой частоты, в программе - уменьшением дискретного такта. Потому-то я привел две диаграммы - медленную, которая в точности повторяет Вашу диаграмму, и быструю, которая может казаться, что "врет".
Но, ведь, с точки зрения модели ни чего не изменилось. Она просто стала быстрее. Может, если Вы увеличите частоту тактового сигнала и у Вас получится такая "быстрая" диаграмма, как у меня?
Резюмирую. Я ориентируюсь только на модель и ее точную реализацию. Ее работа, если это не оговорено в законах ее функционирования, не привязана к нюансам реалиции. Будь она схемной или программной. Конечно, какие-то отличия будут и они будут связаны с внешним восприятием работы это реализации в сранении с ее абстрактной моделью. А по законам теории это отличие будет минимальным, если уменьшать дискретное время. Чем оно меньше, тем мы ближе к идеалу. Чем оно меньше, тем меньше влияние внешней среды на работу модели (того же требования к устойчивости внешних сигналов).
Вот поэтому мне и хотелось бы видет именно граф автомата, а не ту же программу на верилоге. Граф - формальная модель. Верилог - реализация. Моя программа - реализация. Сравнивать надо сначала формальные модели. Это критерий истинности. Если они (модели) одинаковы, то затем уже можно судить/сравнивать и различные реализации. Оценивать насколько они адекватны исходной модели. И уже в рамках реализации думать об апертурах, нюансах программной реализации и т.д. и т.п.
Еще раз. Главное - исходная модель. Все остальное - нюансы той или иной реализации. Некоторые "практики" такого "академического" подхода не в силах принять. Ну, это обычное дело: кто-то старается лечить, а для кого-то главное - "резать, пока нет перитонита" ;)
PS. Про state. Это уже внутренняя кухня программной реализации модели. Я их вывел больше для себя, чтобы лучше понять работу модели. Ну, и оставил, чтобы посмотрели и Вы ;).
Чуть не забыл... Вы обещали решения упражнений к книге. Хочется посмотреть. Может, там приведен, интересующий меня граф автомата.
Диаграммы, как cинхронизация с CLK влияет на результаты работы модели:
Эксперименты с CLK
![](https://habrastorage.org/getpro/habr/upload_files/690/18d/c2b/69018dc2b35adf4d5ee738f05d2be402.png)
Первая диаграмма, когда сигнал CLK всегда равен 0. Поскольку в модель введено условие для CLK, то она фактически не работает.
Вторая, когда CLK всегда = 1. Модель фактически его игнорирует и работает все связи с ним.
Третья, когда CLK - синхроимпульсы. Модель согласует работу с его текущим значением. Диаграмма, заметьте, совпадает с Вашей иотличается от второй. Но модель во всех трех случаев одна и та же и дискретное время одно и то же..
"Тогда такой автомат сможет повторить на выходе любой входной сигнал со сдвигом по времени" - не сможет, иначе проблема пересинхронизации не стояла бы так остро.
Интересно, как неприятие наклонных фронтов в книге Х&Х (кстати, в советское время часто именно так фронты изображали в справочниках и никого это не шокировало) согласуется с представленным ниже рисунком автора поста, где фронты по-прежнему (хотя и менее) наклонные?
А что касается генераторов на задержках вентилей (на нечетном количестве), равно как и задержкам на вентиле, то меня в МИЭТ 40 лет назад учили избегать подобных решений ввиду их нестабильности.
Резюмируя, не могу понять, что именно так возбудило автора поста - я Х&Х прочитал не без удовольствия, хотя не верю, что по этой книге можно реально проектировать процессоры.
Чему Вас только там в МИЭТ учили? :)
Об этом даже Википедия знает. Наберите - теорема Котельникова...
У Вас острый глаз ;) Наклон сигнала зависит от скорости параллельного процесса, который отображает дискретные сигналы. Здесь это тоже автомат. Чем он медленнее, тем больше будет наклон. Но если сделать его очень быстрым, то графика будет нагружать среду.
Здесь больше интересует факт их наличия (работа в соотвествующем режиме - генерации). А так - Вам сказали правду.
Резюмирую. Освежите в памяти теорию автоматов, если Вам, конечно, ее преподавали. Может был синтез цифровых/микропрограммных автоматов или что-то подобное (все-таки МИЭТ). Может, тогда поймете.
Да. Книгу Вы прочли. Может попробуете Упражнение 3.29? Было бы интересно: сможет ли, судя по всему, опытный инженер МИЭТ нарисовать автомат по выданному заданию на его проектирование?
Меня в МИЭТ в первую очередь учили правильно применять теоремы.
В данном конкретном случае это означает (и это наверняка написано в Википедии), что теорема Котельникова говорит о входном сигнале с ограниченным спектром, который подвергается дискретизации по времени. Совершенно очевидно, что прямоугольный сигнал (любой частоты) имеет бесконечный спектр и поэтому субъектом вышеуказанной теоремы не является. Соответственно, он не может быть восстановлен без потерь при конечной частоте дискретизации (и даже со сдвигом).Ответ не зачтен - либо Вы категорический противник наклонов на фронтах и тогда с этим злом следует бороться, невзирая на нагрузки, либо их наличие не является существенным обстоятельством и тогда не следует упоминать их в качестве критикуемых недостатков книги - определяйтесь (или крестик или ...).
То есть мы оба понимаем, что делать такие генераторы на практике нельзя, несмотря на чисто теоретическую возможность подобной реализации (что не есть факт) - меня это устраивает.
Честно говоря не понял, что же там такого страшного в 3.29, пойду посмотрю.
Честно говоря не понял, что же там такого страшного в 3.29, пойду посмотрю
Ну и как?
Недоуменно пожимаю плечами.
D-триггер, 2И, 2ИЛИ, мультиплексор 2в1 - реализация прямо прописана в постановке задачи - что тут вообще может пойти не так?
Неужели проблема была в возможности слегка оптимизировать формирование выходного сигнала - но вроде компилятор должен в этой задачей справляться сам?
Может, Вы не поняли. Даю скрин упражнения из книги:
Упражнение 29
![](https://habrastorage.org/getpro/habr/upload_files/2c6/7d5/469/2c67d54690cfa6e1c6783fec8d3e7746.png)
Не нужно кодировать таблицу преходов, выражения для выходов и следующего состояния, не нужна и схема. Можно не рисовать диаграмму для Z, не отвечать на вопрос b, но... "Спроектируейте конечный автомат. Составьте диаграмму переходов". Всего-то ;) Это интересует. Все остальное следует из этого.
![](https://habrastorage.org/getpro/habr/upload_files/727/38c/c20/72738cc20044dd179416d71125bc7044.png)
PS. Взял за основу Ваш вариант.
Во-во!
Прошу прощения за занудство. Я так я не понял - есть ли решебник к книге, в котором было бы приведено решение упражнения 3.29? И, если такое решение есть, приведен ли в нем граф (диаграмма переходов) или таблица переходов автомата?
Да, могу показать решебник. В нем вначале более сложный автомат (не знаю зачем), а потом говорится "но вообще-то можно и так" и дальше описывается как я и @GarryCпоказали. Вот вам решебник:
Сначала диаграммы:
![](https://habrastorage.org/getpro/habr/upload_files/db7/f3a/287/db7f3a287e13a139d44beebe15d040fe.png)
Потом сложное решение:
![](https://habrastorage.org/getpro/habr/upload_files/6e8/4a8/2c2/6e84a82c217e3d125638db36b33b3bc4.png)
![](https://habrastorage.org/getpro/habr/upload_files/fc5/fc1/407/fc5fc1407bccb6fe6be61815b980e578.png)
А потом говорится "но вообще-то, эквивалентная функциональность может быть получена одним D-триггером и логикой" то есть то, что я и GarryC написали:
![](https://habrastorage.org/getpro/habr/upload_files/d84/92b/c0b/d8492bc0b7b47c5fa2e2b37098b48517.png)
Может быть они в первом решении экономят комбинационную логику, а во втором - D-триггеры.
Ну, вот - совсем другое дело! Спасибо, Юрий! Тепрь можно хотя бы сравнить решения и, если не найти верное, то хотя бы разобраться. Хотя, что там искать, если по определению верное должно быть в решебнике ;)
Волшебное, но, думаю, мудреная для практика фраза эквивалентность поведения" подразумевает, что, если мы возьмем три черных ящика поместим в них мое, Ваше-GarryC, и Х&Х и подадим на их входы сигналы A и B, то работая с одинаковой скоростью, т.е. в одинаковом дискретном времени (не путать с тактовой частотой синхросигнала, т.к. формально на диаграммах автоматов его просто нет) мы должны получить одинаковые выходные диаграммы сигнала D. Я думаю с таким подходом согласится даже, по-видимому, "жесткий практик" checkpoint :).
Это все я могу сделать: 1) создать три модели (моя уже есть) 2) запустить их параллельно (ВКПа тут нам в помощь) 3) подать одновременно на их входы сигналы A и B и... смотеть на их диаграммы сигнала Z. Если все три решения верные, то в силу понятия эквивалентности их выходные сигналы совпадут (если их совместить) или кто-то будет отличаться..
Ну что - смотрим? :)
Тест моделей
Результаты тестирования на разных скоростях
![](https://habrastorage.org/getpro/habr/upload_files/2d5/2c4/cf2/2d52c4cf2f2a2d33ea9853c354c09c28.png)
На диаграммах: нижний - H&H, следующий - GarryC, следующий -мой.
Модели GarruC я добавил установку сигнала Z.
Если немного повозиться, то можно смоделировать и схему H&H. И включить и ее в тестирование.
Вообще то сложное решение этой задачи мне бы могло только в страшном сне привидится при высокой температуре.
Не хотелось бы "лезть в будылку", но вообще-то Ваш автомат, хотя и простой, но с явными ошибками. Поясню это на своем автомате:
автомат для упражнения 3.29
![](https://habrastorage.org/getpro/habr/upload_files/f12/a45/51f/f12a4551ff958916ce8fef838cc8f9b9.png)
У меня переход из начального состояния определяется текущим значением A на момент старта автомата. Это, чтобы определить его предыдущее значение для следующего такта. У Вас - просто в 0. Но пред значение может быть 1. Но, кстати, на эту тему - начального состояния ни чего не сказано в упражнении, что тоже не верно. Нач. состояние обязательно должно оговариваться..
Далее. Во-первых, у Вас автомат не выдает сигнал Z. Это совсем нарушения условия задачи. Во-вторых, у Вас переходы только по значению A, но в упражнении есть еще и входной сигнал B. Куда он делся? Вы склеили (по моему предположению) дуги на переходах и сократили этот сигнал? Если это так, то этого нельзя делать, т.к. на этих переходах разные выходные сигналы (см. мой автомат).
Вот, только замечания навскидку, так сказать.
Не нужно кодировать таблицу преходов, выражения для выходов и следующего состояния, не нужна и схема. Можно не рисовать диаграмму для Z... Спроектируейте конечный автомат. Составьте диаграмму переходов
Что Вы попросил, то я и сделал. Приведена именно диаграмма состояний конечного автомата и она элементарна. Если Вам не очевидна схема формирования выходного сигнала из входных сигналов и внутреннего состояния (это автомат Милли), я, конечно, могу ее нарисовать, но это уже перебор.
Видимо, мы с Вами по разному понимаем понятие диаграммы переходов, хотя должен заметить, что например в стандарте USB они понимают диаграмму состояний именно в моем стиле - только внутренние переменные, а внешние указывают в таблице.
А насчет начального состояния Вы правы - в исходной задаче оно не задано, я опирался на решение, приведенное Юрием.
Ну, никак не ожидал, что так можно трактовать мои слова. Я процитировал начальные две фразы пункта c), которые меня интересовали. Это всего лишь одно - граф автомата (в терминологии H&H - диаграмма переходов. Только это, т.к. из нее автоматически следуют ответы на все остальные вопросы. И это ни как не "перебор", а, собственно, решение данного упражнения, из которого следуют все остальные ответы.
По большому счету такой граф - единственное, что нужно. Так что я просил совсем не то, что Вы изобразили. Сигнал Z - обязательно должен быть. Сигнал B может быть исключен только в результате минимизации/оптимизации графа автомата, но это надо показать и доказать. Иначе он тоже должен быть в явном виде.
Насчет начального состояния. "Перевод стрелок" не принимается :) Нужно обязательно проверять сигнал A, т.к. это же понятно, что на момент запуска автомата он может быть в любом возможном для него состоянии.
Да, придираться, так уж придираться ;) В таблице переходов пропущен один переход, который есть на графе. Это как? Опечатка? Или в графе все же лишний переход?
В деле проектирования небрежности ведут к печальным последствиям, когда одна маленькая или даже мизерная ошибка может обернуться трагедией для всего человечества ;) И это вполне без шуток. Ну или, как минимум, бац! - и в Луну :) Или наш последний тренд - "дегенеративные нейронные сети" Они что дают 100%-ю гарантию правильности результата? Но суют или будут теперь пихать во все "дыры". Мы вложим миллиарды! Чтобы потом потерять триллионы? Не ислючен, правда, "мягкий вариант" - кто-то на этом "запилит" миллионы ;)...
А мы тут - сигнал Z, сигнал B... Какая-то мелочь на фоне какой-нибудь, пусть даже маленькой, генеративной нейронки. Но это так, прошу прощения, - эмоции. Лучше бы поддержали теорию автоматов, чтобы ... инженеры и программисты ... не забывали о нальных состояниях :)
Книга замечательная, 2 года ВУЗа, несколько предметов, ужали в книгу, жаль, что 20 лет назад её не было.
Не спеши, Маша! Разбор примеров из книги Хэррис Д.М., Хэррис С.Л. Цифровая схемотехника и архитектура компьютера