PDP-11 на FPGA

[Hunta]

где же её взять MicroPDP-11/93

На моей памяти, пару раз она мелькала на ебэе, если только я не путаю с какой нибудь 11/8x или даже с 11/7x, так что если упереться - я думаю - можно Но боюсь, что цена будет... Так что пока не стремлюсь к обладанию раритетом Хотя и не откажусь

Видно что-то с временными параметрами неладно..

Да это как бы понятно. И даже можно найти и попробовать подкрутить, но... цель пока - Ethernet Я теперь DE-10 будут использовать для проверок времянок - если на мультиконтроллере запускается, а на DE-10 нет - значит, надо выяснять Ну или скажем - на 50-ти работает, а на 100 - нет Но периодически буду пробовать и 200 - а фдрукк?

[Alex]

Надо что-то с отладкой думать...

[Hunta]

Надо что-то с отладкой думать...

Если ты про 200 МГц - это пока не цель. Вот когда Ethernet запуститься - тогда Может быть

[Alex]

Тяжело объять необъятное ... Всё не успеваешь
Остаётся выбрать Главное.

[Hunta]

Тяжело объять необъятное ... Всё не успеваешь

Оптимизация - это такое дело, которое невозможно закончить - её можно только прекратить

Учитывая, что максимальный результат, который я достиг в прошлый раз - 50 МГц, а на 100.... хм... не помню уже, но судя по этому - или не запускалось, или запустилось считанные разы, причём почти наверняка до загрузки дело не дошло (пробегусь как-нибудь по сообщениям, если что - допишу).. По любому - сейчас очень устойчиво работает, в том числе и под RT-11 - это очень неплохой результат Так что - да, в уме буду помнить, но целенаправленно пока не буду заниматься Ну и буду перодически тыркать - а фдрук

[andrews]

