Цифровая археология: 1801 и все-все-все

Цитата:

---

Сообщение от Vslav

Да, идея неплохая. Будем приучать к ней программистов?

---

Если не нулевая версия прошивки в младшем байте будет иметь объективную возможность отличаться у разных экземпляров - это в общем случае конечно же будет более адекватно реальности, чем неизменное нулевое начальное значение.

- - - Добавлено - - -

Ещё один вопрос. Когда процессор осуществляет цикл DATO, что при этом происходит на линиях AD - сначала процессор выставляет адрес и этот адрес виден на шине вплоть до выставления данных записи, которые не снимаются вплоть до выставления адреса следующего за записью цикла или как-то ещё..

Судя по доступным осциллограммам циклов чтения, где ВМ1 держит адрес на шине "до упора" - от него вполне можно ожидать такого же поведения и при выставлении данных записи.

Есть какие-нибудь осциллограммы циклов записи в исполнении реального ВМ1 ?

Может такое быть, что когда осциллограммы снимаются на стенде с "голого" процессора, то отсутствие нагрузки на линиях AD позволяет им "запоминать" последнее значение, тогда как на реальной шине осциллограмма будет другой ?

Цитата:

---

Сообщение от Patron

Ещё один вопрос. Когда процессор осуществляет цикл DATO, что при этом происходит на линиях AD - сначала процессор выставляет адрес и этот адрес виден на шине вплоть до выставления данных записи, которые не снимаются вплоть до выставления адреса следующего за записью цикла или как-то ещё.

---

