Полигон-2

ГОЛОСУЕМ ТОЛЬКО ПОСЛЕ ПРОЧТЕНИЯ и ОСМЫСЛЕНИЯ МАТЕРИАЛОВ ТЕМЫ!!!
Изначально рассматривалась шина PCI. Но поскольку ни одного сторонника она не нашла, а также по причине её сложности, приводящей к высокой сложности необходимых драйверов, которые в общем-то и некому будет писать, от неё отказались.

Затем поступило более реальное предложение реализовать последовательный интерфейс Olimex UEXT по частному стандарту, примеры значительного количества устройств под него можно глянуть тут.
Преимущества данного решения очевидны: малое число выводов для подключения, малое число занимаемых выводов у ПЛИС, простота драйверов, возможность разместить на плате сразу несколько таких интерфейсов для подключения разных устройств (а шина PCI влезет на плату mini-ITX только одна).

Не так давно случайно попалась ссылка на новоделы устройств под ISA, где также достаточно широкий ассортимент, глядя на который решили проработать и вариант шины ISA. В результате он тоже был отвергнут по причине высокой ресурсоемкости ног ПЛИС, необходимости доп. буферов (преобразование к 5В) и регистров.

Также обсуждалась возможность прилепить шину МПИ2 - т.е. разработать новый стандарт шины на основе существующей МПИ, сделав её более скоростной, потеряв при этом совместимость со старыми устройствами (либо лепить нетривиальный коммутатор шины на старый/новый стандарт).
Но вариант с шиной МПИ2 также был снят с серьезного рассмотрения, на основе следующих рассуждений:
1. Есть БК11М с шиной МПИ, под которую есть старые устройства и можно делать новые устройства.
2. Разрабатывается БК12, где будет та же МПИ, с которой смогут работать все устройства от БК11М (и елка там особо не понадобится - нагрузочная способность итак будет неплохая, достаточно просто разветвителя, но можно и елку).
3. Существуют готовые устройства под различные стандартизированные шины, которые можно было бы подключить к БК12, установив там такую шину. Назовем эту шину условно ШИНА-1.
4. Под ШИНУ-1 никто не мешает делать и свои устройства, если очень захочется. Данные устройства можно будет предлагать и в сообщества других платформ, где есть такая шина.
=========вдруг рождается идея о шине МПИ-2==========
5. Тогда вместо набора МПИ + ШИНА-1 в БК12 будет сложный набор ШИНА-1 + коммутируемая МПИ/МПИ2. Либо только коммутируемая МПИ/МПИ2.
6. Устройства под шину МПИ-2 не будут работать на БК11М.
7. Устройства под шину МПИ-2 не будут применимы ни на какой другой платформе.
8. Есть ли хоть один аргумент в защиту того, что шина МПИ-2 для БК12 чем-то привлекательнее, чем простая UEXT с готовыми устройствами?
9. Учитывая, что проработки уровня ГОСТов на шину МПИ-2 нет, существует она только на уровне идеи, готовых устройств для её тестирования нет - довольно странно браться такую шину в БК12. Т.е. ставить разработчику задание - "сделай примерно так, тестировать не надо". И что мы получим?
10. Шина МПИ-2 пожалуй могла бы иметь смысл в БК12 (не как коммутируемая, а как отдельная, в виде слота по типу ISA) в том случае, если найдется желающий полностью проработать и составить спецификацию данной шины, а также желающий (возможно другой кто-то) разработать под неё хотя бы одно не тривиальное устройство и совместно довести процесс отладки такой шины до конца.


Спустя еще какое-то время, после утомительных ночных обсуждений, наконец появилось понимание, что шина LPC (+еще описание LPC) будет наиболее разумным выбором для БК12: с одной стороны она программно совместима с ISA (и можно сделать относительно не сложный адаптер для ISA-устройств) и существуют чипсеты с поддержкой данной шины, а с другой стороны не требует большого числа контактов ПЛИС и не занимает на плате много места. Более того, в текущей конфигурации платы, обмен между двумя ПЛИС итак ведется по схожей с LPC шине, так что фактически изменения будут минимальны.

