Comments 17
А GTKWave очень тормозит когда у вас чуть больше сигналов, чем в игрушечном примере.
Странно, я как-то использовал GtkWave в большом проекте, и его внутренний формат дампов FST оказался эффективнее чем FSDB используемый в Synopsys. И на трассах в несколько гигабайт особенных тормозов не было. Да и сам разработчик GtkWave, который сейчас работает в AMD, утверждает что дебажит в нём симуляции CPU ядра Zen.
Возможно вы просто используете текстовые VCD дампы?
Да. А Икарус умеет производить что-то другое чем текстовые VCD дампы? (сейчас погуглю)
Я также со скепсисом отношусь к тому, что на GTKWave якобы можно эффективно дебажить большой процессор. Например он не умеет искать drivers и loads сигналов, как умеет это делать Cadence SimVision и Synopsys Verdi. Это одна из часто используемых ежедневных операций. Или я чего-то пропустил с GTKWave?
Смех-смехом, а я с помощью yosys сейчас пытаюсь синтезировать схемотехнику вычислителя на элементах струйной логики, а также схему соединений будущего лампового компьютера - эмулятор на верилоге с помощью библиотеки элементов, которые я могу сделать на пневмонике/лампах превращается в схему соединений будущих модулей. Жаль синтезированную схему не получается пока засунуть в kiCAD виде нетлиста - приходится для струйного процессора вручную перерисовывать схему.
В теории даже openRoad можно будет прикрутить, где чипом будет шасси, а элементами - модули. И он мне схему соединений - жгут проводов между ними - засинтезирует.
Надо же, я представлял такое теоретически, но чтобы кто-то реально стал делать гидравлический компьютер с синтезом из Верилога 8-)
Не путайте пневматику и гидравлику - которые работают клапанах и давлении - с пневмоникой - на базе эффекта прилипания струй. Базисом в нем является элемент 2OR-2NOR, и сумматор на нем довольно легко синтезируется.
Вообще интересный проект выходит - синтез схемы в yosys, потом разработка платы соединительных каналов в kicad, проверка корректности работы струйного элемента с помощью симуляции в openFOAM. Прям openSource-процессор для пост-апокалипсиса. Даже электричества не надо для работы, только воздух - можно запитать от баяна, или органа.
Вот как раз со стадией переноса в KiCAD пока проблемы - простую схему можно и вручную быстро перерисовать. Но хотелось бы автоматизации, тогда можно будет в yosys скармливать библиотеку, например 155 и 555 логики, а на выходе получать синтезированную схему процессора на микросхемах малой степени интеграции
>Skywater скооперировалась не только с Пентагоном для его радиационно-устойчивых нужд, но и с компанией Гугл, которая спонсирует молодых гениев,
DARPA программа 3DSoC, статья супер интересная, вперед и вверх!
П.С. С habrastorage какая та проблема, не отображаются картинки. Пришлось дочитывать через TOR
Юрий, вот вы интересно заголовок написали, про 3нм и 130нм. Да, понятно, что для цифрового дизайнера (RTL) разницы нет, под какой процесс писать код. Или, все таки, есть разница?
Начну издалека. Напомню, что частю работы по разработке эсика является верификация, в т.ч. симуляция пост-лейаут нетлиста. С задержками. Проверить те вещи, которые не видит STA. Далее, задержки (SDF) выписываются с помощью STA-тула. А в чем разница в STA на 3нм и 130нм? Разница - статистический STA на тонких процессах. В котором при расчете задержки пути, задержки складываются квадратически, а не линейно. Может так RTL симулятор считать задержки статистическими формулами? Нет, не может. Да и SDF не поддерживает статистические данные. Так как же быть, как симулируют нетлист с задержками на 3нм? Поделитесь опытом. Раз уже упомянули 3нм
Разница есть - разный static timing analysis, особенно с учетом floorplan. Также разные библиотеки памяти и энергопотребление - скос в динамическое.
Мой заголовок о том, что если нет доступа к 3 нм, то это не означает, что нужно ждать у моря погоды, вздыхая "ах, отрезали санкциями, ох, какой смысл, зачем этот навоз мамонта ворошить". Суть в том, что учиться можно и на 130-нм, и в будущем применить это знание.
*** Так как же быть, как симулируют нетлист с задержками на 3нм? ***
Это не симулируют. Точнее где-то в конце может и симулируют, но вообще просто регулярно делают STA с учетом floorplan и после place & route. Вы это можете видеть на диаграмме - STA делается несколько раз - сначала после синтеза, потом после физического размещения. Причем на тонких техприцессах разница может быть 30% и выше. STA с учетом place & route идет долго, поэтому его делают нечасто. Деталей алгоритма я не знаю к сожалению.
Раньше симулировать надо было, ведь только так можно протестировать исключения (иначе - отловить баги) в констрейнтах, которые STA не видит. Но, это вы дизайном занимаетесь, не я. Раз сказали не симулируют, значит стали как то по другому проверки делать. Спасибо за ответ.
А что касается STA в P&R, то его гоняют на всех этапах: до и после плейса, после CTS, route, и конечно в конце, в специализированном signoff туле после сделанной полноценой экстракции паразитов из GDS. Это я уже как специалист говорю.
Есть тулы для верификации констрейнов для случаев multicycle path и подобных которые работают независимо от STA. Я про них может напишу потом - я сейчас на самолет собираюсь
Да, я вспомнил что в Juniper в конце проекта на 7 нанометров далали gate-level simulations, но эти занималась physical design team. Еще gate-level simulation нужен для оценки динамического энергопотребления на уровне блоков. Но вообще чем дальше к back-end, тем я более смутно все представляю - я все-таки front-end logic designer.
Для оценки потребления не обязательно симулировать нетлист с задержками, да и вообще симулировать нетлист - достаточно и симуляции RTL. Второй вариант более универсален, но требует переноса полученной переключательной активности RTL на нетлист, а для этого нужно иметь таблицу соответствия имен регистров и цепей, которые меняются во время синтеза. В целом, проблем нет, но нужно писать транслятор (или покупать готовый). Знаю, поскольку раньше занимался дизайном, и приходилось такое делать.
В моем понимании, везде где есть симуляция (того же нетлиста, или для оценки потребления) - это еще фронтенд. Но уже почти на стыке с другими дисциплинами, согласен.
*** Для оценки потребления не обязательно симулировать нетлист с задержками ***
Synopsys PrimeTime PX требует (по крайней мере я его применял в этом режиме). Он на входе берет результаты симуляции gate-level netlist с исходной testbench для RTL, а также файл с parasitics сгенеренный синтезом. А вот скажем с Power Artist вроде не так (хотя я сейчас в сонном состоянии и могу перепутать)
Здесь нет противоречий с тем, что я писал. Действительно PTPX/Voltus на входе берет нетлист, экстракцию, и - файл переключательной активности элементов. А вот уже как делать этот файл переключательной активности - возможны варианты. Я писал о том, что не обязательно симулировать тот же нетлист, что грузится в PTPX, можно обойтись и RTL.
Можно ли тренировать чиподелов на 3 нанометра упражнениями с 130 нм? А упражнениями с 20000 нм?