Как только вы обеспечиваете нормальную себестоимость и рыночные цены, вы можете быть востребованы. У Байкал Электроникс гораздо больше шансов, чем у МЦСТ в силу того, что они совместимы с огромным количеством доступного на рынке софта.
Аргумент интересный и правильный, но вывод странный. Под совместимостью понимается преимущество использования архитектуры АРМ, полагаю. Но вот вопрос в том, а как Байкал будет покупать ядра АРМ следующих поколений (в условиях санкций). На мой взгляд, у АРМ в РФ нет будущего, надо искать другие ниши/архитектуры.
По x-talk/noise и защелкивание асинхронных схем напишу чуть подробнее.
Любая асинхронная схема так или иначе содержит RS защелки: в явном виде, либо в виде С-элемента, либо в составе NCL элементов. RS защелка это бистабильный триггер, для переключения которого нужен импульс с некоторой минимальной энергией. Для простоты будем считать что амплитуда сигнала фиксирована, и тогда вместо энергии можно говорить просто о длительности импульса, а однократное переключение будем считать импульсом с бесконечной энергией/длительностью. Так вот, если длительность импульса слишком мала, то переключения не произойдет, а если длительность чуть выше, но все равно недостаточна, то получим бистабильное состояние, выражающееся биениями/генерацией на выходе. У меня есть хорошая статья, поясняющая этот эффект. В нашем контексте, импульс это наведенное паразитное переключение.
А теперь представьте, что в Вашей NCL-подобной схеме какой то элемент сработал неверно за счет наведенного импульса. Сработал, и защелкнул неверное состояние. Вот об этой проблеме я и писал выше. Есть еще проблема защелкивания управления, но если его проектировать как и в синхронных схемах, т.е. с экранированием, то проблем быть не должно. В любом случае, нужны исследования.
Согласен со всем, и в частности с недостатком классического dual rail в виде орфанов и повсеместного нарушения DI. Но тут важно понимать, чего мы хотим добиться, и какой ценой. Поясню:
Наиболее серьезный недостаток асинхронных схем, это защелкивание (когда схема просто встает). Причем на практике стоит опасаться не эффектов вида SEU в где то в транзисторах (хотя и это случается тоже), а куда более распостраненного эффекта X-talk/ noise, который как Вы верно написали, в синхронных схемах маскируется клоком, а вот асинхронную схему просто убьет. Причем современные тулы проектирования топологии кристалла помогают снизить этот эффект до приемлемого (для синхронных схем) уровня, но полностью от этого избавиться может и не получится (для синхронных схем это не требуется). И я подозреваю, что данный аспект проектирования асинхронных схем пока вообще никто не изучал. Были пара американских патентов с троированием, и схемой watchdog, которая при срабатывании делала сброс, но .. это какие то убогие костыли, а не системное решение проблемы.
Получается, что на фоне борьбы с защелкиванием, проблеммы с чистотой DI смотрятся уже более чем бледно. И возникает вопрос - а может и вовсе не делать индикацию в логике? Ведь избавившись от индикации (в логике, но не в регистрах) кроме очевидного бенефита в виде скорости/площади/потребления мы получаем еще хоть и небольшую, но защиту от x-talk/noise - случись это где то в середине комбинационной схемы, отголоски такого сбоя могут и не докатиться до выходов. А могут и докатиться, тут как повезет. Скажем, если электромагнитный импульс был наведен снаружи, а не изнутри схемы, то ничего уже не спасет от защелкивания.
Итого, все зависит от задач и имплементации. Но если расставлять приоритеты, то может оказаться, что DI в комбинационной логике не нужно и даже вредно. Причем проблема x-talk/noise - электрическая, т.е. можно сменить CMOS на что то еще, но провода то останутся. Нужны исследования, не хватает практики. По борьбе с защелкиванием в асинхронных схемах практически ничего нет.
У NCL реализации комбинационных схем есть два серьезных недостатка:
Первое - в NCL каждый логический элемент ожидает окончание переходных процессов(ПП). Таким образом вычисление функции и ожидание окончания ПП происходит последовательно. В классическом же dual-rail подходе индикация окончания ПП производится параллельно с вычислением функции, а значит работает быстрее.
Воторое - NCL это проприетарная (!!!) библиотека элементов. Практически в каждом элементе сожержится защелка (С-элемент) для хранения состояния. И если сравнить реализации на NCL и классический dual rail с параллельной схемой индикации ПП, то во втором случае общее число таких защелок получится меньше, т.к. они используются более еффективно. По крайней мере, так получалось у меня в экспериментах, когда я занимался данной тематикой.
Итого, причины не использовать NCL более чем весомые. Да и сам метод dual rail (перекрестная реализация по Варшавскому) мне кажется сильно проще, особенно тем что можно использовать коммерческие синтезаторы синхронных схем DC / Genus. Т.е. приведенный в статье новый (?) метод синтеза - хорошо, но польза от него сомнительна.
В дополнение, и это уже много раз обсуждалось, в том числе и здесь, непонятно где вообще имеет смысл использовать dual rail кодирование для реализации асинхронных комбинационных схем. Не асинхронных схем вообще, а именно комбинационных, т.е. где требуются вычисления. Потому что автоматы (FSM) прекрасно синтезируются и без dual rail.
А картинки по метастабильности честно стырены с хабра, одна лично мной нарисована (про сетап и холд). Но не суть важно, просто в целом, с учетом вышесказанного, впечатление слегка подпорчено.
Кстати, по явлению метастабильности плохо написано, мне кажется, автор не до конца понимает материал. В часности, в западных лекциях обязательно рассказывается о MTBF, и чем специальные селлы-синхронизаторы отличаются от просто цепочки из защелок или флопов.
Есть еще китайские фабы. К примеру Ядро заявляло чип по тех. процессу, доступному на нескольких фабах, включая SMIC. Я не знаю, что будет с лицензиями на тулы, но китайцы врят ли запретят у них выпускаться. А может, и с лицензиями помогут. Мне кажется, тут есть еще место для маневра.
Это выводом средств называется. Разумеется, не бесплатно - смотрите тарифы банка на выводы валюты для ИП. Валютный контроль есть, насколько я понимаю, но если со своего счета на свой (а по другому никак), то подтверждающих документов не нужно, и вообще все просто. Правда, есть хитрый закон, когда счет могут заблокировать вместе с суммой на проверку длинной н-цать месяцев, но если вы не со сбером/втб работаете, то "шанс крайне мал". Кстати по закону, гражданам РФ запрещено делать переводы в валюте другим гражданам РФ. Только в рублях, и никак иначе. Причем запрещено, даже если вы живете за границей и налоговый резидент другой страны. Карается штрафом в размере суммы перевода - если узнают. Нормативный документ искать влом, сорри.
Это как если сравнить инструмент для сборки шкафа из икеи с набором из обрезных досок, фурнитуры, и кучи всевозможных инструментов от пилы до ручных резцов и приборчика по выжиганию. Вроде бы инструмент схожий и там и там, но вот количество, назначение инструмента, и число операций по сборке во втором кейсе - совершенно другое. Как и результат, к слову. Но, тут важно понимать, что автор статьи немного не в той области работает, о которой пишет здесь. Так что без углубления в детали выглядит как бы норм, а если углубляться .. лучше что то другое почитать
Если вас интересует мой личный опыт, то сумма была гдето очень близко к 6 млн, но не могу сказать - превышала или нет. Думаю, один год все же превышала. Что там банк с контрактом делал - без понятия. Контракт был зарплатный, с цифровой подписью, на фиксированную сумму, но при этом реальная сумма плавала в обе стороны очень сильно. Были и бонусы и авансы, и аут-оф-покет возвраты, и несколько месяцев платили заметно меньше. Никаких проблем. Проработал я так около 3 лет, потом закрыл ИП. Закрытие было ровно таким же, как и открытие - банк с налоговой договорился сам, а я только заявление сьездил подписать.
Я как бы вам с самого начала намекаю, что для работы это все знать не нужно. Можно разобраться, но не нужно. Тем более это не нужно, если материал для начинающих.
- валютный контроль, это любое зачисление валюты по инвойсу, не только изучение договора. Для пользователя прозрачно, делает сам банк.
- квартальные отчисления равно как и налоговые делает мобильная бухгалтерия. Снимает рубли со счета и сама шлет куда нужно (налоговая, ПФР и т.д.). Для пользователя прозрачно, нужно только счета подписывать.
- вопросом я действительно особо не владею, но это и не было нужно (в десятый раз уже пишу).
У меня складывается ощущение что в сбере вам там здорово по мозгам проехались. Нормальный банк (никакой рекламы!) - это условный 1% в добавок к УСН 6%, и никаких проблем и заморочек - ни с чем. По крайней мере, если у вас просто зарплатный контракт.
Отвечаю, с чем не согласен. Нет тонкостей, нет ухищрений, нет квартальных отчетов и нет прохождения валютного контроля. Для пользователя ничего этого нет. Все делает банк и мобильная бухгалтерия. Мой опыт ИП - с 2018 по 2020, т.е. не много, но и не мало.
Не согласен. Я не вижу смысла пугать людей тем, что было много лет назад и сбивает их с толку стеной текста. _Сейчас_ получение зарплаты в валюте через ИП описывается двумя предложенями, что я и продемонстрировал выше.
Если честно, то я вообще не понял, о чем столько текста. Мой опыт - открыл ИП на УСН, октрыл долларовый счет (модульбанк - не реклама), отослал им контракт, оплатил мобильную бухгалтерию, и каждый месяц отсылал инвойсы и получал на счет баксы, конвертил в рубли и слал на личный счет в тинькоф (не реклама). Все! Одним предложением.
Закрытие выглядело так же просто - подал заявление в налоговую, уведомил банк (они отослали что требуется). Все! Тоже одним предложением. Не напрягался ни разу.
Нет здесь курицы и яйца, все проще: групп проектирования мало, потому что заказчик один, т.е. рыночная экономика не работает и никогда не работала в российской микроэлектронике. Со всем вытекающим из этого факта.
Нну, все же рынок вакансий для программистов в РФ огромен, он просто гиганский. А по эсикостроению - практически отсутствует (по физ дизайну совсем отсутствует). Со всем вытекающими в виде зарплат и выбора ( выполняемых задач, коллективов, локации и т.д.). Зато этот выбор есть в Европе, о чем каждый раз напоминает автор данной публикации
В РФ действительно почти нет работы по обсуждаемой специальности. Байкал и Ядро не круглый год людей хантят, а команды физ дизайна в российский фирмах/нии - едва ли пара десятков человек, это вам не эппл с единицами тысяч. Т.е. рынок труда в этом сегменте очень маленький, в нем тесно, иногда на хедхантере месяцами нет вакансий. Студентов с удовольствием берут за копейки, а профессионалы боятся голову поднять, чтобы не уволили. Это очень очень плохая и нездоровая ситуация, длящаяся уже десятилетиями, не годами. В качестве примера выступаю я сам - почти год сидел без работы, и в результате уехал. Т.е. посыл обсуждаемой статьи мне лично совершенно очевиден - учиться, чтобы уехать. Проблема только в том, что наших не очень то и жалуют там, т.е. рецепт для уехать физ дизайнером - тоже весьма сомнительный, ведь будучи программистом это сделать куда как проще (просто по статистике). Т.е. как ни крути, а ребенка бы я не стал сейчас не то что на физ дизайн, а вообще в электронный вуз отдавать. Такое вот личное мнение
Про память с калькулятором - не понял связи. Лично я писал про: когерентность кеша, совместный доступ к памяти, реализации арбитров и семафоров, а так же про специализированные интерфейсы и фабрики.
На мой взгляд, знать об этом нужно хотя бы в общеобразовательных целях (собственно, задача обсуждаемого учебника), иначе снова получаем порядком устаревший курс. Да, работа над первым учебником была проведена колоссальная. Но, данный учебник уже третий, и пора бы сделать качественный шаг вперед (а не просто переписать несколько страниц под новую уархитектуру).
Нужно обязательно про многоядерность писать. Одно ядро - вчерашний день, сейчас даже микроконтроллеры стали многоядерными. При этом качественная разница между одноядерным и многоядерным процессором примерно такая же, как между однотактовой и конвеерной организацией вычислений. Для пятых рисков это наверное пока не очень актуально, а вот АРМ - да, учитывая что эппл отъело гиганский кусок рынка со своими М1 процессорами, основанными на АРМ64. Т.е. при всем многообразии организаций многоядерных вычислений появился совершенно четкий пример, как делать хорошо (архитектура М1/АРМ). Это давно уже не будущее, а настоящее (и лет 15 как прошлое), поэтому включать такой материал в учебник надо обязательно
Спасибо! Timing reports - уже показатель, что тул не просто так оптимизирует булевы функции, но и немножко смотрит на тайминг. Т.е. к примеру известен чисто математический минимизатор булевых функций - Espresso, и его гипотетически можно припрячь делать синтез, просто результат будет .. математический, т.е. от наших задач далекий. А вот чтобы смотреть еще и на тайминг при синтезе - это уже нужен STA-engine, так что Yosys здорово вырос в моих глазах.
Так, а нетлист (я его выше structural verilog-ом обозвал) точно не выписывается? Это как-бы основной результат синтеза, он должен быть. Расширения могут быть любые, но внутри - верилог.
Какие брали библиотеки, как подключали. Есть ведь, к примеру, в сети различные FreePDK с библиотеками селлов. Хочется видеть конкретные ссылки
Как используется топологическая информация при синтезе - грузится LEF abstract, или используется допотопный wireload? А как быть с макро ячейками?
Что получилось на выходе - просто structural verlog, или к примеру можно sdf выписать, а может быть даже timing_reports?
Тема очень интересная, а бесплатных синтезаторов как бы и нет больше (поправьте, если не прав). К сожалению, у самого пока руки не дошли этот тул попробовать, отсюда и вопросы. Спасибо!
Аргумент интересный и правильный, но вывод странный. Под совместимостью понимается преимущество использования архитектуры АРМ, полагаю. Но вот вопрос в том, а как Байкал будет покупать ядра АРМ следующих поколений (в условиях санкций). На мой взгляд, у АРМ в РФ нет будущего, надо искать другие ниши/архитектуры.
По x-talk/noise и защелкивание асинхронных схем напишу чуть подробнее.
Любая асинхронная схема так или иначе содержит RS защелки: в явном виде, либо в виде С-элемента, либо в составе NCL элементов. RS защелка это бистабильный триггер, для переключения которого нужен импульс с некоторой минимальной энергией. Для простоты будем считать что амплитуда сигнала фиксирована, и тогда вместо энергии можно говорить просто о длительности импульса, а однократное переключение будем считать импульсом с бесконечной энергией/длительностью. Так вот, если длительность импульса слишком мала, то переключения не произойдет, а если длительность чуть выше, но все равно недостаточна, то получим бистабильное состояние, выражающееся биениями/генерацией на выходе. У меня есть хорошая статья, поясняющая этот эффект. В нашем контексте, импульс это наведенное паразитное переключение.
А теперь представьте, что в Вашей NCL-подобной схеме какой то элемент сработал неверно за счет наведенного импульса. Сработал, и защелкнул неверное состояние. Вот об этой проблеме я и писал выше. Есть еще проблема защелкивания управления, но если его проектировать как и в синхронных схемах, т.е. с экранированием, то проблем быть не должно. В любом случае, нужны исследования.
Согласен со всем, и в частности с недостатком классического dual rail в виде орфанов и повсеместного нарушения DI. Но тут важно понимать, чего мы хотим добиться, и какой ценой. Поясню:
Наиболее серьезный недостаток асинхронных схем, это защелкивание (когда схема просто встает). Причем на практике стоит опасаться не эффектов вида SEU в где то в транзисторах (хотя и это случается тоже), а куда более распостраненного эффекта X-talk/ noise, который как Вы верно написали, в синхронных схемах маскируется клоком, а вот асинхронную схему просто убьет. Причем современные тулы проектирования топологии кристалла помогают снизить этот эффект до приемлемого (для синхронных схем) уровня, но полностью от этого избавиться может и не получится (для синхронных схем это не требуется). И я подозреваю, что данный аспект проектирования асинхронных схем пока вообще никто не изучал. Были пара американских патентов с троированием, и схемой watchdog, которая при срабатывании делала сброс, но .. это какие то убогие костыли, а не системное решение проблемы.
Получается, что на фоне борьбы с защелкиванием, проблеммы с чистотой DI смотрятся уже более чем бледно. И возникает вопрос - а может и вовсе не делать индикацию в логике? Ведь избавившись от индикации (в логике, но не в регистрах) кроме очевидного бенефита в виде скорости/площади/потребления мы получаем еще хоть и небольшую, но защиту от x-talk/noise - случись это где то в середине комбинационной схемы, отголоски такого сбоя могут и не докатиться до выходов. А могут и докатиться, тут как повезет. Скажем, если электромагнитный импульс был наведен снаружи, а не изнутри схемы, то ничего уже не спасет от защелкивания.
Итого, все зависит от задач и имплементации. Но если расставлять приоритеты, то может оказаться, что DI в комбинационной логике не нужно и даже вредно. Причем проблема x-talk/noise - электрическая, т.е. можно сменить CMOS на что то еще, но провода то останутся. Нужны исследования, не хватает практики. По борьбе с защелкиванием в асинхронных схемах практически ничего нет.
У NCL реализации комбинационных схем есть два серьезных недостатка:
Первое - в NCL каждый логический элемент ожидает окончание переходных процессов(ПП). Таким образом вычисление функции и ожидание окончания ПП происходит последовательно. В классическом же dual-rail подходе индикация окончания ПП производится параллельно с вычислением функции, а значит работает быстрее.
Воторое - NCL это проприетарная (!!!) библиотека элементов. Практически в каждом элементе сожержится защелка (С-элемент) для хранения состояния. И если сравнить реализации на NCL и классический dual rail с параллельной схемой индикации ПП, то во втором случае общее число таких защелок получится меньше, т.к. они используются более еффективно. По крайней мере, так получалось у меня в экспериментах, когда я занимался данной тематикой.
Итого, причины не использовать NCL более чем весомые. Да и сам метод dual rail (перекрестная реализация по Варшавскому) мне кажется сильно проще, особенно тем что можно использовать коммерческие синтезаторы синхронных схем DC / Genus. Т.е. приведенный в статье новый (?) метод синтеза - хорошо, но польза от него сомнительна.
В дополнение, и это уже много раз обсуждалось, в том числе и здесь, непонятно где вообще имеет смысл использовать dual rail кодирование для реализации асинхронных комбинационных схем. Не асинхронных схем вообще, а именно комбинационных, т.е. где требуются вычисления. Потому что автоматы (FSM) прекрасно синтезируются и без dual rail.
А картинки по метастабильности честно стырены с хабра, одна лично мной нарисована (про сетап и холд). Но не суть важно, просто в целом, с учетом вышесказанного, впечатление слегка подпорчено.
Кстати, по явлению метастабильности плохо написано, мне кажется, автор не до конца понимает материал. В часности, в западных лекциях обязательно рассказывается о MTBF, и чем специальные селлы-синхронизаторы отличаются от просто цепочки из защелок или флопов.
Есть еще китайские фабы. К примеру Ядро заявляло чип по тех. процессу, доступному на нескольких фабах, включая SMIC. Я не знаю, что будет с лицензиями на тулы, но китайцы врят ли запретят у них выпускаться. А может, и с лицензиями помогут. Мне кажется, тут есть еще место для маневра.
Это выводом средств называется. Разумеется, не бесплатно - смотрите тарифы банка на выводы валюты для ИП. Валютный контроль есть, насколько я понимаю, но если со своего счета на свой (а по другому никак), то подтверждающих документов не нужно, и вообще все просто. Правда, есть хитрый закон, когда счет могут заблокировать вместе с суммой на проверку длинной н-цать месяцев, но если вы не со сбером/втб работаете, то "шанс крайне мал".
Кстати по закону, гражданам РФ запрещено делать переводы в валюте другим гражданам РФ. Только в рублях, и никак иначе. Причем запрещено, даже если вы живете за границей и налоговый резидент другой страны. Карается штрафом в размере суммы перевода - если узнают. Нормативный документ искать влом, сорри.
Это как если сравнить инструмент для сборки шкафа из икеи с набором из обрезных досок, фурнитуры, и кучи всевозможных инструментов от пилы до ручных резцов и приборчика по выжиганию. Вроде бы инструмент схожий и там и там, но вот количество, назначение инструмента, и число операций по сборке во втором кейсе - совершенно другое. Как и результат, к слову. Но, тут важно понимать, что автор статьи немного не в той области работает, о которой пишет здесь. Так что без углубления в детали выглядит как бы норм, а если углубляться .. лучше что то другое почитать
Если вас интересует мой личный опыт, то сумма была гдето очень близко к 6 млн, но не могу сказать - превышала или нет. Думаю, один год все же превышала. Что там банк с контрактом делал - без понятия. Контракт был зарплатный, с цифровой подписью, на фиксированную сумму, но при этом реальная сумма плавала в обе стороны очень сильно. Были и бонусы и авансы, и аут-оф-покет возвраты, и несколько месяцев платили заметно меньше. Никаких проблем. Проработал я так около 3 лет, потом закрыл ИП. Закрытие было ровно таким же, как и открытие - банк с налоговой договорился сам, а я только заявление сьездил подписать.
Я как бы вам с самого начала намекаю, что для работы это все знать не нужно. Можно разобраться, но не нужно. Тем более это не нужно, если материал для начинающих.
- валютный контроль, это любое зачисление валюты по инвойсу, не только изучение договора. Для пользователя прозрачно, делает сам банк.
- квартальные отчисления равно как и налоговые делает мобильная бухгалтерия. Снимает рубли со счета и сама шлет куда нужно (налоговая, ПФР и т.д.). Для пользователя прозрачно, нужно только счета подписывать.
- вопросом я действительно особо не владею, но это и не было нужно (в десятый раз уже пишу).
У меня складывается ощущение что в сбере вам там здорово по мозгам проехались. Нормальный банк (никакой рекламы!) - это условный 1% в добавок к УСН 6%, и никаких проблем и заморочек - ни с чем. По крайней мере, если у вас просто зарплатный контракт.
Отвечаю, с чем не согласен. Нет тонкостей, нет ухищрений, нет квартальных отчетов и нет прохождения валютного контроля. Для пользователя ничего этого нет. Все делает банк и мобильная бухгалтерия. Мой опыт ИП - с 2018 по 2020, т.е. не много, но и не мало.
Не согласен. Я не вижу смысла пугать людей тем, что было много лет назад и сбивает их с толку стеной текста. _Сейчас_ получение зарплаты в валюте через ИП описывается двумя предложенями, что я и продемонстрировал выше.
Если честно, то я вообще не понял, о чем столько текста. Мой опыт - открыл ИП на УСН, октрыл долларовый счет (модульбанк - не реклама), отослал им контракт, оплатил мобильную бухгалтерию, и каждый месяц отсылал инвойсы и получал на счет баксы, конвертил в рубли и слал на личный счет в тинькоф (не реклама). Все! Одним предложением.
Закрытие выглядело так же просто - подал заявление в налоговую, уведомил банк (они отослали что требуется). Все! Тоже одним предложением. Не напрягался ни разу.
Если это в сбере столько хлопот - бегите оттуда.
Нет здесь курицы и яйца, все проще: групп проектирования мало, потому что заказчик один, т.е. рыночная экономика не работает и никогда не работала в российской микроэлектронике. Со всем вытекающим из этого факта.
Нну, все же рынок вакансий для программистов в РФ огромен, он просто гиганский. А по эсикостроению - практически отсутствует (по физ дизайну совсем отсутствует). Со всем вытекающими в виде зарплат и выбора ( выполняемых задач, коллективов, локации и т.д.). Зато этот выбор есть в Европе, о чем каждый раз напоминает автор данной публикации
В РФ действительно почти нет работы по обсуждаемой специальности. Байкал и Ядро не круглый год людей хантят, а команды физ дизайна в российский фирмах/нии - едва ли пара десятков человек, это вам не эппл с единицами тысяч. Т.е. рынок труда в этом сегменте очень маленький, в нем тесно, иногда на хедхантере месяцами нет вакансий. Студентов с удовольствием берут за копейки, а профессионалы боятся голову поднять, чтобы не уволили. Это очень очень плохая и нездоровая ситуация, длящаяся уже десятилетиями, не годами. В качестве примера выступаю я сам - почти год сидел без работы, и в результате уехал. Т.е. посыл обсуждаемой статьи мне лично совершенно очевиден - учиться, чтобы уехать. Проблема только в том, что наших не очень то и жалуют там, т.е. рецепт для уехать физ дизайнером - тоже весьма сомнительный, ведь будучи программистом это сделать куда как проще (просто по статистике). Т.е. как ни крути, а ребенка бы я не стал сейчас не то что на физ дизайн, а вообще в электронный вуз отдавать. Такое вот личное мнение
Про память с калькулятором - не понял связи. Лично я писал про: когерентность кеша, совместный доступ к памяти, реализации арбитров и семафоров, а так же про специализированные интерфейсы и фабрики.
На мой взгляд, знать об этом нужно хотя бы в общеобразовательных целях (собственно, задача обсуждаемого учебника), иначе снова получаем порядком устаревший курс. Да, работа над первым учебником была проведена колоссальная. Но, данный учебник уже третий, и пора бы сделать качественный шаг вперед (а не просто переписать несколько страниц под новую уархитектуру).
Нужно обязательно про многоядерность писать. Одно ядро - вчерашний день, сейчас даже микроконтроллеры стали многоядерными. При этом качественная разница между одноядерным и многоядерным процессором примерно такая же, как между однотактовой и конвеерной организацией вычислений. Для пятых рисков это наверное пока не очень актуально, а вот АРМ - да, учитывая что эппл отъело гиганский кусок рынка со своими М1 процессорами, основанными на АРМ64. Т.е. при всем многообразии организаций многоядерных вычислений появился совершенно четкий пример, как делать хорошо (архитектура М1/АРМ). Это давно уже не будущее, а настоящее (и лет 15 как прошлое), поэтому включать такой материал в учебник надо обязательно
Спасибо! Timing reports - уже показатель, что тул не просто так оптимизирует булевы функции, но и немножко смотрит на тайминг. Т.е. к примеру известен чисто математический минимизатор булевых функций - Espresso, и его гипотетически можно припрячь делать синтез, просто результат будет .. математический, т.е. от наших задач далекий. А вот чтобы смотреть еще и на тайминг при синтезе - это уже нужен STA-engine, так что Yosys здорово вырос в моих глазах.
Так, а нетлист (я его выше structural verilog-ом обозвал) точно не выписывается? Это как-бы основной результат синтеза, он должен быть. Расширения могут быть любые, но внутри - верилог.
Честно говоря, хотелось бы узнать
Какие брали библиотеки, как подключали. Есть ведь, к примеру, в сети различные FreePDK с библиотеками селлов. Хочется видеть конкретные ссылки
Как используется топологическая информация при синтезе - грузится LEF abstract, или используется допотопный wireload? А как быть с макро ячейками?
Что получилось на выходе - просто structural verlog, или к примеру можно sdf выписать, а может быть даже timing_reports?
Тема очень интересная, а бесплатных синтезаторов как бы и нет больше (поправьте, если не прав). К сожалению, у самого пока руки не дошли этот тул попробовать, отсюда и вопросы. Спасибо!