Второе но - я пока не видел ни одного эмулятора, который бы эмулировал оригинал на 100 процентов. И не увижу. Потому что все эмуляторы работают ПОСЛЕДОВАТЕЛЬНО (да, можно нарисовать многопоточный, но тут с параллельностью мы упрёмся в количество процессоров на целевой системе и то, что целевых систем РЕАЛЬНОГО времени - то есть с предсказуемым временем отклика - сейчас КРАЙНЕ мало, да и писать под них - ещё та задачка...А поэтому сэмулировать ПАРАЛЛЕЛЬНУЮ работу составляющих даже процессор элементов - неа, не получится.
- - - Добавлено - - -

верно замечено всё зависит от того на чём, как и подо что писать. В каждом ПК параллельные ядра с ресурсами+видеокарта в которой параллелизм еще выше. А вот операционки максимально эффективно управляющей всеми этими ресурсами нет, не говоря уже о средствах разработки. Деталей этих архитектур никому кроме Microsoft изготовители железа не откроют. С другой стороны программирование для FPGA более затратный процесс, мало приспособленный для обычных программистов и от этого более трудоемкий. Так что и здесь нет дружественных высокоуровневых средств разработки. Железо FPGA кстати тоже не вечно. Через 20-30 лет об интеловских циклонах вряд ли кто-то вспомнит. Поэтому любую архитектуру, которую есть желание "увековечить" надо хранить в независимом от конкретного железа декларативном коде.

[Advertiser]

[Hunta]

В каждом ПК параллельные ядра с ресурсами+видеокарта в которой параллелизм еще выше.

Проблема только в том, что в FPGA - сигналы, СОХРАНИТЬ состояние которых - надо приложить усилия.
А на ПК и видео картах - это вполне себе устойчивые данные, ИЗМЕНИТЬ которые - надо приложить усилия.
Ну и по количеству элементов, которые могут выполнить работу - FPGA уделывают и видеокарты и процы.
Что умеют лучше процессорные и видео ядра - выполнять разные виды работ, в FPGA LE умеют меньше, но кто мешает из них собрать и что то более умное? Благо их хренова туча.

мало приспособленный для обычных программистов

Фигня. Просто люди, особенно с возрастом, с трудом меняют привычный образ мышления, плюс всё хуже и хуже начинают учиться новому. Ну и привычная лень. Главное - захотеть.

Мне в этом плане повезло - и область интересов трижды до FPGA менял и учился новому постоянно - как в школу пошёл.
Так что въехать - чего тут и как - было не сложно, сложно было начать, а потом привычно покатилось.

Так что и здесь нет дружественных высокоуровневых средств разработки.

Ага, конечно.

Через 20-30 лет об интеловских циклонах вряд ли кто-то вспомнит.

Циклон - это конкретная реализация идей FPGA. Закроют это семейство - будет что то своё. Но пока экономически будет оправданным выпуск - будут выпускать.

надо хранить в независимом от конкретного железа декларативном коде.

Вы для начала побольше почитайте про VHDL, Verilog - а потом уже рассуждайте по поводу зависимости.

[andrews]

Проблема только в том, что в FPGA - сигналы

а не данные! Чтобы сделать сигналы виртуальными и отображающимися по желанию разработчика без внешних приборов, на FPGA нужно допилить очень многое. На ПК нет хорошего инструментария для описания моделей, а то что есть - сильно дорого и не сильно высокого уровня. И в этот инструментарий прямо нельзя интегрировать те же vhdl-модельки.

Ну и привычная лень.

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

vhdl- не сильно высокоуровневый инструмент, я его изучал. Вы не можете включить в проект некий чип простым кодом, и внести в него изменения, не залезая в код реализации, как поступают с объектами в ООП. Я не могу вносить изменения в блок регистров, добавлять способы адресации, менять структуру кэшей, конвеера и т.п. Сам vhdl об этом ничего не знает, так как он более низкоуровневый.

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

[Hunta]

Чтобы сделать сигналы виртуальными и отображающимися по желанию разработчика без внешних приборов, на FPGA нужно допилить очень многое.

Да ладно! А мой сигналтап то и не знает... Надо его расстроить..

и не сильно высокого уровня

А ничё, что железо - оно само как бы не сильно высокого уровня?

как поступают с объектами в ООП.

Да не дай бог туда ещё ООП приплетут - и получим мы в железе гигабайты LE и будут у нас железки, как современные Windows и Linux. Да ну нах.

Я не могу вносить изменения в блок регистров, добавлять способы адресации, менять структуру кэшей, конвеера и т.п.

А реализовать - ну ни как.

Сам vhdl об этом ничего не знает, так как он более низкоуровневый.

Вот жешь блин, как же это создатели не догадались добавить команду - "А ну быро всё за меня сделать!"

Вы же грузите в железо код, который оно воспринимает.

Аха, конечно. Я в железо гружу результат синтеза, который получен из VHDL, который как бы не зависит от железки

[SuperMax]

а не данные! Чтобы сделать сигналы виртуальными и отображающимися по желанию разработчика без внешних приборов, на FPGA нужно допилить очень многое. На ПК нет хорошего инструментария для описания моделей, а то что есть - сильно дорого и не сильно высокого уровня. И в этот инструментарий прямо нельзя интегрировать те же vhdl-модельки.

скорее надо перестроить мозги с последовательного "программирования" на "параллельное" и тогда многое становится проще.
ну и надо понимать саму схемотехнику, а не тупо делать какие-то операции не задумываясь как они воплотятся в железе (как часто делают обычные программисты )

а это двигатель прогресса.

скорее убийца ресурсов
ибо развитие стратегии "из амна и палок но зато быстро" привело к тому, что банальный браузер гипертекста жрет ГИГАБАЙТЫ оперативки.

vhdl- не сильно высокоуровневый инструмент, я его изучал. Вы не можете включить в проект некий чип простым кодом, и внести в него изменения, не залезая в код реализации, как поступают с объектами в ООП.

см выше, идеология ООП вредна, хоть и удобна.
грубо говоря ООП убивает производительность на порядок - см хороший пример https://lionet.livejournal.com/118853.html