Shivers

Там выше ссылка на гайд по таймквесту - малтисайкл указан и по сетапу и по холду, это эти ключи и в стандарте SDC. Я лишь указал на важность того, чтобы правильно указывать число тактов, поскольку сам не раз налетал на эти грабли.

Иногда ПЛИС-макет, это еще и отдельный этап отчетности перед заказчиком. Прежде чем заплатить десятки-сотни килобаксов за запуск в производство, заказчик хочет убедиться, что разработка логической модели завершена, т.е. его не разводят. Как убеждать заказчика - показывать листинги кода и вейвформы? Куда нагляднее - демонстрация макета, работающего в железе, с работющим софтом. Конечно, это лишняя работа, но зачастую макетирование в ПЛИС - жесткое требование заказчика, прописанное в ТЗ.

Самое главное с малтисайклом, это что по сетапу указывается на 1 такт больше чем по холду. Если по сетапу малтисайкл 3, то по холду 2. Если по сетапу 5,то по холду 4. Если по сетапу 2, то по холду 1. и т.д.

Прототипирование в ПЛИС нужно для того, чтобы тестировщики начали писать программные тесты еще до того, как с фабрики придет микросхема. Софт не в три дня пишется, его тоже надо отлаживать, поэтому подобное распараллеливание сильно ускоряет общий процесс запуска микросхемы в серию. Ну и конечно, ПЛИС это дополнительная верификация - не всегда можно все промоделировать и надежно покрыть тестами, случаются и двойные ошибки - в тесте и RTL.

Спасибо за отзыв, очень любопытно! По собственному опыту (я писал парсер для сильного видоизменения нетлиста на Verilog-Perl) советую потестить с разными версиями DC/RC/Genus. Даже в DC от релиза к релизу бывают изменения. К примеру, я сталкивался с тем, что в DC одной версии к каждому неиспользуемому порту подключается *LOGIC0*, а в другой версии заводится цепь с assign XXX=0; , а потом уже эта цепь заводится на все порты. В общем, бывают всякие чудеса, надо хорошенько все тестить. На Verilog-Perl я проблем почти не имел, поскольку библиотека отлажена уже много лет. Но зато и код не защитить, не скомпилировать в бинарник. Т.е. я понимаю, почему Вы затеяли писать все с нуля. Про Liberty - удивлен что используете. Зачем это Вам? А если уж решили все проверять, то и LEF грузите - бывает что нетлист выгружен с ключем physical, когда и цепи питания и аналог выписываются - их в Liberty может и не быть, зато в LEF присутствуют обязательно.

А что open source? Если бы у нас скачали эти исходники и спроектировали бы аналогичный чип с 1024 ядрами, то его никак не изготовить по технологии ниже 28нм - запрет США на экспорт технологий (все современные заводы на американском оборудовании работают). Да и на 28нм не сделать - существует куча ограничений на микросхемы для России, и такой чип точно не пропустят. А раз чип нельзя сделать, то его можно только купить - но и тут действует запрет на экспорт технологий. Санкциями обложили очень плотно, это не шутки. Единственный шанс пощупать такой чип - прошить его RTL модель в кластер из ПЛИС, и гонять на пониженной частоте( поскольку полную частоту на ПЛИС вытянуть вряд ли получится). Это если исходники достанете. Ну или на эмуляторе типа QEMU поиграться. А вот оригинальный чип в Россию ввезти не удастся, имхо.

Сделан с софинансированием DARPA? Боюсь, вы этот процессор только в подкладке пальто вывезете, с риском присесть лет на 10 за шпионаж. Абсолютно уверен, что этот чип попадает под ограничения экспорта технологий из США.

Вероятность сбоя на выходе синхронизатора мультипликативна - при добавлении в синхронизатор дополнительного триггера, она умножается на вероятность сбоя этого триггера. Судя по формулам, вероятность сбоя при удвоенной частоте на входе и 4х триггерах такая же, как при ординарной частоте входного сигнала и двух триггерах в синхронизаторе. Об этом кстати явно написано в статье по ссылке выше.

Наверное всем будет интересно: оказывается, RISC-V делают и в РФ, причем давно. Кремниевое отделение Тэкон изготовило один SoC с 32-х разрядным ядром RISC-V, а сейчас разрабатывает и 4-х ядерную версию. Процессоры предназначены, я так понимаю, для внутренних нужд Тэкон (АСУ). Было бы интересно услышать от самого Тэкона, что за процессорные ядра у них - купленные, скачанные из интернета, или сами разрабатывали.

А чего удивляться .. далеко ходить не надо - efabless.com разработка аналоговых айпи в облаке. Прямо в окне браузера открывается виртуальный десктоп, где установлены все тулы и PDK - работай не хочу. Причем все бесплатно (пока?), а готовое айпи потом продавать можно через тот же сайт. Для ПЛИС наверняка сделают то же самое, со временем.

