как избежать проблем при переносе VHDL проекта, отлаженного на многократно программируемой микросхеме ProAsic на однократно программируемую SX?

Может есть у кого подобный опыт?, прошу поделиться советом gjcrjkmre поскольку воникли проблемы в работе логики на SX.

Заранее благодарен.

Сообщение отредактировал another_one - Dec 26 2008, 15:19

Работал с однократными Actel eX. А в чем суть проблемы?

Проблема заключается в следующем:

Время от времени читается предыдущее регистров регистров или не все биты регистров совпадают записанному.

Дизайнер при компиляции выдает предупреждения о том что производные клоки от HCLK не имют достаточной нагрузочной способностью для всех такируемых ими триггеров.

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

Отдельно для этих клоков с помощью атрибутов Synplify/Synplify pro типа "maxfan" изменить их нагрузочную способность не получается.

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

Другие версии.
Что-то покорежил Synplify... Очень редко, но бывает. То же самое – проверяется при моделировании нетлиста (при использовании однократных FPGA проверять “на железе” советовать не приходится). Попробуйте:
- отключить FSM Compiler
- задать Fanout = 9999 (при этом Synplify не будет размножать триггеры) _и_ указать Hard-limit to fanout

Важно. Проверьте в репорте Actel Designer, что все тактовые частоты назначены на глобальные цепи! Там в текстовой ‘табличке’ слева указан fanout, потом – тип. Тип должен быть CLK_NET.

С нагрузочной способностью драйверов проблема, мне кажется, скорее всего не связана.

Самый главный совет - первый - промоделировать нетлист. Если проблема есть, то она с большой вероятностью проявится.

Спасибо Вам большое за поддержку.



У меня микросхема A54SX32A, отлаживался на APA300. У 54SX32A три глобальных клока -1 Hardwired Clocks (HCLK) и 2 Routed Clocks (CLKA, CLKB) . HCLK меня в схеме устройства тактируется геренратором на 16МГц. Остальные не изпользуются. HCLK тактирует все схему в поведенческой моделе(цепь "clk"). В моделе я ввел еще два клока clk2 и clk3 - производных от "clk" для тактирования двух таймеров разной разряднойсти. Синтезатор ввел проризводные от двух последних(clk2_0, clk2_1,clk2_3, clk_3_0) , которые Дизайнер упомянул в сообениях о том что у них недостаточно нагрузочных ресурсов. По поводу clk2 и clk3 Дизайнер выдает тоже самое. Моделирования после разводки и имплементации не показало ошибок при записи / чтении, те которые были на практике.



у меня тоже такое подозрение, поскольку у меня стоит Libero 8.2 и поверх ставил еще 8.4 b Synplify pro.
Изменял значения Fanout в "implementation options" Synplify, в итоге он сообщил о диапаозне от 6 до 24, при границах которого синтезатор добавляет либо удаляет буферы, изменяя при этом основную имплементацию. При увеличении количества буферов сообщения Дизайнера только увеличиваются - увеличивается количество производных от clk2 и clk3(вследствии доюваления триггеров при изменении имплементации). Поэтому получается замнкнутый цикл. Отдельно добавить буферы для clk2 и clk3 с помощью атрибутов(пробовал с syn_maxfan) Synplicity не получается.



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

Вот такого типа сообщение-прдупреждение:
Warning: Non-global resource 'inst_2/clk2_0' is being used to drive multiple clock pins. Clock
pins should be driven by global resources if available.

А у Вас клоки подключены как?
HCLK - через буфер HCLKBUF
CLKA, CLKB - через буфер CLKBUF или с использованием примитива CLKINT

Так?

точно не помню, вроде было так:

Log synplify:

clkbuf: 1 clock buffer
hclkbuf: 1 clock buffer

clkint: 2 clock buffer

Log Designer:

CLOCK Used: 2 Total: 2
HCLOCK Used: 1 Total: 1


т.е вероятно HCLK подключен через clkbuf, а CLKA, CLKB через clkint. точного определения для CLKA и CLKB такого как для HCLK(hclkbuf: 1 clock buffer) не видел.

Прошу еще немного мне помочь.


Проблема решиться если найдется решение как предотвратить автоматическое перераспределение Netlist Дизайнером в следующем случае.

У меня следующие клоки:

- HCLK;
- CLKA;
- CLKB;
Разводимые клоки(CLKA, CLKB) внешним тактируемым сигналом не используются, поэтому я их заземлил. В VHDL проекте используются еще два под клока, один - производная от HCLK, другой внешний сигнал по квосходящему фронту которого защелкиваются несколько регистров(синтезатор определил этот сигнал как клок). В этоге распиновка этого сигнала была изменена дизайнером, вследствии привязки этого сигнала к разводимому клок буферу CLKA - дизайнер самостоятельно привязал этот сигнал к ножки CLKA.

Прошу подсказать как убрать автоматичекое перераспределение распиновки Дизайнером.

Пробовал поставить флаг в Синтезаторе "Disable I/O insertion" - в этоге дизайнер перестал вообще компилировать, ругаясь на отсутствии какого-то элемента библиотеки.


Заранее благодарен.

нужно добавить атрибут в разделе entity

entity example is
port (
...
not_clk : in std_logic;
...
);
attribute syn_noclockbuf : boolean;
attribute syn_noclockbuf of not_clk : signal is true;
end example;

Более подробное описание атрибутов можешь найти в хелпе к Sinplify

К сожалению это не решает проблему, только убирает глобальную цепь для сигнала, на который Дизайнер после применения данного атрибута ругается предупреждениями о том что недостаточная нагрузочная способность.

Я так понял что ruoted clock - CLKA, CLKB отличаются от HCLK, тем что эти глобальные цепи могут быть применнимы к вутренним сигналам. Поэтому привязка CLKA, CLKB к определенным выводам в этом случае не должна быть.

Эта проблема решилась при добавлении атрибута?



Это всего лишь пердупержение. Если бы у вас частота была около 100 мгц то на него стоило бы обратить внимание. Вообщето там написано что если есть возможность то следует использовать клоковую цепь А вообще моделсим должен эту ситуацию отмоделировать корректно.



Два предположения:1) где-то возникает гоночная ситуация - попробуйте увеличить время между приходом данных в регистры и клоком по которому он их сохраняет.
2) или вы делаете какое-то действие во время записи в регистры в результате чего запись не производится. такое например бывает при одновременной попытке записи и чтения.



Чудеса Моделсим практически непогрешим. Все зависит от того насколько адыкватна ваша модель

Спасибо большое за поддержку



Да, Дизайнер в этом случае не изменял netlist.