Какую шину на Ваш взгляд следует реализовать в БК0012 ? (Опрос с целью выявления общественного мнения по вопросу выбора универсальный шины для карт расширения в БК12. Рассмотрены и обсуждаются все нюансы ...)

[Voland]

Опрос с целью выявления общественного мнения по вопросу выбора универсальный шины для карт расширения в БК12. Рассмотрены и обсуждаются все нюансы возможных или невозможных вариантов.

ГОЛОСУЕМ ТОЛЬКО ПОСЛЕ ПРОЧТЕНИЯ и ОСМЫСЛЕНИЯ МАТЕРИАЛОВ ТЕМЫ!!!
Изначально рассматривалась шина 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, но можно и не переносить.

[gtnhtyrj]

ISA или лучше EISA ( IMHO ) . А почему собственно отвергли ? Выводы ПЛИС поможет съэкономить пара ~ тройка 1533ир31 или это тоже религиозно неприемлемо ? Вообще то чем больше разных шин будет, тем лучше. Вот в стародавние времена делали и VLB и MCA и EISA и NuBus и ту же PCI .
Из них осталось сами знаете, что.
Но могло бы быть и по другому.
И самыми "долгожителями" оказались в любом случае те платы, на которых было две ~ три разных шины.( у меня две такие "многошинные" есть, в работоспособном виде причём )
Хотя в данном случае речь, разумеется идёт не о массовом продукте, а о единичном - ну несколько десятков изделий в лучшем случае - ориентированном изключительно на адвентистов ( предпочитателей ) БК-шки, так что действительно надо просто провести опрос всех потенциальных пользователей - можно даже по почте или в лс задать вопрос каждому - всего то несколько десятков раз "кликнуть" мышой..

[wrenchrox]

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

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

[MM]

Я проголосовал за ИСА - это единственная возможность воспользоваться внешними устройствами от ИБМ ЭВМ.
И простые платы проще всего на ИСА делать - сопоставимо по простоте с МПИ.

[Anonymous1]

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

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

[Voland]

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

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

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

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

Я проголосовал за ИСА - это единственная возможность воспользоваться внешними устройствами от ИБМ ЭВМ.

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

ISA или лучше EISA ( IMHO ) . А почему собственно отвергли ? Выводы ПЛИС поможет съэкономить пара ~ тройка 1533ир31 или это тоже религиозно неприемлемо ? Вообще то чем больше разных шин будет, тем лучше. Вот в стародавние времена делали и VLB и MCA и EISA и NuBus и ту же PCI .
Из них осталось сами знаете, что.
Но могло бы быть и по другому.
И самыми "долгожителями" оказались в любом случае те платы, на которых было две ~ три разных шины.

Это всё теоретические рассуждения, верные для продукта массового или даже всемирного производства. На практике мы наталкиваемся на то, что под БК12, которая едва ли ли разойдется тиражом 50шт, никакую из шин программировать некому, писать дрова под каждое конкретное устройство некому, прорабатывать архитектуру программиста этих шин в составе архитектуры pdp-11 - некому, либо предложенные варианты не устраивают моего разработчика, от отметает их как слишком непродуманные и сырые.
И возникает закономерный вопрос - нафига уродовать такой шиной полплаты, занимая дефицитные ноги ПЛИС, если вряд ли кто-то реально будет ею пользоваться? Проще поставить LPC, которая много выводов не займет, а в сравнении с ISA хуже только тем, что под неё нет готовых карт.
Но в то же время для ISA непонятно, даже если кто-то где-то на свалке отроет какую-то карту, запрограммирует под неё драйвера, где другим искать такую же карту, чтобы воспользоваться те ми же драйверами?

Ну и Вы же понимаете, поставить много разных параллельных 16/32разрядных шин на плату формата mini-ITX невозможно физически.

[Anonymous1]

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

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

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

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

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

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

[MM]