Картинка с циклами записи и чтения-модификации записи (.png 70КБ, после двоеточия между скобок): (http://s019.radikal.ru/i625/1511/01/13251f5ed795t.jpg)
Листинг кода:

Код:

---


    268        001576        012706        000710                entry:                mov        #$stack, SP                ;
    269        001602        005267        177102                                inc        $ticks                        ;
    270        001606        012767        001122        177304                        mov        #$rxbuf, $rxend                ;
    271        001614        012767        001122        177274                        mov        #$rxbuf, $rxbeg                ;
    272        001622        012767        000716        177064                        mov        #$txbuf, $txend                ;
    273        001630        012767        000716        177054                        mov        #$txbuf, $txbeg                ;
    274                                                                                        ;
    275        001636        012700        014001                                mov        #14001, R0                ;
    276        001642        004767        177564                                jsr        PC, outhex                ;
    277                                                                                        ;
    278        001646        012737        000100        177560                        mov        #100, @#RXCSR                ;
    279        001654        012737        000000        177564                        mov    #000, @#TXCSR                ;
    280        001662        005000                                        clr        R0                        ;
    281        001664        106400                                        mtps        R0                        ;

---

Цитата:

---

Сообщение от Patron

Может такое быть, что когда осциллограммы снимаются на стенде с "голого" процессора, то отсутствие нагрузки на линиях AD позволяет им "запоминать" последнее значение, тогда как при подключении к реальной шине осциллограмма будет другой ?

---

Один отсчет на картинке составляет 10 нс (частота дискретизации анализатора 100МГц, поэтому единицы наносекунд ловить не имеет смысла), частота процессора 5 МГц.
На шине собственно процессора установлены резисторы 2K2, подтягивающие на +3.3V (процессор вообще на вход получает высокое логическое +3.3V а не 5V, на всем модуле, на скорость это почти не влияет). Анализатор подключен к пинам ПЛИС изнутри, то есть, грубо говоря, к кабелю, который соединяет платы DE0 и модуля. Данные AD проходят на этот кабель от процессора через шинные формирователи типа АП6 (74LVC245), задержка там небольшая, 5нс примерно. Направление шинного формирователя определяется сигналом st_ena (добавил на новой картинке) с задержкой 10 нс. Когда это сигнал низкий - значение на AD формируется платой DE0, высокий - трансляция с шины процессора. Если выводы AD процессора в высокоимпедансном, то резисторы формируют высокий и анализатор видит 000000 (инвертирует значение у себя, для удобства). Остальные входные сигналы проходят от процессора на анализатор через MAX3064-7 с задержкой порядка 5-10нс. Выходные (например rply + меры по исключению конфликта) формируются DE0 и этой задержки нет.

PS Судя по картинке, при чтении процессор удерживает адрес еще 20-30нс после активации DIN, вполне соответствует постоянной времени линии с резистором 2К2 и 10-15пФ емкостью.

- - - Добавлено - - -

Вот я раньше приводил фотографию - пины ПЛС на плате DE0 выходят в итоге на кабель, анализатор захватывает значения с кабеля. Видны также шинные формирователи, буферная MAX3064 и куча резисторов возле пустого слота второго процессора - шина там общая.

http://s019.radikal.ru/i607/1308/c3/fac718ad88a3t.jpg

Осциллограммы с SignalTap стало получать достаточно просто, в пару кликов в Квартусе, надо будет еще быстренько модуль с ВМ2 запустить, тоже посмотреть чего там происходит.

Update: на кабеле тоже установлены резисторы на +3.3V, но уже 22К, так что ничего свободно не болтается. И да, это же картинка получена не с симулятора. Симулятор мог бы вычислить из модели и показать Z-состояние. А суровый челябинский анализатор может физически измерить и показать только логические уровни 0 или 1.

Цитата:

---

Сообщение от Vslav

Вот я раньше приводил фотографию - пины ПЛС на плате DE0 выходят в итоге на кабель, анализатор захватывает значения с кабеля. Видны также шинные формирователи, буферная MAX3064 и куча резисторов возле пустого слота второго процессора - шина там общая.

---

Очень хочется с настоящим ретро-подлинным ВМ2 увидеть снимок и анализ конечно, вопрос камушек ВМ2 какой предполагается пластик или керамика? Насколько живучесть старых процессоров позволит их использовать, не будет ли с этим лишних проблем, причём я все цело за "родные сердечки на платах" поэтому и вопрос такой задаю (извиняюсь если немного не научно прозвучало).

- - - Добавлено - - -

ВМ1 и ВМ2 по площади разные и не совместимы, то есть топология платы под ВМ2 будет другой и однопроцессорной? (скорее констатация чем вопрос).

Цитата:

---

Сообщение от Vslav

Судя по картинке, при чтении процессор удерживает адрес еще 20-30нс после активации DIN

---

Если округлить до целых тактов - картина такая:

1. Адрес снимается процессором на том же такте, на котором устанавливаются SYNC и DIN - в конце такта SYNC и DIN активны, на AD нули.

2. Данные записи выставляются на том же такте, что и DOUT.

3. Данные записи снимаются на следующем такте после снятия DOUT.

4. Сигнал WTBT в фазе адреса снимается на том же такте, на котором устанавливается SYNC.

5. SYNC снимается на следующем такте после снятия RPLY.

6. В цикле DATO между тактом установки SYNC и тактом установки DOUT проходит ещё один такт.

7. В цикле DATIO между тактом снятия RPLY и тактом установки DOUT проходит ещё один такт.


- - - Добавлено - - -

Цитата:

---

Сообщение от Vslav

Осциллограммы с SignalTap стало получать достаточно просто, в пару кликов в Квартусе.

---

Тогда есть смысл посмотреть ещё и на поведение сигнала WTBT при байтовой записи.

Цитата:

---

Сообщение от hobot

Очень хочется с настоящим ретро-подлинным ВМ2 увидеть снимок и анализ конечно, вопрос камушек ВМ2 какой предполагается пластик или керамика?

---

Пока есть только снимок :)

http://s017.radikal.ru/i413/1511/a8/15e317b2aaa2t.jpg

Цитата:

---

Сообщение от hobot

Насколько живучесть старых процессоров позволит их использовать, не будет ли с этим лишних проблем

---

