[Putnik 0]

Замечено изменение работоспособности проекта при добавлении виртуального логического анализатора (Identify, ChipScope)

C чем может быть связано, и куда смотреть (код, констрейны, ...)?

Интересны даже общие соображения, или может кто-то с таким тоже сталкивался..

[Beby 4]

Замечено изменение работоспособности проекта при добавлении виртуального логического анализатора (Identify, ChipScope)

C чем может быть связано, и куда смотреть (код, констрейны, ...)?

Интересны даже общие соображения, или может кто-то с таким тоже сталкивался..

Да, есть такое дело.

1. Обычно плывут не за'constraint'ненные или неправильно за'constraint'ненные цепи. Более вероятны потаённые глюки в местах перехода данных с одного clock domain в другой.

2. Частенько, при добавление логических проб, они устанавливаются не только на выходы триггеров, но и на цепи, сформированные логикой - а это может изменить разбивку логики на LUT'ы в результате чего вылезают ранее не выявленные проблемы, описанные в предыдущем пункте.

3. Так бывает, что некоторая не очень новая версия ISE не правильно рассчитывает задержки для Hardware IP, например ISE 9.2 (без SP) неправильно проводила временной анализ Virtex-5 PCI-E Endpoint'а.

[disel 0]

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

[Beby 4]

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

Ага, а чтобы такого не было, надо использовать constraint IOB, принуждающий среду укладывать нужные триггеры в IOB. Ну и еще необходимо использовать constraint'ы OFFSET IN/OUT, которые задают те самые временные ограничения. Т.е. если наблюдается описанный негативный эффект, то:

1. Обычно плывут не за'constraint'ненные или неправильно за'constraint'ненные цепи.

[disel 0]

Ага, а чтобы такого не было, надо использовать constraint IOB, принуждающий среду укладывать нужные триггеры в IOB. Ну и еще необходимо использовать constraint'ы OFFSET IN/OUT, которые задают те самые временные ограничения. Т.е. если наблюдается описанный негативный эффект, то:

 

IOB используются, но если подключен чипскоп, то маппер кладет на этот констрейн и пишет соотвествующий варнинг, который не всегда можно заметить. Задавать же OFFSET OUT не всегда бывает нужно. Например у меня ЦАП АД9776А сам умеет подстраиваться, и никакой OFFSET OUT ему задавать не нужно, достаточно знать что IOB выполнен.

[Beby 4]

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

Ну так, map же ДАЖЕ напишет Warning - а смотрите ли Вы на них,.. или не смотрите - это уже персонально Ваши проблемы. Важно, что Warning принципиально появится.

 

Задавать же OFFSET OUT не всегда бывает нужно. Например, у меня ЦАП АД9776А сам умеет подстраиваться, и никакой OFFSET OUT ему задавать не нужно, достаточно знать что IOB выполнен.

Да, если Вы любите острые ощущения, то, пожалуй, OFFSET OUT - лишний constraint. Я же обычно добавляю OFFSET OUT на критичные ножки при любом раскладе: для цепей, где это не важно - развожу проект с пустым OFFSET OUT, смотрю получившиеся значения и вношу их в OFFSET OUT; и если что-то в проекте уносит - я это вижу. Но, опять-таки, некоторые любят острые ощущения... я же отношусь к перестрахуям - область применения обязывает.

[disel 0]

Ну так, map же ДАЖЕ напишет Warning - а смотрите ли Вы на них,.. или не смотрите - это уже персонально Ваши проблемы. Важно, что Warning принципиально появится.

ISE этих варнингов сотнями выдает, в том числе на собственные ядра. Если каждый раз анализировать все, то можно только этим и заниматься.

 

Да, если Вы любите острые ощущения, то, пожалуй, OFFSET OUT - лишний constraint. Я же обычно добавляю OFFSET OUT на критичные ножки при любом раскладе: для цепей, где это не важно - развожу проект с пустым OFFSET OUT, смотрю получившиеся значения и вношу их в OFFSET OUT; и если что-то в проекте уносит - я это вижу. Но, опять-таки, некоторые любят острые ощущения... я же отношусь к перестрахуям - область применения обязывает.

Любите вы себе лишнюю работу себе добавить:)

Про острые ощущения... Мне кажется вы не прочитали мое сообщение про то что ЦАП сам умеет подстраивать окно приема данных под эти данные. Надо его только попросить об этом. Главное чтобы разброс в шине был минимальный, что гарантируется укладыванием тригеров в IOB. Это гораздо более надежное и простое решение чем установка OFFSET OUT. Потому что оно не зависит от того куда чего уведет в проекте, как измениться фазовый сдвиг частот между ЦАПом и плисом, ни от температуры (циклы самоконтроля проходят периодически), ни от длины проводников в плате (ну при условии что шина выровнена). При этот отпадает необходимость применения DLL, PLL и прочих плисовых синтезаторов, без которых выполнение OFFSET OUT на высоких частотах не возможно. Соответственно меньше потребление, нет необходимости следить за локом синтезатора и формировать ему ресет.

C OFFSET IN та же история. Современные АЦП и клочныме дистртибьютеры позволяют обойтись без задания OFFSET IN.

Понятно, что есть случаи, когда эти констрейны обязательны.

Про OFFSET OUT на некритичных ногах вообще не понял. Зачем и куда? На статичные сигналы? Возможно просто у вас очень много свободного времени.