Ладно, коли не хватает ног в плюшке - надо тогда сделать нормальную МПИ по стандарту ДВК - но с желтыми колодками под НР1-3 330/680 ом ( 330 - к +5в, 680 - общий ), по умолчанию подтянуть ее на резисторы 1 ком типа НР1-4-9М и поставить на выходе эти самые КР531АП2 ( цена в Москве от 4 до 10 руб, в зависимости от продавца ).
Следует предусмотреть выбор перемычками длительность выставления адреса на МПИ до сигнала SYNC - 100, 200, 300 нс - т.к.
БК11 надежно работает только от 200 нс, а если учитывать потери в шлейфе - от 300 нс. Также следует предусмотреть выбор длительности удержания адреса на МПИ после сигнала SYNC - 50, 100, 150 нс - тоже для совместимости с кривыми устройствами
по типу матери БК11.
Общественность спрашивает - почему именно АП2 - потому что они весьма мощные ( не менее 60 ма в электр. 0 в. ) и имеют открытый коллектор - т.е. есть возможность применять их в системах даже с 2-вольт уровнями. Более того, они дешевы и имеют исполнение как с 2.5 мм шагом, так и милитарисское с 1.25 шагом ( цена таких на Украине - около 40-50 руб ).
АП2 имеют отличное быстродействие - по этикетке - 20 нс при нагрузке 50 пф. ( Для применения в удлинителе МПИ следует рассматривать нагрузку в 300 пф - это около 50 нс. задержки в кабеле и АП2 ).
*
Далее - очень интересно реализовать адаптер МПИ-ИСА премерно по тем параметрам, что я приводил в наброске ТО на форуме БК10.орг - по-возможности, так, что бы его можно было прикрутить в корпус АТХ как расширение главной платы БК12.
Насчет коннекторов МПИ по типу гребенки - следует изначально предусмотреть коаксиальность в кабеле - т.е. каждый 2-й вывод - общий, и шаг - 2.54 мм - для применения импортных шлейфов. Рекомендую развести 1х40 и 1х50 гребенки - т.к. у МПИ порядочно ног, особенно с учетом адресов А16-А21.
Примерный список ног МПИ - АД0-А21 ( 22 ноги ), SYNC-DIN-DOUT-WTBT-RPLY-INIT-BS7 - ( 7 ног ), VIRQ-IAKO-DMR-SACK-DMGO ( 5 ног ),
ACLO-DCLO-HLT-HLTM-EVNT ( 5 ног ), можно даже предусмотреть сигнал ТА - но он вроде как в ДВК не применяется. Итого - 40 ног, а учитывая, что все они предусматривают частоты до 20 мгц и выше ( т.к. частота синтетического процессора - ок. 50 мгц ) - коаксиальность строго необходима. Если использовать расширенный МПИ ( т.е. фактически МПИ-2 тов. Patron ) - то необходимы сигналы SSYNC ( 1 нога ) и сигналы, специфичные для БК11 - WR177716, RE177716, E177600, IRQ370 - еще 4 ножки.
Итого выходит 45 ног - т.е. гребенка на 40 и гребенка на 50 ног - все коаксиальное, не требует изготовления пользователем шлейфов - подойдут покупные, и можно прямо цеплять кординку от ДВК - без платы М-ЭВМ, разумеется.
*
Насчет адаптера МПИ-ПЦИ32/33 - вот насчет этих самых 33 мгц есть большие сомнения, а в общем дело возможное, особенно если кто-нибуть возмется его спроектировать. О вопросе софта под это дело - скромно умолчим.

[Anonymous1]

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

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

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

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

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

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

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

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

[Voland]

С каких пор pci стала "сложнейшей"? Вопрос был про то, как вы продумали подставлять старшие 16 бит адреса всего лишь, и про то, как байты памяти БК будут отображены на pci, которая заточена под 32 бита.

Мне сложно судить о сложности, так глубоко в этом не разбираюсь, я просто ориентируюсь на мнение людей, которые занимаются коммерческим проектированием современных устройств и они говорят мне, что реализация ПОЛНОЦЕННОГО PCI (т.е. с рабочим Master-режимом, когда устройство само обмен инициировать может) - очень сложна в сопряжении с БК. И сложна НЕ АППАРАТНО, а программно, никто даже примерно не может представить, как это программировать на БК. Никто не хочет браться за проработку конкретики - конкретных регистров, конкретных адресов, я уже не говорю о том, что там нужны драйвера как на уровне ОС, так и на уровне устройства, которые тоже некому программировать.

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

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

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

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

Держали т.к. не задумывались о программной реализации, а не об аппаратной. Разработчик и сейчас говорит - "аппаратно не проблема сделать, я лишь предупреждаю о последствиях, а именно о том, что не найдется потом реальных людей для её использования из-за сложности программирования".
Одно время на общеизвестном черном форуме даже были высказывания, что PCI я туда вкорячил из-за личных симпатий и кроме меня она там никому не нужна. Ну и на мои попытки выяснить, есть ли желающие как-то её использовать, или помочь с концепцией, были примерно такие же ответы.

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

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

[Anonymous1]

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

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

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

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

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

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

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

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

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

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

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

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