Bad0512

Я поглядел ваш изначальный проект, и не увидел в нём никаких ошибок в тайминге. Возможно вы сделали в проекте какие-то критические для тайминга изменения. Не могли бы вы выложить текущий проект ещё раз? А то получается что мы разные версии проекта смотрим.

трудно гадать на кофейной гуще. Тайминг может расползтись по самым разным причинам. Приложите отчет по таймингу, хотя бы самые критичные цепи.

Мои 5 копеек в тему. 1. Микроблейз вам скорее всего не нужен. Если есть встроенный АРМ - зачем ещё плодить сущности? 2. АРМ можно легко запрограммить самому, тут (о боже!!!) можно обойтись без "программистов высокого уровня". Достаточно собрать под sdk (снейчас это называется Vitis) своё небольшое bare metal приложение. Если ваша цель - доказать работоспособность железа, то этот путь очень даже подходит. 3. Всякие унылые мосты SPI-I2C - очень неплохая задачка для скучающих студентов, но у вас, наверняка, время ограничено.Все эти неспешные протоколы гораздо проще реализовывать в софте. На отладку всех этих мелких корок (с учетом диалектов протоколов под разные мелкие девайсы) вы угробите гораздо больше времени, чем на отладку bit bang драйвера. Ну то есть идея проста как валенок - заводите все ноги от низкоскоростных протоколов на Zynq GPIO и дергаете ими как вам захочется. 4. Посчитатйте потоки данных с ваших АЦП/ЦАП и убедитесь, что производительности присоединенных AXI stream шин достаточно для вашей задачи. Если недостаточно - примите меры. 5. Ваше bare metal application может потом быть использовано для factory testing. В отличие от линуха, оно может спокойно уместиться во внутренней RAM и тестировать внешнюю DDR на предмет исправности.

А за жирный шрифт тут занете что бывает? И зачем одну и ту же вакансию дважды переписывать? Не идёт никто за 70к деревянных в дефолт-сити плисоводом горбатиться? Да неужели???

Если есть возможность модифицировать плату, то не проще ли генератор прицепить кварцевый? Но подобного рода трюки я встречал.

Не в этом вопрос. Такие финты не во всех архитектурах возможны в принципе, вот в чем дело.Грубо говоря нельзя от слова "совсем" подать на клоковый буфер сигнал с LUT или FLOP. Поэтому на клоковый вход сигнал поступает мимо тактового дерева, по обычному интерконнекту (почему так можно? хз, возможно это сделано для реализации latch) и в итоге разница в клоковых задержках по дереву сильно возрастает.

Проблема заключается вот в чём. По хорошему выход подобного тактового генератора необходимо пропустить через специальный тактовый буфер чтобы в дальнейшем полученный тактовый сигнал рапространялся по специальному клоковому дереву, а не по обычному интерконнекту. Это сильно влияет на clock skew, но к сожалению не все архитектуры позволяют такое сделать. Соответственно мы получаем заведомо худшие условия для соблюдения тайминга в подобном случае по сравнению с обычным внешним клоком, приходящим на клоковый пин. Ну то есть тайминг анализ можно провести, но всё это будет "на глазок" и не гарантируется производителем. На свой страх и риск. З Ы Помню видел даже какие-то диковинные примеры, когда в альтерах нельзя было просто подать клок на вход внутренней PLL и чтобы обойти это ограничение делали внешнюю петлю: выводили клок на обычный пин, а с него внешней петлёй на clock capable input.

