Golikov

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

| - это как раз знак что несколько параметров в одну строку будут слеплены) перечисляются параметр и значения через | если для одной сети, либо каждый параметр отдельно и имя сети перед ним. Или любые комбинации

вообще не очень понятно что вы делаете. Не очень понятно где вы создали инстанс интерфейса, то есть вы его описали - здорово, а где сам интерфейс то создается, где его экземпляр? Не очень понятно зачем называть одинаково разные интерфейсы? Не очень понятно зачем 2 топ модуля в одном файле? скорее всего проблема в том что вы путаете экземпляр и описание интерфейса. И пытаетесь на уровне описания делать различные его экземпляры. Ну или я вообще не понял что вы делаете:)

еще бы -max и -min атрибутики бы выставить в то какой вы путь определяете. ну собственно ничего и не должно, :) задержка не может быть точной, она может быть в воротах. Потому что от температуры и питания плавает. так что ограничивайте ее сверху или снизу, но не задавайте точно, это невозможно.

можно и в одну строку и в отдельных строках. Обычно план-ахед визард любит перебирать констраин файл и записывать эти атрибуты в разные строки, иногда даже в разные части файла:). Думаю вивада ведет себя также. 1. У не клокового сигнала нет периода%) "Частота" его следования задается частотой клока его формирования. То есть если вы имеете сигнал который формируется по клоку и по клоку где-то используется, то задав период клока вы автоматически задаете среде следить чтобы этот сигнал от формирующего триггера до всех остальных использующих его дошел за (период минус сетап). То есть пути следования сигналов надо определять только для асинхронных сигналов или идущих из одного клокового домена в другой, у которых клоки асинхронны. Все остальные пути автоматически привязываются к клокам. Более того пропустив клок через ПЛЛ и делители, и обконстрайнив входной, все производные клоки автоматически обконстраиниваются. 2. Это влияет на частоту выходной ноги. В даташите даны задержки выход в зависимости от заданной скорости. Но надо еще читать главу про шумы, в зависимости от числа одновременно переключаемых ног, их скорости и числа линий питания - земли получается разный шум. Со скоростями, если важен шум, надо быть аккуратным. 3. То же в даташите есть влияние на шум, и скорости 4. Выходы ног выровнены на клок, чтобы по клоку все ноги выдали максимально близко, и клок тоже выровнен. Не знаю участвуют в этом как-то задержки или нет, но уверен что полезно задавать задержки с пониманием, а не просто на минимум. Если бы 0 - было бы самым лучшим вариантом, он наверняка стоял бы по умолчанию.

да вроде бы на выходах стоят элементы задержки управляемые. ALTIOBUF megafunction

Правильно понимаете. Вы иминуете сигнал SysClk как сеть SysClk, там у вас есть какие то различия в больших и маленьких буквах, но не суть. А потом говорите что на эту сеть наложено временное ограничение по периоду, автоматически это ограничение распространится на все остальные зависящие от нее сети, в том числе и производные полученные через PLL и DCO. А дальше вы говорите что все входные сигналы для данной сети будут выставлены минимум за 1.25 нС до клока, и будут сохранять свое значение минимум 2.5 нС. То есть как бы вы задали сетап и холд. Причем от обоих фронтов, при этом выходной офсет у вас не задан. А вот как описать задержку входного сигнала несвязанного с клоком - ответ никак. Потому что вы ее не знаете и знать не можете, если он формируется не по вашему клоку. Если по вашему вы должны учитывать все пути до и обратно, иначе этот сигнал является асинхронным и никак не описывается. Внутри проекта применяются меры по его синхронизации и защиты от мета-стабильности и все, больше ничего сделать нельзя и не требуется. Этот прибор вам тут не друг, потому что это все поедет от питания, экземпляра и температуры. Экспериментально констрайны не задают.

во-первых, у ксалинкса есть визард написания констраинов, очень рекомендую им воспользоваться. во-вторых, можно сгенерить IP корки каких-то сложных блоков типа контроллера DDR памяти или МАС езернета, и там будут приложены файлы ограничений их можно почитать. Дальше кратко по сути: - Задавать в 0 и пусть пыжится не вариант. Он будет долго пыжится, а потом может устать и вообще бросить что-то делать, то что получится не факт что самое лучшее или что это не сожрет кучу ресурсов. - Величина задержек вычисляется из документации и схемы, обычно оценочно и с генеральскими запасами -Временные группы нужны для удобства работы и описания, можно для каждого сигнала до другого описать констраины, а можно собрать сигналы в группы, и писать от группы до группы. Группировать можно через маски, иногда бывает удобно. Какие сигналы объединять в группы на совести разработчика, это просто для удобства описания. вот пособие от ксалинкса https://www.xilinx.com/itp/xilinx10/books/d...straints_ug.pdf есть еще общее описание юзер констраинов где оно главой

