des00 25 12 января, 2015 Опубликовано 12 января, 2015 · Жалоба Только цепочка должна быть не тупо с повышением тактовой, а такой, как распространяется сигнал сброса, не привязываясь к частотам, то есть, оттуда, где он генерируется (например в домене "А"), он идет в домены "Б", и "В", а потом, обратно из доменов "Б" и "В", сигнал, говорящий домену "А", что все сбросилось, и можно начинать работать, то есть, снимать сигнал сброса с себя. Вот как-то примерно так. Направление, по большому счету, зависит от того, кто инициирует операцию, и кто на нее откликается - инициатор должен разрешаться только после того, как все остальные домены сбросились, независимо от того, у кого какая тактовая. Вы правы, но это только в случае реализации "тупого" инициатора и приемника, например, когда сигнал готовности приема данных при сбросе устанавливается в состояние разрешения. А в подавляющем большинстве случаев, если в других доменах нет ничего, чтобы происходило без ведома домена-инициатора (каких-нибудь самостоятельных таймеров, и т.п.), достаточно резетнуть все эти домены асинхронным сигналом, и в домене-инициаторе выдержать задержку, гарантирующую, что в других доменах пройдет по два-три клока, и только потом начинать работать. Я стараюсь делать модули во время сброса пассивными во всех смыслах, порой это приводит к наличию дополнительной логики, но зато никаких проблем со сбросами. И как сказал проброс сигнала делаю с низкочастотного домена в высокочастотный. Хотя это не обязательно, но люблю порядок :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 12 января, 2015 Опубликовано 12 января, 2015 · Жалоба Я стараюсь делать модули во время сброса пассивными во всех смыслах, Вот именно. И получаем простую схему: 1) совершенно АСИНХРОННЫЙ сброс, без всякого проброса чего либо и куда либо. Просто, глобальный резет. 2) Этот сброс, в том числе, запрещает работу всех приемников, таймеров, и прочего, что может словить метастабильность. 3) Инициатор (а он всегда есть, и один, который самый первый из всех), через какое-то время после снятия сброса разрешает работу всего, чего надо, и разрешает уже по каналам управления, которые проброшены через домены, как им следует быть проброшенными. И единственное синхронизированное от сброса место - эта первичная разрешалка. Один бит данных. А сброс при этом, совершенно асинхронный... И думать о нем не надо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 12 января, 2015 Опубликовано 12 января, 2015 · Жалоба А сброс при этом, совершенно асинхронный... И думать о нем не надо. согласен. я раб привычек доведенных до автоматизма, наверное поэтому и ставлю :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vea 0 13 января, 2015 Опубликовано 13 января, 2015 (изменено) · Жалоба Вот именно. И получаем простую схему: 1) совершенно АСИНХРОННЫЙ сброс, без всякого проброса чего либо и куда либо. Просто, глобальный резет. 2) Этот сброс, в том числе, запрещает работу всех приемников, таймеров, и прочего, что может словить метастабильность. 3) Инициатор (а он всегда есть, и один, который самый первый из всех), через какое-то время после снятия сброса разрешает работу всего, чего надо, и разрешает уже по каналам управления, которые проброшены через домены, как им следует быть проброшенными. И единственное синхронизированное от сброса место - эта первичная разрешалка. Один бит данных. А сброс при этом, совершенно асинхронный... И думать о нем не надо. Я правильно понимаю, что асинхронный сброс используется только для этого первого блока, а остальные включаются синхронным ENABLE (т.е. в них синхронизированный асинхронный сброс просто не заходит)? Изменено 13 января, 2015 пользователем vea Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 13 января, 2015 Опубликовано 13 января, 2015 · Жалоба Я правильно понимаю, что асинхронный сброс используется только для этого первого блока, а остальные включаются синхронным ENABLE (т.е. в них синхронизированный асинхронный сброс просто не заходит)? Не совсем. Во первых, асинхронный сброс (который ни с чем не надо синхронизировать), заходит во все блоки сразу во всех доменах, и их всех асинхронно сбрасывает. Для этого в FPGA придумана единая глобальная линия сброса, и поэтому она там одна (а не пачка, как линий тактовых). И никакого "синхронизированного асинхронного сброса" нет. Он заходит на все сбросы не синхронизированным - прямо Ваш "RESET_n" как он есть. (но! внимание! именно на АСИНХРОННЫЕ входы сбросов всех блоков, которые требуют сброса) Во вторых, этот самый Enable нужен далеко не всем блокам, и не целиком целиком - Enable нужен конкретным отдельно взятым триггерам, которые на момент снятия RESET-а по каким-то причинам могут иметь на входе состояние, отличное от того, во что они были установлены по RESET, и то, не всем. Например: - Если это регистр, который записывается по команде из блока-инициатора, то ему отдельный Enable не нужен. Его и так инициатор разрешает только тогда, когда ему надо, и гарантировано, что не сразу после сброса.. - Eсли это таймер, считающий сам по себе с момента снятия резета, с приращением в 1 - то тоже не нужен. Почему? Потому что, при смене его состояния из 0 в 1 худшее, что может произойти, это что он задержится в состоянии 0 на 1 такт из-за метастабильности. Ну и что? От этого никому не холодно и не горячо. - А вот если это некий сумматор, который прибавляет к значению регистра некий код, не равный 1 (а точнее, не коду с одним разрядом, установленным 1), и этот код может быть таким в момент снятия резета, то вот тут уже нужно разрешение работы, чтобы не было сбоя. Тот есть, это самое разрешение нужно только в нескольких точках, отвечающих за старт работы системы в целом, и только в таких точках, где от метастабильного состояния в момент снятия резета реально может произойти сбой. Таких мест, если подумать, в проекте обычно или нет, или единицы (в основном автоматы, управляемые чем-то синхронным снаружи без доп. синхронизаторов, которые тоже сбрасываются по reset, или таймеры-счетчики, прибавляющие не единичные значения) UPD: А вот Enable этот генерируется синхронизирвоанным, как-то так: reg [2:0] en_ff always @(posedge clk or negedge RESET_n) if (~RESET_n) en_ff <= 3'd0; else en_ff <= {en_ff[1:0], 1'b1}; выход синхронизированного Enable берется с en_ff[2], и подается в необходимые точки, при необходимости, пересинхронизированным на другие клоки и в остальные клок-домены. А цепь асинхронного сброса надо исключить из временнОго анализа через set_false_path, так как Вы сами, схемотехнически устранили все возможности для сбоев. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Krys 2 14 января, 2015 Опубликовано 14 января, 2015 · Жалоба - Eсли это таймер, считающий сам по себе с момента снятия резета, с приращением в 1 - то тоже не нужен. Почему? Потому что, при смене его состояния из 0 в 1 худшее, что может произойти, это что он задержится в состоянии 0 на 1 такт из-за метастабильности. Ну и что? От этого никому не холодно и не горячо.Идея хорошая. Но есть сомнения. Вот тут (страница 13, второй снизу абзац): в приложении неплохая статья. изучайте.говорится, что: If the asynchronous reset is released at or near the active clock edge of a flip-flop, the output of the flip-flop could go metastable and thus the reset state of the ASIC could be lost. Это значит, что таймер может и не с нуля начать считать... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 14 января, 2015 Опубликовано 14 января, 2015 · Жалоба Это значит, что таймер может и не с нуля начать считать... Неа, не может, если изучить схему CMOS триггера. Если он сам в нуле, и на входе данных тоже ноль, то, что с ним не делай (кроме асинхронной установки в 1, которая тут не используется), в единицу его никак не загнать. Метастабильное состояние может возникнуть лишь тогда, и только тогда, когда в результате некоего действия ожидается смена состояния. И тогда оно может, как бы, неполностью смениться, что и есть суть метастабильности. А если внешних причин к смене состояния нет, то и метастабильность невозможна. То есть, автор статьи, скорее всего сознательно, опустил этот нюанс, что для метастабильности недостаточно снять резет невовремя, а надо еще иметь на входе сигнал данных, отличный от состояния в резете. Иначе бы весь смысл его статьи потерялся бы :) :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Krys 2 15 января, 2015 Опубликовано 15 января, 2015 · Жалоба Иначе бы весь смысл его статьи потерялся бы :) :)Хотелось бы Вам верить. Ведь так гораздо проще реализовывать. Но вот в статье "уважаемые дяденьки" пишут... и подкинул нам её как эталон "уважаемый товарищ" ))) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 15 января, 2015 Опубликовано 15 января, 2015 · Жалоба Хотелось бы Вам верить. А не надо мне верить. Возьмите, и поанализируйте схемы триггеров на транзисторном уровне. Сейчас в доступе есть достаточно и схем, и технологических либ разных фабов. Не первой свежести, но вполне достаточно. Хотя, профессиональному схемотехнику для этого достаточно схему лишь визуально изучить, даже без симуляции. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Krys 2 15 января, 2015 Опубликовано 15 января, 2015 · Жалоба А не надо мне верить. Возьмите, и поанализируйте схемы триггеров на транзисторном уровне.Во всё вникать и проверять доказательства самому - не хватит времени на всё, это надо было делать ещё в вузе ))) Сейчас проще прислушаться к опыту "старших товарищей". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 15 января, 2015 Опубликовано 15 января, 2015 · Жалоба Во всё вникать и проверять доказательства самому Когда дело доходит до оптимизации, когда надо "впихнуть невпихуемое", еще не тем заниматься приходится... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vea 0 16 января, 2015 Опубликовано 16 января, 2015 · Жалоба Когда дело доходит до оптимизации, когда надо "впихнуть невпихуемое", еще не тем заниматься приходится... Спасибо за развернутые объяснения. Пока все-таки буду перестраховываться и пропускать сброс через каскад - меньше шансов наделать ошибок. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vea 0 20 января, 2015 Опубликовано 20 января, 2015 (изменено) · Жалоба Неа, не может, если изучить схему CMOS триггера. Если он сам в нуле, и на входе данных тоже ноль, то, что с ним не делай (кроме асинхронной установки в 1, которая тут не используется), в единицу его никак не загнать. Метастабильное состояние может возникнуть лишь тогда, и только тогда, когда в результате некоего действия ожидается смена состояния. И тогда оно может, как бы, неполностью смениться, что и есть суть метастабильности. А если внешних причин к смене состояния нет, то и метастабильность невозможна. В статье Asynchronous & Synchronous ResetDesign Techniques - Part Deux, пункт 7.2 так и говорится: "[...] examine the transistor-level version of the model [...] the circuit was indeed not susceptible to metastability problems if the d-input was low when a reset recovery violation occurred [...]" (речь о втором регистре в каскаде, о третьем-четвёртом даже не говорится). Вот именно. И получаем простую схему...Правда, схемы в этой статье не такие уж и простые. Изменено 20 января, 2015 пользователем vea Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 20 января, 2015 Опубликовано 20 января, 2015 · Жалоба the circuit was indeed not susceptible to metastability problems if the d-input was low when a reset recovery violation occurred [...] Перевожу: "схема была действительно не восприимчива к проблемам метастабильности, если вход "D" был низким, когда произошло нарушение времени восстановления сброса" Собственно, именно это утверждаю и я, как и тот инженер, что в этом случае метастабильность невозможна. А все остальное - глюки моделей разных вендоров, а не проблемы железа. Я и под этим подпишусь, вообще, в части метастабильности, почти все модели глючные. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
troiden 0 20 января, 2015 Опубликовано 20 января, 2015 · Жалоба А вот Xilinx не сответует использовать везде глобальный асинхронный сброс. Мол не дает использовать дополнительный вывод у тех триггеров ячейки, в которые этот ресет не заводится, и увеличивает количество занимаемых ресурсов. Ну и у некоторых элементов вообще нет входа асинхронного сброса. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться