[johan 0]

Всем доброго дня!

 

В проекте есть главный модуль, который занимает 80-90% всей логики, и он питается от одной системной частоты ( внутри этого модуля все синхронно ). Так же на него заходит асинхронный сброс с контрольных регистров, которые управляются через SPI.

 

Все регистры модуля можно разделить на две группы: 1) задержанные данные ( широкие данные типа [127:0] data ), 2) управляющие сигналы ( data_val, rd/wr_req, FSM, счетчики ).

 

Исторически сложилось, что этот сброс приходит на все-все регистры, но встает резонный вопрос: если вся управляющая логика правильно написана, то зачем сбрасывать в ноль широкие данные? В проекте чаще всего идет борьба за Fmax, и на сколько я понимаю, разводка асинхронного ресета никак не должна влиять на Fmax и на используемые ресурсы.

 

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

 

P.S. Целевая FPGA от Альтеры, но интересно услышать мнение и от пользователей FPGA от других производителей.

 

Заранее спасибо.

[o_khavin 0]

Всем доброго дня!

 

В проекте есть главный модуль, который занимает 80-90% всей логики, и он питается от одной системной частоты ( внутри этого модуля все синхронно ). Так же на него заходит асинхронный сброс с контрольных регистров, которые управляются через SPI.

 

Все регистры модуля можно разделить на две группы: 1) задержанные данные ( широкие данные типа [127:0] data ), 2) управляющие сигналы ( data_val, rd/wr_req, FSM, счетчики ).

 

Исторически сложилось, что этот сброс приходит на все-все регистры, но встает резонный вопрос: если вся управляющая логика правильно написана, то зачем сбрасывать в ноль широкие данные? В проекте чаще всего идет борьба за Fmax, и на сколько я понимаю, разводка асинхронного ресета никак не должна влиять на Fmax и на используемые ресурсы.

 

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

 

P.S. Целевая FPGA от Альтеры, но интересно услышать мнение и от пользователей FPGA от других производителей.

 

Заранее спасибо.

 

1) Сброс должен быть синхронным.

2) Сбрасывать всё, естественно, нет смысла. Во первых нужно завести сброс на входы и выходы управления и состояния. Во вторых нужно сбрасывать генераторы, т.е. элементы, следующее состояние которых зависит от их же предыдущего состояния - счётчики, машины состояния. В третьих нужно выяснить, какой продолжительности должен быть сброс, чтобы все остальные элементы конвейеров перешли в исходное состояние.

Лучшей проверкой сброса будет отсутствие начальной инициализации при проверки в симуляторе. Если из X-ов после применения сброса всё встанет в правильное положение, значит и в реальной жизни всегда будет сбрасываться в предопределённое состояние.

Всё IMHO, но приобретённое на опыте. :)

Изменено 2 февраля, 2014 пользователем o_khavin

[SM 0]

1) Я всегда сбрасываю регистры, только которые сбрасывать необходимо по алгоритму работы устройства. Те же, например "широкие данные", если они идут в конвейер цифрового фильтра, я сброшу, так как от них могут быть последствия в виде долгой реакции фильтра. Если же эти данные - просто шина данных, и сопровождаются стробом - то я сброшу только строб, чтобы система видела - что эти данные не нужные. Стараюсь минимизировать количество регистров, требующих сброса - так как, если с данного проекта или IP-блока понадобится синтезировать заказную ИМС, то это сэкономит место (которое area, которое непосредственно стоимость ИМС на выходе).

 

2) По возможности я стараюсь писать блоки так, чтобы они были не требовательны к синхронности сброса, то есть, чтобы при любых нарушениях removal/recovery времен, работа схемы не нарушалась, то есть, что бы никогда не было двух или более инициаторов, которые могут инициировать что-то после сброса одновременно, ну либо делаю арбитр таких инициаторов, сбрасываемый сам по себе, гарантировано не могущий быть ни в чем, кроме нуля, на одном-двух тактов (или более) с момента асинхронного сброса. И, только если иначе никак - то синхронный сброс. Причина банальна - см. пункт 1, "если с данного проекта......, то площадь это наше все - деньги" (регистр с асинхронным сбросом там обычно меньше, чем с синхронным)

 

3) Разводка глобального резета на Fmax не влияет, но только, если это синтез для FPGA, и только, если по специальной глобальной цепи, предназначенной для резета. Иначе влияет.

[krux 8]

асинхронный сброс плох следующим моментом:

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

со всем вытекающими последствиями.

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

[dmitry-tomsk 0]

асинхронный сброс плох следующим моментом:

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

со всем вытекающими последствиями.

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

Нормальные инженеры сбрасывают тем же сигналом и pll и накладывают TIG констрэйнт на сигнал сброса, чтобы на времянки он не влиял совсем.

[SM 0]

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

 

Ну, во первых, накладывается, проверка recovery/removal делается на равне с setup/hold, ее никто не отменял. Если ее не запретить насильно отдельным констрейном.

 