Когда то беседовал со службой поддержки ксалинкса. У ксалинкса есть возможность задать ограничение выхода сигнала относительно основного клока, то есть можно гарантировать что сигналы появятся на ножке не позже чем заданное время от фронта клока. При констраине на период по умолчанию время выхода ставиться период. При этом нет возможность задать чтобы данные появились не раньше. То есть время выхода сигнала от 0 до указанного времени. Задать нижнюю границу больше 0 нет никакой возможности. Во всяком случае до 6 серии включительно. Как следствие вы не можете задать соотношение 2 выходных сигналов формируемых по одному клоку точнее чем 1 такт. То есть если вы выставляете по клоку данные и строб данных, единственное что вы можете это попросить чтобы они вышли не позже чем через какое-то время, а сделать так чтобы данные вышли раньше строба можно только с кратностью такта, то есть в одном такте выдать данные в следующем строб. При этом совершенно спокойно данные могут добраться до выхода под конец такта, а строб вылететь в начале, и разница между ними будет очень мала. Более того клок до элементов может добраться в разное время, и может так оказаться что они даже местами поменяются. Входные констрайны еще более бедные. Изложив это все поддержке получил следующий ответ. Для любого управляемого соотношения между сигналами их надо щелкать в IOBах. Архитектурно клок до этих элементов выровнен и разница между приходом клока к ним минимальна и описана в даташите. Там же описана максимальная разница в пути от IOB до ножки. Так что весь вход - выход управляемо работает только при размещении его в IOB, а времянка входа выхода управляется кратно такту частоты. Внутри ПЛИС после задания частоты основного клока, все становится легко. ПЛИС сама следит за тем чтобы сигналы добирались за нужное время до фронта, причем не только для основной частоты, но и для всех производных. Для асинхронных сигналов опять же можно задать ограничения пути сверху (снизу снова нельзя).

Ну зачем что-то делать чтобы иметь мнение?:) Я достаточно плотно писал на VHDL в начале карьеры, потом перешел на Verilog так что я могу сравнивать. Синтаксис Verilog очень далек от совершенства, но в целом он удобнее чем VHDL. Синтаксис и организация кода.

Ну в VHDL есть такое что надо одно и тоже в нескольких местах писать, а как чуть не так и синтез с моделированием разошлись:) По мне это не верный подход. Так как синтезатор может сделать много места мало времени, и наоборот, и много средних вариантов. При этом оптимизация идет до тех пор, пока не уложится в ограничения. Так что оценивать что одна схема быстрее чем другая без ограничений не совсем верно. Просто так получилось что в одном случае так, в другом сяк, а в условиях ограничений они могли вообще выродиться в третью схему. Поэтому и оценка ресурсов в вакууме тоже не совсем верна.

проверка >= порождает вычитатель и схему сравнения, проверяйте на равенство и выиграете ресурсы, более того проверка на константу хуже чем проверка на нулевое значение или проверка на 1 в старшем разряде на этом тоже можно что-то выиграть. Вопрос только в том зачем это все? Более того смотреть надо не эту схему, а технологический вид, потому что в итоге это все ляжет в ЛУТы - Лешки и будет все совсем по другому, а может даже одинаково. Точно также изменится частота после мапинга на реальную схему. Правильно и изящно описывать то что вам надо по поведению, предоставив схему городить синтезатору и оптимизатору. Лично я стараюсь избегать в синтезируемых схемах интежеров и подобное, использую битовые вектора заданной разрядности, так мне кажется как-то правильнее.

пожалуй поддержу, только и потуги можно не прекращать :)

Да и это не сложно проверить always @(clk) begin clk <= ~clk; $stop(); end И запускаем постоянно, сигнал будет беситься, а время идти не будет. Если есть отображение дельтациклов они будут бешено расти. И не упустите предложение выше:)

будет, просто бесконечно быстро, кажется :) Ну то есть на самом деле симмуляция не будет идти. Она повиснет на первом алвайсе и не перейдет в следующий цикл. А вот если поставить задержку после always @(clk) begin clk <= ~clk; #10; end то да, ничего уже не сработает. сразу после события клок упадет обратно, он даже не поднимется, а потом отработается задержка, и мы опять придем в ожидание изменений с постоянным не меняемым сигналом

