[dsmv 0]

Здравствуйте.

 

У нас на фирме периодические вспыхивают споры по стилю описания конечных автоматов. Вот собственно хочу поинтересоваться кто и как пишет конечные автоматы.

У меня сложилась следующая структура:

 

type stp_type is (s0, s1, s2,s3 );   -- описание типа
signal  stp  : stp_type;                 -- состояние автомата


rst <= not reset after 1 ns when rising_edge( clk );  -- из асинхронного сброса делаем синхрпонный

pr_stp: process( clk ) begin
if( rising_edge( clk ) ) then
     case( stp ) is
        when s0 => -- начальное состояние
                  a<= '0' after 1 ns;
                  b<= '0' after 1 ns;
                  c<= '0' after 1 ns;
                  if( d='1' ) then
                       stp <= s1 after 1 ns;
                  end if;

      when s1 =>
                 a<= '1' after 1 ns;
                 if( d='0' ) then
                     stp <= s0 after  1 ns;
                 end if;

      when s2 => -- что - то делаем
      when s3 => -- что - то делаем
   end case;


    if( rst='1' ) then
          stp <= s0 after 1 ns;  -- переход в начальное состояние
    end if;
  end if;
end process;

 

Особенности описания:

1. Всё в одном процессе

2. Все сигналы выходят после триггера

3. Предполагается, что входные сигалы (например d) тоже формируются на триггере на частоте clk

4. Сброс - синхронный, действует только на stp

5. Начальное состояние - s0, в нём прописываются начальные значения для других сигналов

6. После назначения сигнала добавляется after 1 ns - для того, что бы удобно смотреть на временной диаграмме

[id_gene 0]

боян, конечно, но вы эти статьи читали?

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

[dsmv 0]

боян, конечно, но вы эти статьи читали?

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

 

Конкретно эти статьи не читал, но там ничего особо нового нет.

Автоматы Миля и Мура. Но реализация этих автоматов в классическом виде в ПЛИС не эффективна.

[dvladim 0]

Но реализация этих автоматов в классическом виде в ПЛИС не эффективна.

А как же эффективно? И чем различаются классический и неклассический виды?

[Shtirlits 0]

Здравствуйте.

 

dsmv, вы привели несинтезируемый автомат.

Вероятно, есть какая-то зависимость между способом изложения автомата и скоростью работы симулятора, но я бы не стал на этом сосредотачиваться. Мало ли, выйдет новая версия и рецепты от старой станут вредны.

Для модели или теста важно другое - правильно, понятно и наглядно.

Ведь если вы не можете убедиться в правильности модели и теста, как сделать схему?

 

Для синтезируемых автоматов может оказаться полезным такой способ, при котором легко менять концепцию. Например, переход от Миля к Муру или даже от одного шага за такт к двум или более шагов автомата за такт.

Я пользовался двумя способами:

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

Регистры формируются в модуле на уровень выше.

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

 

Оба подхода работают, но эффект может отличаться при синтезе в зависимости от интеллекта синтезатора. Интуитивно второй способ мне кажется предпочтительнее.

 

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

Сроки поджимают, а площадь и потребление - нет.

Тогда мы снижаем частоту вдвое и переделываем автомат на 2 шага за 1 такт. Данные будут поступать по два слова за такт. Руками легко описать автомат с парой-тройкой состояний. И во всяком случае, не захочестя трогать уже верифицированный однословный автомат.

 

Этот же подход имеет смысл применять при кодировании вычислений, когда еще неясно как все будет разводиться. Вычисления рубятся на минимальные шаги. Для каждого делается функция и необходимые структуры данных. В симеляторе вычисление будет записываться так:

result = step10(step9(step8(........)));

или так:

stage1 = step1(arg);

stage2 = step2(stage1);

....

result = step10(stage9);

 

После верификации вычислений, можно изучить разводку:

process(clk)
  begin
     if rising_edge(clk) then
       stage1_sig <= step1(arg)
       stage2_sig <= step2(stage1_sig)
       stage3_sig <= step3(stage2_sig)
       ...
       result <= step10(stage9)
      end if;
  end process;

 

Если в этом pipeline-е окажутся маленькие соседние шаги, то их можно будет объединять.

Например, первые три объединяются выносом пары строк из процесса:

       stage1_sig <= step1(arg)
       stage2_sig <= step2(stage1_sig)

process(clk)
  begin
     if rising_edge(clk) then
       stage3_sig <= step1(stage2_sig)
       ...
       result <= step10(stage9)
      end if;
  end process;

 

К сожалению, этот способ нарушает наглядность кода.

[des00 25]

