Асинхронный ресет Atmel ATF280, У ПЛИС есть только асинхронный ресет Опции

[spooki]

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

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

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

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

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

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

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

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

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

Эскизы прикрепленных изображений

 

[spooki]

Смотрите архитектуру ячейки (как Вам уже советовали) - на входе триггера в макроячейке имеется два трехвходовых LUT'а.

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

Что же Вам мешает сделать синхронный сброс???

Ничего.

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

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

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

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

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

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

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

Эскизы прикрепленных изображений