А во вторых, можно (и IMHO нужно) так проектировать схему, чтобы при снятии асинхронного резета в любое время, даже в "нехорошее", с нарушением recovery/removal, она работала как задумано. Это не сложно, просто надо каждый раз, подключая резет к какому-то регистру, подумать, а что в этом месте может быть на старте, и сделать схему так, чтобы ничего плохого не могло произойти.

[krux 8]

Нормальные инженеры сбрасывают тем же сигналом и pll и накладывают TIG констрэйнт на сигнал сброса, чтобы на времянки он не влиял совсем.

я бы сформулировал немного по-другому.

Дефолтные настройки ISE таковы, что PAR дается указание, что он обязан выполнить явно невыполнимые констрейнты.

И разработчику приходится лезть и руками указывать TIG даже на какой-нибудь отладочный светодиод, находящийся в слишком далеком (по мнению PAR) банке, иначе проект "не собирается".

У конкурентов немного по-другому.

Поэтому оценивать "нормальность" инженера количеством явно указанных TIG без привязки к лагерю (Altera/Xilinx) некорректно ;-)

Изменено 2 февраля, 2014 пользователем krux

[johan 0]

Всем спасибо за конструктивные ответы!

 

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

 

работа схемы не нарушалась, то есть, что бы никогда не было двух или более инициаторов, которые могут инициировать что-то после сброса одновременно

SM, а когда может возникнуть ситуация, когда после сброса происходит начало какого-то не запланированного действия? Мне казалось, что такое может быть, когда активное-рабочее состояние триггера - ноль, и он сразу после сброса внезапно оказывается активен. Сигнал типа: data_n_val: инверсия сигнала data_val.

[SM 0]

SM, а когда может возникнуть ситуация, когда после сброса происходит начало какого-то не запланированного действия? Мне казалось, что такое может быть, когда активное-рабочее состояние триггера - ноль, и он сразу после сброса внезапно оказывается активен.

 

Ну.... Как бы это сказать....

 

Берем два разных процесса.... Оба из них инициируют какую-то транзакцию. Эти два процесса должны быть удовлетворены. Ну так их следует удовлетворить в нужной последовательности....

 

ЗЫ - не бывает незапланированных действий, если Вы их не запланировали :beer: :1111493779:

 

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

 

2 johan -

 

такая ситуация возникнет тогда, когда после снятия сигнала сброса, но до допустимого времени, возникнут какие либо воздействия на схему.... вот так...

[Golikov 0]

1. берем конечный автомат который после снятия ресета находиться в состоянии IDLE, и ожидает сигнал старта, после которого начинает работать.

 

2. берем конечный автомат который после снятия ресета сразу пускает что-то молотить, допустим фильтровать данные.

 

Первый автомат более устойчив к некорректному выходу из ресета, в случае второго автомата при выходе очень близко к основному клоку, какие то сигналы могу не занять своего истинного значения, и он полетит вперед по неправильному пути. Надеюсь я понятно объяснил что имею ввиду:)

 

 

[SM 0]

1. берем конечный автомат который после снятия ресета находиться в состоянии IDLE, и ожидает сигнал старта, после которого начинает работать.

 

2. берем конечный автомат который после снятия ресета сразу пускает что-то молотить, допустим фильтровать данные.

 

ну а разница лишь в том, что в первом случае тот же автомат пойдет выполнять "нечто, взявшееся откуда-то", а в другом случает тоже самое нечто, но предопределенное разработчиком. Обязательно, сопровождайте свои данные стробом.

[krux 8]

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

[Golikov 0]

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

 

другими словами для конечных автоматов асинхронные ресеты недопустимы?

 

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

[krux 8]

тут дело тонкое. надо соображать для чего делается, и с какой долей ответственности.

если снаружи этим SPI рулите тоже вы, то всё ок.

А вот как IP-корку такое уже не продашь. Почему? например при неактивном CS поведение SCK для этого слейва не определено, т.е. во время когда SPI-мастер работает по той же шине, но с другим слейвом, - он может менять частоту. и например вдуть по SCK вашему автомату 50 МГц вместо 2 МГц. Если у автомата нет собственной частоты и нет clock gating по CS (на которой он кстати как минимум сохраняет своё состояние каждый такт) - то ему может и поплохеть от такой болтанки.

Изменено 2 февраля, 2014 пользователем krux

[SM 0]

другими словами для конечных автоматов асинхронные ресеты недопустимы?

Допустимы и легко, при условии, что любое состояние, в которое он может уйти из того состояния, в котором он находится при активном резете, отличается от него значением только в одном разряде регистра. Тогда при нарушении по recovery или removal, самое плохое, что может случиться, это автомат задержится в своем начальном состоянии лишний такт (иначе - может улететь вплоть до непредусмотренного, если данные меняются в нескольких разрядах, а хотя бы в одном из них не изменится). Не устану повторять - главное понимать физику происходящего! Ну выучите уже как работает триггер, товарищи HDL-программисты!