У нас на фирме периодические вспыхивают споры по стилю описания конечных автоматов. Вот собственно хочу поинтересоваться кто и как пишет конечные автоматы.

 

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

 

Теперь немного по вашему стилю.

 

1. Всё в одном процессе

 

для больших автоматов не всегда удобно

 

2. Все сигналы выходят после триггера

 

вызывает задержку реакции автомата на входные условия, в некоторых задачах не применимо.

 

4. Сброс - синхронный, действует только на stp

 

в даном примере вы неправильно синхронизируете асинхронный сброс, кстати этой теме тоже посвящено много литературы

 

6. После назначения сигнала добавляется after 1 ns - для того, что бы удобно смотреть на временной диаграмме

 

сильно загрязняет код, ИМХО я бы такой подход не использовал, если уж так горит смотреть на вейвормы не вооруженным глазом заверните в обертку с транспортными задержками.

 

я придерживаюсь разных стилей описания КА, в зависимости от условий и удобства в конкретном случае: общий, SV onehot, register/unregister output, states as outputs и т.д.

 

ЗЫ. Шаблон моего общего классического трех-процессного описания КА можно посмотреть здесь генератор КА, в примерах лежит сгенерированный файл.

[dsmv 0]

dsmv, вы привели несинтезируемый автомат.

Такие автоматы полностью синтезируется и прекрасно работают.

 

Для модели или теста важно другое - правильно, понятно и наглядно.

Вот это я полностью поддерживаю.

Вы используете очень интресное описание автоматов на основе функций, мне понравилось.

Может быть буду использовать.

 

 

 

в даном примере вы неправильно синхронизируете асинхронный сброс, кстати этой теме тоже посвящено много литературы

А в чём неправильность ? И что можно улучшить ?

 

я придерживаюсь разных стилей описания КА, в зависимости от условий и удобства в конкретном случае: общий, SV onehot, register/unregister output, states as outputs и т.д.

Это правильно, но у меня как-то всё свелось вот к такому виду.

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

Запись after 1 ns я считаю очень важной, это резко повышает наглядость временных диаграмм и избавляет от ошибок связанных с delta задержками. А их вылавливать очень трудно.

[Shtirlits 0]

Такие автоматы полностью синтезируется и прекрасно работают.

Запись after 1 ns я считаю очень важной, это резко повышает наглядость временных диаграмм и избавляет от ошибок связанных с delta задержками. А их вылавливать очень трудно.

Решительно возражаю против таких конструкций при синтезе.

Кто мешает "для наглядности" сделать after 5 ns и получить несоответствие симуляции и реальной схемы на 200MHz?

 

Я обнаружил три стадии развития разработчика синхронных логических схем:

1) рисуем или пишем на hdl схему, симулятор не используем, сразу в устройство и тыкать осциллографом до посинения

2) пишем на hdl модель, тесты и схему, гоняем в симуляторе, осциллограф пылится на складе, и без него вся понятно и отлично работает

3) пишем используя всю мощь hdl или других спец-средств, визардов, готовых ядер, самодельных синтезаторов, симулятор как-то и не нужен

 

Шли бы вы .... к третьей стадии.

[des00 25]

А в чём неправильность ? И что можно улучшить ?

 

нарезка асинхронного сигнала на триггере чревата возможным нарушением tsu/th, что может привести к т.н. эффекту метастабильности триггера. для подавления этих эффектов используют т.н. синхронизаторы сигналов сброса и деревья сброса. Причем ИМХО делать это надо не в каждом блоке, а на топлевеле.На форуме это уже обсуждалось и выкладывались статьи на эту тему, пользуйтесь поиском.

 

Это правильно, но у меня как-то всё свелось вот к такому виду.

 

в параноидальном вхдл, это чуть ли не единственный возможный вариант, в верилоге все намного проще. В атаче пример SV onehot автомата state as outputs, который лучше всего подходил под описание.

 

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

 

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

 

Запись after 1 ns я считаю очень важной, это резко повышает наглядость временных диаграмм и избавляет от ошибок связанных с delta задержками. А их вылавливать очень трудно.

 

сколько работаю ни разу не испытывал проблем с делата задержками особенно в языке VHDL, ядро которого полностью детерменированно и никаких гонок там нет. В отличие от чистого верилога. Но в нем эти записи хоть выглядят красиво вида odat <= #Tp idat, а тут все теряется в after.... В SV данную проблему вообще убрали.

 

ЗЫ. а вообще если уж писать, но надо писать красиво и понятно, т.к. код читают больше чем пишут (с) Макконел Совершенный код.

hssdrc_decoder_state.v

[dsmv 0]

