dxp

Да, это сразу нагуглилось. Там вопрошающий делал выход по $finish, и удивлялся, что код ошибки не "ошибочный", ведь он же по асерту выходит. $fatal там, судя по всему, ведёт себя как надо. У меня исходно запуск осуществлялся так: vsim -c -do prj.tcl -do sim_begin -do sim_run где sim_run sim_begin run -all exit Так вот, если в коде есть $fatal или $error, то до exit дело не доходит - симулятор выходит неким иным путём. И по идее он должен сам вернуть код ошибки (там у него есть в доках таблица с кодами ошибки), что и происходит в обсуждении по ссылке. У меня же как раз этого не случается почему-то - возвращает 0.

Всем привет! Обнаружилась непонятка в, казалось бы, совершенно безобидном месте. По непонятной причине симулятор после прогона возвращает код 0 там, где должна быть ошибка. Конкретно, вот есть код: initial begin $fatal(); $stop(2); end Запуск: vsim -c -do prj.tcl -do sim_begin -do "run -all; exit" prj.tcl содержит всё необходимое окружение - имена файлов, ключи, процедуры - например, указанная выше 'sim_begin' определена там же: proc sim_begin { } { global vsim_cmd vsim_flags; quit -sim; set cmd [concat ${vsim_cmd} ${vsim_flags}]; eval ${cmd} radix -hex log -r /* } При запуске выхлоп: # run -all # ** Fatal: Assertion error. # Time: 0 ps Scope: top_tb File: top_tb.sv Line: 129 # ** Note: $finish : top_tb.sv(129) # Time: 0 ps Iteration: 0 Instance: /katun_tb # End time: 10:39:56 on May 19,2022, Elapsed time: 0:00:01 # Errors: 1, Warnings: 2 Вроде норм. Но проверка кода возврата говорит: $ echo $? 0 Из-за этого не удаётся использовать прогон симулятора в пакетном режиме, когда в случае неуспеха вся сборка должна остановиться. Если принудительно выходить с кодом ошибки, например, по команде exit -code 1 то код возврата правильный. Была идея закостылить - проверять наличие ошибки и выход делать вручную, как показано выше, но это не работает, т.к. в случае ошибки сим выходит сам, не достигая проверки, которая может быть запущена только после останова по $stop() или $finish(). Ну и вообще, хочется разобраться, и чтобы работало правильно, а не на костылях. Буду благодарен за любые идеи.

В смысле, Xilinx поставляет Versal в РФ? Или для кого эта новость?

Из всего, чем пользовался, больше всего нравился PSpice (потом OrCAD PSpice, сейчас входит в Allegro). Схематик там, собственно, OrCAD. Является стандартом де-факто в отрасли, подавляющее большинство моделей вендоров делаются для него и совместимым с ним. К сожалению, начиная с какого-то момента Linear Technology (RIP) перестала делать пригодные для него модели (начали вводить какие-то проприетарные элементы в них), которые стали годиться только для LTspice. Мегаудобная фича у OrCAD PSpice - он умеет показывать прямо на схеме режимы по постоянному току (напряжения в узлах, токи через элементы), включается это одной кнопкой. В том же LTspice чтобы вывести напряжение на узле, нужно для каждого узла это делать отдельно и итоговый вид далёк от желаемого. Главный недостаток PSpice: он сильно коммерческий. И установка с лечением там местами нетривиальные. И да, при выборе движка симулятора надо выбирать не PSpice, а другой движок (на букву A начинается, точнее не помню, но там их всего два), т.к. PSpice тут скорее как бренд, а сам движок там старый и давно не развивается (неверное держать для какой-нить совместимости), на относительно современных моделях ОУ были проблемы со сходимостью. А новый работает чётко.

На VMK180 (Versal Prime) для DDR4 (аппаратный, via NoC) мне не удалось найди example project. Пришлось самостоятельно ковырять.

Офтопный вопрос. Вот тут report_property возвращает некие объекты с кучей параметров. А можно где-то посмотреть код, где описаны эти property? Насколько мне известно, Tcl язык незамысловатый и в нём не то, что сложных объектов, и типов-то почти нет (есть базовый тип "строка", значения которого кастуются по месту в зависимости от контекста). А тут такие навороченные объекты, представление которых подозрительно сильно похоже на С++'ные типы. Интересно посмотреть, как они это на Tcl реализовали.

И сразу отлично видно потенциально проблемное место, на которое компилятор промолчит, и сразу видно, что к чему кастуется. Вот это: if(br >= 0 && !can->setBitRate((cCAN::eBitRate)(br + 1))) выглядит ничем не лучше, даже наоборот - нужно прилагать усилия, чтобы понять, что тут ручное преобразование типов, а не просто скобки для выделения приоритетов операций. И вдобавок тут может скрываться злобный reinterpret_cast, если, скажем, тип, к которому делается преобразование, например, указатель. static_cast это с ходу отловит.

Про различие static_cast и reinterpret_cast сказали выше - это очень разные "по силе" касты (и последствия от преобразований тоже разные), но С не различает их в своём синтаксисе. А смысл их такого громоздкого синтаксиса именно в том, чтобы они своим безобразным видом прямо-таки подсвечивали место потенциальной ошибки (там где компилятору велели "умыть руки" и не контролировать работы с типами). Каст на С в коде зачастую нетрудно пропустить, т.к. это обычное выражение с круглыми скобками, коими С/C++ злоупотребляют. А *_cast<...>() кроме того ещё и подсвечивается в программерских редакторах, т.к. являются ключевыми словоми языка.

Я всё равно не догоняю роль задержек, когда речь идёт об асинхронных клоках. Там при любых задержках будет "наползание" одного клока на другой даже если они одинаковой частоты. Т.е. всегда будет возникать момент, когда данные из одного домена будут попадать на фронт клока другого домена. А вот сам этот момент (его появление на временнОй оси) будет зависеть в том числе и от задержек. Но частота "пересечения" данных и клоков зависит от величин самих клоков, от логики, которая определяет частоту переключения данных (не на каждый период клока данные могут меняться), но от задержке в путях данных. И именно эта частота "пересечения" данных и клоков на входах флопов и влияет на вероятность сбоя.

А как MTBF зависит от заполненности ПЛИС? Там же только от соотношения частот зависит, как часто будут фронты сигналов (клок и данные) пересекаться.

Я не очень знаю за Altera, но из общих соображений: если работаете не на уровне TLP, а по шине, то все эти вопросы про разбиение на размеры MPS, учёт tag и т.п. берёт на себя корка. Вам остаётся только следить, чтобы запрос не пересекал границу 4к. А вот если на уровне TLP, то там в полный рост пляски вокруг MPS, tag, CplD (RCB) и т.д.

+1. Там внутри аппаратного блока PCIe оно на порядка 200 нс задерживается (если верить симуляторной модели), а таких блоков как минимум два (передающий и приёмный). На серверной плате, где PCIe дивайс подключен к Root Complex непосредственно (т.е. без коммутаторов по пути) наименьший round trip, который удалось наблюдать (через ILA), составлял 600 нс, что неплохо согласовывается с задержками на аппаратных блоках PCIe: 200 + 200 + задержка внутри RC (обращение в память, чтение из неё).

Ни разу не помню проблем с always_comb. Да и вообще к синтезу как таковому претензий нет. Больше доставало падение в Internal Error при использовании modport expressions в интерфейсах, из-за чего приходилось переписывать рабочий код.

И как вы будете эти случаи различать? А если по логике задания сигнал может быть только 5 и 10, а 7 и 2 быть не может, это ошибка, то как эту ситуацию обходить? То, что вы хотите, на SV достигается с помощью SVA.

С чего это переполнение разрядности является ошибкой? Часто это штатное поведение - например, тот же банальный free-running counter.

Ну, Synplify это только synthesis, PnR там нету (во всяком случае не было, когда я его использовал, ещё до поглощения Synopsys, но полагаю, что и сейчас этого тоже нет - PnR всегда было и остаётся прерогативой вендора чипа). А Quartus вполне приличный тул, и поддержка того же SV в нём началась раньше и была лучше, чем в Synplify (почему я сего и спрыгнул в пользу Quartus). Правда, это было ещё на каких то 7-8-9 версиях, после 13.1 он начал, имхо, портиться, к сожалению. Кстати, а вот тут может работа в 32-битных (интах) целых может оказаться эффективнее для симулятора - не надо эмулировать нестандартную ширину.

А откуда берётся варнинг, если есть правила стандартных преобразований типов? Варниги лезут от тулов - одни ругаются, другие нет. Помнится, был опыт работы с Synplify, так он спокойно жевал эти ' + 1' без криков, хотя очень придирчивый синтезатор и цеплялся буквально ко всему. А Quartus на том же коде пропускал массу всего, к чему придирался Synplify (кстати, по делу придирался по большей части), зато вот на это ' + 1' ворчал. В итоге, я просто заткнул его. Зачем писать больше, если можно писать меньше (не говоря уже о читабельности)? "Это короче, чем я могу написать, а компилятор должен понимать умолчания" © Б.Страуструп. Но может я чего-то не знаю, не понимаю, что-то упускаю, какой-то важный нюанс (хотя ещё ни разу ничего не прилетело с этой стороны). Вот поэтому и интересуюсь.

А разве стандартные преобразования типов тут не работают? Какая практическая разница в результате между + 1 и + 1'b1? В каких случаях это критично?

Если чисто на логике делить, то возникает вопрос, как потом этот сигнал затащить в домен клоков - т.е. имеются ли в этой ПЛИС аппаратные средства для этого. Ну, и если требуется синхронность этого клока по отношению к другим, то тут скорее всего облом. Чтобы не было траблов с времянками, надо ещё прописать констрейн multicycle на эти пути, тогда тул будет знать, требуемую реально времянку и не будет излишне напрягаться. И тут всё синхронно получается (если это актуально).

Ретайминг разве размножает регистры? Он, вроде, перемещает их по пути прохождения сигнала для балансировки задержек между регистрами, где это возможно (т.е. не нарушается логика описания). А размножение регистров происходит, например, при включенной Duplicate Register опции.

Защищаться чисто топологическими методами, имхо, не особо эффективно - никто не будет анализировать "артефакты" на плате, просто тупо изготовят по имеющимся герберам и всё, даже не узнают, что там, оказывается, есть "закладки". И будет там ровно такая же топология со всеми "антеннками", "змейками" и прочим. Соответственно и работать будет как оригинал. Вот если при производстве, например, заложить в на уровне технологии какие-то неочевидные нюансы - например, изготовить какой-нибудь слой с более тонкой (толстой) медью, тогда, измеряя сопротивления некоторых участков, можно будет понять, оригинальная плата или нет. Но это работает до тех пор, пока: 1) нет доступа к информации о заказе ПП (у своих, приближённых он есть); 2) за плату не возьмутся серьёзно квалифицированные специалисты - они быстро расковыряют "закладку" и поймут, в чём дело (выводы АЦП подключены к внутренним проводникам зачем-то, это подозрительно, далее просто сравнить импеданс этого участка на оригинальной плате и на клоне. Более тонко: стек слоёв. Т.е. схемотехника и топология ровно та же, но за счёт стека можно изменить волновое сопротивление и ловить "звоны".

Анекдот, вообще-то, про то, что сравнивают несравнимые вещи. А не про качество.

Зависит от контекста. Если заниматься только разводкой плат, то да. Если помимо этого ещё много всего, и платы - это не более 5% времени, затрачиваемого на проекты, и при этом это не лютый хайспид, то вполне годятся инструменты попроще. Кстати, про "стоимость владения" полностью согласен: нужно ведь не только освоить, но и постоянно поддерживать квалификацию, для чего нужно постоянное использование. Для сценария периодического использования это весьма актуально: сложный инструмент забывается быстрее и вспоминается тяжелее. В общем, не нужен самосвал для поездок на дачу.

Хитро. :) Но это, имхо, уже костыльно. Предпочитаю, где не требуется жёстко AXI, использовать нативные интерфейсы. Да, тоже пришёл к подобному: сделал свой интерфейс, по идеологии похожий на AXI4, но без ограничений, накладываемых оным. Нет лишних сигналов (есть addr, len, avalid, aready для канала адреса, есть data, last, valid, ready для канала данных, длина транзакции задаётся в байтах, что очень удобно при переходе к пакетным интерфейсам типа PCIe, когда надо сразу знать длину). Нет паразитных предупреждений на лишние сигналы. Легко преобразовывается в AXI4 если надо.

А можно в нём создать TDATA шириной 11 бит? Или таки придётся делать 16? И не будет ли синтез нудеть пустыми предупреждениями о неиспользуемых сигналах (с 12 по 15-й)? С AXI4-Stream почти всё хорошо. А вот AXI4 уже далеко не так удобен, если дизайн построен не вокруг какого-нить CPU. Поэтому нативный интерфейс должен быть. Если надо AXI - врапер нахлобучить не так уж сложно.