Здравствуйте, уважаемые форумчане.

Есть некий проект, который писался под Xilinx или Actel.
По некой иронии судьбы приходится пихать его в Atmel ATF280.

Штука зверски тормозная, поэтому то, что на Xilinx или Actel шло на 100 МГц на Atmel и на 20 не тянет.

Одна из причин такой тормознутости у этой ПЛИС - у регистров нет синхронного ресета, только асинхронный. Весь проект был написан под синхронный "правильный" ресет. Следовательно синтезатор замутил все сигналы ресета на вход данных тригеров через логику это вызвало дополнительные задержки из-за:
- дополнительной логики на пути сигнала данных тригеров (D)
- сильно разветвленные цепи сигналов ресета по неспециализированным путям что давало задержку только этих цепей >20нс

Отсюда есть несколько вопросов как лучше переделать дизайн. Впринципе уже есть несколько тестируемых вариантов переделок интересует как правильнее.

1)Оставить описание ресета синхронным.
-Улучшить ситуацию включением опции Maximum fanout(благо присутствует).
-Выкинуть ресет отовсюдо откуда можно. Насколько это кстати корректно иметь регистры без сброса? (В изначальном дизайне ресет есть у всех тригеров)

В этом случае у нас вообще не будет "настоящего"(заведенного на соответствующей пин тригера) ресета нигде. Насколько это корректно и надежно для серьезного автономного проекта на ПЛИС с длительным ресурсом работы? Мои предположения - что это не проблема.

2)Переделать проект под асинхронных ресет.
-Заменить везде ресет на асинхронный.
-Выкинуть ресет отовсюдо откуда можно.

Асинхронных ресет будет синхронизироваться через триггеры.

Посмотрите на структуру базовой ячейки. (Устанавливаются ли триггера по включению питания в 0 как у xilinx fpga или требуется внешний ресет (наверно как у Actel).

Судя по Вашим рисункам - Вам этот clr не нужен ибо сразу после его снятия перезапишется состояние по входу D.
Если это и нужно, так наверно для триггеров с разрешением по записи.

Строка из Datasheet
The initialization of the register is also programmable. It can be either SET or RESET

Строка из Precision RTL при синтезе
Warning: [45765]: Ignoring Initial value for this signal/variable as initial value is not supported for the specified technology.

Придется мучить support Atmel.



Это понятно в таких местах и некоторых других уже выкинул.

Вопрос по сути был в правильности использования синхронного ресета при отсутствие его встроенного исполнения.

Кто Вам это сказал???
ATF280 - это RadHard-версия старого атмеловского семейства AT40K.
Смотрите архитектуру ячейки (как Вам уже советовали) - на входе триггера в макроячейке имеется два трехвходовых LUT'а.
Что же Вам мешает сделать синхронный сброс???

Смотрел - знаю.


Ничего.

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

Например у вас в проекте 100 триггеров с глобальными(или одинаковым сигналом) ресетами. При этом:

Например путь от триггера А к триггеру Б с синхронным ресетом 30 нс (рисунок 1). Определяется временем установки сигнала ресета.
Разводка обычного сигнала синхронного ресета до 100 триггеров приводит к задержке на этой линии ресета в 30нс.

В случае асинхронного ресета(рисунок 2) сигнал ресета за 10 нс сбрасвает 1 триггер и еще за 10 нс сбрасывает линию данных второго триггера => суммарная задержка по критическому пути 20нс.
Путь сигнала данных от тригера А до тригера Б занимает в обоих случаях 10 нс(нормально для локального сигнала) остальное добавляет сигнал ресета.

Асинхронный ресет разводится по специальным линиям вроде клоковых и имеет задежку на своей линии 10нс. Синхронный ресет по ним развести нельзя ибо у триггеров нет для него отдельного порта и линии не предусмотрены!
Итого применяя асинхронный ресет получаем выигрыш в 1.5 раза по скорости.
Вот такие задержки у Atmela.

П.С. Правда проблему большой задержки синхронного ресета я частично решил установкой максимального кол-ва подключенных элементов к линиям. Maximum Fanout

Сообщение отредактировал spooki - Dec 22 2011, 08:29