Перейти к содержанию

    

проблемы с SignalTap

Добрый день, дорогие форумчане! 
Пришлось столкнуться со следующей проблемой: проект работает только если после прошивки ПЛИС в окне SignalTap нажать "Program Device" (если не нажать, то и сам анализатор не запустится, и проект корректно работать не будет. Точнее будет, но такое ощущение, что как при другом варианте прошивки=/). Если в настройках отключить галочку "enable SignalTap II logic analyzer", то проект тоже корректно работать не будет. Может кто-то сталкивался, в чем тут может быть дело? 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Да тысячи причин.

 

Проект необконстрейнен.

Либо обконстрейнен, но недостаточно. Либо  неправильно.

Либо не совсем корректно написан: нет CDC, например.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
1 минуту назад, andrew_b сказал:

Да тысячи причин.

 

Проект необконстрейнен.

Либо обконстрейнен, но недостаточно. Либо  неправильно.

Либо не совсем корректно написан: нет CDC, например.

Я просто немного добавлю. Когда подключаете логический анализатор, то это значит, что добавляются новые линии связи. И какой-то сигнал, который раньше шел по короткому пути, теперь еще идет и по дополнительному проводу интерконнекта к инстансу анализатора. А это добавляет емкостную нагрузку к источнику сигнала и сам сигнал чуть-чуть замедляется. Или проект перекладывается так, что вместо локального интерконнекта, теперь используется глобальный. И вот этого хватает для того, чтобы "заработало"... У меня такое было в начале работы с ПЛИС в конце 90-х. Сигнал дополнительно вывожу на светодиод - работает... Убираю - сбоит... Потом научился... :) 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

andrew_b, вот как раз с констрейнтами вожусь, спасибо! 


iosifk, а как научились?) Тоже в основном удавалось решать проблему констрейнтами? 

Изменено пользователем Faton_11

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Кстати, да, по собственному опыту если всё начинает рушится после подключения, или каких-то телодвижений в СТП - это 100% неправильные или вообще отсуствующие врЕменные ограничения. По-хорошему, после первого эскизного набора проекта, если ожидаются тактовые частоты выше 40-50МГц нужно сесть, не поленится и потратить время на грамотное заполнение sdc'шника. Иначе начинаются битвы с "песочным человеком" :(

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
2 часа назад, Kluwer сказал:

рЕменные ограничения

ВременнЫе.

2 часа назад, Kluwer сказал:

частоты выше 40-50МГц

Писать sdc надо всегда, независимо от частот. Хуже от этого не будет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
On 10/19/2018 at 11:58 AM, Kluwer said:

Кстати, да, по собственному опыту если всё начинает рушится после подключения, или каких-то телодвижений в СТП - это 100% неправильные или вообще отсуствующие врЕменные ограничения. По-хорошему, после первого эскизного набора проекта, если ожидаются тактовые частоты выше 40-50МГц нужно сесть, не поленится и потратить время на грамотное заполнение sdc'шника. Иначе начинаются битвы с "песочным человеком" :(

я не против грамотного заполнения SDC,  только вот с этим совсем все плохо, и вот тому пример:

В проекте есть следующие клоки :

-          Mlndr_CLK - клок, идущий с внешнего генератора на порт общего назначения ПЛИС и равный 12.5 МHz;

-          clk_dbg - клок с  генератора, установленного на отладочной плате (Сyclone II FPGA Starter Board) и равный 50 МHz;

-          PLLclk – клок с выхода мегафункции PLL равный 100 MHZ (на входе PLL - clk_dbg)  

Данные поступают на вход модуля цифрового фильтра по клоку  Mlndr_CLK, арифметика вычисляется на более "быстром" клоке - PLLclk

always@(posedge PLLclk)
   case(st)
      SUM_step0: begin
        begin 
          if (Mlndr_CLK) st=SUM_step1; else st=SUM_step0; 
        end
          begin
             //арифметика..
          end
       end