1801ВМ1Г 89 года выпуска корректно отмолотил 12 часов на заводском тесте 401 на 7.2МГц, без всяких замечаний, 1801ВМ2 не должен быть хуже.

Цитата:

---

Сообщение от hobot

причём я все цело за "родные сердечки на платах" поэтому и вопрос такой задаю (извиняюсь если немного не научно прозвучало).

---

Еще приятно что получается сделать ПЛИС-реплику и переходник к реальному модулю в рамках одного интерфейса. То есть, в БК на ПЛИС достаточно заменить одну строчку и она будет работать на реальном процессоре вместо копии, и наоборот.

- - - Добавлено - - -

Цитата:

---

Сообщение от Patron

Тогда есть смысл посмотреть ещё и на поведение сигнала WTBT при байтовой записи.

---

Байтовая запись и байтовая чтение-модификация-запись: (http://s019.radikal.ru/i624/1511/df/842486211a8bt.jpg)
Подтверждение прерывания по приему от 065: (http://s017.radikal.ru/i429/1511/cc/7b2af6a18065t.jpg)

Цитата:

---

Сообщение от Vslav

Байтовая запись и байтовая чтение-модификация-запись

---

Получается, как и в модели - сигнал WTBT при записи байта устанавливается на предыдущем такте перед установкой DOUT, а снимается на следующем такте после снятия DOUT.

Очередная ревизия VM1CPP с учётом всех правок, сделанных ранее Patronом, и изменений новой ревизии модели 1.4с
Вложение 55056
Кроме того, были сделаны некоторые попытки дальнейшей оптимизации быстродействия для матриц, и изменён булев тип с BOOL на bool, чтобы компилятор более строго относился к операциям с булевыми переменными.
--
Уточнены алгоритмы eval_p и eval_n для vm1, архив во вложении обновлён.

Цитата:

---

Сообщение от gid

были сделаны некоторые попытки дальнейшей оптимизации

---

Быстродействие возросло в 3.5 раза - это круто.

Цитата:

---

Сообщение от gid

с учётом всех правок

---

Одна поправка осталась не учтённой - описание enum CPU_TYPE должно находиться в публичной части класса - с этой правкой модель без проблем компилируется и работает в составе адаптера МПИ :

Код:

---

class C1801VM1
{
        friend class CDebugger;
public:
        enum CPU_TYPE
        {
                CPU_VM1A,
                CPU_VM1G
        };

private:
        DWORD m_nDeviceID;

---

Главный глюк V-модели по-прежнему активен - если сигнал RPLY снимается между eval_p и eval_n - модель перестаёт реагировать на тактовую частоту :

Код:

---

#################
POWER - ON
#################

-------------------------------------------------
 C        B S D D W R B I I D D S I H E A D I S S
 L  AD  S Y I O T P S R A M M A N A V C C R L L
 C        Y N N U B L 7 Q K R G C I L N L L 3 1 2
-------------------------------------------------
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 1 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 1 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 1 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 1 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
-------------------------------------------------
 C        B S D D W R B I I D D S I H E A D I S S
 L  AD  S Y I O T P S R A M M A N A V C C R L L
 C        Y N N U B L 7 Q K R G C I L N L L 3 1 2
-------------------------------------------------
 0 177716 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0
 0 160005 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0
 0 160005 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0


  160000 [000340]      BR    160016

-------------------------------------------------
 C        B S D D W R B I I D D S I H E A D I S S
 L  AD  S Y I O T P S R A M M A N A V C C R L L
 C        Y N N U B L 7 Q K R G C I L N L L 3 1 2
-------------------------------------------------
 0 160000 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000406 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000406 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000406 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 ------------ и так до бесконечности ------------
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

---

Именно поэтому в коде tboard.cpp находится специальный костыль для выравнивания изменений RPLY :

Код:

---

void tboard::maincycle()
{
        bool b_rply_n  = m_pMPI->rply_n;
        m_pMPI->rply_n = bPrev_rply_n;

        m_pCPU->eval_n(m_nClk, m_pMPI); //отработаем передний фронт ТЧ


        m_pMPI->rply_n = ( m_pCPU->m_IOPins.pin_rply_n ? b_rply_n : false );


        m_pCPU->eval_p(m_nClk, m_pMPI); //отработаем задний фронт ТЧ

        bPrev_rply_n = m_pMPI->rply_n;

        m_pMemory->eval(m_pMPI);
        m_pIRPS->eval(m_pMPI);

        m_nClk++;
}

---

Если убрать костыль и не выравнивать изменения RPLY - модель зависнет :

Код:

---

void tboard::maincycle()
{
        m_pCPU->eval_n(m_nClk, m_pMPI); //отработаем передний фронт ТЧ

        m_pCPU->eval_p(m_nClk, m_pMPI); //отработаем задний фронт ТЧ

        m_pMemory->eval(m_pMPI);
        m_pIRPS->eval(m_pMPI);

        m_nClk++;
}

---

Не пора ли разобраться с причиной этого глюка - ни в одной из родных моделей на Verilog такого не происходит ( см. ЗДЕСЬ ).

Цитата:

---

Сообщение от Patron

описание enum CPU_TYPE должно находиться в публичной части класса

---

Забыл, сам-то я этот функционал не использую, он на будущее задан.

Цитата:

---

Сообщение от Patron

Не пора ли разобраться с причиной этого глюка

---

Подозреваю, что причиной глюка является механизм симуляции Z-состояний на МПИ, который я кое-как еле-еле слепил, он скорее всего работает не совсем корректно и только в некоторых частных случаях. Как правильно реализовать их, я так и не догадался, но без них модель вообще не работает. Поэтому, как разобраться с глюком, я не знаю.
Нужно отказаться от Z-состояний и шины МПИ и перейти на использование wishbone, но здесь я вообще не представляю, как сохранить точную потактовую симуляцию связки ВМ1+ВП1-037 на МПИ, поэтому пока даже не смотрю в эту сторону. Вот когда Vslav напишет модель, эмулирующую БК, тогда, после её изучения, может что-то можно будет сделать.

Цитата:

---

Сообщение от gid

Подозреваю, что причиной глюка является механизм симуляции Z-состояний на МПИ.

---

Сильно сомневаюсь.

Скрытый текст

...

Ведь этот механизм работает одинаково и в первой половине такта, и во второй, сигнал RPLY тоже в обоих случаях снимается совершенно одинаково, но в одном случае модель работает, а во втором виснет.

Поясню конкретнее, что имеется в виду.


Вариант 1 :

1. Первая половина такта. На входе модели RPLY в состоянии N - всё работает.

2. Вторая половина такта. На входе модели RPLY в состоянии Z - всё работает.

3. Первая половина такта. На входе модели RPLY в состоянии Z - всё работает.

4. Вторая половина такта. На входе модели RPLY в состоянии Z - всё работает.


Вариант 2 :

1. Первая половина такта. На входе модели RPLY в состоянии N - всё работает.

2. Вторая половина такта. На входе модели RPLY в состоянии N - всё работает.

3. Первая половина такта. На входе модели RPLY в состоянии Z - модель зависла.

4. Вторая половина такта. На входе модели RPLY в состоянии Z - модель продолжает висеть.



Зависшая модель продолжает реагировать на изменение DCLO :

Код:

---

-------------------------------------------------
 C        B S D D W R B I I D D S I H E A D I S S
 L  AD  S Y I O T P S R A M M A N A V C C R L L
 C        Y N N U B L 7 Q K R G C I L N L L 3 1 2
-------------------------------------------------
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0

---

[свернуть]

- - - Добавлено - - -

Возник вопрос по работе ВЕ-таймера.

В предыдущих версиях CPP-модели reg.tve_div = 0 выполняется при каждой установке сигнала INIT, а в 4-й версии CPP-модели reg.tve_div = 0 выполняется только при установке сигнала DCLO.

Это правильно ?