Из минусов - для неё не существует стандарта разъема, т.к. она является межчиповой (внутриплатной) и не рассчитывалась на подключение устройств через слоты, поэтому придется выбирать разъем, предположительно PCI-Express x1 (36pin) или SL-36.
На некоторых ноутбуках LPC-шина выведена на Mini PCI-Express разъём, хотя опять же, единого стандарта распиновки нет. Вот тут пример карты, одновременно поддерживающей интерфейсы mini-PCI/mini-PCI-Express/LPC.

Вторым, более существенным минусом, является необходимость реализации на VHDL модуля IP - Intellectual Property.

Локальным плюсом данной шины будет то, что возможна унификация разъема и распиновки данной шины между проектом БК12 и проектами уважаемого Vslav, что положит начало некому стандарту в ретро-проектах.

Касаемо замечаний, что шина не вписывается в концепцию развития БК0010 -> БК11М -> ДВК -> БК12, то добавлю, что БК12 изначально туда мало вписывается наличием на борту USB & Ethernet на процессоре PIC32MX, но в то же время ни наличие PIC32MX, ни наличие шины LPC никак не отменяет возможности запускать софт ДВК на БК12, другой вопрос в том, что отлаживать FPGA-реализацию режима полной совместимости с ДВК просто некому, в обязанности моего разработчика это не входит.

Сейчас идут жаркие споры в привате, не можем определиться, что ставить на плату в качестве разъема шины LPC: IDC, SL-36, PCI-Express (36pin), или еще чего ?

Разработчик настаивает, что слотовые - крайне ненадежны и имеет место безумный геморрой при изготовление макеток под такие слоты. Настаивает на использовании IDC-разъемов под шину, но при таком количестве IDC на плате меня от них уже воротит. И потом, массовые производители, видимо оценив с маркетинговой точки зрения и с точки зрения надежности, решили все-таки для промышленных массовых шин использовать слотовые разъемы, а не IDC и не DIN, не смотря на дороговизну золочения плат под слоты, более дорогие разъемы и необходимость качественной фрезеровки края текстолита под слот.

Опять же, большая часть даже не сильно массовых плат в коммерческих проектах стараются делать как можно симпатичнее визуально, Natami тому пример - начиная с правильной геометрии расположения каждого резистора, заканчивая полным отсутствием громоздких и неказистых IDC-2.54, а в качестве универсальных шин если не промышленные стандарты, то во всяком случае те же краевые слоты, что было и в ZX Evo использовано, и как-то же делают платы теперь под них.

Переговорил с Романон Чуниным (разработчик ZX Evo), он использует SL-62, никаких проблем ни с разработкой карт расширений, ни с их эксплуатацией или производством он припомнить не смог, сказал что использует никелирование вместо золочения и по цене это вполне демократично выходит.

Дополнительно возник вопрос - а нужно ли оставлять МПИ/УП на плате mini-ITX БК12 ? По идее они будут мало востребованными в таком формате платы/корпуса и по большому счету будут бессмысленно занимать выводы дополнительной ПЛИС, уродливо смотрясь на плате в виде разъемов IDC-50 (сейчас шаг 2.54, планирую уменьшить до 2.00). Логичнее было бы перенести их на плату расширения под будущую шину LPC, но можно и не переносить.

Не голосую, но можно вас об этом моменте спросить что-нибудь?

Voland написал:

[q]

Вторым, более существенным минусом, является необходимость реализации на VHDL модуля IP - Intellectual Property.

[/q]

Я проголосовал за PCI, кому надо - легко сделают мост с PCI на ISA, МПИ, МПИ2, VME, порты UEXTа, >тут список можно в бесконечность вести>, любую нужную шину.

P.S. а как для процессора PCI будет выглядеть уже продумывали? Прозрачно с расширением адреса через аналогичный UMAP механизм?

