Вид для печати
Ну я же подробно расписал как работает GOR. Будут импульсы RDATA - будет внутренний GDR, RDINITx, FIN_STB. Вот FIN_STB и приведет триггер в исходное состояние ожидания чтения/записи A1. Но, судя по цитатам из описания дисководов, импульсов RDATA в режиме записи нет, то GOR будет полностью проигнорирован микросхемой.Цитата:
Сообщение от Patron
Судя по программе форматирования - любое чтение регистра данных немедленно обрывает запись, поэтому при записи сектора, после появления в регистре статуса флага записи контрольной суммы - в регистр данных пишется слово 0x4E4E и только после выставления требования - выполняется чтение регистра данных.
В процессе эмуляции КМД выяснилось, что если режим записи ВП1-128 находится в состоянии NOT A1_WRITTEN ( т.е. до записи 0xA1 или после записи контрольной суммы ) - то чтение регистра данных переводит ВП1-128 в режим предварительного чтения - не выровненного ни на границу байта, ни на границу бита. Поэтому, в данном режиме можно только искать синхрозону. При чтении в районе синхрозоны - слово читаемых данных будет иметь значение 0x0000 или 0xFFFF.
Позже выяснилось, что это не так. При чтении регистра данных в режиме записи - устанавливается тот режим чтения ( поиск маркера или обычное чтение ) который имел место до начала записи.
Перевод осуществляется в любом режиме, не зависит от того записали 0xA1 или CRC, или не записали. На дискете в реальности вся дорожка аккуратно выровнена только после форматирования, а стоит записать сектора, то все и пойдет наперекосяк. Потому при поиске синхрозоны и проверяют и на 0x0000, и на 0xFFFF. Но так будет читаться только если контроллер не находится в подрежиме поиска маркера. Если маркер еще не найден, то вся информация с дискеты, проходящая через сдвиговый регистр, не попадает в регистр данных.Цитата:
Сообщение от Patron
Цитата:
Сообщение от Alex_K
Получается, что в режиме предварительного чтения содержимое регистра данных обновляется, но требование не выставляется.Цитата:
Сообщение от Vslav
Код прошивки -255 это подтверждает:
Код:; Пропуск не нулей при неактивном ИНДЕКСЕ
6704$: MOV #51010,R1 ; R1 = длина дорожки в цикле
6710$: TST @R4 ; Линия ИНДЕКС активна?
BMI 6762$ ; Да
MOV @R5,R0 ; Считанное слово равно нулю?
BEQ 7014$ ; Да
INC R0 ; Считанное слово равно 177777?
BEQ 7014$ ; Да
SOB R1,6710$ ; Цикл по пропуску не нулей
BR 6666$ ; Нет дискеты - ошибка
; Удостоверение в том, что попали на синхрозону
7014$: MOV #3,32(R3) ; Счетчик для удостоверения
7022$: MOV @R5,R0 ; Считанное слово равно нулю?
BEQ 7032$ ; Да
INC R0 ; Считанное слово равно 177777?
BNE 7066$ ; Нет - не синхрозона
7032$: DEC 32(R3) ; Уменьшить счетчик
BNE 7022$ ; Продолжаем дальше
Ещё вопрос - чем отличается поведение ВП1-128 при установленном сигнале защиты записи ?
А что это за режим предварительного чтения? Есть только режим чтения и его подрежим поиска маркера. Так вот в режиме поиска маркера требование не выставляется, но регистр данных чтения не обновляется, данные идут только через сдвиговый регистр.Цитата:
Сообщение от Patron
А коду прошивки не всегда стоит доверять, авторы прошивки работы с дисководом (и на УКНЦ, и на КМД) судя по всему тоже не все знали. Как можно по такой скудной документации написать код, мне непонятно.
Тогда какой режим устанавливается в этом случае:Цитата:
Сообщение от Alex_K
Если при чтении регистра данных в режиме записи - устанавливается один и тот же режим чтения, незавивисимо от состояния записи A1_WRITTEN - то в этом режиме чтения данные должны выдаваться, но требование выставляться не должно.Цитата:
Сообщение от Vslav
В любом случае устанавливается третий режим чтения, вопрос лишь в том - один и тот же ли этот режим при любом чтении в ходе записи или устанавливающийся режим зависит от фазы прерванной записи по состоянию A1_WRITTEN ( что менее вероятно ).
---------- Post added at 16:43 ---------- Previous post was at 16:04 ----------
Техническая разница между режимами предварительного чтения и нормального чтения в том, что предварительное чтение не выровнено даже по границе бита. Алгоритмическая же разница ( насколько я понимаю ) в том, что в режиме предварительного чтения не выставляется требование. Это вполне логично - при пропуске требования надо проверять контрольную сумму, но о какой контрольной сумме может идти речь, когда заранее известно, что чтение не выровнено по границе байтов.
Ну нету в контроллере никакого режима предварительного чтения. Если уж он начал читать, то читает. Хотя по схеме есть один тонкий момент, что если установился признак LATCH_TR, то сбросить его может только сигнал FIN_STB, а при активном LATCH_TR признак требования не устанавливается. Надо посмотреть повнимательнее схему, проанализировать.Цитата:
Сообщение от Patron
Приеду домой, осмотрю и напишу.
Это режим обычного чтения, при котором не устанавливается требование. Режим этот был обнаружен экспериментально.Цитата:
Сообщение от Alex_K
Если игнорировать результаты экспериментов и при невыровненном чтении требование устанавливать - все прошивки работают точно так же, потому что в режиме предварительного чтения никогда не проверяют бит требования.
Но если при невыровненном чтении действовать в соответствии с экспериментально наблюдаемыми результатами и требование НЕ УСТАНАВЛИВАТЬ - то все прошивки полностью сохраняют работоспособность именно потому, что в режиме предварительного чтения никогда не проверяют бит требования.
В результате каких экспериментов?Цитата:
Сообщение от Patron
Не проверяют они его потому, что неизвестно состояние контроллера. Он может находится в режиме поиска маркера, и пока он его не найдет, то и чтение данных не начнется. Есть еще момент - бит требования устанавливается только после чтения двух байтов, а ведь сдвиговый регистр байтовый. Поэтому таким чтением можно прочесть уже следующий байт без установки бита требования. Представим записано на диске 1 2 3 4 5 6 ... Сначала в регистре данных чтения прочтется <1 2> и выставится бит требования, потом будет <3 2>, но бита требования не будет стоять, а уже когда окажется <3 4>, то установится бит требования. Потому в программах поиска синхрозоны и не проверяют бит требования, чтобы не подвиснуть на долгое время.Цитата:
Сообщение от Patron
А если контроллер перешел в режим чтения, то он аккуратно будет нарезать данные каждые 64 мкс, при присутствии сигналов на входе в соответствии с подстройкой ФАПЧ, а если сигнала нет, то будут поступать нули каждые 64 мкс.
А так надо знать как формируются сигналы STB_**, зная их можно точно сказать как работает и чтение и запись.
Вот таких:Цитата:
Сообщение от Alex_K
Цитата:
Сообщение от Vslav
В режиме поиска маркера данные в регистр данных не передаются, поэтому читать регистр данных при не установленном требовании - совершенно бессмысленно.Цитата:
Сообщение от Alex_K
Нет никакой разницы - 21000 раз прочитать бит требования или 21000 раз прочитать регистр данных. Однако, программа поиска синхрозоны именно 21000 раз читает регистр данных, ни разу при этом не проверяя бит требования ( хотя бит индекса в том же самом регистре статуса программа поиска синхрозоны проверяет 21000 раз - перед каждым чтением регистра данных ):Цитата:
Сообщение от Alex_K
Весьма похоже, что ни одна программа поиска синхрозоны ни в одной прошивке, работающей с ВП1-128 - не проверяет бит требования в режиме предварительного чтения.Код:; Пропуск не нулей при неактивном ИНДЕКСЕ
6704$: MOV #21000.,R1 ; R1 = длина дорожки в цикле
6710$: TST @R4 ; Линия ИНДЕКС активна?
BMI 6762$ ; Да
MOV @R5,R0 ; Считанное слово равно нулю?
BEQ 7014$ ; Да
INC R0 ; Считанное слово равно 177777?
BEQ 7014$ ; Да
SOB R1,6710$ ; Цикл по пропуску не нулей
BR 6666$ ; Нет дискеты - ошибка
Об этом я говорил много раз, сохраняется старое значение.Цитата:
Сообщение от Patron
Естественно ни одна.Цитата:
Сообщение от Patron
Так я все-таки не понял, что за режим предварительного чтения? Я знаю только два режима чтения: собственно чтение и поиск маркера. Во время поиска маркера неактивен сигнал PLL_RDY, соответственно сигналом BCNT_CLK не крутится 4-хразрядный счетчик битов, не вырабатывается сигнал RDR_STB, соответственно отсюда нет сигналов RDR_HSTB и RDR_LSTB, вся информация со сдвигового регистра не поступает в регистр данных чтения. Но вот как только появился маркер, то активизируется сигнал PLL_RDY, начинает работать счетчик, ну и информация копируется в регистр данных чтения. Бит требования TR устанавливается по сигналу RDR_LSTB при неактивном LATCH_TR. А вот если требование не удовлетворено, то активизируется признак LATCH_TR по сигналу RDR_HSTB. Он остается установленным до следующего сигнала RDR_HSTB, когда выработается FIN_STB и сбросит признак LATCH_TR. Вот если при установке LATCH_TR прочесть регистр данных и сбросить требование, то следующим сигналом RDR_LSTB оно установлено не будет, т.к. активен LATCH_TR.
Это режим, в котором находится ВП1-128, когда выполняется этот код:Цитата:
Сообщение от Alex_K
Хорошо видно, что программа поиска синхрозоны 21000 раз читает регистр статуса, но не проверяет там бит требования. Вместо это программа 21000 раз читает регистр данных, каждый раз предполагая, что его значение изменилось без установки бита требования.Код:; Пропуск не нулей при неактивном ИНДЕКСЕ
6704$: MOV #21000.,R1 ; R1 = длина дорожки в цикле
6710$: TST @R4 ; Линия ИНДЕКС активна?
BMI 6762$ ; Да
MOV @R5,R0 ; Считанное слово равно нулю?
BEQ 7014$ ; Да
INC R0 ; Считанное слово равно 177777?
BEQ 7014$ ; Да
SOB R1,6710$ ; Цикл по пропуску не нулей
BR 6666$ ; Нет дискеты - ошибка
Сам я обратил на это внимание только тогда, когда Vslav сообщил, что при переводе ВП1-128 из режима записи в режим чтения путём простого чтения регистра данных - запись мгновенно обрывается на случайном бите и начинается такое чтение, при которомЦитата:
Сообщение от Vslav
Ну то что читает данные, это еще не значит, что бит требования не устанавливается. По аналогии можно читать регистр терминала 177562 без опроса регистра 177560. При этом содержимое 177562 может меняться, но при этом и будет устанавливаться флаг готовности в 177560, просто мы его игнорируем и сбрасываем чтением регистра 177562.Цитата:
Сообщение от Patron
Точно также и у 1801ВП1-128, если активен сигнал PLL_RDY, то сигналом RDR_LSTB при неактивном LATCH_TR будет установлено требование, сбрасывается требование чтением или записью регистра 177132.
А после записи, если переводят в режим чтения, то схема чтения может находится или в режиме чтения, или в режиме поиска маркера. Кстати, в режим чтения переход осуществляется не сразу, а по определенным условиям.
А когда программа 21000 раз читает регистр данных, то это не значит, что 21000 раз разные значения.
Не устанавливается, я специально смотрел. Если мы были в режиме записи, и уже была запись маркера и потом вдруг прочитали регистр данных, тем самым перейдя в чтение, то начнется чтение с диска, данные будут помещаться в регистр, но требования не будет. Это как режим поиска маркера, только маркер обнаружен не будет, поскольку триггер A1W общий для режимов чтения/записи и он сброшен нормально не был (сумму то мы не писали).Цитата:
Сообщение от Alex_K
А на временные диаграммы посмотреть можно? И что это за триггер, какой элемент в схеме? Вроде запись маркера никак особо на работу не влияет.Цитата:
Сообщение от Vslav
Если при эмуляции ВП1-128 сделать так, что чтение регистра данных при записи переводит ВП1-128 в режим поиска маркера - дорожка начинает писаться за 10 оборотов вместо одного и программа TESTMY.SAV сообщает, что контроллер неисправен.Цитата:
Сообщение от Alex_K
Надо проверить то же самое, но уже при чтении регистра данных после записи контрольной суммы, записи ещё одного слова в регистр данных и появления требования записи - будет тогда выставляться требование при невыровненном чтении или не будет..Цитата:
Сообщение от Vslav
Судя по коду прошивки - требование при чтении тогда тоже не выставляется.
Про триггер написано в этом сообщении.Цитата:
Сообщение от Alex_K
Диаграмма моделирования чтения регистра данных без пропуска требования в аттаче.
P.S. Было бы хорошо если кто-нибудь еще поставил Quartus+ModelSim, проект 128-ой для Quartus открыто выложен, разобраться с основами и запустить моделирование помогу. Потому что много нюансов, я могу где-то и ошибиться.
И ещё небольшой вопрос - чем отличается поведение ВП1-128 при установленном сигнале защиты записи ?
Если записываются сплошняком все 10 секторов, то после записи данных, при чтении регистра данных, контроллер переходит именно в режим чтения, т.к. до записи схема чтения находилась не в режиме поиска маркера.Цитата:
Сообщение от Patron
Кстати в УКНЦ, если подряд записываются сектора, то поиск следующей синхрозоны происходит с опросом бита требования. Подпрограмма по адресу 134132.
---------- Post added 28.12.2013 at 00:06 ---------- Previous post was 27.12.2013 at 23:48 ----------
Про это я читал. Просто при моделировании у Вас схема чтения находилась в режиме поиска маркера. Это видно, как только перешли в режим чтения, то сразу же кончились импульсы BCNT_CLK. Для того, чтобы перейти в режим чтения, надо дать маркер 0xA1 именно с пропущенным синхроимпульсом, ну и чтоб он совпал по фазе. А вот схема для сброса CRC останется взведенной и регистры CRC не очистятся, это факт, считаться будет полный бред и в итоге контрольная сумма не сойдется.Цитата:
Сообщение от Vslav
Вот программа поиска синхрозоны в ПЗУ УКНЦ:Цитата:
Сообщение от Alex_K
Это практически точная копия программы из прошивки -255 и смысл её именно в том, что в режиме предварительного чтения бит требования не проверяется.Код:132656$:MOV #4,R1
CMPB #5,23301 ; Формат 1024 байта в секторе ?
BNE 132702$ ; Нет
TST @R4 ; Присутствует линия индекс ?
BPL 132702$ ; Нет
MOV #36,R1
132702$:MOV @R5,R0 ; Прочесть слово с дискеты
BEQ 132730$ ; Это нуль
INC R0
BEQ 132730$ ; Это минус один
TSTB @#177710 ; Таймер окончил счет
BPL 132656$ ; Нет
CALL 134242$ ; Сбросить готовность таймера
SOB R2,132656$
BR 133002$ ; Ошибка (не найден межсекторный промежуток)
---------- Post added at 23:14 ---------- Previous post was at 23:08 ----------
Интересно найти хотя бы одну прошивку, которая не сможет работать, когда в режиме предварительного чтения ВП1-128 не выставляет требование.
Кстати, я тут посмотрел внимательно на этот триггер A1W и выяснил что он только CRC_RST генерирует. А вот за запуск чтения другой триггер отвечает - на A30, который PLL_RDY выдает. Я сейчас немного сместил выдачу маркера на чтение - и начало выставляться требование! То есть при предыдущем моделировании просто оно не распознало маркер (попало на противофазу). Но при этом чтении все равно CRC не сбросилась, поэтому результирующая сумма будет неверная.
В-общем, мне кажется все работает так:
- есть два отдельных триггера - A1W и A30(PLL_RDY)
- триггер A1W устанавливается FIN_STB, сбрасывается при обнаружении A1 в сдвиговом регистре, в момент перехода 1->0 вырабатывает nCRC_RST и обнуляет сумму
- триггер A30(PLL_RDY) сбрасывается GOR и взводится по обнаружении полноценного маркера с пропущенным синхроимпульсом
- запись на диск начинается при записи любого значения в регистр данных
- сброс суммы CRC (обнуление) произойдет только при записи первого A1, и только если триггер A1W установлен. При обнулении CRC триггер A1W уже сброшен, следующие записи A1 и сбросы A1W не обнуляют сумму (нет перехода триггера 1->0).
- чтение регистра данных всегда переводит в режим чтения
- чтение всегда сначала ищет маркер, при обнаружении срабатывает триггер A30/PLL_RDY.
- если PLL_RDY установлен то в режиме чтения будет устанавливаться требование
- режим поиcка маркера - только при сброшенном A30. То есть если маркер был найден то новый поиск маркера начнет только после GOR, иначе продолжается чтение, даже при необслуженном требовании. Необслуживание требования при чтении, видимо, имеет одну цель - подсчет суммы и выработку FIN_STB. Потом чтение вполне себе продолжается и даже обнулит сумму если вдруг найдет A1.
---------- Post added at 22:30 ---------- Previous post was at 22:29 ----------
Ага, я это только сейчас заметил.Цитата:
Сообщение от Alex_K
Дальнейшая проверка работы прошивок в режиме предварительного чтения.
Прошивка БК-0011:
Видно, что синхрозона ищется без проверки требования, а сразу после установки GOR - начинается ожидание требования.Код:.SbTtl Check for Data
20$: Call ChkInd
Bcs 100$
Beq 20$ ;Zero, skip it
Com R0
Beq 20$ ;---"----"-----
30$: Call ChkInd
Bcs 100$
Beq 40$
Com R0
Bne 30$
.SbTtl Real Adress mark Checking
40$: MovB #3,ErrCnt ;Retry Counter
50$: Mov @R5,R0 ;Data = Zero ?
Beq 60$ ;Yes,
Com R0 ;Inverted Zero ?
Bne 20$ ;No
60$: DecB ErrCnt ;Yes, Wait once more
Bne 50$
Call StrtRd ;Set GoR
Mov #20.,R0
70$: TstB @R4 ;Wait for Data ready
Bmi 80$ ;Ready
Sob R0,70$ ;Not Ready, Timeout
Br 20$
Это отсюда качать?Цитата:
Сообщение от Vslav
---------- Post added at 00:43 ---------- Previous post was at 00:37 ----------
Вот, как я понял, контроллер переходит в режим записи сразу же. Так как активен режим записи, то импульсы BCNT_CLK идут всегда и счетчик битов всегда работает. Но этот счетчик не сбрасывается, поэтому если он работал ранее в режиме чтения данных, то возможны такие варианты:Цитата:
Сообщение от Vslav
- запишется несколько битов из сдвигового регистра (то что было);
- в зависимости от числа счетчика может записаться сначала младший байт, затем старший и выставится требование;
- может записаться только старший байт и выставится требование, младший уже не запишется.
---------- Post added at 00:45 ---------- Previous post was at 00:43 ----------
При установленном сигнале WRP с дисковода, на дисковод в режиме записи не подается сигнал WRE, и соответственно он (дисковод) остается в режиме чтения.Цитата:
Сообщение от Patron
Нет, надо WEB-edition, он бесплатный.Цитата:
Сообщение от Alex_K
Спасибо! Правда вникать я наверное буду долго. А так надо бы прояснить все временные диаграммы сигналов STB_**, как контроллер переключается в режим чтения, ну и тд и тп.Цитата:
Сообщение от Vslav
Интереснее всего проверить, что происходит при поиске синхрозоны заголовка следующего сектора после записи блока данных предыдущего сектора.Цитата:
Сообщение от Alex_K
Последовательность при этом следующая:
1. Прочитать регистр данных
2. Установить и сбросить GOR
3. Ждать требование
4. Записать 0xA1A1
5. Ждать флаг CRC
6. Записать 0x4E4E
7. Ждать требование
8. Прочитать регистр данных
В результате ВП1-128 переходит в такое состояние чтения, в котором ни одна из прошивок не проверяет требование. При этом ( например ) УКНЦ, для определения смены слова в регистре данных, вместо того, чтобы проверять требование - использует таймер УКНЦ.
Какой был бы смысл использовать таймер вместо бита требования, чтобы определить момент смены слова в регистре данных, если бы бит требования в режиме предварительного чтения выставлялся как обычно..
Ох, Patron, прицепились вы к этому требованию и придумали какой-то режим предварительного чтения, которого нет. Повторюсь еще раз, что требование не проверяется потому, что неизвестно в каком режиме находится контроллер - поиск маркера (где оно не выставляется до тех пор, пока не будет найден) или режим чтения.Цитата:
Сообщение от Patron
А про использование программируемого таймера в прошивке УКНЦ я Вам сейчас все расскажу. Периферийный процессор в УКНЦ обслуживает кроме дисковода еще эмулятор терминала, который принимает данные по каналу 0, использует сетевой таймер для скроллинга и мигания курсора. Чтобы все это хорошо работало надо чтобы возникали прерывания в нужный момент времени, т.е. нужна система более-менее реального времени. А 1801ВП1-128 как известно не имеет ни режима прерываний, ни ПДП, т.е. чтение данных с дискеты должно идти при полностью запрещенных прерываниях. А вот теперь представьте, что мы прочитали заголовок сектора, а номер сектора не тот, что нам надо. Или прочли маркер данных. Вот здесь, чтобы тупо не читать этот ненужный нам сектор до конца, программа управления дисководом в УКНЦ поступает очень умно. Она программирует таймер на время прохождения сектора, и отдает управление прерванной программе. Когда головка дисковода подходит к концу сектора, то вырабатывается прерывание от программируемого таймера, и программа чтения уже может искать следующий маркер. В КМД ДВК это не надо, и там, если нашли не тот маркер или заголовок, тупо пропускаются все данные.
Т.е. при чтении регистра данных в режиме записи - контроллер всегда переходит в тот режим чтения, который был до этого ( поиск маркера или обычное чтение ).Цитата:
Сообщение от Alex_K
Когда Vslav проводил эксперимент с чтением регистра данных перед записью контрольной суммы - до начала эксперимента у ВП1-128 был режим поиска маркера, поэтому он и установился в момент чтения регистра данных. Если бы перед началом эксперимента уже был режим обычного чтения, то в ходе эксперимента - после чтения регистра данных установился бы режим обычного чтения.
Контроллер переходит в режим чтения, возможно и поиск маркера, в зависимости от состояния триггера PLL_RDY.Цитата:
Сообщение от Patron
Если с дисковода поступают данные, то сбросится триггер PLL_RDY и контроллер перейдет в режим поиска маркера.Цитата:
Сообщение от Patron
Если данных с дисковода не поступает, то установка и сброс GOR ничего не меняют.
Контроллер нашел маркер и перешел в режим чтения. В регистре считанных данных находится 0xA1A1. Начинается подсчет CRC. Триггер A1 сброшен.Цитата:
Сообщение от Patron
А вот это тонкий момент. То что контроллер перейдет в режим записи это точно. Но зависит все от того, что было в счетчике битов. Так что записывать начнет наверное остаток сдвигового регистра, а потом скорее всего только один байт 0XA1. Но так как триггер A1 был сброшен, то CRC не начнет снова считаться, а продолжиться.Цитата:
Сообщение от Patron
Начнет записываться CRC сосчитанная из того, что прочитали, и того, что записали. Но вот прочитали не только 0xA1A1, но и то, что за ним (несколько бит). Выработается сигнал FIN_STB и взведется триггер A1.Цитата:
Сообщение от Patron
Запишется в регистр данных записи.Цитата:
Сообщение от Patron
После установки требования уже будет записана CRC и один байт 0x4E, начинает писаться следующий 0x4E.Цитата:
Сообщение от Patron
Прерывается запись 0x4E, контроллер спустя некоторое время переходит в режим чтения без поиска маркера, именно чтения. Невыровненные данные будут поступать в регистр данных с установкой требования. Так как триггер A1 взведен, то если произойдет чудо и попадется маркер не смещенный по фазе, то сброситься регистр CRC и начнется счет снова. Но это при условии, что регистр считываемых данных будут считывать при установке требования.Цитата:
Сообщение от Patron
Да, здесь я полностью согласен. Единственный тонкий момент, это следить за состоянием триггера A1, чтобы знать в какой момент сбрасывать регистр CRC. А так генератор CRC никогда не прекращает считать. На него все время поступает информация со сдвигового регистра, ну или нули в режиме записи CRC (при установленном признаке LATCH_TR).Цитата:
Сообщение от Patron
Или всё же единицы..Цитата:
Сообщение от Alex_K
Ведь на диск пишется инвертированное содержимое сдвигового регистра CRC, а в режиме "холостого хода записи" ( насколько я понял ) - нули пишутся именно на диск.
Может и единицы, ибо сигнал по схеме инвертируется несколько раз.Цитата:
Сообщение от Patron
То, что CRC инвертируется перед записью на диск - это точно. Поэтому, если на диск при "холостой записи" пишутся нули - в регистр CRC добавляются единицы.Цитата:
Сообщение от Alex_K
---------- Post added at 13:42 ---------- Previous post was at 13:31 ----------
Vslav сообщал, что при "холостой записи" на диск пишутся нули - это точно так ?
Возможно. Когда требование не удовлетворилось, то по обратному фронту RDR_HSTB защелкивается триггер LATCH_TR. При активном LATCH_TR в регистр CRC начинают вдвигаться единицы. После записи CRC в регистре CRC оказываются все единицы. По новому сигналу RDR_HSTB формируется сигнал FIN_STB. Этот сигнал очищает триггер LATCH_TR, но после очистки LATCH_TR исчезает и FIN_STB, он получается очень короткий. Сигнал RDR_HSTB подлиннее, и по идее снова должен защелкнуться LATCH_TR, и соответственно пойти запись регистра CRC, а там уже все единицы, они же снова и будут вдвигаться.Цитата:
Сообщение от Patron
Получается, что так, пишутся одни нули.
Есть еще один момент. Получается когда задвинуты все единицы, то должен сформироваться признак CRC_VALID, который защелкнется в триггере J34 по сигналам nLATCH_TR и nSTB_P03. А этот триггер выводится в бит 14 регистра состояния при нахождении контроллера в режиме чтения.
В этом случае при переходе в режим чтения установится флаг CRC, который можно сбросить только по INIT/GOR ?Цитата:
Сообщение от Alex_K
А так будет после любой записи CRC или только при пропуске требования записи после записи CRC ?
Да, сбросить его можно только этими сигналами.Цитата:
Сообщение от Patron
Так будет, если активны сигналы LATCH_TR и STB_P03. LATCH_TR устанавливается при неудовлетворенном требовании на следующие 64 мкс. А вот времянку сигналов STB_** я не знаю. Сложноватая схема формирования. Кстати, в схеме много различных триггеров сделано на мелкой логике. Её в принципе можно сильно уменьшить и привести в удобоваримый вид.Цитата:
Сообщение от Patron
Перекачал и установил Quartus II Software (includes Nios II EDS) и ModelSim-Altera Edition (includes Starter Edition). Quartus требует еще установить устройства. Можно любое, поменьше, например MAX II, MAX V device support ? А то остальные очень сильно пожирают место на диске.Цитата:
Сообщение от Vslav
Если только для моделирования - то, наверное, лучше что-то из Циклонов 1/2/3. У MAX может просто ячеек не хватить. Для поведенческого моделирования выбор конкретного FPGA не важен - все временные параметры из модели берутся.Цитата:
Сообщение от Alex_K