| |
 Непонятная проблема с Digilent Spartan-3 starter Kit и евойной Ext. SRAM, То ли не пишет, то ли не читает... Ай нид ХЕЕЕЛП!!! |
|
|
|
|
 Mar 21 2007, 19:26
|
Участник
Группа: Новичок
Сообщений: 34
Регистрация: 24-01-07
Пользователь №: 24 706
|
Цитата(khach @ Mar 21 2007, 16:10)  Попробуйте вот этот http://www.cmosexod.com/sdram.html контроллер. Там дока хорошая, и встроенный тестер есть. у меня SRAM на плате, а не SDRAM,..
|
|
|
|
|
|
|
|
Mar 25 2007, 20:53
|
Местный
Группа: Свой
Сообщений: 443
Регистрация: 22-07-06
Из: Украина, г. Харьков
Пользователь №: 19 006
|
Действительно странные проблемы на ровном месте. У самого в самом первом проекте на FPGA стояла SRAM, и с чем только проблем не было, но только не с ней.
Наверняка дело не в этом, (раз все просматривается пошагово на железе)но все же: Когда я только начинал разбираться с реализацией двунаправленных шин на верилоге, у меня была схожая проблема - при переводе пина на вход, он как положено переводился в Z состояние, но читалось с него чертий что. Проблема была в неправильном использовании блокирующих и неблокирующих присваиваний. Но это обнаружилось еще при моделировании.
Ну и еще: может пины сконфигурированы не в тот стандарт? Конечно совсем бред, но мало-ли. Микруха тогда может не видеть ноль или еденицу, и соответственно работать неправильно. Опять же было и такое раз, Кто там на осциллографе смотрит какой высоты импульсы - можно и не заметить, что они низковаты, или там ноль на вольт над землей поднят.
Кроме того вот здесь:
[code]
--SRAM_ADDR <= ADDR; -- адрес не переключаю, на шине - KEEPER
SRAM_OE <= '0';
SRAM_WE <= '1';
SRAM_CE <= '0';
SRAM_LB <= '0';
SRAM_UB <= '0';
DATA_READ <= SRAM_DATA;
[\code]
смущает то что все записано подряд, тоесть одновременно, в то время как "DATA_READ <= SRAM_DATA;" должно быть в следующем такте, т.е через некоторое время.
Сообщение отредактировал Artem_Petrik - Mar 25 2007, 21:01
|
|
|
|
|
|
|
|
Mar 28 2007, 02:17
|
Участник
Группа: Новичок
Сообщений: 34
Регистрация: 24-01-07
Пользователь №: 24 706
|
Цитата(Artem_Petrik @ Mar 25 2007, 20:53) Проблема была в неправильном использовании блокирующих и неблокирующих присваиваний. чуть-чуть раскрыть тему можно? Цитата(Artem_Petrik @ Mar 25 2007, 20:53) Кроме того вот здесь:
[code]
--SRAM_ADDR <= ADDR; -- адрес не переключаю, на шине - KEEPER
SRAM_OE <= '0';
SRAM_WE <= '1';
SRAM_CE <= '0';
SRAM_LB <= '0';
SRAM_UB <= '0';
DATA_READ <= SRAM_DATA;
[\code]
смущает то что все записано подряд, тоесть одновременно, в то время как "DATA_READ <= SRAM_DATA;" должно быть в следующем такте, т.е через некоторое время. вы не поверите, но я делал даже не просто "через некоторое время", а через секунды. Вот разве что в реализации двунаправленной шины какой-то косяк
|
|
|
|
|
|
|
|
Mar 29 2007, 19:50
|
Местный
Группа: Свой
Сообщений: 443
Регистрация: 22-07-06
Из: Украина, г. Харьков
Пользователь №: 19 006
|
Цитата чуть-чуть раскрыть тему можно? Проблема была, если мне не изменяет память, в том, что при расположенных подряд Код data = 'bZ;
read_data = data; в read_data (в симуляторе) попадало Z а не значение, установленное на ногу извне. После замены присваиваний на "<=" проблема пропала. Правда понятия не имею, как этот глюк будет проявляться в железе. Еще раз отмечу - у меня verilog. У меня есть плата с циклоном и срамом. Попробую на верилоге набросать тупенький тестовый проект, типа записать разные значения в три адреса подряд, а потом прочитать первый, и дать вам на растерзание. Правда сильно быстро не обещаю, на этой неделе нужно кровь из носа одну вещь доделать. Но постараюсь побыстрее.
Сообщение отредактировал Artem_Petrik - Mar 29 2007, 19:51
|
|
|
|
|
|
|
|
Mar 31 2007, 19:48
|
Местный
Группа: Свой
Сообщений: 443
Регистрация: 22-07-06
Из: Украина, г. Харьков
Пользователь №: 19 006
|
Вобщем вот такой нехитрый код у меня в железе работает: Код LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.numeric_std.all;
ENTITY vhdl_sram IS
PORT
(
clk : IN STD_LOGIC;
rst : IN STD_LOGIC;
-- Сигналы для SRAM
address : OUT STD_LOGIC_VECTOR(16 downto 0);
data : INOUT STD_LOGIC_VECTOR(7 downto 0);
oe_n : OUT STD_LOGIC;
ce_n : OUT STD_LOGIC;
we_n : OUT STD_LOGIC;
-- Считанное назад значение
readed_data : OUT STD_LOGIC_VECTOR(7 downto 0)
);
END vhdl_sram;
ARCHITECTURE rtl OF vhdl_sram IS
TYPE state_type IS (state1, state2, state3);
SIGNAL state: state_type;
--SIGNAL cnt : UNSIGNED(4 DOWNTO 0);
SIGNAL cnt : INTEGER RANGE 0 TO 31;
BEGIN
PROCESS (clk, rst)
BEGIN
IF rst='1' THEN
cnt <= 0;
ELSIF (clk'EVENT AND clk = '1') THEN
cnt <= cnt + 1;
END IF;
END PROCESS;
PROCESS (clk, rst)
BEGIN
IF (rst='1') THEN
address <= B"0_0000_0000_0000_0000";
data <= (others => 'Z');
ce_n <= '1';
oe_n <= '1';
we_n <= '1';
readed_data <= B"0000_0000";
ELSIF (clk'EVENT AND clk = '1') THEN
CASE cnt IS
WHEN 0 =>
address <= B"0_0000_0000_0000_0000";
data <= B"0110_1010";
ce_n <= '1';
oe_n <= '1';
we_n <= '1';
WHEN 1 =>
ce_n <= '0';
we_n <= '0';
WHEN 2 =>
ce_n <= '1';
we_n <= '1';
WHEN 3 =>
address <= B"0_0000_0000_0000_0001";
data <= B"1100_0101";
WHEN 4 =>
ce_n <= '0';
we_n <= '0';
WHEN 5 =>
ce_n <= '1';
we_n <= '1';
WHEN 6 =>
address <= B"0_0000_0000_0000_0000";
data <= (others => 'Z');
WHEN 7 =>
ce_n <= '0';
oe_n <= '0';
WHEN 15 =>
readed_data <= data;
WHEN 16 =>
ce_n <= '1';
oe_n <= '1';
WHEN OTHERS => NULL;
END CASE;
END IF;
END PROCESS;
END rtl; Пока писал - выяснил для себя, что ничего я в VHDL не понимаю  , так что за красоту не ругайте. У меня микруха 8битная, недостающие сигналы добавите сами, либо вообще можно выдать на них нули навсегда (кроме шины данных естественно). Здесь все циклически повторяется, с задержкой между повторениями, для того, чтобы было наиболее удобно смотреть сигналы осциллографом. Смотреть желательно прямо на ногах SRAM (впрочем к шарикам подлезть трудно, так что замечание лишнее). Заодно обратить внимание на уровни нулей и едениц. Ноги сконфигурить как 3,3V CMOS. Я на шину данных пуллапов/басхолдов не ставил. Если все выдаваемые плисой сигналы в порядке, но ОЗУ все равно ничего не выдает - остается только предпологать неисправность микросхемы SRAM, и, по возможности, заменить ее на заведомо исправную. В частности, если поначалу, по каким-то причинам, при чтении из озу FPGA не переводила шину данных в Z состояние, то Цитата Оные чипы грелись, но... могло быть вызвано вовсе не 50МГц-ами, и привести к выходу микросхем из строя. Эта микруха при Fmax ест порядка 100ма, так что при 50Мгц по идее особо грется не должна. Впрочем "грелись" - понятие растяжимое. Надеюсь моя нехитрая помощь поможет победить эту неприятную проблему.
|
|
|
|
|
|
|
|
Apr 4 2007, 22:49
|
Участник
Группа: Новичок
Сообщений: 34
Регистрация: 24-01-07
Пользователь №: 24 706
|
Цитата(Artem_Petrik @ Mar 31 2007, 19:48) Если все выдаваемые плисой сигналы в порядке, но ОЗУ все равно ничего не выдает - остается только предпологать неисправность микросхемы SRAM микросхемы исправны, я проверил при помощи s3_board_monitor - обе пишутся/читаются. По крайней мере, по тем адресам, что я проверял - сам "монитор" управляется вручную, поэтому я провериол только несколько первых адресов. Так что с чипами всё ok (и с ПЛИС тоже). Но и мой вариант, и ваш - не работают.  Оба ничего не пишут и читают ахинею. У меня была безумная гипотеза: в .UCF неверно прописаны ножки управляющих стробов. Проверил-перепроверил, а потом вовсе скопировал из вышеупомянутого "монитора" кусок UCF-файла. Не помогло. Чипы, как я уже сказал, действительно греются - хоть какая-то реакция  Осцилла дома нету, проверить эпюры нечем - я основываюсь на показаниях всё того же "монитора" и дополнительно ещё использую LED-индикатор, что на плате установлен. Делаю так: запускаю прошивку, которая должна (хехе) прописать по первым четырём адресам разные константы, затем перегружаю плату и запускаю "монитор", чтобы посмотреть, что изменилось в SRAM. А там - ничего не изменилось, кроме ячеек с нулевыми адресами (но, видимо, это уже сам монитор их портит). Чем дальше, тем меньше понимаю, что там происходит 
|
|
|
|
|
|
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0
|
|
|
