nextsid 0 25 августа, 2006 Опубликовано 25 августа, 2006 · Жалоба Как в Libero сделать начальную установку триггеров в 0(1), иначе при симуляции триггеры (счетчики и пр.) в схемах с обратными связями могут долго находиться в неопределённом состоянии. Сейчас завожу в схеме принудительный асинхронный reset только ради этого, но это совсем не дело. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Postoroniy_V 0 25 августа, 2006 Опубликовано 25 августа, 2006 · Жалоба Как в Libero сделать начальную установку триггеров в 0(1), иначе при симуляции триггеры (счетчики и пр.) в схемах с обратными связями могут долго находиться в неопределённом состоянии. Сейчас завожу в схеме принудительный асинхронный reset только ради этого, но это совсем не дело. принудительный ресет как раз таки ДЕЛО но лучше не асинхронный, а синхронный :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
oval 0 25 августа, 2006 Опубликовано 25 августа, 2006 · Жалоба А для какого семейства ПЛИС Actel это все делается? У семейств Actel ProASIC, ProASICPlus, ProASIC3 начальное состояние триггеров неопределено. Поэтому там, где это важно (с точки зрения логики работы схемы) должен быть сброс. Какой асинхронный или синхронный, в принципе не важно, главное его грамотное формирование. Использование синхронного потребует большего количества ячеек, асинхронный же будет занимать специально выделенные ресурсы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Postoroniy_V 0 25 августа, 2006 Опубликовано 25 августа, 2006 (изменено) · Жалоба ...........Какой асинхронный или синхронный, в принципе не важно, главное его грамотное формирование. Использование синхронного потребует большего количества ячеек, асинхронный же будет занимать специально выделенные ресурсы. ну почему сразу больше то? :) не на много больше так разве нельзя сделать? из внешнего асинхронного ресета делаем синхроный (задерживаем в неск-их FF) и с выхода FF подаем на глобальный ресет - а он уже заводится на все FF в LE на асинхрон ресет а и синхр ресет всё же лучше ибо - Feeding Inputs and Resets to Your State Machine Reset signals are traditionally asynchronous and are routed directly to the clear inputs of state machine register elements. When the reset is asserted, all registers (state and output bits) are cleared immediately. All well and good, but what happens when the reset is deasserted? Consider a state machine that will transition from the reset state to some other state directly after the reset is deasserted. If the reset deasserts close to a clock edge, some of the state bits will assume their new states, while others might not. The state machine ends up in an undefined error state, and, yet again, you have egg on your face. The solution? Synchronize that darned reset! That way, the reset will be removed well before the clock edge, and all register elements will correctly transition to their new states. Изменено 25 августа, 2006 пользователем Postoroniy_V Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nextsid 0 25 августа, 2006 Опубликовано 25 августа, 2006 · Жалоба А для какого семейства ПЛИС Actel это все делается? У семейств Actel ProASIC, ProASICPlus, ProASIC3 начальное состояние триггеров неопределено. Поэтому там, где это важно (с точки зрения логики работы схемы) должен быть сброс. Для ProASICPlus и для 3-го. Мне сброс для работы схемы не нужен, схема сама выйдет на нужный режим из любой начальной комбинации триггеров. И вот приходится подрисовывать этот ненужный для работы сброс, иначе симуляция становится невозможной, а это ухудшит результат трассировки чипа, что понизит возможности чипа по частоте и емкости. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
oval 0 25 августа, 2006 Опубликовано 25 августа, 2006 · Жалоба ...........Какой асинхронный или синхронный, в принципе не важно, главное его грамотное формирование. Использование синхронного потребует большего количества ячеек, асинхронный же будет занимать специально выделенные ресурсы. ну почему сразу больше то? :) не на много больше так разве нельзя сделать? из внешнего асинхронного ресета делаем синхроный (задерживаем в неск-их FF) и с выхода FF подаем на глобальный ресет - а он уже заводится на все FF в LE на асинхрон ресет а и синхр ресет всё же лучше ибо - Feeding Inputs and Resets to Your State Machine Reset signals are traditionally asynchronous and are routed directly to the clear inputs of state machine register elements. When the reset is asserted, all registers (state and output bits) are cleared immediately. All well and good, but what happens when the reset is deasserted? Consider a state machine that will transition from the reset state to some other state directly after the reset is deasserted. If the reset deasserts close to a clock edge, some of the state bits will assume their new states, while others might not. The state machine ends up in an undefined error state, and, yet again, you have egg on your face. The solution? Synchronize that darned reset! That way, the reset will be removed well before the clock edge, and all register elements will correctly transition to their new states. ...........Какой асинхронный или синхронный, в принципе не важно, главное его грамотное формирование. Использование синхронного потребует большего количества ячеек, асинхронный же будет занимать специально выделенные ресурсы. ну почему сразу больше то? :) не на много больше Если описать на HDL именно как синхронный (то есть внутри тактового условия, если так можно выразиться), то на входе триггера появиться мультиплексор. Для технологии Actel ProASIC получиться в два раза больше. :) так разве нельзя сделать? из внешнего асинхронного ресета делаем синхроный (задерживаем в неск-их FF) и с выхода FF подаем на глобальный ресет - а он уже заводится на все FF в LE на асинхрон ресет Почему нельзя? Можно, как вариант. Есть еще варианты. :) Главное снимать синхронно. ;) а и синхр ресет всё же лучше ибо - Feeding Inputs and Resets to Your State Machine Reset signals are traditionally asynchronous and are routed directly to the clear inputs of state machine register elements. When the reset is asserted, all registers (state and output bits) are cleared immediately. All well and good, but what happens when the reset is deasserted? Consider a state machine that will transition from the reset state to some other state directly after the reset is deasserted. If the reset deasserts close to a clock edge, some of the state bits will assume their new states, while others might not. The state machine ends up in an undefined error state, and, yet again, you have egg on your face. The solution? Synchronize that darned reset! That way, the reset will be removed well before the clock edge, and all register elements will correctly transition to their new states. Как раз то, о чем я упомянул выше. Есть тут ньюансы, временные ограничения, например, желательно задать. Вообщем, если все продумать и грамотно сделать, все будет ок! :) Для ProASICPlus и для 3-го. Мне сброс для работы схемы не нужен, схема сама выйдет на нужный режим из любой начальной комбинации триггеров. И вот приходится подрисовывать этот ненужный для работы сброс, иначе симуляция становится невозможной, а это ухудшит результат трассировки чипа, что понизит возможности чипа по частоте и емкости. В этом случае просто определяйте начальное состояние сигналов (как я понимаю, речь идет об HDL). Можно еще в схеме для синтеза подать на сигнал сброса константу (неактивный уровень), синтезатор сам выкинет эту ненужную логику. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nextsid 0 25 августа, 2006 Опубликовано 25 августа, 2006 · Жалоба В этом случае просто определяйте начальное состояние сигналов (как я понимаю, речь идет об HDL). Можно еще в схеме для синтеза подать на сигнал сброса константу (неактивный уровень), синтезатор сам выкинет эту ненужную логику. Ввод графический. Если подать на сброс неактивную константу, то триггер так и останется в неопределенном состоянии. Может где-то в либеро можно указать начальную инициализацию триггеров? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Джеймс 4 25 августа, 2006 Опубликовано 25 августа, 2006 · Жалоба Как в Libero сделать начальную установку триггеров в 0(1), иначе при симуляции триггеры (счетчики и пр.) в схемах с обратными связями могут долго находиться в неопределённом состоянии. Сейчас завожу в схеме принудительный асинхронный reset только ради этого, но это совсем не дело. Отвечая на ваш вопрос, можно было бы посоветовать использовать initial (если бы вы использовали Verilog). Только это был бы плохой совет. Это может пройти для FPGA на основе SRAM (соответствующие семейства у Xilinx и Altera), но это не подходит для FPGA на основе flash. Нужен reset, причем подавать его лучше с монитора питания. А машины состояний – это вообще отдельный разговор. Без reset-а ничего гарантировать нельзя (т.к. синтезатор может изменить стиль кодирования – достаточно сравнить собственный код с нетлистом, но это опять же касается HDL-описаний). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nextsid 0 25 августа, 2006 Опубликовано 25 августа, 2006 · Жалоба Например, ввел в схему в графическом редакторе счетчик, или сдвиговый регистр с обратной связью - им не надо сброс, "вживую" они работают и без него. Но как посмотреть в Libero (точнее в ModelSim) как все крутится? Вот и приходится порисовывать сброс в схеме на время отладки или в процессе симуляции в ModelSim делать это индивидуально для каждого триггера, но их много и при каждом рестарте процесса всё сначала приходится делать. А как иначе сделать не знаю, как указать что начинать симуляцию (и только её) с нуля в триггерах? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Джеймс 4 26 августа, 2006 Опубликовано 26 августа, 2006 · Жалоба ..... Вот и приходится порисовывать сброс в схеме на время отладки или в процессе симуляции в ModelSim делать это индивидуально для каждого триггера, но их много и при каждом рестарте процесса всё сначала приходится делать. А как иначе сделать не знаю, как указать что начинать симуляцию (и только её) с нуля в триггерах? Напишите файл .do для ModelSim, типа такого: force s1 0 0 -cancel 1ns force s2 0 0 -cancel 1ns force s3 0 0 -cancel 1ns force s4 0 0 -cancel 1ns run 1ms Где s1,s2,s3 и т.д. - ваши выходные сигналы триггеров. Описание force смотрите в Command Reference у ModelSim. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nextsid 0 26 августа, 2006 Опубликовано 26 августа, 2006 · Жалоба Напишите файл .do для ModelSim, типа такого: force s1 0 0 -cancel 1ns ......... Спасибо, это уже кое что. Этот Force в МоделСиме по правой кнопке мыши на сигнале я и делаю, а вот вставить в wave.do файл не догадался :) . Правда, придётся индивидуально для каждого сигнала прописывать (изменять) force при изменениях в схеме, но уже куда лучше чем было. Можно и сокращенно написать: force s1 0 0 срабатывает, вот такое бы для всех сигналов. Попробовал: force * 0 0 , ругается, говорит - больше одного неможет: ** Error: (vish-4010) Cannot force more than one item at a time. Спасибо, пока так поиграюсь :) . Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться