Вид для печати
Вроде вот такой тест должен работать:Цитата:
Сообщение от andreil
http://zx-pk.ru/attachment.php?attac...5&d=1418316129
И выдавать вот такую картинку:
http://zx-pk.ru/attachment.php?attac...1&d=1389740514
Но у меня в эмуляторе оно почему-то не заработало (может баг в эмуляторе - ХЗ).
Точно, как я мог о нём забыть...Цитата:
Сообщение от Error404
На FPGA с внутричиповой памятью в текущем варианте работал 100%.
Для его работы на картинку надо правильно выставить переключатели - это есть в мануале по ПРО:
https://image.prntscr.com/image/_hAc...FyM7xWG1Vg.png
- - - Добавлено - - -
Да, проблема с таймингами, буду разруливать - видны артефакты.
Точно. Подзабыл уже, что для него надо еще и DIP-switch переставлять (как по мне - совершенно лишнее, т.к. потом еще надо вспомнить как оно было).
Это да, вспоминать всегда тяжело :)
По памяти - такое ощущение, что необходимо полностью менять схему работы с ней. По работе теста видно, что иногда в память пишется мусор.
С OnChipMemory такого не было, потому что она очень быстрая и там были разные порты для чтения и записи. А с реальной заметны переходные процессы на пинах данных - в момент переключения с чтения на запись там идёт случайный мусор. И этот мусор имеет некоторый шанс успеть записаться в память по адресу видеоданных, сканируемых до начала цикла обращения CPU к памяти.
В общем, надо делать дополнительный сигнал отключения памяти на 20нс перед обращением. Сейчас цикл занимает 100нс, можно его разбить на 2 части:
1) выключаем CE, выключаем OE, выставляем адрес, выставляем данные - пауза 20нс (1 такт клока);
2) включаем CE, включаем WE - держим до окончания обращения.
Жирным выделил то, что и так есть, а вот дополнительное управление CE/WE надо дополнить...
Нашел ещё одно проблемное место - сигнал DSYN формируется асинхронно, из-за чего наблюдается "иголка", мешающая записи в память. Буду переделывать и этот узел.
Заметил, только синхронизировав анализатор по частоте 300МГц.
- - - Добавлено - - -
Модификация доступа к ОЗУ сделана, но этого недостаточно:
https://image.prntscr.com/image/5rg6...7CC3FzV_cw.png
Фронт обращения к памяти значительно увеличился, раньше по длительности было равно длительности сигнала WR от Z80 - схему формирования обращения к памяти взял от ПРОшки, придётся модифицировать.
- - - Добавлено - - -
Уменьшил фронт обращения памяти к прежнему варианту (100нс).
Да, работа процессора с памятью теперь нормализована, но порой видео не может достучаться до памяти - где-то ещё проблема с таймингами... Это заметно при зажатии сброса - картинка идеальная, без артефактов.
Из проблем - при переходе на реальную память в правой части изображения непонятная фигня творится - а должна быть нормальная картинка.
Как-то всё запутанно с этим косяком - во время заливки памяти есть левые данные в видео, а после заливки всё идеально.
Такое ощущение, что для памяти ещё и после записи надо передёргивать CE, судя по мусору:
https://image.prntscr.com/image/nvD3...eTZERhpGIA.png
CE поднимаю только перед началом записи.
SA - шина адреса памяти, SD - её же данные. SOE - нога OE, SWE - и так понятно, что WE памяти.
DSYN_N - негативный строб обращения CPU к памяти.
По тесту - в память пишется строго 2 байта - 0xFF и 0x00, весь мусор только от переходных процессов на шине. Если делать "передёргивание" CE и в конце записи, то цикл обращения сократиться до 60нс...
"Моргать" CE это как-то не согласуется со схемой Ориона - там же ОЗУ всегда выбрано (Активно), а потребитель (ШД/видео) переключаются соответствющими выходными регистрами/буферами. Раз на запись с ШД хватается что-то не то (почему DRAM, в разы более медленные, кстати, так не хватали? Скорость то не на порядок выше) то я бы посмотрел в сторону того как работает буфер ШД, как вариант дополнительно в нужный момент защелкивать правильное состояние ШД латчем, а уже из него писать в ОЗУ. Чем щелкать СЕ дело не в дело, да еще и срезая запасы по времени обращения. Как такой вариант?
У меня ШД на память и так защёлкивается латчем (самописный аналог АП6, готового в кактусе не было):Цитата:
Сообщение от Error404
Тактирую я его очень высокой частотой (100МГц и более), так что он точно успевает.Код:-- altera vhdl_input_version vhdl_2008
library ieee;
use ieee.std_logic_1164.all;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity bidir_buf is
port (
A : inout std_logic_vector(7 downto 0);
B : inout std_logic_vector(7 downto 0);
AB : in std_logic;
OEn: in std_logic;
clk: in std_logic
);
end entity;
architecture rtl of bidir_buf is
begin
process (clk)
begin
if (rising_edge(clk)) then
if (OEn = '1') then
A <= (others => 'Z');
B <= (others => 'Z');
else
if (AB = '0') then
B <= (others => 'Z');
A <= B;
else
A <= (others => 'Z');
B <= A;
end if;
end if;
end if;
end process;
end rtl;
Буду "ковырять" позже, попробую разные варианты...
А вот участок формирования сигналов для памяти.
MA16 - это МА16 из ПРОшки. MRDn, MWEn - чтение и запись для памяти, ест, формируются как в ПРОшке, только без различий по банкам - это формируется здесь, в зависимости от типа памяти (для 16 битной - MA16 выбирает половинку слова, а MA19 выбирает чип, для 8 битной - MA16 выбирает чип). clk_mem - тактирование для OnChipMemory, сейчас 250МГц.
- - - Добавлено - - -
По поводу памяти - есть Verilog/VHDL модель от производителя, можно понять внутреннюю логику работы. Как понимаю, она примерно одинакова для всех SRAM.
- - - Добавлено - - -
По записи - надо как минимум восходящий фронт WE делать более ранним, поскольку запись идёт именно по нему - а там адрес ещё защёлкнут старый, но на данных защёлка уже переключилась, из-за чего и возможен мусор.
Аналогично и с нисходящим фронтом WE - внутри защёлкнут адрес видео-ячейки, появляется WE и данные для записи, МС успевает их записать. Более медленная память просто не успевает этого сделать.
Всё это моё ИМХО, просьба поправить ошибки - выводы сделал на основании анализа кода модели памяти.
АП6 это шинник, он когда открыт траслирует весь мусор как есть. Латч - это ИР22, там есть защелкивание управляемое по входу загрузки. Как вариант ИР23, но на ней будет бОльшая задержка из-за того что это честный регистр а не латч.
На момент активации этого элемента это не важно - ШД со стороны процессора уже давно стабилизированна, мусора там нет.Цитата:
Сообщение от Error404
Я говорю о мусоре в момент ухода записи от ЦП, когда в памяти на адресе ещё висит адрес записи, а на данных висит Z-состояние - данные от процессора уже "ушли", а новые ещё не прочитались.
А память во время записи по фронту любого из сигналов (данных, адреса, CE, WE) пишет новые данные:
Код:always @(posedge WE_n ) begin
WE_dly <= WE_n;
read_WE_n_start_time <=$time;
if (($time - write_WE_n_start_time) >=twp1)
begin
if ( (CE_n == 1'b0) && ( ($time - write_CE_n_start_time) >= tcw) )
begin
Address_write2 <= Address_write1;
dummy_array0[Address_write1] <= dataIO1[7:0];
dummy_array1[Address_write1] <= dataIO1[15:8] ;
activate_webar <= 1'b1;
end
else
activate_webar <= 1'b0;
end
else
begin
activate_webar <= 1'b0;
end
end
always@(CE_n or WE_n or OE_n or Address or DataIO )
begin
if ((CE_n==1'b0) && (WE_n ==1'b0))
begin
Address_write1 <= Address;
Address_write2 <= Address_write1;
dataIO1 <= DataIO;
dummy_array0[Address_write1] <= dataIO1[7:0] ;
dummy_array1[Address_write1] <= dataIO1[15:8] ;
end
end