....... //арифметика....
    SUM_step3: 
         begin
           gnrt2[4].add_dataa=gnrt2[1].add_res;
           gnrt2[4].add_datab=gnrt_mult[8].mult_res;

           st=SAVE_add_res;

         end	

SAVE_add_res:   st=SAVE_div_res;
SAVE_div_res:   st=SUM_step0;

default: st=SUM_step0; 
endcase

//_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 		  
	always @ (posedge PLLclk)
		if (st==SAVE_add_res)
		   buff_reg1=gnrt2[4].add_res;
//_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 				
	always @ (posedge PLLclk)
		if (st==SAVE_div_res)
	      buff_reg2=quotient_bx[ADC_WIDTH-1:0];
//_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 				
	always @ (posedge Mlndr_CLK)
	     dataout=buff_reg2; // выходные данные, идущие наружу модуля 

, где   gnrt2[4].add_res - результат вычислений с выхода мегафункции сумматора (находится в блоке generate):

Adder_bx addr_bx (add_dataa,add_datab,add_res);

этот результат сохраняется в регистре buff_reg1 и затем поступает на мегафункцию делителя: 

Div div_rounding_bx(denom, buff_reg1,quotient_bx,remain_bx);

результат сохраняется в регистре buff_reg2, затем по фронту "медленного" клока Mlndr_CLK, подается на выход модуля

TimeQuest выдает сплошные "слэки" (см. прикрепленный файл).  

Констрейны, собственно,  такие: 
 

create_clock -name Mlndr_CLK    -period 12.5MHz [get_ports {Mlndr_CLK}]
create_clock -name clk_dbg   -period   50MHz [get_ports {clk_dbg}]
create_generated_clock -name PLLclk -source [get_ports {clk_dbg}] -multiply_by 2 -duty_cycle 50 

(видимо, для PLL ещё нужно указать параметр "[get_pins{.....]}]", но в выпадающем списке пинов ничего подходящего не было( 


Чем можно эти слэки исправить и почему в отчете Timequest-a в качестве launch и latch клоков стоит clk_dbg, а не PLLclk? 

отчет.jpg

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
7 минут назад, Faton_11 сказал:

-          Mlndr_CLK - клок, идущий с внешнего генератора на порт общего назначения ПЛИС и равный 12.5 МHz;

-          clk_dbg - клок с  генератора, установленного на отладочной плате (Сyclone II FPGA Starter Board) и равный 50 МHz;

-          PLLclk – клок с выхода мегафункции PLL равный 100 MHZ (на входе PLL - clk_dbg)  

Данные поступают на вход модуля цифрового фильтра по клоку  Mlndr_CLK, арифметика вычисляется на более "быстром" клоке - PLLclk

always@(posedge PLLclk)
   case(st)
      SUM_step0: begin
        begin 
          if (Mlndr_CLK) st=SUM_step1; else st=SUM_step0; 

А что, Mlndr_CLK идет синхронно с PLLclk? Или генераторы независимы и метастабильность может быть?

И что, фронт  Mlndr_CLK настолько хорош, что PLLclk, который в 8 раз быстрее, не может на фронте Mlndr_CLK отловить десяток-другой дребезга?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
21 hours ago, iosifk said:

always@(posedge PLLclk)
   case(st)
      SUM_step0: begin
        begin 
          if (Mlndr_CLK) st=SUM_step1; else st=SUM_step0; 

А что, Mlndr_CLK идет синхронно с PLLclk? Или генераторы независимы и метастабильность может быть?

И что, фронт  Mlndr_CLK настолько хорош, что PLLclk, который в 8 раз быстрее, не может на фронте Mlndr_CLK отловить десяток-другой дребезга?

Понимаю, что там асинхронщина, но не понимаю как в данном случае она влияет? Смотрю на анализаторе: данные ADC_Out, поступающие в ПЛИС, защелкиваются по фронту сигнала Mlndr_CLK. В состоянии SUM_step0, предположим, первый дребезг фронта клока отлавливается и происходит переход в следующее состояние.  Автомат успевает проходить все состояния до нового фронта Mlndr_CLK. Что в моих рассуждениях неверно?) 

1.jpg

Изменено пользователем Faton_11

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
39 минут назад, Faton_11 сказал:

Понимаю, что там асинхронщина, но не понимаю как в данном случае она влияет? Смотрю на анализаторе: данные ADC_Out, поступающие в ПЛИС, защелкиваются по фронту сигнала Mlndr_CLK. В состоянии SUM_step0, предположим, первый дребезг фронта клока отлавливается и происходит переход в следующее состояние.  Автомат успевает проходить все состояния до нового фронта Mlndr_CLK. Что в моих рассуждениях неверно?) 

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