На мой взгляд, пока в ВУЗах не введут моду приглашать лекторами спецов с производств (т.е. людей с большим практическим опытом), никакого толку от реформ не будет. А то, что делают сейчас - это на безрыбье добивают выживших. Безрыбье - поскольку что советские кадры, что молодежь, всем им очень далеко до современного уровня. У преподов советской школы хоть базовые знания отличные, а молодежь, которая сама в 90е или нулевые в ВУЗах училась - и того нет. По хорошему, надо беречь и тех и других, поскольку старики больше знают, а молодые еще могут научиться. Сокращают конечно же стариков в первую очередь.

По поводу алгоритма STA, на основе констрейнтов и библиотек элементов строится ациклический граф (DAG - directed acyclic graph), а уже по нему ведется расчет задержек. Меняем констрейнты - меняется граф, и меняется алгоритм расчета. Если граф содержит асинхронные арки, расчет ведется неверно. На эту тему можно почитать здесь: https://habrahabr.ru/post/273849/ Собственно, из представления графа в ациклическом виде и следует в первую очередь, что интерфейсы надо констрейнить через set_input_delay. Иначе, не будет части графа, ответственной за интерфейс, а будет просто обрубок на пине микросхемы. Но спорить на эту тему надоело

Про анализ тоже не понял. Обе схемы - двухтактные асинхронные триггеры с парафазным кодированием информации и двумя фазами передачи данных. Вторая фаза - спейсерная, код 00. Первый триггер имеет синфазный вход разрешения записи. Индикации окончания переходных процессов нет - это не самосинхронные схемы. Больше ничего проанализировать нельзя =)

Собственно, науку сейчас гробят изо всех сил. Почему? Потому что науку всегда толкали студенты и аспиранты. Уровень студентов и аспирантов в ближайшие лет 5 очень заметно просядет, поскольку с подачи неких управленцев из ВШЭ, и дебилов из нашего (речь о России) правительства, затевается масштабная реформа ВУЗов. Реформа затеяна из за того, что выполняя распоряжение главного, придумали способ повысить зарплаты преподам. Как? А просто - их увольняют, до 70% штата, самых образованных, еще Советской школы. Прикрывается это тем, что кафедры и факультеты расформировываются, а на их месте создаются т.н. центры и/или под-институты. При этом число кадров, разумеется, сокращается в разы. Таким образом в Москве уже "реформирован" МИЭМ, последний год доживает (каким его всю жизнь знали) МИФИ, и полным ходом готовится реформа Питерского Политеха. Это только из того что я знаю. Далее, после реформы РАН несколько лет назад, в разы упало число защит кандидатских. Сейчас многие дис. советы хорошо если одну защиту в год проводят. Все в совокупности выглядит как резкое обескровливание науки. Т.е. она не сама медленно загибается, а последние два-три года ее именно что душат, с особым цинизмом. Так чего же тогда ждать от научных журналов, хоть и ВАК?

На основании чего сделан вывод, что клок считается? Обратите внимание, что в синхронном пути должен быть Source (Launch) clock и Destination (Capture) clock. Клок, о котором Вы пишете, считается в обоих случаях только для Destination (Capture) clock. А для Source (Launch) clock расчет есть только в одном репорте из двух. Да, в репортах есть строка Source Clock Delay (SCD): 0.000ns Но это может означать две вещи - либо задержка нулевая, либо этого клока вообще нет. Поэтому надо смотреть непосредственно на трэк распространения сигнала. В одном случае это Location Delay type Incr(ns) Path(ns) Netlist Resource(s) ------------------------------------------------------------------- ------------------- G2 0.000 0.000 r rxframe (IN) net (fo=0) 0.000 0.000 rxframe G2 IBUF (Prop_ibuf_I_O) 0.994 0.994 r rxframe_IBUF_inst/O net (fo=1, routed) 0.000 0.994 rxframe_IBUF ILOGIC_X1Y83 ZHOLD_DELAY (Prop_zhold_delay_DLYIN_DLYIFF) 6.691 7.685 r frame_reg_OPT_INSERTED/DLYIFF net (fo=1, routed) 0.000 7.685 OPT_ZHD_N_frame_reg ILOGIC_X1Y83 FDRE r frame_reg/D а в другом Location Delay type Incr(ns) Path(ns) Netlist Resource(s) ------------------------------------------------------------------- ------------------- (clock rxclk rise edge) 0.000 0.000 r input delay 12.600 12.600 G2 0.000 12.600 r rxframe (IN) net (fo=0) 0.000 12.600 rxframe G2 IBUF (Prop_ibuf_I_O) 0.994 13.594 r rxframe_IBUF_inst/O net (fo=1, routed) 0.000 13.594 rxframe_IBUF ILOGIC_X1Y83 ZHOLD_DELAY (Prop_zhold_delay_DLYIN_DLYIFF) 6.691 20.285 r frame_reg_OPT_INSERTED/DLYIFF net (fo=1, routed) 0.000 20.285 OPT_ZHD_N_frame_reg ILOGIC_X1Y83 FDRE r frame_reg/D Во втором примере переходной процесс начинается с Delay type - clock rxclk rise edge, что трактуется как выходной триггер устройства-формирователя шины синхронного интерфейса, далее input delay - задержка выходных каскадов (падов) этого устройства + задержка на плате, и затем переходной процесс заходит в микросхему. В то же время в первом репорте нигде не указано ни что интерфейс синхронный (Delay type - clock блаблабла), ни по какому клоку работает. Поэтому, в первом репорте приведен асинхронный путь сигнала.

