Про триггер написано в этом сообщении.Сообщение от Alex_K
Диаграмма моделирования чтения регистра данных без пропуска требования в аттаче.
P.S. Было бы хорошо если кто-нибудь еще поставил Quartus+ModelSim, проект 128-ой для Quartus открыто выложен, разобраться с основами и запустить моделирование помогу. Потому что много нюансов, я могу где-то и ошибиться.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Это отсюда качать?
---------- Post added at 00:43 ---------- Previous post was at 00:37 ----------
Вот, как я понял, контроллер переходит в режим записи сразу же. Так как активен режим записи, то импульсы BCNT_CLK идут всегда и счетчик битов всегда работает. Но этот счетчик не сбрасывается, поэтому если он работал ранее в режиме чтения данных, то возможны такие варианты:
- запишется несколько битов из сдвигового регистра (то что было);
- в зависимости от числа счетчика может записаться сначала младший байт, затем старший и выставится требование;
- может записаться только старший байт и выставится требование, младший уже не запишется.
---------- Post added at 00:45 ---------- Previous post was at 00:43 ----------
При установленном сигнале WRP с дисковода, на дисковод в режиме записи не подается сигнал WRE, и соответственно он (дисковод) остается в режиме чтения.
Нет, надо WEB-edition, он бесплатный.
Спасибо! Правда вникать я наверное буду долго. А так надо бы прояснить все временные диаграммы сигналов STB_**, как контроллер переключается в режим чтения, ну и тд и тп.
Интереснее всего проверить, что происходит при поиске синхрозоны заголовка следующего сектора после записи блока данных предыдущего сектора.
Последовательность при этом следующая:
1. Прочитать регистр данных
2. Установить и сбросить GOR
3. Ждать требование
4. Записать 0xA1A1
5. Ждать флаг CRC
6. Записать 0x4E4E
7. Ждать требование
8. Прочитать регистр данных
В результате ВП1-128 переходит в такое состояние чтения, в котором ни одна из прошивок не проверяет требование. При этом ( например ) УКНЦ, для определения смены слова в регистре данных, вместо того, чтобы проверять требование - использует таймер УКНЦ.
Какой был бы смысл использовать таймер вместо бита требования, чтобы определить момент смены слова в регистре данных, если бы бит требования в режиме предварительного чтения выставлялся как обычно..
Последний раз редактировалось Patron; 28.12.2013 в 13:14.
Ох, Patron, прицепились вы к этому требованию и придумали какой-то режим предварительного чтения, которого нет. Повторюсь еще раз, что требование не проверяется потому, что неизвестно в каком режиме находится контроллер - поиск маркера (где оно не выставляется до тех пор, пока не будет найден) или режим чтения.
А про использование программируемого таймера в прошивке УКНЦ я Вам сейчас все расскажу. Периферийный процессор в УКНЦ обслуживает кроме дисковода еще эмулятор терминала, который принимает данные по каналу 0, использует сетевой таймер для скроллинга и мигания курсора. Чтобы все это хорошо работало надо чтобы возникали прерывания в нужный момент времени, т.е. нужна система более-менее реального времени. А 1801ВП1-128 как известно не имеет ни режима прерываний, ни ПДП, т.е. чтение данных с дискеты должно идти при полностью запрещенных прерываниях. А вот теперь представьте, что мы прочитали заголовок сектора, а номер сектора не тот, что нам надо. Или прочли маркер данных. Вот здесь, чтобы тупо не читать этот ненужный нам сектор до конца, программа управления дисководом в УКНЦ поступает очень умно. Она программирует таймер на время прохождения сектора, и отдает управление прерванной программе. Когда головка дисковода подходит к концу сектора, то вырабатывается прерывание от программируемого таймера, и программа чтения уже может искать следующий маркер. В КМД ДВК это не надо, и там, если нашли не тот маркер или заголовок, тупо пропускаются все данные.
Т.е. при чтении регистра данных в режиме записи - контроллер всегда переходит в тот режим чтения, который был до этого ( поиск маркера или обычное чтение ).
Когда Vslav проводил эксперимент с чтением регистра данных перед записью контрольной суммы - до начала эксперимента у ВП1-128 был режим поиска маркера, поэтому он и установился в момент чтения регистра данных. Если бы перед началом эксперимента уже был режим обычного чтения, то в ходе эксперимента - после чтения регистра данных установился бы режим обычного чтения.
Контроллер переходит в режим чтения, возможно и поиск маркера, в зависимости от состояния триггера PLL_RDY.
Если с дисковода поступают данные, то сбросится триггер PLL_RDY и контроллер перейдет в режим поиска маркера.
Если данных с дисковода не поступает, то установка и сброс GOR ничего не меняют.
Контроллер нашел маркер и перешел в режим чтения. В регистре считанных данных находится 0xA1A1. Начинается подсчет CRC. Триггер A1 сброшен.
А вот это тонкий момент. То что контроллер перейдет в режим записи это точно. Но зависит все от того, что было в счетчике битов. Так что записывать начнет наверное остаток сдвигового регистра, а потом скорее всего только один байт 0XA1. Но так как триггер A1 был сброшен, то CRC не начнет снова считаться, а продолжиться.
Начнет записываться CRC сосчитанная из того, что прочитали, и того, что записали. Но вот прочитали не только 0xA1A1, но и то, что за ним (несколько бит). Выработается сигнал FIN_STB и взведется триггер A1.
Запишется в регистр данных записи.
После установки требования уже будет записана CRC и один байт 0x4E, начинает писаться следующий 0x4E.
Прерывается запись 0x4E, контроллер спустя некоторое время переходит в режим чтения без поиска маркера, именно чтения. Невыровненные данные будут поступать в регистр данных с установкой требования. Так как триггер A1 взведен, то если произойдет чудо и попадется маркер не смещенный по фазе, то сброситься регистр CRC и начнется счет снова. Но это при условии, что регистр считываемых данных будут считывать при установке требования.
Перекачал и установил Quartus II Software (includes Nios II EDS) и ModelSim-Altera Edition (includes Starter Edition). Quartus требует еще установить устройства. Можно любое, поменьше, например MAX II, MAX V device support ? А то остальные очень сильно пожирают место на диске.
Если только для моделирования - то, наверное, лучше что-то из Циклонов 1/2/3. У MAX может просто ячеек не хватить. Для поведенческого моделирования выбор конкретного FPGA не важен - все временные параметры из модели берутся.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
