Jump to content

    

dxp

Свой
  • Content Count

    3695
  • Joined

  • Last visited

Community Reputation

0 Обычный

1 Follower

About dxp

  • Rank
    Adept

Информация

  • Город
    Novosibirsk

Recent Profile Visitors

8412 profile views
  1. Эта есть. Только это не про gotchas.
  2. Благодарю за ответы. Блокировать предупреждения, конечно, вариант, но есть два "но". 1. В виваде это делать, мягко говоря, неудобно - у неё совершенно тупой механизм для этого - либо блокировать именно текущее конкретное, либо по текущему ID. Помниться, в квартусе была куда более продвинутая система - там можно было гибко по маске задавать, т.е. можно было задавить предупреждения на конкретном модуле и/или наборе конкретных сигналов. Я так и делал - отсмотрел, убедился, что ругань не по делу, заблокировал, чтобы не маскировали новые. Иногда всё же там есть предупреждения по делу, поэтому блокировать по ID не хочется. 2. Принимая во внимание п.1, получается, что приходится блочить каждое сообщение индивидуально. А т.к. их там тыщи, это порождает конского размера файл проекта (в ква там просто добавлялась маска в отдельный файлик и всё). Кстати, есть такое наблюдение. Там в логе есть два вида сообщений по виду на одну тему: 1. [Synth 8-6014] Unused sequential element <...> was removed. 2. [Synth 8-3332] Sequential element (<...>) is unused and will be removed from module <...>. Вроде по тексту одно и то же. А на деле это совсем разные предупреждения. Похоже, что эти анализаторы писали разные индусы (или второй писали не индусы), и работают они (анализаторы) на разных этапах синтеза. Сообщения первого типа появляются ближе к началу лога, а второго - в конце (что выглядит, если смотреть на употребление времён, несколько парадоксально - по идее времена было бы уместно использовать наоборот). Так вот, сообщения первого типа далеко не всегда соответствуют тому, что заявляют - говорит, что выкинул элемент, а он (элемент) во многих случаях на месте. А вот сообщения второго типа, если сказано, что элемент выкинет, то это так и есть. Поэтому на сообщения второго типа следует обращать пристальное внимание - там реально оно выкидывает то, что считает не нужным. А по первому типу - надо просто проверить, на месте ли (по нетлисту), и по-хорошему можно бы и заблочить, если бы система управления сообщениями лога позволяла это делать удобно и эффективно.
  3. Всем привет! Возможно, вопрос обсуждался, но мне найти не удалось. Суть в следующем. Есть проект, успешно собирается и даже работает. Но при синтезе возникают тонны предупреждений такого рода: WARNING: [Synth 8-3331] design <...> has unconnected port <...>. Выглядит угрожающе, но на деле по нетлисту (схематику) видно, что сигналы-то на месте, всё подключено. Анализ показывает, что почти все они относятся к сигналам интерфейсов. И похоже, что синтезатор ругается на сигналы модпортов интерфейса, которые не используется в том или ином модуле. Т.е. насколько понимаю, картина такая: есть интерфейс, у него есть модпорты m0, m1, s0, модпорт m0 подключается к модулю master0, модпорт m1 - к модулю master1, а модпорт s0 - к модулю slave0. Получается, что интерфейс прокинут во все модули, но часть сигналов, которые относятся к другим модпортам, естественно в данном конкретном модуле не подключена - например, в модуле master0 не подключены сигналы модпоротов m1 и s0. Получается, что ругань как бы не по делу. Собственно вопрос: как с этим бороться, т.к. подобные предупреждения выглядят неприятно?
  4. При "прямоугольнике" Nx1 всё будет хорошо на DRAM. При "прямоугольнике" 1xN будет не хорошо - фактически это буден N одиночных обращений, из которых немало будет попадать в разные страницы памяти. Тут скорость просядет в разы.
  5. Много раз ставили BGA (1.0 мм, 0.8 мм шаг) на 6-412-A Flux Plus EFD, ни разу не было с ними вопросов. Приборы (разные) эксплуатировались и в офисных условиях, и в тяжёлых (на улице круглый год, испытания проходили на многократное -40..+50, удары под 500 g и т.д.). Лужение было HASL. Паялось всегда в печи по термопрофилю.
  6. Да, это вполне ординарно. Но это я про требования стандарта написал, а вот то, насколько это требование соблюдается производителями, это вопрос. Т.е. по спеке должно работать, но на практике - не факт. Зависит от конкретной реализации железа.
  7. PCIe стандарт предусматривает работу от асинхронных опорных клоков - его физический уровень на это рассчитан (elastic буфера, SKIP ordered set'ы), есть требование, чтобы точность клоков укладывалась в 300 ppm.
  8. Да это просто пример с явно заданными псевдонимами типов (typedef), технически это всё то же самое, что у @RobFPGA, просто синтаксический сахар. Но читабельность, имхо, повышается, особенно по мере роста проекта. Я практически всегда завожу именованный псевдоним типа вместо logic [...] ..., это выглядит компактнее, единобразнее и читабельнее. Особенно, когда передаёшь значения в функцию (тут преобразование типа срабатывает неявно автоматически), описываешь тип возврата из функции, применяешь операции $size()/$bits(). Тут меньше поле для ошибок и код воспринимается легче. Писанины кажется чуть больше, но это только кажется - как только нужно хотя бы пару раз сослаться на тип, сразу идёт уже выигрыш и по объёму писанины. Ну, а про счётчики уже писал выше, всегда использую вариант: cnt <= cnt + 1;.
  9. Или так. typedef logic [A_WH-1 :0] var_a_t; typedef logic [B_WH-1 :0] var_b_t; typedef logic [A_WH+2-1:0] var_c_t; var_a_t var_a; var_b_t var_b; var_c_t var_c; ... var_b <= var_b_t'(var_a + 1); var_c <= var_c_t'(var_a + 3);
  10. Это конкретно фича квартуса. Придирчивый синплифай (когда я с ним ещё работал) не вопил на a <= a + 1, да и нынешняя вивада тоже, они молча приводят размеры к типам, как и положено по стандарту. В квартусе я просто этот тип предупреждений отправлял молча в игнор (через механизм suppress, он неплохо в ква сделан, в отличие от вивады, где его можно сказать нет), т.к. вопли не по делу.
  11. Если в системе используется IOMMU, то произвольный доступ через PCIe в системную память вполне может быть заблокирован. Кроме того, PCIe устройство - это периферия, её нужно настроить. Для этого оно сперва должно пройти так называемую енумерацию - этим занимается либо BIOS, либо ОС, затем драйвер устройства должен настроить внутренние регистры устройства, чтобы оно могло корректно работать с PCIe шиной. Наверное, можно настройку сделать автономно, но для этого надо знать как и что сделать, а это не такое простое дело. В случае ошибок можно легко завалить весь хост.
  12. Несколько не так. Исходно HDL (верилог, в частности) разрабатывались как языки для моделирования. Отсюда и возникла концепция исполнительной виртуальной машины, обеспечивающей корректное моделирование параллельно выполняемых процессов, и машина эта работает по определённым правилам - например, те же самые блокирующие и неблокирующие присваивания, которые работают в разных регионах событий и позволяют более гибко описывать процесс моделирования. Идея использовать синтез из верилог-описания возникла позднее, и не все средства языка для этого поддерживаются - существует некое синтезируемое подмножество. Естественно, что синтезированная реализация работает на другой исполнительной платформе, где нет виртуальной машины, соответственно, нет и ограничений, связанных с ней. С другой стороны возникает набор своих требований - например, не всякое даже в принципе синтезируемое описание может быть реализовано на конкретной платформе - например, если вы напишите: always @(posedge clk or negedge clk) ... и попытаетесь скормить это синтезатору практически любой современной ПЛИС, то получите отлуп, т.к. такая конструкция предполагает реализацию в виде флопа, работающего по обоим фронтам, а таких в нынешних ПЛИС просто нет (вроде были в Spartan или Spartan2), в то время как симулятор это съест без проблем. Собственно именно логика работы неблокирующих присваиваний в тактируемых поведенческих блоках и ложится нативно на поведение флопов - по фронту записывается значение, которые было на входе до фронта (на момент его возникновения). А блокирующее присваивание нарушает эту логику - там выстраивается цепочка присваиваний - это как раз хорошо ложится на описание комбинационной логики - там важен порядок следования сигналов по логическим переменным. Отсюда и возникло простое правило: для описания флопов - тактируемые блоки с неблокирующими присваиваниями, для комбинационной - нетактируемые блоки с блокирующими. Это порождает корректное поведение с точки зрения соответствия "виртуальная машина симулятора - аппаратное исполнительной устройство". Отсюда простой вывод: если хочется иметь в арсенале мощный инструмент для моделирования (симулятор) и иметь от него пользу, надо просто соблюдать пару простых правил. Блокирующие присваивания, кстати, очень даже применимы в тактируемых блоках, но только для вычисления значений переменных, используемых в правой части неблокирующих присваиваний - нередко это просто удобно и повышает читабельность, когда логика развесистая и нетривиальная. Для симулятора тут всё корректно: сперва вычисляются значения блокирующих (Active Region), причём итеративно (учитывая изменения переменных в других блоках в текущем дельта-цикле), затем они присваиваются через неблокирующие (NBA Region). Синтез тоже понимает эту логику и прекрасно разносит реализацию на комбинационную логику и флопы.
  13. Потому что для всякого выразительного (или не очень) средства языка есть свой контекст применения. @RobFPGA уже достаточно внятно объяснил, что к чему. Добавлю только, что если хотите понимать, что там "под капотом", почитайте про планировщик виртуальной машины симулятора (по ссылкам выше про это тоже есть), например, тут. Вы увидите, что блокирующие и неблокирующие присваивания обрабатываются в разных стадиях (регионах событий) цикла планировщика (блокирующие раньше), из-за этого возникают гонки и странное поведение на симуляторе. Синтез имеет другую исполнительную модель - "тру параллел", там гонок в этом смысле нет. Симулятор является мощным инструментом отладки логики дизайна, отказ от его использования резко понижает "потолок" сложности. Но чтобы от инструмента была польза, надо пользоваться им правильно, понимая условности и ограничения метода.