При работе на третьей стадии обнаруживается интересная вещь - всё собрали и не работает. Вот тут и нужно провести анализ проекта. Моделирование - это один из этапов анализа, наряду с осциллографом и тестами.

Так что можно ввести четвёртую стадию:

система не работает - моделирум - обнаруживаем ошибку в модели - исправляем - и всё работает и в железе.

 

А по поводу 5 нс на 200 МГц - не ставьте 5 нс, поставьте 1 нс и всё будет отлично.

[id_gene 0]

1) сам разделяю автомат в отдельный процесс, присваивание выходов - в отдельный.

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

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

 

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

[dsmv 0]

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

 

Вот простой тест на delta задержки

library IEEE;
use IEEE.STD_LOGIC_1164.all;

entity temp is
end temp;

architecture temp of temp is

signal    clk            : std_logic:='0';
signal    clk1        : std_logic;

signal    a,b,c,d        : std_logic:='0';
signal    a1,b1,c1,d1    : std_logic:='0';

begin
    
clk <= not clk after 5 ns;
clk1 <= clk;

a <= not a after  1 ns when rising_edge( clk );
b <= not b after 1 ns when rising_edge( clk ) and a='1';
c <= a and b after 1 ns when rising_edge( clk );
d <= a and b after 1 ns when rising_edge( clk1 );

a1 <= not a1 when rising_edge( clk );
b1 <= not b1 when rising_edge( clk ) and a='1';
c1 <= a1 and b1 when rising_edge( clk );
d1 <= a1 and b1 after 1 ns when rising_edge( clk1 );

end temp;

 

результат моделирования в файле temp.jpg

 

Пояснения:

clk - формируем сигнал тактовой частоты

clk1 - переназначаем сигнал, он будет через delta

 

a,b,c,d - с использованием after 1 ns

a1,b1,c1,d1 - без использования

 

В результате c и d формируются одинаковыми

c1, d1 - разными.

 

Гарантировать, что в большом проекте нигде не произойдёт присваивание одного клока другому нельзя.

В результате получается, что без использования after 1 ns (или 0.1 ns) результаты моделирования могут разойтись с работой реальной ПЛИС, со всеми вытекающими последствиями.

 

Этот пример я моделировал на Activ-HDL 8.1

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

[rsv2007 0]

в документации на синтезатор от ксайлинкса есть описание как кодировать автоматы, довольно понятное. Опять же, в старой-доброй-глючной среде разработки xilinx ISE есть Language template, из которого можно взять готовый шаблон КА мили или мура.

просто путем проб и ошибок пришел к выводу, что если производитель микросхемы (и синтезатора для нее) что-то рекомендует, то это неспроста...

[Shtirlits 0]

a <= not a after  1 ns when rising_edge( clk );
a1 <= not a1 when rising_edge( clk );

Не согласен!

 

Для написания теста все средства хороши, лишь бы понятно было и наглядно.

Но, елы-палы, вас же дети читать будут!

К синтезу и проекту для ПЛИС эта конструкцияя имеет отношение 0%.

Если при моделировании синтезируемой схемы хочется наблюдать фронты сигналов с выходов асинхронных элементов, то для этого вам, барин, нужна ¨post place and route simulation model¨. Долго будет думать симулятор, но покажет.

[des00 25]

Вот простой тест на delta задержки

 

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

 

Гарантировать, что в большом проекте нигде не произойдёт присваивание одного клока другому нельзя.

 

library IEEE;
use IEEE.STD_LOGIC_1164.all;

entity temp_sub is 
  port (
    clk : in std_logic; 
    a,b,c,d : out std_logic
    );
end temp_sub;

architecture rtl of temp_sub is 

  signal ai, bi, ci, di : std_logic := '0';
  
begin 

ai <= not ai when rising_edge( clk );
bi <= not bi when rising_edge( clk ) and ai ='1';
ci <= ai and bi when rising_edge( clk );
di <= ai and bi when rising_edge( clk );

a <= ai; 
b <= bi;
c <= ci;
d <= di;

end rtl;

library IEEE;
use IEEE.STD_LOGIC_1164.all;

entity temp is
end temp;

architecture temp of temp is

signal    clk         : std_logic:='0';
signal    clk1        : std_logic;

signal    a,b,c,d        : std_logic;
signal    a1,b1,c1,d1    : std_logic;

begin

clk <= not clk after 5 ns;
clk1 <= clk;

temp_sub   : entity work.temp_sub port map (clk, a,b,c,d); 
temp_sub_1 : entity work.temp_sub port map (clk1, a1,b1,c1,d1); 

end temp;

 

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

 

ЗЫ. Описывать регистры как вы делаете я бы не стал, лучше придерживаться классики, пусть хоть она и требует большего количества букв.