[Faton_11 0]

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

[andrew_b 14]

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

 

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

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

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

[iosifk 3]

1 минуту назад, andrew_b сказал:

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

 

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

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

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

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

[Faton_11 0]

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

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

Изменено 16 октября, 2018 пользователем Faton_11

[StewartLittle 40]

Инкрементальную компиляцию не забудьте включить.

[Kluwer 0]

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

[andrew_b 14]

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

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

ВременнЫе.

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

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

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

[Faton_11 0]

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? 

[iosifk 3]

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 отловить десяток-другой дребезга?

[Faton_11 0]

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 ноября, 2018 пользователем Faton_11

[iosifk 3]

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 неработоспособных состояний. Я же сразу пытаюсь удалить все состояния, о которых я знаю, если они теоретически могут привести к отказу. Возможно это аппаратно будет избыточно, но это экономит время на разработку...

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

[Kluwer 0]

20 hours ago, Faton_11 said:

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

 

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

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

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

[Faton_11 0]

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

[iosifk 3]

6 минут назад, Faton_11 сказал:

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

Вот тут я и напишу...

Мой учитель и наставник АМ Полонский учил меня, что есть только 2 марксистско-ленинских способа отладки. Метод "устранения" и метод "усугубления"... И есть к этим двум еще один метод, правда не  марксистско-ленинский, а радиолюбительский. И он называется "рукосуйство".... Так вот, умело применяя эти 3 метода можно отладить любую аппаратуру. :)