ASM51

olá Pessoal,


Estou aqui novamente para pedir ajuda, mas agora em Verilog. A dúvida talvez nem seja exatamente com a linguagem, mas apenas com o aplicativo; mais exatamente com a estética da apresentação dos blocos no RTL viewer. O que acontece é que eu gostaria de criar máquinas de estado que fossem visualizadas em camadas, ao invés de tudo no mesmo sheet.

Baixei o template da ALTERA para um state machine do tipo Moore para criar nele o esqueleto do meu projeto. O projeto que eu havia feito anteriormente num uC consistia de estados principais e estados internos, digamos assim. Em outras palavras, quando o programa entrava num determinado modo de operação ( estado principal ), ele ficava retido nesse modo, e sequenciava operações internas ( estados internos ).

No programa abaixo, eu criei os estados principais S0>S1>S2>S3 num loop infinito, ou seja, na incialização começa em S0 e quando atinge S3 retorna para S0 circularmente. Os estados intermediários subS0>subS1>subS2 que se inciam somente quando alcança S3, como abaixo:

• S0<=S1
• S1<=S2
• S2<=S3
  
  • subS0<=subS1
  • subS1<=subS2
  • subS0<=subS3
• S3<=S0

O esqueleto do programa é esse abaixo, no qual eu usei um case-endcase dentro do outro:

Código: Selecionar todos

module moore_mac
(
   input   clk, data_in, reset,
   output reg [2:0] data_out
);
        reg [2:0] sub_state, state ;
   
   // Declare states
   parameter   S0   = 3'b000, S1   = 3'b001, S2   = 3'b010, S3   = 3'b011, S3_0 = 3'b100, S3_1 = 3'b101, S3_2   = 3'b110, S3_3   = 3'b111;
   
   // Determine the next state
   always @ (posedge clk or posedge reset) begin
      if (reset)
         begin
            state       <= S0   ;
            sub_state   <= S3_0 ;
         end
      else
         case (state)
            S0:
                           begin state          <= S1; end
            S1:
               /*if (data_in) state       <= S1;
                   else    */ begin state       <= S2; end
            S2:
               /*if (data_in) state       <= S1;
                   else    */ begin state       <= S3; end
            S3:            
            // internal states - begin : keep on S3 *******************************            
               case (sub_state)
                     S3_0:
                              sub_state    <= S3_1 ;
                     S3_1:
                              sub_state    <= S3_2 ;
                     S3_2:
                           begin
                              sub_state   <= S3_0 ;
                              state       <= S0   ;
                           end
               endcase
            // internal states - end : exit from S3 *******************************   
         endcase
   end

   // Output depends only on the current state
   always @ (state) begin
      case (state)
         S0:
            data_out = S0 ;
         S1:
            data_out = S1 ;
         S2:
            data_out = S2 ;
         S3:
            data_out = S3 ;
         default:
            data_out = S0 ;
      endcase
   end

endmodule


E olhando a simulação, as coisas acontecem como o previsto:

E olhando as maquinas de estados criadas, estão ocorrendo na sequencia:

Mas o RTL viewer não mostra os estados em camadas:

Sei que estou pastando em algo trivial, mas não descobri ainda como resolver.
Pensei em usar o recurso de função, ou até separar em arquivos .v distintos...

Poderiam dar uma luz ?

entao, nao conheco o software da altera... mas o software da xilinx mostra maquinas de estado como emaranhados de flip-flops e porta logicas. daih uma opcao para nao embaralhar as coisas eh colocar em modulos separados e ativar uma opcao na sintese que preserva a hierarquia.

Valeu Marcelo, realmente o Quartus também tem a opção de apresentar a estrutura na forma das macrocelulas, que eles chamam de technology map viewer ( se der um duplo clique nas caixas abaixo, dá pra ver também o conteudo de cada macrocelula, com seu flip-flop e porta lógica ).



De qualquer modo, acho que vou ter de experimentar como voce falou, em modulos separados, primeiramente no mesmo arquivo e se não funcionar, divido. Só tenho receio que o projeto no final seja uma coletanea de dezenas de arquivos, mas deve ser isso mesmo. Em 'C' também não era muito diferente disso.

abcs

voce pode fazer dois modulos no mesmo arquivo... por exemplo:

Código: Selecionar todos

module state_l0(input clk, input res, input in,output [1:0] out);

    reg [1:0] state = 0;

    wire req,ack;

    always@(posedge clk)
    begin
        if(res)
            state <= 0;
        else
            case(state)
                0: state <= 1;
                1: state <= in ? 2 : 1;
                2: state <= in ? 3 : 2;
                3: state <= ack ? 0 : 3;
            endcase
    end

    assign out = state;
    assign req = state==3;

    state_l1 state_l1(clk,res,req,ack);

endmodule

module state_l1(input clk,input res,input req,output ack);

    reg [1:0] state = 0;
   
    always@(posedge clk)
    begin
        if(res)
            state <= 0;
        else
            case(state)
                0: state <= req ? 1 :0;
                1: state <= 2;
                2: state <= 3;
                3: state <= 0;
            endcase
    end

    assign ack = state==3;

endmodule

isso vai gerar um top level com:

http://darklife.org/pics/xilinx/Screen% ... 8%20PM.png

