Комментарии 52
При создании схем и диаграмм лучше придерживаться правила (что даже было раньше в ГОСТах): слева вход элемента, а справа – выход. Тогда не надо напрягаться, чтобы понять схему.
Да, я слышал о таком правиле. Очень неудобное правило для тех, кто пытается объяснить работу арифметических блоков (разряды числа расположены так, что слева - старшие, а справа младшие, действия начинаются обычно с младших) и запоминающих устройств для двоичных слов, переданных как последовательность бит (первый символ для человека из Eвропы - самый левый, когда я попытаюсь "положить" первый символ переданной последовательности в стек, мне будет удобнее это сделать из потока направленного справа на лево). Так что, при всем моем уважении к традициям - лично мне в этой книге почти всегда будет удобно потоки пускать справа на лево.
Тем не менее, в литературе, все-таки следуют «слева-направо» и никаких проблем с арифметикой не имеют.
В другой литературе фокус сделан на другом, там для читателя удобно, чтобы мячик на киноэкране экране и потоки данных на схеме катились слева на право, но опять же, не для жителей Азии, например.
Ну вы-же не только для жителей Азии книгу пишите. И уверен, что для глобального понимания схем они используют общие стандарты. С вашими примерами можно и иероглифы использовать или шумерские палочки итд. Но тогда, это усложняет понимание. Знаете - как в анекдоте - корм должен рыбе вкусный быть, а не рыбаку.
Ну вот, еще один горячий спор о правостороннем и левостороннем движении. Давайте оставим пока дискуссию открытой.
Наверное, если бы я лет 20 видел только один вариант, то от инверсии потоков меня бы тоже коробило. Тем не менее для повествования удобно, чтобы потоки в каждой схеме шли так, как сподручней именно для этой схемы. Для большинства схем сподручнее с права налево (иначе последовательности приходится с конца нумеровать и арифметика вся шиворот-навыворот получается), но бывает и наоборот. Есть и такие схемы, естественное изображение которых требует направление потоков в противоположных направлениях (адресное дерево записи и чтения, например). Обещаю пока только, что внутри одной схемы будет поддерживаться однообразие и некоторая логика.
А может тогда вместо линий и черный и белых полукужков, мнемоника которых может быть прочитана по-разному, использовать линии со стрелочками? Тогда сразу видно куда "текут" данные. И в зависимости от ситуации можно будет нарисовать и так, и так, и читатель сможет прочитать.
Более сложные блоки (например, FIFO с, скажем, valid/ready интерфейсом для симметричности (или любое другое устройство с AXI-подобным интерфейсом)) мне приходится рисовать так, что у него входы и выходы с двух стороны, и группировать сигналы не по направлению, а по смыслу: с одной стороны вход FIFO (входные данные и валидности и выходной сигнал готовности), с другой - выход FIFO (выходные данные и валидность и входной - готовность).
Вы понимаете, что данные например по шине данных текут и туда и сюда, и контроллеры памяти по одним и тем-же ножкам их, эти данные или берут или отдают назад. Как-то люди до сих пор справляются при чтении схем! Даже 'упрощение' в виде шины вместо 64 битовых дорожек никого не выбивает из коллеи.
Есть общепринятые вещи. И автор решил их полностью видоизменить. Такие как слева/на право и сверху/вниз. По возможности входы слева, выхода справа. Ну или вертикально сверху/вниз. Даже стандартные символы например мультиплексора - слева много-много входов и адрес, справа всего один единственный выход. Итд. Можно конечно и произвольно, и в этом случае метки названий входов/выходов всё равно нужно указывать. И этого уже хватает. Иначе у 32 битового мультиплексора ещё и 32 дополнительные стрелочки рисовать надо.
Но автор конечно-же в праве сам решать - придерживаться стандартов или совершать революцию. Но в последнем случае надо всегда иметь ввиду, что такой подход может и не 'стрельнуть'. И в этом случае может быть хорошие идеи не найдут своего читателя, и только потому, что автор усложнил восприятие. Для детского уровня я может быть это и могу представить, но не для профессионального подхода.
Я конечно вижу похожесть этого визуального подхода со мнемоникой или стрелочками с моделирование баз данных (ER Diagram). Там это используется для указания отношений полей между таблицами. Но это совсем другое. По крайней я так думаю.
Спасибо. Я подумаю насчет стрелок.
Я так понимаю, представленный материал есть не что иное как глубинная основа STA - static timing analysis. Проблема в том, что даже для основ изложено слишком математизированно. Конечно, если абстрагироваться от физики проводников и полупроводников, то выглядит вполне. Но вот если рассматривать вопрос более практично, то у DAG (directed acyclic graph или по русски направленный ацикличный орграф) появляются дополнительные ребра в виде setup/hold/recovery/removal check, прохождение по графу учитывает полярность сигнала и возможность его инверсии при прохождении вершин .. и т.д. - куча усложнений, притягивающих всю изложенную математику к практике. Материала на русском по этой тематике действительно мало. Лет 10 назад было много научных публикаций и даже диссеры в Зеленограде ... но до написания софта так дело и не дошло. Я в свое время учил это все (практическую часть STA, т.к. нужно было для работы) по скачанным лекциям MIT. И даже сделал небольшой пост здесь https://habr.com/ru/post/273849/ Собственно, именно по прикладной STA очень и очень не хватает публикаций, а в идеале учебника на русском. На уровне лекций MIT и даже глубже - языком математики, как вы и запостили. Для будущих инженеров, если страна все же сможет выбраться из под санкций.
Я в физике слабоват, больше по алгоритмам работать как-то приходилось. Но если есть вербализованная потребность, давайте ее здесь продвинем и порекламируем - наверняка какой-нибудь поверхностный читатель моих статей окажется специалистом в озвученной Вами теме, который потом сможет и захочет о ней написать.
Ок, тогда наверное мне нужно уточнить. Поясню, что я имел ввиду под "физикой". Задержки ребер графа (банально RC проводов). Зависимость задержки вершин графа (элементов) от полярности сигнала: рассматриваем мы передний или задний фронт. Тип вершины (выхода элемента): инвертирующий или нет. Вот и все. Хотя это малое может сильно повлиять на выводы в ваше публикации. К примеру, кратчайший путь - вовсе не тот где меньше вершин в графе, а тот, где суммарные задержки (с учетом задержек ребер, полярностей сигнала на отрезках, и т.д.) меньше.
Ну и надо пояснить про дополнительные ребра графа, которые я выше обозвал как [setup/hold/recovery/removal check]. По русски их можно назвать контрольными ребрами, поскольку на них фактически сравниваются задержки прохождения графа разными путями (я об этом подробно писал по ссылке выше).
Хотя это малое может сильно повлиять на выводы в ваше публикации. К примеру, кратчайший путь - вовсе не тот где меньше вершин в графе, а тот, где суммарные задержки (с учетом задержек ребер, полярностей сигнала на отрезках, и т.д.) меньше
Подождите, но у меня кратчайший примерно так и считается: по сумме задержек, а не числу вершин. Я конечно не учитываю, что в разных ситуациях и на разных парах вход-выход одного и того же блока могут быть разные задержки отклика на изменения, но в целом - в статье именно тот подход, который Вы считаете правильным.
Хорошо. Значит не совсем верно понял, мои извинения.
Еще одно замечание. Важно считать не только кратчайший путь, но и самый длинный. Поскольку оценка всегда делается для обоих граней "окна" переходных процессов - верхней и нижней. Зачем - это уже надо вводить такие понятия как Setup, Hold, и метастабильность. И контрольные ребра графа, о которых я писал выше.
Иии.. и еще одно совсем маленькое замечание. Дело в том, что в индустрии последние лет 10 используют статистические величины задержек. В простейшем случае для модели задержки используется распределение Гаусса - т.е. mean и sigma (для расчетов обычно используют 3 сигма), в некоторых случаях это распределение складывается из двух разных "половинок колокола" (почему - можно написать много текста), в еще более продвинутом случае ось колокола имеет наклон (тут скрыто еще больше текста). Соответственно все формулы расчета задержек превращаются в статистические, обычный "+" уже не работает. Надеюсь, кто нибудь когда нибудь запилит об этом пост .. для будущих инженеров. Что до вашей книги - наверное об этом стоит просто упомянуть вскользь.
Теперь мои извинения: я проглядел слово "кратчайший". Я рассматривал именно самые длинный. А кратчайшие - это зачем? Чтобы регистры успевали правильно скопировать следующее значение что ли?
Повторюсь:
Поскольку оценка всегда делается для обоих граней "окна" переходных процессов - верхней и нижней. Зачем - это уже надо вводить такие понятия как Setup, Hold, и метастабильность. И контрольные ребра графа, о которых я писал выше.
О, это сильно выше моих познаний и лежит явно за пределом формализма схем из логических блоков.
Дело в том, что без этого никак. Задержки в одной лишь комбинационной логике интересны, но не практичны. На практике орграф потому и ацикличен, что один конец отрезка всегда входной клоковый порт схемы, а вторая точка всегда место разыва - пин данных триггерного элемента, у которого внутрення арка ( вершина графа) от пина данных рвется, и на графе заменяется контрольным ребром между этим пином данных и пином клока. Таким образом мы получаем два пути, которые можно сравнить по величине задержек - от клокового порта до пина данных триггера, и от клокового порта до пина клока этого триггера. А дальше эти два пути просто анализируются на предмет нижней и верхней грани разброса задержек (поиск максимума и минимума). Полученный результат сравнивается с контрольным ребром, который суть - характеристика триггера в виде допуска по этой верхней и нижней грани. Если результат удовлетворяет - схема работоспособна. В этом суть статического временного анализа, на пальцах. Как вы понимаете, на фоне изложенного, ваши выкладки выглядят очень не полно. Об этом я и писал
Да, я примерно понимаю о чем вы говорите, но в свой книге хотел бы оградить читетеля от этих подробностей. Я исхожу из следующих предположений, поправьте меня, если ни не верны.
1)Без потери общности можно считать, что время удержания регистра больше его времени предустановки.
2)Удлиняя или укорачивая провода-ребра клокового дерева (шины по которым распостраняется клоковый сигнал) в принципе можно добится, чтобы ко всем регисрам фронт клокового сигнала пришел чуть ли не одновременно. Это не всегда обязательно и порю нет никакой необходимости заставлят все регистры особенно большой схемы срабатывать одновременно, но в принципе добиться можно.
3) Из 1 и 2 следует, что если перед приходом фронта тактового сигнала на регистры значения в шинах схемы, отличных от шин клока, уже стабилизировались, то смена значений регистров произойдет правильно (их остальные порты точно сохранят стабильные значения на протяжении времени удержания плюс времени задержки по пути до ближайшего выходного порта другого регистра).
4) из 1), 2), 3) следует, что (если схема маленькая и временем задерки в проводах можно пренебречь) длина такта может быть выбрана меньше чем длина критического пути, посчитанной по методике этой статьи, геде термином задерка стабилизации данных - назвоно время удержания, а термином задерка стабилизации значений регистра - время его предустановки.
Все требования пунктов 1)-4) не являются необходимыми, утверждается лишь их достаточность. Да если все пути от регистра к регистру в схеме долгие (большая задержка), то не обязательно требовать от регистра вообще хоть какого-то времени удержания. Можно еще в паре мест "подрезать" площадь и время минимального такта. Но это уже улучшения. Если кто-то принес схему, методикой этой статьи критический путь в которой оценивается как T, то профессионал схемотехник (или программа САПР) должны уметь заставить работоат эту схему на частоте не меньшей 1/T.
Ответ -наверное да, можно так считать, хотя в общем случае это вовсе не обязательно. Суть в другом - анализ на установку и анализ на удержание - разные, не зависимые и не связанные между собой задачи. Но для каждого из этих анализов производится расчет верхней и нижней границы задержек, просто для анализа по установке: путь данных должен быть Макс, и путь клока Мин. А для анализа удержания - путь данных Мин, а путь клока -Макс.
К этому стремятся, но вы помните про вероятностные величины задержек? В реальности вы никогда не получите одновременного прихода клоков, вероятность этого около нулевая. И на практике расхождение прихода клока на разные триггеры может достигать даже величины в несколько периодов.
Но в целом соглашусь с вами - для фундаментальной публикации по математике, алгоритмы вычисления минимальной и максимальной задержки - минимальный и достаточный инструментарий. А как его использовать - уже вопрос практики. Точнее, можно добавить сюда всю ту физику, которая используется в реальных программах STA, и получится тоже очень даже фундаментальная публикация. Только, это уже будет иметь отношение не столько к математике, сколько к физике, алгоритмам, и численным методам. Я не уверен, что такой труд есть даже на английском. Только отдельные научные публикации, и все. Это та область знаний, на которой зарабатывают огромные деньги, к примеру одна лицензия синтезатора схем из их описания (Design Compiler) стоит $50к в год. Синтезатор работает, как не трудно догадаться, не просто как синтезатор и оптимизатор булевых функций (задача в общем то простая), а с упором на статический временной анализ во время синтеза. Алгоритмы работы подобных инструментов - охраняемая коммерческая тайна. Я так понимаю, в Зеленограде пытались что то свое создать, судя по публикациям. Но чем закончилось, не известно
Перерисовал картинки в предыдущей статье, теперь не "вырви глаз". Заодно нашел несколько ошибок по невнимательности. Настоящую статью перечитаю и "причешу" через пару дней, когда мозг немного забудет ее текст.
Математические тексты часто строятся с учётом облегчения поиска информации. Выглядит это так:
Моменты, к которым читатель может захотеть вернуться каким-либо способом выделяются.
Моменты, которые некритичны при повторном обращении к работе, так же выделяются с целью не отвлекать внимание читателя на выискивание точек их начала и окончания.
Обычно схема такая:
Определение:
Текст определения.
Теорема/Лемма:
Определение.
Доказательство:
Текст доказательства.
Конец доказательства.
--------
Обычно стимулом для переработки в таком стиле служил либо внутренний максимализм автора, либо строгий цензор/редактор. Если стимула нет, результат будет проще для автора, но хуже для читателя.
Так же было бы уместно указывать цель той или иной леммы/теоремы. Например - теорема о ХХХ нам понадобится для перехода от состояния, когда вы знаете УУУ к состоянию, когда мы сможем применить УУУ к задаче ZZZ доказательно, то есть полностью доказав путь от аксиом до решения ZZZ. Здесь про путь от аксиом можно сказать один раз, а вот применимость теорем стоит показывать каждый раз, иначе текст выглядит неравномерно, где-то на много абзацев описание аналогий с каналами, а где-то сухой текст теоремы и доказательства, без малейших дополнений.
Да, я стараюсь примерно так и писать, но в первой редакции текста внимание слишком сильно сконцентрировано на логической структуре его содержания. Трудно на этом этапе хорошо позаботится о мета уровне (как это содержание воспринимается читателем). Возможно, мне стоит выкладывать статьи не сразу по готовности, а с некоторой задержкой, чтобы текс успел для меня забыться и сам смог взглянуть на него глазами читателя.
сам смог взглянуть на него глазами читателя
Это можно, но разбиение на части с их выделением, это ведь просто алгоритм, про который очень наглядно видно - выполнен или не выполнен. То же и про пояснения, просто подчасть со своим алгоритмом.
Есть смысл потратить время на отработку такого алгоритма. Это одноразовое долговременное вложение, которое будет окупаться постоянно во всех статьях в будущем.
Меня всегда интересовало, а какая глубина схемы суммирования, скажем, 32 битных целых? Ведь там переносы разряда, и она будет не менее 32, что очень много? Или есть какие то трюки?
Как я рад новым комментариям! С удовольствием отвечу на ваш вопрос.
Существует хитрый способ, и я его очень подробно разберу в следующей или послеследующей статье, который для любого k позволяет построить схему сложения двух произвольных k-битных чисел с глубиной O(log k) и при этом задействует O(k) элементарных блоков. Схема называется префиксным сумматором. Он асимптотически самый быстрый из известных.
Не хочу вас обидеть, но моё мнение - вы перемешали всё в кучу. Такие вещи объясняются от простого к сложному. От логических вентелей, потом триггеров (flip flop), потом сумматоров, мульти- и демультиплекторов. Когда-то ALU. И его тоже - вначале на 2 битах, потом 4, 8. С 8-ми бытовом можно уже ALU с памятью соеденить, показать, как возникают инструкции (ISA) итд. Никому никогда в голову не придёт 'путать' выходной порт вентиля с выходом на монитор. Хотя разницы в них в принципе и нет.
Ида, я прочитал и вашу предыдущую статью. Простите меня, но так ни один айтишник, электротехник или ещё кто не выражается, как вы пишите там Вот ваши слова.
"О том единственном выходном порте, к которому присоединена шина, мы будем иногда говорить, что он является ее «началом» или, что он «стоит в ее начале». Обо всех соединенных с шиной входных портах мы будем говорить, как о «концах» этой шины. Из аксиом B2 и B3 следует, что у каждой шины есть по крайней мере один «конец» и в точности одно «начало»."
У шин нет ни начала ни конца. Если есть начало и конец, то это не шина, а интерфейс/соединение или что-то в этом роде. Брать в кавычки что-либо при описании таких тем, как эта - это просто уходить в дебри ненужных абстракций.
А вот эти ваши слова..
"..шинам будут соответствовать металлические проводящие дорожки." или там "..блочки, покрывающая плату затейливым узором." - это для детей книга? Тогда они всё остальное не поймут.
И потом. Есть ГОСТ для описания логических вентилей. Вы-же изобритаете велосипед и этим усложняете то, что просто и понятно.Никто никогда раньше не перепутал у них, где вход, а где выход. Поэтому дополнительные рюшечки не нужны. Я представил, что в книге, где будут учить основам музыки будет использоваться не нотная грамота, а своя, никем невиданная. И у нот специальными полукругами будет указано, где у нот низ а где верх...ну для лучшего понимания...
Запаздывания отдельно взятых вентилей для разработчиков новых микропроцессоров может быть и интересны, но в современных схемах для общего ознакомления наличие такта объясняет всю суть работы и синхронизации всех составляющих. Запаздывания нужны инженерам, но которые не блочками разговаривают. И т.к вы используете свою схемо-рисовалку, то не думаю, что эта литература для будущих спецов Intel, AMD или на худой конец Байкала.
В математическую составляющую я так и не смог вникнуть, очень уж заумно. Аксиомы, доказательства в описание цифровых схем - это вообще считаю - перебор.
Теории придумывать не есть плохо. Но тут такое, что не понимаешь- для чего и кого всё это? Навыдуманно куча новых слов, уже всем понятные слова используются для обозначения новых интерпритаций и берутся в кавычки, итд. Вроде в комментариях к первой статье вы указывали,, что ваша книга для инженеров, чтобы они прокачали свою математическую базу, но забываете или игнорируете, что эта база уже существует и называется бинарная алгебра и все те элементы, которые уже напридуманы. Другой для описания или для выдумывания новых компонентов не надо.
Почитайте и посмотрите у VHDL или VERILOG. Там всё, что надо для современного инженера.
Спасибо ра развернутый отзыв. Я всегда рад мнению профи.
От адекватных мнений мой дофамин не страдает, все в порядке, останется желание читать и писать ваше мнение - буду только благодарен.
Да, с математикой "немного" переборщил для формата популярных статей.
Да, есть некоторые проблемы с неудобгостью традиционой и пока что сыростью моей собственной терминологии. Со временем и в следующей редакции, наверное, с этми наладться.
Да, я собираюсь несколько изменить стиль изложения, разделив материал на популярный и "дополнения" с серьезной математикой.
Но,
Некоторые результаты я не смогу коротко и удобно сформулировать и тем более строго доказать в инженерной терминологии.
Например, мне не известно, где бы я смог увидеть теорему о связи глубины схемы и предельной тактовой частоты сигнала в той строгой и формулировке, в которой вы ее видили здесь. С другой стороны, я смежник, в теме недавно, есл вы накидаете ссылок - отдельное спасибо.
Понятие глуины должно входить в любой даже начальный курс дизайна логических схем на одном уровне с понятием такта. Писать схему на HDL, не понямая глубины - так можно и на 100 МГерц скатиться.
В следующей лекции я собираюсь доказать очень сильное утверждение: любая логическая схема глубины h некоторым алгоритмическим способом может быть превращена в конвейризованную схему глубины 1 с той же логикй работы и запаздыванием между данными на входе и выходе не больше O(h) тактов (данные скармливать можно каждый такт). Если k - число элементов в исходной схеме, то при достаточно реалистичных предположениях конвейризация потребует не больше 3k регистров задержки.
Насколько известен в профессиональной среде такой результат, можно ли какие-нибудь ссылки на литературу.
Лично мне в терминах условного "Харрис&Харрис" доказать его было бы необычайно тяжело.
Насчет Интела, Арм и прочих - а еси я вдруг что-то интересное опубликую и переступив через презрение к хабраюзеро эту писанину в Хуавей прочтут и применят. Думаю директор по развитию в Арм и Интел могут поменяться. Сценарий маловероятный, но и директора по развитию на дороге не валяются - думаю, какого-нибудь студента спровадят на посмотреть))).
О портрете пердполагаемого читателя будущей книги - здесь все куда сложнее. Мне бы очень хотелось, чтобы книга была понятна работающим инженерам, исследователям в области computer science и широкоу кругу абстрактных математиков. Как всем угодить - большой вопрос.
Ну с целью книги и читательской публикой надо определиться. Или книга - ради книги тогда не важно как и что. Если-же цель - какие-то конкретные люди - дети/начинающие/студенты/продвинутые/эксперты, то и языкобьяснения и глубина технической и математической составляющих должен быть подходящий. Это первое.
Теперь про связь глубины схемы и частоты такта. А с чего вы им исходите, что они взаимосвязаны? Ведь частота определяет общую скорость. Отдельные команды же для процессора требуют для их исполнения разное количество тактов. К чему это я? Да к тому, что если какой-то блок для инструкции будет реализован так, что потребуется глубина - не понял ваших понятий - скажу с потолка-100. То и количество тактов для её исполнения будет намного больше, чем например для суммирования двух целых чисел. Но если эта инструкция нужна, то все будут довольны. И будущие инженеры будут работать над тем, как это упростить и уменьшить количество требуемых тактов.
Принципиальное. Если для нового микропроцессора понадобится новая инструкция/команда, то всегда есть два пути для её реализации - эмулировать с помощью примитивных команд или строить для неё блок на логических вентилях. И то и другое сопоставить между собой - важная задача. Для этого есть много критериев - как часто будет использоваться, сложность в форме лог. вентилей их теплоотделение, величина итд.
Не совсем в курсе, сколько конкретно, но много инструкций у процессоров исполнены по принципу - снаружи CISC, внутри RISC, то есть очень многие из них компилируются на ходу и исполняются как куча примитивных. Это удобно, не требуется эл.схемы и можно даже годами позже перезалить, если в них где закралась ошибка, можно скалировать на отдельные ядра итд.
Поэтому ваши доказательную связь глубины схем с задержкой или с тактом - извините, не понял. Но желаю вам творческого успеха.
Как делать микропроцессоры - это очень хорошо изученная прблема - там трудно что-то новое предложить. Сейчас время, когда появляется много специализированных схем, каждая из которых призвана решать узкий круг задач, но делает это очень хорошо. Видеокарты, матричные умножители, схемы для поточной обработки данных. Я видел реализации матричных умножителей от Гугл и Интел - без слез не взглянешь. Даже я могу лучше. Схему для АФАР, говорят, сложно сделать. TSMC вроде как для всех доступна, но не у всех получается алгоритмы быстро реализовать. Тут статья на хабре была интересная у @NVaLEX : https://habr.com/ru/users/NVaLEX/posts/ .
В общем, не все так просто.
За ваше внимание и слова поддержки я вам искренне благодарен.
Замечания попытаюсь учесть в будущих статьях, может к 5-6 все устаканится.
Спасибо, хорошая статья но и там стоит подтверждение моих слов...
Одной из причин, по которой не удалось реализовать открытую и совместную экосистему SoC, является высокая стоимость аппаратных сбоев. Аппаратная ошибка, обнаруженная в изготовленном оборудовании, может обойтись коммерческим компаниям в миллионы или миллиарды долларов в виде отзывов и потерянного дохода. Это отличается от индустрии программного обеспечения, где ошибка часто может быть исправлена на месте с помощью недорогого обновления программного обеспечения.
Практическое дело - это всегда не идеальный путь, а постоянный поиск компромиссов.
Вцелом трудно с вами не согласиться, но компроми и упущение - это все разные щещи. Плохо скроенное платье из золотой ткани - так себе компромис.
Пример — каждая ячейка памяти хоть и существует в отдельности, данные с неё с с миллиард других передаётся всегда через одну и ту-же шину. Через одну шину туда, и назад тоже. Да, может быть в комьютере иметь отдельные провода к каждой ячейки было-бы нааамного лучше, но тогда и размер комьютера был-бы с размеры небоскрёба. Поэтому — компромис. Харвардская архитектура тоже хотела архитектуру Von-Neumann(а) скинуть с трона, но как-то не вышло. Всё равно мир пользуется так называемым бутылочным горлышком Von-Neumann(а), хоть в тероии это не самая лучшая идея. Но как-то уже несколько десятилетий просуществоала.
Или что за основу структур данных взят байт с 8 битами. Не 25, не 250, а именно 8. На всё есть своя причина. И не всегда это только со стороны — плохо/хорошо. Например от вас тоже никто не ожидает, что вы будете владеть 130 языками. И если вы ими не владеете — то так себе вы как интелектуал ;) Всё в жизни — на основах компромисов. Вам решать, соглашаться с этим или нет, но иногда так проще. Поэтому ваш пример с золотым, но плохо скроеным платьем — мне кажеться ничего не обьясняеет. Иногда и такое тоже подойдёт. Хотя это уже не из моей области знаний.
Вон моё общее впечатление от программ, которые разрабытываются для и в фирмах. По всему миру. Я-бы всё это назвал — стыдоба и издевательство над инженерным подходом. Но ничего — существуют миллионы контор, пишут так себе софт, его за миллионы продают, фирмы это покупают — и все довольны и этим создают добавочную стоимость. Поэтому причины — видеть это как что-то несерьёзное у меня нет. Видать по-другому не получается.
Спасибо за разговор, вы навеяли меня на хорошую идею. Буду с ней разбираться.
Да я, в общем-то, с вашими тезисами согласен. По моему рамки - это всегда условность. Рамки - не самоцель, они создаются, чтобы сделать жизнь легче и удобнее. Но это в том числе означает, что, когда те или иные рамки перестают быть удобыми, стоит поискать им на смену другие рамки.
Мир тоже не совершеннен хоть и велик. Быть может, в наших силах сделать его чуточку лучше?
Спасибо, наше общение было для меня приятным и заставилило меня лучше все взвесить. Желаю удачи с вашей идеей.
Как делать микропроцессоры - это очень хорошо изученная прблема - там трудно что-то новое прпредложить.
ну , не скажите - посмотрите на новые модели, например у того-же Apple - M1 Pro. Так там много чего нового инженеры напридумывали или наоптимировали.
Я очень сильно подозреваю, что вам виднее))). Мое дело - более универсальные задачи, которые можно применить и там - и тут, и впроцессорах - и не только. Кончно на острие любой высокой технологии есть свои открытия и новшества. Моя цель - скорее не острие, а тупой и грузный кирпичь ближе к основанию.
Про конвейризацию можно здесь посмотреть: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.134.9731&rep=rep1&type=pdf
Результат почти очевидный наверное для всякого математика, кто когда-нибудь работал с алгоритмами на графа. Я попытаюсь сделать текст доказательсва по возможности простым и самодостаточным, покажу, что утверждение теоремы можно распространить на любую схему (не только комбинационную), для чего потребуется не более чем h раз дублировать каждый регистр начальной схемы.
Имея такую теорему, дальше в своем повествовании я могу разбирать только однотактные неконвейризованные схемы - конвейризация и ее оптимальный способ будут гарантироваться теоремой. Однако эти результаты сложно рассказать не на языке теории графов.
Еще комментарий.
С точки зрения науки сразу ввести полный набор аксиом и с ним продираться через трудности - это правильно.
Но с точки зрения обучения - это перебор. Например, нам на курсе логики на 1 курсе сначала дали логику высказываний, прошли полный путь, а потом добавили кванторы - дали логику первого порядка, и прошли тот же путь, но на следующем уровне сложности.
Может и тут, сначала ограничиться функциональными схемами (без регистров), с ними пройти нужный путь. А потом ввести регистры и с ними повторить всё еще раз? И запомнится легче, и перегруза понятий не будет.
А на схеме (Граф, ассоциированный с «пульсаром») должна быть стрелка из reg.in и reg.out?
А нужно ли так детально погружаться? Например, точно ли нужны времена Δtsʀ и Δtdʀ? Как Вы пишите в другом комментарии, можно считать что клок приходит во все регистры практически одновременно, так что эти времена - это всего лишь какая-то общая константа, которая на смысл дальнейших рассуждений не сильно влияет, но усложняет понимание.
Если хочется быть физически точным, то надо и длину путей (а это значит разводить схему на плоскости) учитывать. У меня часто критический путь - этот тот, у которого 80% - это провода, а только 20% - логика.
А если огрублять, то IMHO это то место, которое вполне можно отложить, считая что регистры срабатывают мгновенно и одновременно. А ближе к концу, если захочется рассмотреть поближе к реальности, то добавить дополнительные времена (и регистров, и проводов).
Да, так формально тоже можно, но получается нарушение общего подхода: у всех блоков, которым соответствуют физические устройства, задержка есть, а у регистров почему-то нету. А так в принципе изменение длин критических путей на константу на O-болшое оценки конечно не влияет.
Гм, меня это не смущает. Вы же при построении ассоциированного направленного графа регистры разбиваете на два, а другие - почему-то нет ;).
Кстати, по поводу этого графа. Вы построили граф портов, а потом приходится на часть ребер ставить веса, а на часть - нет. Т.е. всё равно ребра оказались разного типа. Может не стоит так дробить граф только для того, чтобы посчитать задержку. Я бы предложил оставить схему как есть, только регистр разбить на два: регистр-выход и резистор-вход. Тогда времена будут приписаны вершинам, а не ребрам, но всё считаться аналогично. Такой граф будет минимально отличаться от графа-схемы, но при его построении мы делаем более просто объяснимую вещь: рвем те связи, по которым данные текут через границу такта. Остаются только чисто комбинационные/функциональные стрелки, по которым считаем задержку.
P.S. Да и для констант задержка точна нужна? Вы написали, что в нулевой такт выход станет нужным через Δtc, но в остальные такты (гм, мы же для них на самом деле считаем) выход сразу будет правильный.
Предложенный вами способ имеет свои плюсы и минусы. Про идею разрыва пути в регистрах проще получается. С другой стороны не очень удобно определять длину пути через веса вершин: длина разбитого на фрагменты пути не равна сумме длин фрагментов, или разбиение крайне не естественное выходит. Я над этим подумаю еще.
Для блоков-констант и блоков прямого соответствия в общих определениях задержка вводится, чтобы теоремы и доказательства звучали по проще, без оговорок. Далее в тексте делается оговорка, что их задержку на практике можно считать равной нулю.
Про константы. В итоге я понял так:
Сначала вводим задержку, причем говорит что она имеет смысл [только] на нулевом такте.
Потом ее учитывам на всех тактах (?).
Потом говорим, что она равна нулю (??).
В результате я как читатель запутался.
IMHO не стоит пытаться описать всё, Вы поставили другую цель - описать "удивительный мир", и надо его описывать как можно проще, но не теряя сути. Усложнить можно и потом, а пока читатель не понял о чем тут вообще речь (а он еще не понял), грузить его излишними деталями не нужно.
P.S. В целом это всё мелочи. Сейчас, думаю, Вы стремитесь скорее в черновом виде написать все главы книги, чтобы книга сложилась. И тогда будет лучше видно, что нужно сказать вначале, а что стоит отложить на потом. Вы делаете большую работу!
Про схемы еще такая мысль пришла в голову. Не удобно определять, если считать длину от вершины графа (элементарного блока) до вершины. А если считать от ребра (шины) до ребра, то уже нормально, хотя и непривычно. Это может быть даже более правильно, т.к. именно ребрам/шинам соответствуют переменные в языка, мы именно ребра/шины именуем. И порты - это частный случай именования ребер.
В математике называтся переходом к реберному графу. Пусть имеется какой-нибудь граф, его реберный граф строиться так: вершинами реберного графа являются ребра исходного, направленное ребро между вершинами x и y реберного графа присутствует тогда и только тогда, когда в исходном графе конец ребра x служит началом ребру y.
Я думал, не вввести ли мне реберный граф, но решил, что это уже перебор. Если же я буду следовать вашему совету, то попадись книга человеку с более абстрактным образованием - он ко мне вагон претезий выкатит: мол зачем ты неявно определил и используешь реберный граф, не называя при этом вещи своими именами и страдая от кучи неудобств. Короче говоря, да, есть такая проблема...
Алгоритмы на кристалле. Глава 1 (продолжение): Быстродействие элементарных схем