[Sobol' 0]

Приветствую всех заглянувших.

 

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

 

Только тапками не кидайте в убогого.

[Maverick_ 15]

Приветствую всех заглянувших.

 

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

 

Только тапками не кидайте в убогого.

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

Главное, чтобы правильно и без глюков работало в "железе"...

[SM 0]

На какие варнинги обращать внимание прежде всего?

 

В общем случае, для любой среды:

 

Глобально - на них надо смотреть только тогда, если что-то не работает!

 

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

2) сообщения на тему того, что число/константа/сигнал урезан в разрядности.

3) сообщения о неподключенных портах модулей, или неполностью подключенных (к шинам меньшей разрядности, чем порт).

4) сообщения о наличии тактовых сигналов, не описанных констрейнами.

 

[Sobol' 0]

Глобально - на них надо смотреть только тогда, если что-то не работает!

 

В этом я не сомневался.

Допустим, ситуация такая, что в симуляторе все работает, а в железе - нет.

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

 

 

[Jackov 1]

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

[Krys 2]

Вобщем да. Но бывает, что по-другому никак. При том бывает, что ворнинги генерит коргеновская корка, так что их оттуда уже не вычистить. Для больших проектов скажем под последние виртексы этих ворнингов столько, что заблудишься. Мы даже сделали фильтр, чтобы искал только ворнинги о наших модулях и не трогал чужие. Фильтрация просто по пути модуля.

[Jackov 1]

При том бывает, что ворнинги генерит коргеновская корка, так что их оттуда уже не вычистить.

Ну так-то да. Но ворнинги, хотя бы синтезатора, возникшие по вине разработчика, я считаю, можно вычистить всегда.

 

[Krys 2]

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

[SM 0]

Допустим, ситуация такая, что в симуляторе все работает, а в железе - нет.

Тут, вообще, на варнинги смотреть особо не надо. Кроме одного - "latch inferred" или "latch generated" - могут образоваться защелки там, где вы их не хотели.

Смотрите, в первую очередь, на правильность констрейнов и на их выполнение.

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

В третью - корректность асинхронной логики, особенно если используются асинхронные загрузки регистров и защелок, и асинхронные сбросы-установки, кроме основного резета.

[Sobol' 0]

SM, спасибо за ответ по существу.

 

Про асинхронную логику объясните поподробнее пожалуйста. Если есть у меня асинхронный сброс, отличный от глобального сброса - какие тут могут быть подводные камни?

[SM 0]

Если есть у меня асинхронный сброс, отличный от глобального сброса - какие тут могут быть подводные камни?

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

 

На сбросы это, в общем, не распространяется. Но в частности - может...

[Sobol' 0]

В общем заработала моя железка. Почему заработала пока не осознал.

 

Раз уж речь зашла о клоковых доменах - map выдает варнинг типа

Clock buffer is designated to drive clock loads. BUFGMUX symbol ... has a mix of clock and non-clock loads.

 

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

 

Вот, к примеру есть у меня два клока: clk16 с частотой 16MHz и clk1 с частотой 1MHz. Есть регистр Reg_1, к оторый должен тактироваться clk16 но при определенных условиях менять значение по фронту clk1. Я поступаю следующим образом:

 

// синхронизирую clk1 с clk16:

always @(posedge clk16) clk1_sync <= clk1;

// выделяю фронт:

wire clk1_posedge = clk1 && !clk1_sync;

// полученный сигнал использую в условиях типа:

always @(posedge clk16)

if (clk1_posedge) reg_1 <= ...

else ....

Изменено 16 февраля, 2015 пользователем Sobol'

[SM 0]

Вот, к примеру есть у меня два клока: clk16 с частотой 16MHz и clk1 с частотой 1MHz. Есть регистр Reg_1, к оторый должен тактироваться clk16 но при определенных условиях менять значение по фронту clk1. Я поступаю следующим образом:

 

// синхронизирую clk1 с clk16:

always @(posedge clk16) clk1_sync <= clk1;

// выделяю фронт:

wire clk1_posedge = clk1 && !clk1_sync;

// полученный сигнал использую в условиях типа:

always @(posedge clk16)

if (clk1_posedge) reg_1 <= ...

else ....

 

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

[Sobol' 0]

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

 

Т.е. примерно так:

 

reg [2..0] clk1_sync;

 

always @(posedge clk16) begin

clk1_sync[0] <= clk1;

clk1_sync[1] <= clk1_sync[0];

clk1_sync[2] <= clk1_sync[1];

end

 

wire clk1_posedge = clk1_sync[1] && !clk1_sync[2];

 

always @(posedge clk16) if (clk1_posedge) .......

 

верно?