e um sub level:

http://darklife.org/pics/xilinx/Screen% ... 1%20PM.png

note que a maquina de estado fica espalhada, ou seja, no xilinx ele nao se importa muito em desenhar um simbolo especial para a maquina de estado.

mesmo assim, o technology map eh um bicho completamente diferente:

http://darklife.org/pics/xilinx/Screen% ... 8%20PM.png

eu particularmente prefiro nao tentar entender muito a saida RTL de maquinas de estado... se vc for parar para pensar, elas sao sempre iguais: um contador baseado em flip-flops e uma decodificador de n para 2^n. soh que fora os flip-flops, todo o resto pode ser consideravelmente otimizado, entao tentar entender essas otimizacoes acho que nao vale muito a pena. e daih acho mais facil colocar tudo junto mesmo e nao tentar analisar muito o que ele esta fazendo. o importante eh escrever certo e acreditar nisso! hahaha

essencialmente, qualquer maquina de estado vc pode fazer com o mesmo modelo:

Código: Selecionar todos

always@(posedge clk)
begin
  if(res)
    state <= 0;
  else
    case(state)
      0: state <= algo0 ? 1:0;
      1: state <= algo1 ? 2:1;
      ...
    endcase

  case(state)
    0: out <= algo
    ...
  endcase
end

note que coloquei dois cases ali, um para a maquina de estado mesmo e outro para o out. e acho importante sempre lembrar: a saida de um modulo deve ser sempre flip-flop, pq daih evita propagar glitches da maquina de estado.

o esquematico RTL eh importante para detectar erros de codificacao... por exemplo, esse eh o esquematico RTL de um core RISC:

http://darklife.org/pics/xilinx/Screen% ... 7%20PM.png

o esquematico eh importante para me certificar de que estou realmente codificando corretamente o program counter, que eh o elemento selecionado em azul e que endereca a memoria ROM de 1024x16 elementos.

no caso, a notacao usada para inferir isso eh bem complexa:

Código: Selecionar todos

        PC <=          !RES ? 0 :
                 INST==`RET ? DREG :
                              PC+(INST==`BSR||INST==`BRA||(INST==`LOP&&!DREG[15])?IMMS:1);


se for pensar, nao deixa de ser uma maquina de estados, mas nesse caso o interessante eh justamente forcar para que seja um acumulador.

Ok Marcelo,


Aparentemente não tem jeito mesmo, já tentei de tudo. Parece que qualquer coisa que eu insira dentro do case que não seja um estado explicito, o state machine viewer não o reconhece ou não avalia os estados internos para gerar uma camada inferior de FSM, e diz que não há mais no design nenhuma maquina de estados.

Eu só queria aproveitar um pouco mais desse recurso de abstração, que em principio pareceu ser muito legal, mas se não fizer muito mais que isso pode ser algo meio que restrito somente á um uso mais didático ou limitado a aplicações mais simples.

Acho que vou me ater á um tipo de apresentação como um dos esquemas acima, onde voce gerou uma saída explicita para entrar no outro bloco. Era assim como eu fiz no passado com um bloco acionando o bloco seguinte num pipeline de triggers cada um avisando que terminou seu estado e liberando o processamento no bloco seguinte, mas aí eu vou ter de descer no nível do circuito...eu tava gostando tanto de programar em alto nivel que dá pena ter de voltar a ter de interagir com o design olhando para os circuitos...

Mas pelo menos fazendo como voce sugeriu, o module da camada inferior do estado aparece num ramo mais baixo no project navigator...valeu.

Pessoal,


Decidi passar do Verilog para o SystemVerilog, já que esse outro é quase que apenas uma extensão do primeiro, e está sendo muito interessante, mas conforme eu me complico um pouco mais no programa, começo a sentir as limitações do ambiente de simulação nativa do QuartusII.

Já me recomendaram instalar o ModelSim da Mentor Graphics que pode ser baixado na própria ALTERA, mas estou com problemas em conseguir ativar a licensa. Já recebi o arquivo .dat e também configurei as variáveis de ambiente apropriadamente como indicado no tutorial, mas nada...

Vocês recomendariam algum outro simulador que tivesse recursos de break points e ect ?

eu uso o ISIM da xilinx e nunca precisei de recurso de breakpoint... o simulador dah uma saida estilo analisador logico e vc pode selecionar qualquer janela arbitraria de visualizacao no tempo. mas ultimamente meus projetos tem ficado mais complexos e tenho trabalhado com processadores inteiros, daih apesar de ainda ser possivel depurar usando a visualizacao tradicional, sequencias muito longas sao bem chatas de depurar. nesse caso eu adiciono uma variavel $display() para imprimir algumas coisas durante a execucao do software, por exemplo, o program counter, a palavra de instrucao e alguns sinais modificados de acordo com a instrucao. nao eh complexo e no fim das contas a medida que a simulacao roda eu tenho uma listagem sequencial do fluxo de execucao de codigo. no caso das ferramentas da xilinx, eh possivel colocar $display() inclusive no codigo a ser sintetizado. quando o codigo rodar em simulacao, ele vai avaliar e rodar o $display(), imprimindo a saida no console do simulador, mas quando o codigo for sintetizado, ele vai ignorar o $display() e sintetizar normalmente.