Shivers

Компрехенсив гайд по метастабильности: https://habrahabr.ru/post/317514/

Не sdf, а sdc Нетлист блоков получать не обязательно, достаточно просто RTL загрузить. И, как уже писал, очень желательно потом руками пожать в выписанных констрейнтах запас по интерфейсам. Удобно это делать скриптом, к примеру на perl - ужимать все на 10-15%, скажем.

Если совсем грубо, то внутри PHY есть FIFO, у которого со стороны десериалайзера одна частота и разрядность, а в сторону Core другая частота и другая разрядность. Плюс, может быть опция декапсуляции принятого пакета с проверкой четности. В PIPE эту проблему решает Elastic Buffer, а в RIO еще и добавляется пересинхронизация данных, поскольку сердес работает на восстановленной частоте (clock recovery). И еще о буферизации, если есть несколько последовательных каналов, работающих в параллель. Представьте, что у Вас два последовательных канала параллельно принимают информацию. С первого десериалайзера идет поток данных, и идет поток данных со второго десериалайзера. А теперь представьте, что из-за асинхронности и разбежки фаз в последовательных каналах, оба потока сдвинуты друг относительно друга на один-два такта. Чтобы их выровнять, нужен еще один буфер - он к PHY уже отношения не имеет, и ставится в самом контроллере. По поводу IP - либо Вы используете восстановленный клок на приеме (как в RIO), либо у Вас все устройства на плате работают от одного генератора (как в PCI-E). Можно купить только SerDes (опционально с clock recovery), можно купить целый PHY (PIPE интерфейс в случае PCI-E). Как называется PHY интерфейс в RIO, я не помню; cкорее всего обычный TBI, а все остальное должен делать сам контроллер.

Почему SOI - именно аналоговая технология? То же самое что и объемный кремний, делай что хочешь. Есть небольшой нюанс проектирования топологии (антенны), но не более того. И что за фабрика, где нет IP? Если речь о Микрон 250КНИ, то сердес должен быть. По поводу высокоскоростных PHY, основная проблема это выравнивающий буфер: поскольку в линиях передачи может гулять фаза, то приемный буфер (находится после десериалайзера) обязан эту фазу выровнять. Если сердес заменяется на что то другое - к примеру несколько LVDS впараллель, то приемный буфер все равно нужен. Впрочем, если хост и эндпоинт тактируются с одного генератора (как в pci-e, к примеру), то наверное можно обойтись и без буфера. Почитать обо всем этом можно, погуглив PCI-E Intel PIPE interface. Там это называется Elastic Buffer.

А не проще вивадо позапускать с разными камнями? С автовыбором пинаута Вы в общих чертах определитесь, какой кристалл Вас устраивает по частоте. Потом сделаете полностью проект под этот камень и конкретную распиновку (если есть готовая тест-борда на примете), удостоверитесь что частота устраивает. Как то так.

Да все эту функцию используют, любой мало-мальский SoC удобнее синтезировать bottom-up, особенно когда еще меняется RTL. Другое дело, что в некоторых случаях проще констрейнты на блок руками написать, чем использовать characterize. А маршрут очень простой: загружаете RTL всего проекта, накладываете констрейнты, потом characterize, а потом write_sdc. И еще полезно слегка поджать то, что выпишется в sdc. Затем синтезируете каждый блок отдельно (можно даже сделать layout) и потом выписываете .lib/.db И, наконец, грузите RTL верхнего уровня + .db на блоки и пускаете синтез. Для отладки скриптов рекомендую потренироваться на кошечках: взять, к примеру, процессор из DC/DV-туториала, и синтезнуть его поблочно.

Прочитайте сначала этот пост на хабре https://habrahabr.ru/post/273849/ В расчеты можно не вникать (хотя желательно), а вот как строится граф - надо разобраться обязательно, это основа STA. А потом очень советую изучить эту книгу http://www.springer.com/us/book/9780387938196 с описанием всемх констрейнтов, какие бывают. Это лучшая книга, какую видел по STA, и отлично качается с либгена в формате PDF.

