[Gennadiy_ 0]

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

 

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

 

Хотя прямых противоречий не вижу...

 

Ранее с программирумой логикой и языками описания не работал, мелочевка тоже мимо прошла, в основном ASM.

 

Среда Квартус, чип EPM570.

 

Как вообще обстоят дела с асиннхронной логикой при синтезе ? при реализации ?

 

 

 
//управляем выходом
always @(pres_state ) // or will_be_data or command_reg ?
begin : out_control_FSM
    case (pres_state)


..............................................

    st_command_processing:
    begin  //обработка кода команды
        reg_en_clear; //фиксируем latch для регистра команд, закрываем выход FT

        case (command_reg)
        //надо загрузить счетчик байт в зависимости от кода  команды 

        COLD_RESET:
        begin
            data_count <= 0;
        end;

        RESET:
        begin
            data_count <= 0;
        end;

        GET_VER: data_count <= 0;

        SET_CLOCK: data_count <= 1;
        GET_CLOCK:  data_count <= 0;

        SET_MODE_DEV0: data_count <= 1;
        GET_MODE_DEV0: data_count <= 0;
        SET_DEV0: data_count <= 3;
        GET_DEV0: data_count <= 0;

        SET_MODE_DEV1: data_count <= 1;
        GET_MODE_DEV1: data_count <= 0;
        SET_DEV1: data_count <= 3;
        GET_DEV1: data_count <= 0;

        SET_MODE_DEV2: data_count <= 1;
        GET_MODE_DEV2: data_count <= 0;
        SET_DEV2: data_count <= 3;
        GET_DEV2: data_count <= 0;

        default :  data_count <= 0;
        endcase //data_reg
    end;  //обработка кода команды

................................................................

    st_data_processing:
    begin //обработка данных
        reg_en_clear; // закрываем выход FT и фиксируем данные в регистрах
        
        //*********************************************
        if (will_be_data)    data_count <= data_count-1;
        //*********************************************
        
    end; //обработка данных

..................................................

    default :

    endcase     //pres_state
end;    //out_control_FSM

[BSV 0]

Если Вы хотите получить в результате синтеза логическую функцию, то значения DATA_COUNT должны быть описаны для всех вариантов входных сигналов. В Вашем случае в состоянии st_data_processing в конструкции if отсутствует else, поэтому синтезатором будет вставлен latch и выдано предупреждение на эту тему. Также непонятно что такое reg_en_clear. Я в verilog не копенгаген, возможно, гуру найдут еще недостатки.

 

P.S. Комментарии в коде нормально отображаются? А то я вижу кракозябры.

[Gennadiy_ 0]

- крокозябры после копирования появились.

 

reg_en_clear - task которая сбрасывает все сигналы выбора целевых регистров в не активное состояние

 

в конструкции if отсутствует else, поэтому

 

"reg_en_clear" был введен чтобы не повторять описание в каждом случае всех цепей, если if- else заменяет такое описание то хорошо, учту.

 

Я хочу получить счетчик (тут он "размазан" по коду), который будет устанавливаться в случае st_command_processing асинхронно, по мере вычисления логической функции реализованной в case (command_reg), затем по переходу в другое состояние автомата (любое) его значение фиксируется, т.е. это latch. В состоянии st_data_processing должен производиться счет числа входов в это состояние, по достижении 0, вырабатывается сигнал,

assign will_be_data = (data_count==0)? 0:1;

который, влияет на выбор следующего состояния.

[iosifk 3]

P.S. Комментарии в коде нормально отображаются? А то я вижу кракозябры.

 

описание автомата смотреть некогда, а перед тем как копировать надо перекючить клавиатуру на русский шрифт, и в том месте, куда вставляете - тоже...

[Gennadiy_ 0]

- поправил кракозябры

[m_y 0]

Извините, но Вы попытались скомпилировать то, что написали!? Попытались ли промоделировать?

[Gennadiy_ 0]

нет, нет

 

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

[m_y 0]

У Вас уже есть с чего начать, если Вы предлагаете свой код на обсуждение. Попробуйте скомпилировать(Modelsim). Будут ошибки.

[lotorev 0]

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

1) код действительно неверный

 

строки begin : out_control_FSM

case (pres_state)

 

 

..............................................

 

st_command_processing:

begin //обработка кода команды

 

написаны не согласно стандарту.

2) написав always @(pres_state ) вы собираетесь описывать описывать комбинационную схему. Для того что получить равные результаты симулирования до синтеза и после присвоения должны быть блокирующие через знак равно (=) : data_count = 0. тогда сигнал data_count после синтеза будет выглядеть как вентили.

 

3) вот ссылка на то как правильно описывать автоматы

http://www.sunburst-design.com/papers/Cumm...undamentals.pdf и здесь http://www.sunburst-design.com/papers/Cumm...0Boston_FSM.pdf

довольно хорошо написано.

там же, на http://www.sunburst-design.com/papers/, можно найти другие публикации про правильный стиль написания на верилоге. в своё время прочитал и врубился во всё что там написано.

Изменено 15 августа, 2007 пользователем lotorev

[Voloshchenko 0]

К lotorev

3) вот ссылка на то как правильно описывать автоматы

. . . . . . . . . .

довольно хорошо написано.

. . . . . . . . . .

Спасибо за ссылки!

Согласно классификации из http://www.sunburst-design.com/papers/Cumm...undamentals.pdf , понял, что мои собственные FSM - это структуры с одно-always блоком и регистровыми выходами. Хотя, как понял после прочтения, предпочтительней структура из трех-always блоков с теми же регистровыми выходами.

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