Вот к примеру контроллер RS232 в ПЛИС... Можно брать один отсчет в середине битового интервала. И считать, что сбоев не будет. Ну а дальше навернуть бит нечетности, CRC в протоколе и т.д.

А можно за битовый интервал брать 3 отсчета и их мажоритировать. И при этом уже наплевать и на кабель и на расстояния и на запросы по битым пакетам, потому как их реально станет меньше. Да, конечно, в Ваших рассуждениях все верно. Подброшенная монета всегда падает и точно встает на ребро. Но я столько раз сталкивался с тем, что проклятая монета иногда зависает в воздухе. А потому теперь для меня проще сразу же привести медленный входной сигнал к системному тактовому, отфильтровать его и выделить передний фронт. Вот тогда строка начала расчета запустится без метастабильности и выполнится только один раз... А if (Mlndr_CLK) без if (!Mlndr_CLK) такого не гарантируют. Возможно у Вас вычисления дольше, чем длительность Mlndr_CLK, но я так никогда не играю.

Если взять алгоритм работы Вашего устройства, то вектор событий, разрядностью N, даст 2^N состояний, причем одно или два из них правильные, а остальные дают ошибки в работе. Ну и Вы говорите, что по одному их этих состояний Вы и пошли, ибо не работает.  Вам всего лишь осталось устранить 2^N - 1 неработоспособных состояний. Я же сразу пытаюсь удалить все состояния, о которых я знаю, если они теоретически могут привести к отказу. Возможно это аппаратно будет избыточно, но это экономит время на разработку...

Подробнее могу только голосом...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
20 hours ago, Faton_11 said:

Понимаю, что там асинхронщина, но не понимаю как в данном случае она влияет? Смотрю на анализаторе: данные ADC_Out, поступающие в ПЛИС, защелкиваются по фронту сигнала Mlndr_CLK. В состоянии SUM_step0, предположим, первый дребезг фронта клока отлавливается и происходит переход в следующее состояние.  Автомат успевает проходить все состояния до нового фронта Mlndr_CLK. Что в моих рассуждениях неверно?)

 

Коллега, Иосиф прав абсолютно, если у вас шина (а не один бит), то тут никакая абсолютно асинхронщина не допустима. Я даже не буду объяснять почему, полно лит-ру по этому вопросу.

Причём, если у вас переход шин, то варианта, по-сути, только два: а) навороченный автомат в стиле связнЫх протоколов (а в реальности вы, скорее всего, по-просту поставити стэк (Фифошку); б) жёсткая завязка клоков на ФАПЧе (PLL). В вашем случае, чтения потоковых отсчётов с ацп, скорее всего, вообще только второй вариант доступен.

Соотвественно, клок должен быть тот же, что используется ацп (сам он генерит, или внешний), дальше (например, у вас квадратурный детектор с последующим прореживанием (децимацией) либо генерите дочерние клоки на ФАПЧ (в sdc можно их объявить автоматически derive_pll_clocks), либо делите на регистрах (только не на логике!) и тащите либо кратные частоты как таковые, либо тащите исходный клок с прореживающими стробами (каждый вариант имеет свои достоинства и недостатки). Только так, иначе метастабильности приведут к тому, что вы будете бегать вокруг девайса с криками "да это мистика какая-то! как такое может быть вообще?!" :).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

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

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти
Авторизация