Я лет так на 10 отстал от темы, но разве пакет Cadence PSD для линукса не содержит Concept HDL+Allegro+SIP? Когда то работал в Concept HDL, и он меня полностью устраивал: ввод схем, создание библиотек. А маршрут действительно сквозной, поскольку чертеж корпуса микросхемы делается в SIP на основе данных из Innovus, а затем импортируется в библиотеку Concept HDL. Получается маршрут от микросхемы до печатной платы. Только стоит этот маршрут ...

Частоту двигать не стоит, поскольку дерево в ПЛИС фиксированное, и это может затруднить работу фиттера. Лучше буферы в данные добавлять. Фокус вот в чем. Предположим, есть эндпоинт - приемный триггер. До его входа есть критический путь setup (самый медленный), и есть критический путь hold (самый быстрый). Эти два пути не совпадают, разумеется. Далее, если буфер поставить просто на входе триггера, то выправите Setup но угробите Hold. Поэтому надо быть хитрее: найти общий элемент в обоих путях (критические сетап и холд), у которого через один вход проходит критический путь setup, а через другой - критический путь Hold. Понимаете фокус? Тогда буфер можно поставить на холдовый вход этого элемента: так и сетап не загубите, и холд вытащите. Вот только это техника из ASIC-ко строения, я не уверен что можно в ПЛИС таким тюнингом заниматься. Если получится, напишите, любопытно. p.s. И еще раз отошлю к своей статье на хабре https://habrahabr.ru/post/302806/ Там очень подробно опино о природе нарушений сетап и холд, и о том, как с нарушениями бороться.

CPPR - Common Path Pessimism Removal занимается тем, что выравнивает задержки клока вплоть до последней общей точки. Начиная с этой вилки клоки до StartPoint и EndPoint идут по разному. Отрицательное время - это значит, что клок пришел раньше; к примеру, фаза могла быть сдвинута PLL. Так и считается нарушение Hold: наихудший случай, это когда источник сработал очень рано, а клок приемника пришел очень поздно. Почитайте эту статью на хабре про сетап и холд https://habrahabr.ru/post/302806/ clock pessimism в данном случае определяется исключительно результатами работы фиттера; поскольку дерево клока в ПЛИС не одинаково, то фиттер может расставить триггер-источник и триггер-приемник как с положительным clock pessimism, так и с отрицательным, причем значение clock pessimism тул очень точно рассчитывает, здесь нет каких прикидок и погрешностей - как тул написал, такой точно clock pessimism и будет в конкретно данной разводке. В Вашем случае clock pessimism получился отрицательным, почему - не знаю, надо у фиттера спросить.

Я это к тому, что ядро - всего одно пока, а чип по ссылке - один из тех 15, о которых написано на сайте risc-v.org Других ядер видимо пока нет. Что касается CHISEL, то я так и не понял - какие синтезаторы его поддерживают? А вот объяснения авторов о выборе языка https://www.quora.com/What-exactly-is-the-p...e-pros-and-cons

Это все то же ядро Rocket-chip из Беркели, с инструкциями RISC-V и продвинутыми кэшами. Исходники открыты, но кто умеет писать на CHISEL? Чтобы это ядро пощупать, нужно ждать, когда его кто нибудь портирует на более привычный HDL. Хорошо ребята зашифровались, нечего сказать.

Наткнулся на такую статью http://www.eejournal.com/archives/articles...crosemi-risc-v/ Похоже я был не прав, говоря о бесполезности опен сорс ядер. В ПЛИС может и взлететь за счет массовости. Очень понравился этот кусок, к вопросу об архитектуре и ISA:

В этом случае Вы нерационально используете ресурсы ПЛИС, поскольку обычно все триггеры имеют асинхронный сброс, который заведен на глобальные трассы. Синхронным сбросом Вы занимаете дополнительные региональные трассы роутинга для логики, усложняете саму логику, и тем самым получаете больше размер и ниже частоту. Классическое описание регистра на верилоге, это always @(posedge clock or negedge async_reset) if (~async_reset) Q <= 1'b0; else Q <= (sync_comb_set | ~sync_comb_reset & Q); либо else Q <= ~sync_comb_reset & (sync_comb_set | Q); Это самый кандовый и потому работающий рецепт для правильного описания синтезируемых D-триггеров на верилоге. Здесь присутствует асинхронный глобальный сброс (сам сигнал сброса должен быть синхронным этому клоковому домену), комбинационная формула установки триггера, и комбинационная формула сброса триггера. Т.е. все разложено по полочкам, надо лишь подставить нужную логику в нужное место формулы триггера. Если появляются дополнительные условия для сброса триггера - они просто замешиваются в формулу sync_comb_reset.

Есть еще третий вариант - с выхода комбинационной логики нет роута к трассе регионального сброса. И четвертый вариант, что такая схема вообще запрещена. Я бы все же посоветовал выход логики использовать как синхронный сброс (или просто ввести в код формирования данных на входе триггеров), а цепь асинхронного сброса не трогать. Комбинационная логика в цепи сброса - моветон, хоть и не запрещена.

Обратите внимание - этот сброс на рисунках Асинхронный! Он обязан синхронизироваться в целевой клоковый домен, но затем используется на Асинхронных входах триггеров. Конечно, его можно использовать и как синхронный сброс, но это бесполезная трата ресурсов ПЛИС. Можно, но в таком случае Вы теряете в ресурсах ПЛИС, поскольку число трасс для глобальных и региональных сбросов ограничено. Причем, Вы можете сначала синхронизировать сброс, а потом завести в логику, а можете наоборот - сначала смешать с логикой, а затем синхронизировать.

Я не очень понял вопроса про модели выходов. Имеются ввиду какие то эквивалентные схемы замещения моделей транзисторов? Я использовал модели транзисторов TSMC 65нм (BSIM4), и элементы из этой же библиотеки: логику, триггеры. Все это NDA, публиковать не могу. Для обычного D-триггера пробовал вычислять постоянную времени и окно метастабильности. По моим расчетам, на частотах около гигагерца (CDC) метастабильность должна возникать на выходе триггера раз в несколько секунд. Если брать килогерцы, то - раз в миллионы лет. Расчеты делал для себя, они очень грубые; и я не готов их публиковать.

Я моделировал эти режимы на спайсе для 65нм, в т.ч. и токи "КЗ", когда у инвертора открыты оба транзистора. Сопротивление между шинами в этот момент - килоОмы, так о "КЗ" речь вообще не идет! Не будет ни нагрева, ни повышенной электромиграции, ничего. Просто, течет чуть повышенный ток. Кому известно, где это написано? Если схема состоит из одного транзистора и десяти логических элементов, то ток вырастет заметно. А если в схеме транзисторов - миллионы, и один попал в метастабильность, то разницу в потреблении ни один прибор не увидит. Метастабильность конечно распространяется в логике, но через 3-5 вентилей уровень сигнала достигает нижнего или верхнего порога, и дальше уже идет нормальный сигнал.

По поводу Flex 10KE - это последняя серия Flex 10K сделанная по 220нм 2.5В. К примеру, 10КА -300нм 3.3В, а 10К - 420нм 5В. Разница конечно не только в питании, но и в скорости. А в остальном это одна и та же архитектура.

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

Так а всеж таки, зарелизена уже какаято ISA, рекомендованная к производству и имеющая рабочий тулчейн, или это все пока прожекты на будущее?

Метастабильность бывает только у триггеров (бистабильных элементов). При этом, все равно какой триггер - Шмитдта, на элементах И, ИЛИ, либо сделанный на проходных ключах и двунаправленных буферах. Абсолютно любой триггер может попасть в метастабильное состояние, это доказано с помощью математики в Theory of metastable Operations. Условие для возникновения метастабильного состояния - энергии переключающего импульса(ов) недостаточно, чтобы полностью переключить триггер, но и обратно в стабильное состояние триггер вернуться уже не может, и как бы подвисает в некоем устойчивом состоянии между логическим нулем и единицей. Время выхода из метастабильного состояния определяется распределением по Пуассону и может теоретически достигать бесконечности. На практике всегда присутствуют тепловые токи, которые выводят триггер из метастабильного состояния. Можно рассчитать вероятность попадания триггера в метастабильное состояние. К примеру, такой расчет проводят для CDC - Clock Domains Crossing. Двух триггеров достаточно, чтобы метастабильность возникала раз в несколько лет, трех триггеров - раз в несколько миллионов лет. Но всегда остается шанс, что даже три триггера не защитят от метастабильности на выходе. Сопротивление открытых КМОП каналов очень велико и токи низкие, поэтому никакого жуткого потребления и нагрева нет. Метастабильность плоха только неправильной интерпретацией схемы логического уровня - к примеру вместо 0 схема отработала 1, это считается сбоем.

Из того что я видел, самое полезное - добавлять номер стадии в качестве индекса в название каждой переменной. А еще лучше добавлять в начало названия (префикс) - очень потом помогает при отладке. А пишут кто как: кто то разделяет куски кода разных стадий комментариями, а кто то пишет в одну кучу.

Вопрос из серии "на заборе тоже написано". Задумайтесь, кто учил этих людей, и где? В РФ образования в нашей области считайте что нет: преподают одни самоучки без опыта реальных проектов, без опыта разработки САПР, да вообще без опыта (никоим образом не хочу обидеть уважаемых преподавателей: это не их вина, как и в 10-15 летнем отставании страны в области электроники). Поэтому реальный вес имеет инфа только на известных зарубежных сайтах вроде этого: http://www.asic-world.com/examples/verilog/d_ff.html Берите и пользуйтесь. И не будете иметь проблем с синтезом. А кто еще как пишет, или даже учит студентов - да какая разница? Это их проблемы. Реальность такова, что писать правильно синтезируемый RTL исключительно скучно - достаточно просто использовать всего 3-4 стандартных шаблона на верилоге. А хотите изысков, раскрыть все возможности языка - идите в верификаторы. Собственно, из RTL-кодинга есть два пути дальнейшего профессионального роста - если Вы больше тяготеете к программированию, то лучше свернуть в верификацию, там больше возможностей развернуться. А если Вам ближе схемотехника, то лучше уходить в синтез, STA и далее в бэк енд (впрочем, программировать и там придется не меньше, только не на верилоге, а на tcl). А выдумывать велосипед - новое описание триггера на верилоге .. хмм .. ну, удачи :-)

+1. В самых лучших IP-ядрах, с которыми работал, так и делалось - одна олвейз конструкция на один триггер, и к нему еще две строки комментариев что этот триггер делает. Существуют определенные даже не правила, а рекомендации по объединению: в общий олвейз блок помещаются регистры с общим клоком и сигналом сброса, либо с общим клоком и вообще без сброса. Компилятору так проще обрабатывать RTL, поскольку он понимает что под общей олвейз конструкцией находятся однотипные триггеры. Эти рекомендации я видел то ли в доках Synopsys, то ли в статьях SNUG; сейчас искать уже не возьмусь. Безусловно, это - рекомендации, их соблюдать не обязательно, но желательно (чтобы однажды не споткнуться на ровном месте). Видите ли, Вы задаете в начале вопросы новичка, а затем выясняется, что ответ вроде бы знаете. Спрашивается, а зачем тогда вообще эта тема? Но я сам 12 лет писал RTL и могу догадаться об ответе. Что тут можно сказать. Маршрут проектирования микросхем включает в себя множество этапов, в которых разработка RTL - один из первых. Но разработчики RTL часто забывают, что конечная цель - микросхема, а RTL - только первый этап из длинного списка. В результате, разработчик не видит за своим кодом конечной схемы, состоящей даже не из транзисторов, а просто из элементов. Как следствие, я за свою практику наблюдал два пути написания RTL-кода: путь, исходящий из представлений о результате всего маршрута проектирования, и путь программиста - воплощение спецификации изделия сразу в виде кода, не думая о схемотехнике. Ваши вопросы - следствие программерского подхода к написанию RTL, отсюда и желание строить эксперименты с конструкциями языка. Опытный же схемотехник вообще не интересуется всякой ересью, а использует только однотипные конструкции, наилучшим образом распознаваемые компилятором (именно компилятором, а лишь затем синтезатором, мэппером и т.д.). Да, это скучно, но только используя правильные однотипные конструкции можно писать 100% правильно синтезируемый верилог, поскольку конечная цель - схема, а не изящество строк кода. Почему бессмысленно ставить эксперименты с кодом? Потому что современный софт жутко глюкавый, и поддержка сомнительных конструкций языка может быть реализована по разному у разных производителей тулов, и Вашу сомнительную конструкцию надо проверить сначала во всех тулах, прежде чем с уверенностью использовать в проектах. Итого, либо 100% результат и переносимость (независимость от платформы и тулов), либо эксперименты. Третий вариант - от лукавого.