Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Не получается реализовать SRAM интерфейс
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
zuy
Чтобы потренироваться работать с FPGA подключил я Spartan 6 к микроконтроллеру на шину статической памяти в режиме 8 бит.
И для начала решил просто выдавать на шину данных последние 8 бит шины адреса. Планировалось получить что-то типа пилы.
Тактовая частота CLK_IN 100 МГц.
Набросал код:
Код
module sram_test(
   input [12:0] ADDR,
   output[7:0] DATA,
   input  wire OE,
   input  wire RESET,
   input  wire CLK_IN,
  
   output TEST_1,
   output TEST_2,
   output TEST_3
   );

    reg[ 7 : 0 ] DATA_r;
    reg[ 12: 0 ] ADDR_r;
    reg[ 7 : 0 ] time_r;
    reg[ 1 : 0 ] state_r;
    reg          rd_strobe;
    
    always @( posedge CLK_IN ) begin
      if( ~RESET ) begin
         state_r = 0;      
      end else begin
         case( state_r )
            0:
               if( ~OE ) begin
                  state_r = 1;
                  time_r  = 2;
                  ADDR_r  = ADDR;
               end
              
            1:
               begin
                  time_r = time_r - 1'b1;
                  if( time_r == 0 ) begin
                     rd_strobe = 1;
                     time_r    = 2;
                     state_r   = 2;
                  end
               end
              
            2:
               begin
                  time_r = time_r - 1'b1;
                  if( time_r == 0 ) begin
                     rd_strobe = 0;
                     state_r   = 3;
                  end
               end
              
            3:
               if( OE )
                  state_r = 0;
              
            default: state_r = 0;
         endcase
      end
    end

    
    always @( posedge rd_strobe ) begin
      DATA_r <= ADDR_r[ 7 : 0 ];    
    end
    
    assign TEST_1 = OE;
    assign TEST_2 = DATA_r[ 0 ];
    assign TEST_3 = rd_strobe;
    assign DATA   = DATA_r;

endmodule


Задумал такую логику:
1. Жду активности OE, и запоминаю состояние шины адреса в этот момент
2. Через 2 такта делаю активным сигнал строба длиной также два такта. По фронту строба выдаю на шину данных младшие 8 бит запомненого адреса.
3. Жду пока OE станет неактивным и обратно к п.1.

Для проверки, я контроллером читаю последовательно 1024 байт и смотрю на прочитанный массив.
В результате получается пила но на ней постоянно в разных местах есть какие-то помехи и имеют они разную форму( синий график на картинке ).
Если я в послднем Always блоке заменяю сохраненый регистр ADDR_r на прямое подключение к шине адреса ADDR то картинка становится идеальной( зеленый график ).
Нажмите для просмотра прикрепленного файла

Помогите понять, почему так происходит.


Kuzmi4
2 zuy
пробую телепатировать - констрейны есть?
zuy
Цитата(Kuzmi4 @ Aug 13 2012, 22:42) *
2 zuy
пробую телепатировать - констрейны есть?

Только обьявления пинов.
kopterr
А в чем смысл в данном случае в одном олвейс блоке использовать блокирующие присваивания а в другом неблокирующие?
zuy
Цитата(kopterr @ Aug 13 2012, 23:26) *
А в чем смысл в данном случае в одном олвейс блоке использовать блокирующие присваивания а в другом неблокирующие?

Похоже осталось после экспериментов.
Я пробовал в обоих блоках блокирующие, в обоих неблокирующие и разные. Результат никак не меняется.
Kuzmi4
Цитата(zuy @ Aug 14 2012, 09:44) *
Только обьявления пинов.

В этом похоже и причина, задайте SDC и будет вам счастие laughing.gif
"TimeQuest для чайников" можно почитать для затравки
zuy
Цитата(Kuzmi4 @ Aug 14 2012, 01:35) *
В этом похоже и причина, задайте SDC и будет вам счастие laughing.gif
"TimeQuest для чайников" можно почитать для затравки

Спасибо за ссылку, почитал.
Правильно я понял, что вы думаете, у меня проявляется метастабильность из-за отсутствия констрейнов?
Но я не понимаю где она может проявляться.
Значение на шине адреса уже устоялось на тот момент, когда OE стал активным. Далее только через 2 такта системного клока я генерирую строб для вывода данных, а это 20нс задержки. За это время шина адреса не меняет своего значения и, как я думаю, значение шины адреса уже запомнилось в регистре ADDR_r.
Не могу понять саму суть, откуда такие выпады могут появляться sad.gif
sazh
Цитата(zuy @ Aug 15 2012, 08:51) *
Не могу понять саму суть, откуда такие выпады могут появляться