ту такая история always @(clk) begin #10; clk = ~clk; end сначала процесс ждет фронта клока, дождавшись проваливается во внутрь, там выжидает паузу 10, потом в клок запихивает обратное значение сохраняет его там, и идет на второй круг. Но так как клок уже в новом значении изменения мы никакого не дождемся и повиснем. always @(clk) begin #10; clk <= ~clk; end в этом варианте ждем фронта, проваливаемся во внутрь, ждем 10, и "планируем" изменение клока, выходим и ждем изменения, которое параллельно происходит, и соответственно мы его ловим и повторяем процедуру. То есть как бы игра на том в какой момент реально сохраняется значение clk, и видно ли на следующем цикле изменение.

И такая тоже может быть. А может быть что ты ему покажешь программу которая их сверяет, но не квалифицирована, а он скажет понятно, принимается, но напишем что у вас некто Н все глазами сличил. Ровно как может заартачится и не принять проверку глазами на 10 контрольных примерах. Основная мысль что его поведение и аттестаты на самом деле прямо на качество не виляют. С ДО скорее всего лучше чем без него, но он не панацея.

должны быть установлены, но сами критерии не обозначены. И вот тут всегда есть субъективная составляющая.

Смотрите допустим у вас есть тестовые примеры, набор запросов и ответов. Вы можете положить ответы в файл, и положить в другой файл ответы ваше системы. После этого запустить скрипт который сравнит эти файлы. В этом случае скрипт и среда должны быть квалифицированы. С другой стороны вы можете сказать что вы проглядели оба файла глазами и сравнили каждое значение, в этом случае вам ничего квалифицировать не нужно. И дальше 2 вопроса: 1. кто подпишется что он сравнивал файлы 2. поверять ли ему те кто вас проверяет что он так сделал. В целом все это ДО это решение задачи по убеждению того кто ставит подпись что проверка проведена и она нормальная.

Это не ошибка реализации, это ошибка требований или модели, а это уже не ДО-254 для конкретной железки. В целом да. Он не имеет рецептов как сделать хорошо. К примеру там написано что должны быть правила кодирования, но какие они должны быть не сказано. То есть можно написать что мы все имена начинаем с большой буквы и это единственное правило и все вы в стандарте по данному пункту. Когда работаете по ДО254 это означаете что вы прям реально запариваетесь и кто-то это проверяет, но никак не гарантирует что то что получилось будет супер надежным.

там будет куча НДА по той же физике... бесспорно, но это просто демонстрация общих принципов.

Это хитрый стандарт. Он не говорит что если вы по нему сделаете то это будет хорошо летать. Он говорит что если вы по нему сделаете, то это будет максимально что вы могли сделать на текущий момент. При этом если оно дрепнется и будет системная ошибка, они обещают добавить контроль за ней в стандарт... Потом там много политеса, вас в итоге должны аттестовать, то есть это игра ради проверяющего. к примеру вот есть устройство класса А. А теперь берем 2 таких устройства делаем в разных местах, и ставим работать в параллель, теперь можно им дать класс В, а то и С, потому что ошибка в одном не вызовет катастрофы, а одинаковая ошибка практически невероятное событие. И второй вариант аттестуют гораздо легче. так что в итоге надо плотно работать с теми кто вам печатьку будет ставить, какие практики им нравятся, как они привыкли видеть результаты и отчеты.

Между соседними точками на 200 МГц, будет достаточно малое изменение для достаточно широких полос) сколько в цифрах прям так прикинуть не могу.

Данные с АЦП практически наверняка за счет фильтров будут сильно коррелированными. Ну то есть даже если грубо брать 16 битный отсчет. Передавать его, а дальше передавать разность между текущим и предыдущим. Битность этой разности будет значительно меньше, потому что мгновенного изменения на АЦП ждать не стоит. Можно расширить Н бит АЦП до Н+1. первый бит взять маркером, если он 0, то дальше Н бит с АЦП, если он 1, то дальше разность текущего и предыдущего, допустим размерности Н/2. Накладных расходов 1/Н, а в случае успеха почти в 2 раза зажатый поток.

для сильно коррелированных коими будут последовательные отчеты АЦП процент будет весьма хорошим. Только любая задача сжатия, это поиск корреляции и ее устранение, то есть для нормального сжатия алгоритму нужен весь массив данных и тут без большой памяти и несколько проходной обработки не обойтись. Что, естественно, удобнее делать на процессоре, потому без него это лучше и не затевать. Другое дело если вы знаете распределение своих данных, тогда можно закодировать наиболее часто появляющиеся значение наименее коротким кодом, в таком случае по готовой таблице данные можно будет обрабатывать на лету. Это алгоритм Хаффмана, посмотрите. В вашем случае это просто таблица замены. Где входному числу ставиться в соответствие код, тем короче чем чаще появляется число. В оригинале таблица частоты появления строится по полному массиву данных, в вашем случае можно попробовать ее спрогнозировать заранее. Вероятность успеха я думаю процентов 40.