1. Использовать частоту от I2C нельзя, потому что она присутствует только при передаче данных. В остальное время - нет. С SPI подобная же история. Всё зависит от реализации, иногда частота присутствует всегда, а иногда только когда данные передаются. Делать свои автоматы зависимыми от такого клока - удел студентов из серии "никто так не делает, а я сделал". 2. Да, можно сгенерировать частоту на PLL. Но в отсутствии внешнего рефернеса её частота будет очень сильно зависеть от множества факторов, это значит мы сразу "помахали рукой" всем синхронным интерфенйсам от Aurora вплоть до UART. Я уж молчу про всякие синхронные модемы с восстановлениме тактовой и несущей и прочие частотно зависимые вещи. 3. Я не утверждаю, что так сделать нельзя. Я утверждаю, что это - пример костыля, когда сэкономили на копеечном кварцевом генераторе, и поимели себе на ровном месте вагон дерьма. А нужно было просто предусмотреть независимый стабильный клок. И всё. При чём важно иметь именно независимый клок, а не навороченную внешнюю PLL с прогрузкой регистров по I2C / SPI. Почему? Потому что изначально эта PLL может не генерить вообще ничего (до прогрузки регистров). А чтобы прогрузить регистры (не важно чем, FSM там или soft processor) нужен клок.

В моём понимании gated clock - это сигнал, используемый в дальнейшем для тактирования, полученный с выхода LUT. Ваш пример с BUFG_CTRL крайне неудачный, так как в этом элементе иемеется своя (и довольно навороченная кстати) логика, позволяющая избежать проблем при переключении клоков или включении - выключении. И это хорошо описано в мануалах. Одним из побочных косяков предложенной вами схемы является то обстоятельство, что частота полученного клока зависит от очень многих факторов и не поддаётся прогнозированию, поэтому про тайминг анализ можно забыть. Этот код - это классический пример того, как одни разработчики (в данном случае плисоводы) исправляют косяки других разработчиков (схемотехников). То есть "костыль".Да, красивый, но всё же костыль. Потому что за отсутствие на ПЛИС постоянного независимого источника клока надо гнать из схемотехников ссаными тряпками.

1. Я не утверждал, что атрибут отсутствует - посмотрите оригинал. 2. Клок, сформированный на LUT stg[LEN-1] (из которого вы потом путем деления на триггере формируете выходной сигнал) - что это если не gated clock?

Вот чисто моё имхо: напрасно вы, уважаемый, учите новичков подобного рода конструкциям. В плане плисоводческих трюков это выглядит конечно красиво, но тут в явном виде есть источник вечного геморроя начинающих, а именно gated clock. И (с моей старческой методологической колокольни) гораздо правильне не использовать gated clock никогда и нигде, чем уметь пользоваться подобного рода трюками. И ещё замечу, что без соответствующего атрибута любой синтезатор эту конструкцию заоптимизирует.

Вы понимаете что каждый "контакт" (в вашей терминологии) - это отдельная физическая сущность. Ну для простоты , например, физическая ножка микросхемы. Так как вам заранее неизвестно какие из этих "сотен тысяч" контактов с кем буду соединяться, то очевидно, что все эти "контакты" должны приходить на одну ооочень большую коммутационную матрицу. У которой сотни тысяч ног. Такую штуку ещё не изобрели, увы. Либо вы предолжите способ как эти сигналы (термин "контакты" уж больно детсадовский) будете уплотнять в физических каналах (существует много разных способов).Для того, чтобы ответить на все эти вопросы нужно внятное ТЗ (техническое задание). И там должны быть циферки. Например, ширина полосы аналогового канала или что-то похожее. Если для вас все эти слова - темный лес, то скорее всего вам ещё рано заниматься подобного рода задачами. Сорри, ничего личного.

Я наверное глупый вопрос задаю, но всё же : ПЛИС работают с цифровыми сигналами, вы предлагаете коммутировать аналог. Как вы собираетесь это делать?

Чем подкупает если не секрет? Вам лениво поставить простейшую QSPI флешку и развести 6 дорожек (максимум)? По сабжу смотрите AC характеристики, у Xilinx описаны, например, максимальные частоты работы триггеров, клоковых цепей, умножителей и т.д. У Альтеры должно быть аналогично. Понятно что эти характеристики зависят от выбранного спидгрейда.

Справится по моим подсчетом и со сложением 1024 8-битных чисел за один такт 20 МГц. Вопрос хватит ли на это ресурса. Особенно хватит ли Carry chain. А в остальном всё просто - задираем частоту до 200МГц например, строим классическое дерево с регистрами, за 10 тактов этой частоты складываем 1024 числа. Не забываем об увеличении разрядности сумм. З Ы Но вообще это не очень эффективный способ, гораздо правильнее (если есть такая возможность конечно) складывать числа последовательно с накоплением результата в аккумуляторе.