Voland написал:

[q]

Так в этом-то и проблема, сложнейшую 32-разрядную шину подцепить и запрограммировать для 16-разрядного ВМ1.

[/q]

С каких пор pci стала "сложнейшей"? Вопрос был про то, как вы продумали подставлять старшие 16 бит адреса всего лишь, и про то, как байты памяти БК будут отображены на pci, которая заточена под 32 бита. В имевшихся у меня двух разных адаптерах pci>->qbus (для СЦВМ БТ-25/55 и БТ-83), в окне со стороны pci, каждое полуслово пропускается, что будет неудобно. Потому спросил, как вы обошли работу с 32-разрядными словами со стороны 16-битового процессора.

Voland написал:

[q]

Никто не знает, как это грамотно сделать, никто не знает, какие устройства потом туда цеплять,

[/q]

А какие устройства нужно цеплять вообще на системную шину, если есть USB у вас в системе?

Voland написал:

[q]

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

[/q]

Т.е. вы столько времени держали анонсированным для БК12 в качестве внешней шины стандарт PCI, но при этом не задумывались о реализации? И откуда опять бред про "сложнейшие драйвера", тот же мост pci>->qbus в десяток ассемблерных команд инициализируется, с обработкой прерываний ничуть не сложнее.

MM написал:

[q]

Ладно, коли не хватает ног в плюшке - надо тогда сделать нормальную МПИ по стандарту ДВК

[/q]

Если не PCI, то действительно МПИ пусть будет.

MM написал:

[q]

Следует предусмотреть выбор перемычками длительность выставления адреса на МПИ до сигнала SYNC - 100, 200, 300 нс - т.к.БК11 надежно работает только от 200 нс, а если учитывать потери в шлейфе - от 300 нс.

[/q]

Лучше сигнал ответа по адресу и таймеры: если никто не выставляет SSYNC - держим адрес долго, после чего по дефолтному времени срабатывает SYNC, а если ранее кто-то выставил SSYNC, то еще немного держим до допустимого минимума, при котором ВПшка на той же шине гарантированно не заглюкает.

MM написал:

[q]

Также следует предусмотреть выбор длительности удержания адреса на МПИ после сигнала SYNC - 50, 100, 150 нс - тоже для совместимости с кривыми устройствамипо типу матери БК11.

[/q]

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

MM написал:

[q]

можно даже предусмотреть сигнал ТА - но он вроде как в ДВК не применяется.

[/q]

Сигнал полезный, т.к. у ВМ3 нет сигнала BSY, потому если начался цикл чтения, выставляется TA вместе с адресом при неактивном SYNC, а если начался цикл записи, то выставляется WTBT вместе с адресом до SYNC, имея информацию о начале цикла, можно много полезного успеть сделать...

Voland написал:

[q]

И сложна НЕ АППАРАТНО, а программно, никто даже примерно не может представить, как это программировать на БК.

[/q]

Устройства разные есть, например, упоминавшиеся мною мосты требуют задания нескольких параметров и далее функционируют прозрачно, как линейный массив памяти. От драйвера pci драйвер устройства получит список занятых(или незанятых) областей и адреса в конфигурационном пространстве, где его адаптер сидит, после чего слазиет туда и разрешит работу своего адаптера в незанятых адресах с соответствующей длиной области, о чем уведомит драйвер шины. Также сажается драйвер прерывания, которому по цепочке будет передано управление в случае возникновения требования прерывания от pci, в задачу которого входит проверить его ли устройство дернуло прерывание и передать обратно результат проверки.

Voland написал:

[q]

Никто не хочет браться за проработку конкретики - конкретных регистров, конкретных адресов, я уже не говорю о том, что там нужны драйвера как на уровне ОС, так и на уровне устройства, которые тоже некому программировать.

[/q]

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

Voland написал:

[q]

Могу пригласить сюда одного из этих людей, чтобы он прояснил все сложности PCI в БК.

[/q]

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

Voland написал:

