Вроде вот такой тест должен работать:Сообщение от andreil
http://zx-pk.ru/attachment.php?attac...5&d=1418316129
И выдавать вот такую картинку:
http://zx-pk.ru/attachment.php?attac...1&d=1389740514
Но у меня в эмуляторе оно почему-то не заработало (может баг в эмуляторе - ХЗ).
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Точно, как я мог о нём забыть...
На FPGA с внутричиповой памятью в текущем варианте работал 100%.
Для его работы на картинку надо правильно выставить переключатели - это есть в мануале по ПРО:
- - - Добавлено - - -
Да, проблема с таймингами, буду разруливать - видны артефакты.
"Байт-48"
Точно. Подзабыл уже, что для него надо еще и DIP-switch переставлять (как по мне - совершенно лишнее, т.к. потом еще надо вспомнить как оно было).
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Это да, вспоминать всегда тяжело
По памяти - такое ощущение, что необходимо полностью менять схему работы с ней. По работе теста видно, что иногда в память пишется мусор.
С OnChipMemory такого не было, потому что она очень быстрая и там были разные порты для чтения и записи. А с реальной заметны переходные процессы на пинах данных - в момент переключения с чтения на запись там идёт случайный мусор. И этот мусор имеет некоторый шанс успеть записаться в память по адресу видеоданных, сканируемых до начала цикла обращения CPU к памяти.
В общем, надо делать дополнительный сигнал отключения памяти на 20нс перед обращением. Сейчас цикл занимает 100нс, можно его разбить на 2 части:
1) выключаем CE, выключаем OE, выставляем адрес, выставляем данные - пауза 20нс (1 такт клока);
2) включаем CE, включаем WE - держим до окончания обращения.
Жирным выделил то, что и так есть, а вот дополнительное управление CE/WE надо дополнить...
Нашел ещё одно проблемное место - сигнал DSYN формируется асинхронно, из-за чего наблюдается "иголка", мешающая записи в память. Буду переделывать и этот узел.
Заметил, только синхронизировав анализатор по частоте 300МГц.
- - - Добавлено - - -
Модификация доступа к ОЗУ сделана, но этого недостаточно:
Фронт обращения к памяти значительно увеличился, раньше по длительности было равно длительности сигнала WR от Z80 - схему формирования обращения к памяти взял от ПРОшки, придётся модифицировать.
- - - Добавлено - - -
Уменьшил фронт обращения памяти к прежнему варианту (100нс).
Да, работа процессора с памятью теперь нормализована, но порой видео не может достучаться до памяти - где-то ещё проблема с таймингами... Это заметно при зажатии сброса - картинка идеальная, без артефактов.
Из проблем - при переходе на реальную память в правой части изображения непонятная фигня творится - а должна быть нормальная картинка.
Как-то всё запутанно с этим косяком - во время заливки памяти есть левые данные в видео, а после заливки всё идеально.
Такое ощущение, что для памяти ещё и после записи надо передёргивать CE, судя по мусору:
CE поднимаю только перед началом записи.
SA - шина адреса памяти, SD - её же данные. SOE - нога OE, SWE - и так понятно, что WE памяти.
DSYN_N - негативный строб обращения CPU к памяти.
По тесту - в память пишется строго 2 байта - 0xFF и 0x00, весь мусор только от переходных процессов на шине. Если делать "передёргивание" CE и в конце записи, то цикл обращения сократиться до 60нс...
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
"Моргать" CE это как-то не согласуется со схемой Ориона - там же ОЗУ всегда выбрано (Активно), а потребитель (ШД/видео) переключаются соответствющими выходными регистрами/буферами. Раз на запись с ШД хватается что-то не то (почему DRAM, в разы более медленные, кстати, так не хватали? Скорость то не на порядок выше) то я бы посмотрел в сторону того как работает буфер ШД, как вариант дополнительно в нужный момент защелкивать правильное состояние ШД латчем, а уже из него писать в ОЗУ. Чем щелкать СЕ дело не в дело, да еще и срезая запасы по времени обращения. Как такой вариант?
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
У меня ШД на память и так защёлкивается латчем (самописный аналог АП6, готового в кактусе не было):
Тактирую я его очень высокой частотой (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 и данные для записи, МС успевает их записать. Более медленная память просто не успевает этого сделать.
Всё это моё ИМХО, просьба поправить ошибки - выводы сделал на основании анализа кода модели памяти.
Последний раз редактировалось andreil; 15.04.2018 в 11:33.
АП6 это шинник, он когда открыт траслирует весь мусор как есть. Латч - это ИР22, там есть защелкивание управляемое по входу загрузки. Как вариант ИР23, но на ней будет бОльшая задержка из-за того что это честный регистр а не латч.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
На момент активации этого элемента это не важно - ШД со стороны процессора уже давно стабилизированна, мусора там нет.
Я говорю о мусоре в момент ухода записи от ЦП, когда в памяти на адресе ещё висит адрес записи, а на данных висит 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
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