Покурите тему RLDRAM - там с рандомным доступом ситуация получше. Но штука не слишком распространенная, поэтому контроллер (возможно) придётся поискать. У Хилых есть реализация, про Альтеру-Интел не знаю.

По поводу соответствия стандартам целиком и полностью согласен. Но мы же понимаем, что не всякая синтаксически верная конструкция может быть синтезирована (или ,например, однозначно трактуема) синтезатором. В данном конкретном случае речь идёт именно о синтезируемом подмножестве. И вопрос именно был не "соответствует - не соответствует?", а "правильно - неправильно?".

1 Как писать правильно? Например, посмотреть в темплейты. Вопрос тут не в привычках описания, а в том, что одно описание сразу однозначно расставляет приритеты между reset и CE, а второе этот вопрос отдаёт на откуп создателям синтезатора. ИМХО первый вариант надёжнее, а поэтому правильный. А вообще практика писать конструкции типа if-elseif-elseif-endif пошла у меня от борьбы с латчами, которые по неопытности плодил иногда в случаях множественных вложенных if-endif.

1 Зачем мне эта дичь? Пытаться выстрелить себе в ногу и убедиться что не попал ибо от этого меня "спас" разработчик синтезатора? Почему не научиться сразу писать правильно? 2 Зачем вы тут мне рассказываете как устроена ячейка ПЛИС? Вы думаете я этого не знаю? Вопрос ведь не в том "как оно получится" а в том "как писать правильно". 3 По поводу абсолютной пользы темплейтов целиком и полностью согласен.

Ну и что говорит стандарт о подобных конструкциях? Как он разрешает подобные коллизии? "я сам так всегда пишу" - это аргумент из серии " я улицу перехожу не глядя на светофор, и ни разу ещё ничего не случилось". З Ы Я допускаю, что разработчики конкретного ситезатора подстелили соломки и трактуют подобные неявные конструкции в пользу наиболее вероятного поведения. Но это относится только к данному синтезатору, и не факт что другой синтезатор будет поступать так же.

Что вы понимаете под "правильно"? В коде есть неоднозначность, которая позволяет синтезатору по своему разумению расставить приритеты между сигналами reset и count_enable. Думаете он знает как "правильно" с вашей точки зрения? Что будет в случае если reset = 1 и count_enable = 1 ? Какое событие произойдёт и почему?

Это не флешка, флешка это IC2. Возможно это - преобразователь уровней или LDOшка. Флешка соединяется с ногами 61 62 63.

Может конечно в Виваде что и поменялось, но раньше для синтеза необходимо было цеплять нетлист *.ngc. Точнее даже не так. Синтезу пофиг на ваши фифошки если у них есть атрибут black_box. А вот на этапе имплементации понадобятся нетлисты. Но если вы всё делаете в Виваде, то инструкции от Роба очень правильные.

Флаг пустоты работает как надо, но он показывает состояние на текущий такт. На следующий такт ситуация может поменяться и это необходимо учитывать. Полезно также мониторить флаги underflow и overflow.

У фифошек от Xilinx есть дополнительный флаг valid. Он гарантирует что вы читаете не из пустой фифошки. Я обычно разделяю логику запросов (fifo_rd = ~fifo_empty в самом простом случае) и логику записи из фифошки в следующий регистр (reg_we = fifo_valid). Таким образом, при попытке прочитать из пустой фифошки флаг валидности не будет выставлен. Будет нарушено количество чтений, но не целостность данных. Кроме того, данная схема позволяет не заморачиваться вопросом через сколько тактов после запроса на чтение на выходе появятся данные ( а тут могут быть разные варианты ) - всё регулируется флажком валидности. И ещё. Если вы защелкиваете флаг пустого фифо и из этого формируете строб чтения - так делать нельзя. Рано или поздно наступите на грабли чтения из пустого фифо. Можно только на комбинаторике fifo_rd = ~fifo_empty & _еще_какое_то_условие_если_это_нужно_;