[barabek 0]

Вопрос в следующем. Имеем объявления (видел подобное в примерах от des00, наверно, это стандартное решение):

 

    typedef enum {IDLE_b,RECIEVE_b,PARITY_b}Recieve_state_b_en;

    enum bit[2:0]{
            IDLE       =        3'h1<<IDLE_b,
            RECIEVE  =    3'h1<<RECIEVE_b,
            PARITY   =        3'h1<<PARITY_b
            }state,nextstate;

при использовании бит из переменной state:

 

 always_comb source_eop=state[PARITY_b] & finish_parity;

 

или что-нибудь подобного, в крайнем случае даже так: source_eop=state[PARITY_b];

 

квартус 9.1 SP 1 выдает варнинг "Warning (10230): Verilog HDL assignment warning at RS_encoder.v(66): truncated value with size 3 to match size of target (1)"

 

Если строку изменю: source_eop=finish_parity; То варнинга нет - оно и понятно, все величины однобитовые. Однако, state[PARITY_b] это  также однобитовое значение. Почему же ква на него ругается? При этом, на работе стоит версия 9.0 таких предупреждений не выдает. Из-за этого боюсь на работе обновлять версию. Можно ли это предупреждение игнорировать или оно будет приводить к неправильной работе, кто сталкивался? 

[ViKo 1]

Однако, state[PARITY_b] это также однобитовое значение.

Я вижу в перечислении state 3-битовые значения.

[des00 25]

Из-за этого боюсь на работе обновлять версию. Можно ли это предупреждение игнорировать или оно будет приводить к неправильной работе, кто сталкивался? 

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

[barabek 0]

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

Не, писать боюсь чтобы не спалиться :). 

 

Я вижу в перечислении state 3-битовые значения.

 

 Да, но запись "state[PARITY_b] " равносильно записи "state[2]", т.е. обращение к биту.

[ViKo 1]

Да, но запись "state[PARITY_b] " равносильно записи "state[2]", т.е. обращение к биту.

Не к биту, а к элементу перечисления номер [2], каждый из которых - 3-битовый bit[2:0].

[barabek 0]

Не к биту, а к элементу перечисления номер [2], каждый из которых - 3-битовый bit[2:0].

Что-то, сдается мне, вы вводите неопытного (меня) в заблуждение. Я вообще не нашел в стандарте обращения к элементу перечисления (кроме методов типа first(), next() и т.д., но это не обращение к элементу, а получение значения члена перечисления). Это же не массив. В общем, с терминологией у меня плоховато. Не могу выразить мысль, в чем Вы не правы. 

 

В таком случае не могли бы привести пример, как обратиться к конкретному биту вектора state?

[ViKo 1]

IEEE Std 1800-2009 SystemVerilog (на ftp имеется, циферками обозван, точнее не помню), раздел 6.19. Обращение к переменным перечисляемого типа в разделе 6.19.4, как раз перед методами. Не к элементу перечисления, я неправильно выразился, извиняюсь :)

Это не массив, а список значений переменных state и nextstate.

А к конкретному биту - как-то так: status[2][0], наверное...

Исправляюсь - это вектор, Вы правы. Принимающий значения IDLE, RECEIVE, PARITY, каждое из которых 3-битовое.

[des00 25]

Что-то, сдается мне, вы вводите неопытного (меня) в заблуждение.

согласен %)

[ViKo 1]

Кажется, я был не прав с самого начала :) Вернее, с поста #5

Ухожу листать стандарт и насиловать Quartus.

[ViKo 1]

Продолжим?

Создал код:

module TestEnum (input wire CLK, output bit[2:0] OUT, output bit TEST);
  parameter IDLE_b = 0, RECEIVE_b = 1, PARITY_b = 2;
  enum  bit[2:0] {
     IDLE =  3'h1<<IDLE_b,
     RECEIVE = 3'h1<<RECEIVE_b,
     PARITY = 3'h1<<PARITY_b
  } state, next;
        
  always @(posedge CLK)
  begin
    case(state)
      01: state = RECEIVE;
      02: state = PARITY;
      03: state = IDLE;
      default: state = IDLE;
    endcase
  end

  assign OUT = state;
  // assign TEST = state[1];
endmodule

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

Как только убираю комментарий в предпоследней строке, Quartus 9.0 (no SP) изобретает "страшную" RTL-схему, выходы садит на 0, ЛЭ не использует совсем, и говорит, что State Machine нет.

[des00 25]

Продолжим?

Ваш код не совсем корректен для квартуса,

для ручного ван хота пишите так

что бы ква

  always @(posedge clk)
  begin
    case(1'b1)
      state[IDLE_b]    : state <= RECEIVE;
      state[RECEIVE_b] : state <= PARITY;
      state[PARITY_b]  : state <= IDLE;
      default : state <= IDLE;
    endcase
  end

[ViKo 1]

для des00

Ваш код Quartus скушал (и без assign TEST, и с ним), однако State Machine Viewer говорит, что нет SM.

[SergeyF 0]

Я не изучал условия извлечения автоматов из SV, но для Verilog точно нельзя вытаскивать состояния и их биты наружу (см handbook и справку Quartus). Как раз тогда (и во многих других случаях) он не извлекает автомат и делает RTL).

 

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

enum int unsigned { S0 = 0, S1 = 2, S2 = 4, S3 = 8 } state, next_state;

[des00 25]

[/b]Ваш код Quartus скушал (и без assign TEST, и с ним), однако State Machine Viewer говорит, что нет SM.

дык здесь и нет FSM, в том смысле в котором это понимает квартус %) Кстати поиграйте над вашим файлом настройками вида кодирования автомата и автоматическое распознавание автомата, узнаете много нового %)

 

Но в исходном описании в начале темы я не понял вот чего: если кодирование автоматов выполняет Quartus в соответствии с настройками или директивой синтезатора, зачем с таким усердием и хитростью его кодировать через еще один enum?

Потому что в данном примере enum используется для задания эксклюзивных констант, а не для описания состояний автомата. И рождает это дело автомат с точки зрения функционирования, но не с точки зрения квартуса. Используется это тогда, когда автор точно знает что он хочет (кста на верилоге тоже можно описать такой ван хот) %)

 

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

[barabek 0]

 Но в исходном описании в начале темы я не понял вот чего: если кодирование автоматов выполняет Quartus в соответствии с настройками или директивой синтезатора, зачем с таким усердием и хитростью его кодировать через еще один enum? Почему не сделать как в примере в квартусе:

enum int unsigned { S0 = 0, S1 = 2, S2 = 4, S3 = 8 } state, next_state;

 

Так удобнее. Первое - описание самого конечного автомата (как это описано у des00 в ответе #11). Второе. Можно написать так always_comb read=state[RECEIVE_b]; Если нет первого enum, то эту запись придется делать либо always_comb read=state[1]; (Через два дня глядя на свой код будешь вспоминать, к какому состоянию относится 1 в квадратных скобках), либо always_comb read=state==RECEIVE; Может квартус и соптимизирует эту запись до проверки одного бита, а может построит полный элемент сравнения. Не проверял. А в первом варианте у него вариантов не остается (простите за каломбур :) ). 

 

Следовательно, рассматривая  read=state[RECEIVE_b]; и read=state[1]; первый гораздо лучше читается. К тому же, в процессе работы могут появляться новые состояния, приходится вручную править номера, в общем, есть дополнительная возможность для ошибок.

 

des00, что - то боязно мне писать баг репорт с моим "честным" использованием квартуса :)