[q]

Не понял вопроса, Вы имеете ввиду, что если есть USB, то можно вообще больше никаких шин не ставить?

[/q]

Почти так. Вопрос был в буквальном смысле: какие из внешних устройств БК требуют прямой адресации пользовательской программы, какие устройства нельзя вывесить на программный уровень системных макросов/EMT-запросов при планирующейся/анонсированной производительности процессора?

Voland написал:

[q]

что PCI я туда вкорячил из-за личных симпатий и кроме меня она там никому не нужна.

[/q]

Я вас там сразу поддержал с концепцией PMC-карточек для классического(ретро) варианта материнки.

Voland написал:

[q]

Сможете на себя взять этот вопрос и отвечать за него? Тогда будем делать PCI, если полностью проработаете и опишите концепцию PCI в архитектуре БК и будете теоретически курировать этот вопрос в дальнейшем.

[/q]

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

Voland написал:

[q]

что проблем там куча, ведь не за пару дней работы оплата нужна..

[/q]

Обычно бывает, как выше описали уже на "черном форуме", когда начинаешь делать - всплывает куча нюансов... Про сложность шины я писал в аппаратном смысле, хотя и там надо увесистый блок регистров иметь. И от менеджера ресурса, ака драйвера шины, никуда не уйти.

Voland написал:

[q]

в проработке программной модели PCI, пока даже без самих драйверов, просто составить типа документа-спецификации, как именно низкоуровневому программисту надо будет общаться с PCI внутри БК в двух режимах - ВМ2/ВМ3.

[/q]

Не лучше ли это не закрыто обсуждать, а вынести на форум? Разницы не должно быть между ВМ1/2/3/5 - нужно окно и вторичный диспетчер памяти, например, как делалось в плате с ВМ3 на VME16 (24 бита на адрес).

Voland написал:

[q]

Ради интереса - во сколько оцениваете такую работу?

[/q]

Не оцениваю пока, т.к. нет как раз требований конкретных. Позвонил сотруднику с прежней работы, который один из вышеупомянутых мостов с PCI на МПИ делал - тот рекомендовал отказаться. :D

Потому как на окончание разработки БК0100-01 по-прежнему не хватает ок. 1500Е.
Примерные спецификации БК0100-01 :
1.Размер - в корпус классической БК0011М.
2.ЦПУ - 1801ВМ3А-6 мгц ( доп. зам. на 1836ВМ3-16 ) и 1801ВМ1А-5 мгц
3.Размер прямо адресуемой СОЗУ - 2 ( 4 ) Мбайт.
4.Размер Электродиска - 8 Мбайт.
5.Клава - ПС/2 - аппаратно совместимая с 1801ВП1-014 ( через доп. контроллер )
6.ПЗУ - 1801РЕ2-324, 325, 326/330. Видимо, будет и 2х556РТ7 - но это опция.
7.Батарейки - 2 шт. АА - для СОЗУ. ( не менее 2 лет - 1 компл .)
8.Видеодисплей - На базе 1801ВП1-037 с 1-такт ЦПУ ожиданием ( отдельный контроллер на СОЗУ )
9.Внутренняя МПИ - по типу ДВК ( с многочисленными ИС КР531АП2 )
10.Внутренний символьный ( накладной на видеовыход БК ) терминал с портами 177560 и сопром 1801ВМ3А - для реализации контроллера по типу КЦГД от ДВК.
11.Порты USB1.1 - 2 шт, IDE PIO ( совместимый со всеми предыдущими версиями аппаратно ), 1801ВП1-128, RS-232/ИРПС/МИДИ.
12.Режим совместимости как с оригинальной БК11М, так и с ДВК-4 ( пойдут мониторы ХМ, FB и т.п. без модификации ядра. )
Пока отлажены большинство контроллеров, дело за тиражом 6-ти слойки - практически и есть указанная сумма.
*
П.С. Пока только ведутся вялые переговоры о написании дров к USB - контроллеру и т.п. работы.