Разве Вы не получили при синтезе предупреждения
Warning (21074): Design contains 5 input pin(s) that do not drive logic
Warning (15610): No output dependent on input pin "ADDR[8]"
Warning (15610): No output dependent on input pin "ADDR[9]"
Warning (15610): No output dependent on input pin "ADDR[10]"
Warning (15610): No output dependent on input pin "ADDR[11]"
Warning (15610): No output dependent on input pin "ADDR[12]"
zuy
Цитата(sazh @ Aug 14 2012, 22:35) *
Разве Вы не получили при синтезе предупреждения
Warning (21074): Design contains 5 input pin(s) that do not drive logic
Warning (15610): No output dependent on input pin "ADDR[8]"
Warning (15610): No output dependent on input pin "ADDR[9]"
Warning (15610): No output dependent on input pin "ADDR[10]"
Warning (15610): No output dependent on input pin "ADDR[11]"
Warning (15610): No output dependent on input pin "ADDR[12]"


Получил. Но я и нигде и не использую биты старше 8-го от шины адреса. Я так решил, что синтезатор это понял и выкинул их из проекта, выдав это предупреждение.
Разве это может привести к такому результату, как у меня на картинке?

На всякий случай, урезал шину адреса до 8 бит. Пересобрал, ни одной ошибки и ни одного предупреждения больше нет, все стадии с зелеными галочками.
Но результат никак не поменялся.
Джеймс
Цитата(zuy @ Aug 14 2012, 10:22) *
В результате получается пила но на ней постоянно в разных местах есть какие-то помехи и имеют они разную форму( синий график на картинке ).
Помогите понять, почему так происходит.


Причина в этом:

always @( posedge CLK_IN )
always @( posedge rd_strobe )

никаких "производных" тактовых частот быть не должно

Второе важное замечание. Поскольку в state-машине внутри always вы используете блокирующие присваивания, поведение на модели не соответствует поведению "в железе". Измените на <=
zuy
Цитата(Джеймс @ Aug 15 2012, 00:18) *
Причина в этом:

always @( posedge CLK_IN )
always @( posedge rd_strobe )

никаких "производных" тактовых частот быть не должно

Второе важное замечание. Поскольку в state-машине внутри always вы используете блокирующие присваивания, поведение на модели не соответствует поведению "в железе". Измените на <=


Заменил все присваивания на неблокирующие. И упростил код, убрал второй блок Always и соеденил регистр ADDR_r напрямую с шиной данных.
Т.е. теперь код просто через 2 такта после активации OE запоминает адрес в ADDR_r, который соединен с шиной данных.
Код
module sram_test(
   input [7:0] ADDR,
   output[7:0] DATA,
   input  wire OE,
   input  wire RESET,
   input  wire CLK_IN,
  
   output TEST_1,
   output TEST_2,
   output TEST_3
   );

    reg[ 7 : 0 ] ADDR_r;
    reg[ 7 : 0 ] time_r;
    reg[ 1 : 0 ] state_r;
    reg          rd_strobe;
    
    always @( posedge CLK_IN ) begin
      if( ~RESET ) begin
         state_r <= 0;      
      end else begin
         case( state_r )
            0:
               if( ~OE ) begin
                  state_r <= 1;
                  time_r  <= 2;
               end
              
            1:
               begin
                  time_r <= time_r - 1'b1;
                  if( time_r == 0 ) begin
                     rd_strobe <= 1;
                     ADDR_r    <= ADDR;
                     state_r   <= 2;
                  end
               end
              
            2:
               if( OE )
                  state_r <= 0;

            default: state_r <= 0;
         endcase
      end
    end

    assign TEST_1 = OE;
    assign TEST_2 = ADDR_r[ 0 ];
    assign TEST_3 = rd_strobe;
    assign DATA   = ADDR_r;

endmodule


Помех стало меньше и они изменили свой вид.
Правильно ли я понимаю, что теперь это похоже на то, что я иногда не верно детектирую сигнал OE ?
Нажмите для просмотра прикрепленного файла
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.