если тестбенч не пройдет то дисковод темболее
а по поводу помех :) на скрин глян.
То что за*****е это типа поток от дисковода
Вид для печати
Ewgeny7 погоняй на скорпэве, Дмитрий завтра появиться попробуем попросить его собрать бин для пентевы
Код:`timescale 1ns/10ps
module pll28(
input wire clk, // 28mhz
input wire rddat_n,
output reg rclk,
output reg rawr_n
);
// filter
reg [3:0] sr;
reg rawr_sync;
always @ (posedge clk)
begin
sr <= { sr[2:0], rddat_n };
if (sr == 4'hF || sr == 4'h0)
rawr_sync <= sr[3];
end
// rawr
reg [4:0] rawr_sr;
always @ (posedge clk)
begin
rawr_sr <= { rawr_sr[3:0], rawr_sync };
rawr_n <= !(rawr_sr[4] && !rawr_sr[0] ); // rawr 140ns
end
// rclk
reg [5:0] counter = 0;
wire[5:0] delta = 27 - counter;
wire[5:0] shift = { delta[5], delta[5], delta[4:1] }; // sign div
wire[5:0] inc = rawr_sr[1:0] == 2'b10 ? shift : 1;
always @ (posedge clk)
begin
if (counter < 55)
counter <= counter + inc;
else
begin
counter <= 0;
rclk = ~rclk;
end
end
initial
rclk = 0;
endmodule
Оки - ждем до завтра. Лисице осцилограмки дам часов после 9 вечера.
Счас попозжа проверю - заканчиваю переводить диски в трд
v5 тоже работает, а вот сравнить разные версии пока не могу - дите требует внимания.
ZEK, есть диск, который туго читается вовсе :) сейчас доделываю свой плагин для RealCommander-а, который форматит и проверяет дискеты, причем он будет выдавать репорт с количеством попыток чтения каждого сектора (понадобился для проведения анализа качества работы ФАПЧей на разных клонах :) ).
Особых изменений на 5й версии не заметил если честно.
я просто делаю так - прошиваю конфиг и начинаю сливать фаталом с диска в трд.
диски которые читаются с ошибками откладываю в одну кучку - без ошибок - в другую.
с новой версией - беру пачку ошибочных и пробую опять. как правило ошибок становится либо меньше либо уходят совсем. в отвал опять уходят ошибочные диски -ждут новую версию ФАПЧ. И так по кольцу.
Лисица - я конечно сорри ( может уже упареный) но визуально - особой разницы не вижу между твоим фапчем и ZEKa .
Картинки в аттаче.
Вернее вижу 2 разницы - е него работает и клок есть всегда, а твой не работает и клок только во время чтения появляется.
P.P.S я конечно сорри за такой монолог одного актера (решил добавлять к старой месаге и не плодить кучу).
говорю же - был запарен - развернул чуть картинку и увидел что часть данных у тебя идет мимо кассы - смотри архив с названием глюк. Видно что часть импульсов проходит не в нужное время - когда клок в еденице. сейчас еще раз загрузу конфиг 5 и гляну что у него.
Да - у него все четко попадает при нуле на клоке. а у тебя часть импульсов идет в другое время.
WFDE, когда в 1 то блокирует его.
Так и должно быть
У меня RCLK на грамульку меньше (как в описаниях - 125мс). Может из за этого и не работает? Попробую увеличить его.
PS А самое лучшее проверять осцилом, записав на трек все 11111111, после все 000000000, потом 10101010. Есть утилитка такая что это умеет, у меня она обзывается ustir1.0, Я её немного переделал на ustir1.1, а то надоело за головкой гоняться по диску из за ошибок.
PPS В диаграмме описано, что ближе к концу.:confused:
это пример, на этой диаграмме нарисовано 2 ситуации
В даташите на wd1793 написано что rclk должен отступать от rawr минимум на 40нс
если думать логически и отодвинуть максимально фронты rawr от rclk то получается что rawr должен находиться в середине rclk, думаем дальше - нам надо устойчивый фапч то есть что бы он мог реагировать на как можно большее отклонение rawr от положенного места, для этого rawr опять же надо поставить в середину что бы было как можно больше запаса для фазовых бросков как вперед так и назад.
блин, застопорился на времени rawr, никак не могу его чюточки увеличить...
так покажи свой код - попытаемся сравнить его с последним от ZEK. бо он тоже воевал с этим.
Попробуй сравнить vhdl и verilog...
Я, например, в ZEKовом коде ничё не понял...
Вот, смотрите, жирным собсно формирование 125 мс как на схеме...Код:library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_unsigned.all;
use IEEE.numeric_std.ALL;
entity fapch is
port(
f28 : in std_logic;
rdat : in std_logic;
wf_de : in std_logic;
del1: buffer std_logic_vector(2 downto 0);
rclk : buffer std_logic;
rawr : buffer std_logic
);
end fapch;
architecture fapch_arch of fapch is
signal rd1: std_logic;
signal rd2: std_logic;
signal fa: std_logic_vector(4 downto 0);
signal del: std_logic_vector(1 downto 0);
signal f8: std_logic;
signal ff: std_logic;
--signal del1: std_logic_vector(2 downto 0);
begin
ff <= f28 xor fa(0);
f8 <= del(1);
process(ff)
begin
if (ff'event and ff='0') then
del <= del + 1;
end if;
end process;
process(f8,rdat,rd1)
begin
if (f8'event and f8='0') then
if rdat = '0' then
rd1 <= '1';
else
rd1 <= '0';
end if;
end if;
end process;
process(f8,rd1,rd2)
begin
if (f8'event and f8='0') then
if rd1 = '1' then
rd2 <= '0';
else
rd2 <= '1';
end if;
end if;
end process;
rawr <= '0' when wf_de = '0' and (rd1 = '1' and rd2 = '1') else '1';
process(f8,rawr)
begin
if (f8'event and f8='0') then
if rawr = '0' then
if fa(3 downto 0) < 3 then
fa(3 downto 0) <= fa(3 downto 0) + 4;
elsif fa(3 downto 0) < 5 then
fa(3 downto 0) <= fa(3 downto 0) + 3;
elsif fa(3 downto 0) < 7 then
fa(3 downto 0) <= fa(3 downto 0) + 2;
elsif fa(3 downto 0) = 7 then
fa(3 downto 0) <= fa(3 downto 0) + 1;
elsif fa(3 downto 0) > 12 then
fa(3 downto 0) <= fa(3 downto 0) - 3;
elsif fa(3 downto 0) > 9 then
fa(3 downto 0) <= fa(3 downto 0) - 2;
elsif fa(3 downto 0) > 8 then
fa(3 downto 0) <= fa(3 downto 0) - 1;
end if;
else
fa <= fa +1;
end if;
end if;
end process;
process(rclk)
begin
if wf_de = '0' then
rclk <= not fa(4);
else rclk <= '1';
end if;
end process;
end fapch_arch;
Ага - ок. распечатаю и сравню попозже - счас пока загружен работой.
Частота клока в этой машине как и у эвы - 28 Мгц?
Сравнил последний свой фапч и твой
ну из того что бросается в глаза, у меня чуть шустрее выравнивает фазы, и при резких броска у тебя прилипает rawr к rclk, у меня делает отступ (по даташиту он обязателен).
Ну и длительность rawr
Ну, это поправимо.
А здесь как? Запоминать RDAT и выставлять его позже?
А вдруг это предыдущий опоздал, или следующий слишком рано прошёл в какую сторону двигать?
Или вы хотите окончательно нечитаемые дискеты чтоб заработали?
Лучше подскажите как импульс RAWR увеличить...
Прошу Дмитрия сделать сборку для проверки.
Увеличил RAWR до 142нс и немного ускорил смещение к середине.
Исправил очепятку длины :)
Чёт совсем затихло. Дим, как там, собрал\проверил, или как?
эх, давно не брал я в руки шашку...
Идея такая...
Счетчик/делитель на частоту считывания с дисковода, с фазовым корректором.
На VHDL это выглядит примерно так:
Код:--- заголовки для ясности пропущены
constant phase_level : integer := 128; -- уровень привязки фазы - надо подбирать
constant NN : integer := 4; -- чувствительность -
-- число равное степени двойки, чтобы не усложнять схему.
-- 1 - жесткая привязка
-- 2 - средняя привязка
-- 4 - мягкая привязка
-- подбирать опытным путем или делать настраиваемо
constant frq : integer := 14; -- число считается как frq = Fread*256/Fclk
signal ct : integer range 0 to 255;
signal outCLK : integer range 0 to 1;
begin
process (clk) begin
IF clk'event and clk = vcc THEN
-- приходит импульс (его надо сузить до длины в один период clk)
IF impuls = vcc THEN
ct <= ct + frq + (Phase_Level - ct)/NN;
ELSE
ct <= ct + frq;
END IF;
outCLK <= ct / 128;
END IF;
end process;
end;
Прошил сегодня zxevo_fw_apll_v5.rar и перегнал около сотни дискет.
Субьективно ничего не изменилось, по прежнему спасает только правая рука и смена дисковода... (и то увы не всегда) .
Зависит от того с чем сравнивать
Можно я отвечу? Спасибо. Я думаю, newart использует правую руку в этом процессе, так же, как и я (очень надеюсь, что и многие другие Спектрумисты). Нежно и ласково тереблю дискетку в дисководе, как бы чуть вынул, а потом чуть вставил.... И так многократно. Простые движения. Очень помогает скрасить досуг при чтении плохочитаемых дисков.
ещё практикуется кручение защёлки дисковода правой рукой