Ну почему же, я очень ясно написал: Другими словами, если у Вас в репорте в строках Source и Destination присутствует фраза "clocked by", и указан один и тот же клок, то это синхронный путь.

Честно говоря, даже не знаю что и добавить. Это определенно разные репорты, поскольку один синхронный, а второй асинхронный, что следует из текста репортов. Был задан вопрос в чем разница, и был дан ответ. Если Вас устраивает констрейнить синхронные интерфейсы асинхронными констрейнтами - Ваше право.

Отлично, Вы привели второй репорт для Setup. Что в нем есть: clk_bf - это интерфейсный клок. input delay - внешняя задержка. Есть приемный клок- тоже clk_bf. Это чистый синхронный путь, такой каким он и должен быть. Слэк положительный - нарушений Setup нет. Такие же пути должны быть во всем проекте, если он синхронен. Резюмирую: с input delay Вы получаете правильный граф и правильный STA, а с max_delay получается недоконстрейненный проект, и из-за этого асинхронные пути. Делать вывод о работоспособности схемы основываясь на асинхронных репортах - неправильно. При чем тут Vivado или ASIC мне не понятно - у Вас STA не работает.

О чем я и писал - Вы привели репорт для асинхронного пути. Если делать репорт для синхронного интерфейса, то в Source будет Launch clock, а не входной пин. Попробуйте выписать timing_report для любого пути register 2 register, и сравните.

Сделайте report_timing до входа Вашего триггера через входной пин. С set_input_delay получите честный синхронный путь с правильным launch clock и capture clock. А если наложен констрейнт set_max_delay то в репорте, насколько я понимаю (сам никогда такими экспериментами не занимался) должна получиться ерунда (асинхронный или анконстрейнед путь). Еще момент - Вы check_timing делаете? По идее, если интерфейсы обконстрейнены через set_max_delay, то должны посыпаться ошибки.

Принципиальное отличие в том, что set_input_delay выглядит на графе как виртуальный триггер, работающий на одном из клоков. Т.е. этот констрейнт используется при накладывании ограничений на синхронный интерфейс. Если же интерфейс асинхронный, то с set_input_delay нужно использовать с виртуальным клоком. А set_max_delay - это ограничение на задержку асинхронных арок (т.е. не привязано к клоку), очень редко используется внутри схемы. Для синхронных интерфейсов этот констрейнт совершенно бессмысленен, а для асинхронных - все же обычно используют виртуальный клок с set_input_delay. p.s. вот, меня опередили =)

Разница принципиальная, что следует из названия. set_max_delay - контролирует длины любых арок графа. А set_input_delay относится только к интерфейсам - часть графа, которая достраивается вокруг схемы на основе констрейнтов. p.s. set_max_delay обычно не используют, он избыточен, поскольку пути reg2reg контролируются периодом клока, а интерфейсы - input_delay/output_delay

а ASIC делать не планируете?

Нашел исходники какого то простенького ядра risc-v на верилоге https://github.com/ucb-bar/vscale Но так почитал, оказывается Chisel вполне себе HDL язык, поскольку существует транслятор в верилог. Т.е. гипотетически можно взять открытые сорцы rocket-chip на Chisel и прошить их в ПЛИС. А тем временем выложили слайды с конференции 5th RISC-V Workshop https://riscv.org/2016/12/5th-risc-v-workshop-proceedings/

Плавает, конечно. Не плавают те, кто постит в IEEE, а не хабр ;) Да и то не факт По пункту 5 - пост все же о метастабильности, а не STA. Хороший гайд по STA+CDC получится объемом не меньше, а может быть даже больше. Есть желающие написать? Я бы почитал p.s. Вы просили спайс модели - там в комментах есть ссылки на FreePDK 45