"Открытый" последовательный интерфейс, Найти готовый или рискнуть и взяться за разработку? Опции

[Alex Zorg]

Существует много стандартный последовательных интерфесов от SPI до Fibre Channel. Но почему-то не получается ничего подобрать. Вот требования:

1) Реализуемость на ПЛИС FPGA (с ценой до 20$) для скоростей порядка 10MBit/s
2) Произвольный выбор реализации уровня "проводов" от банального TTL, до LVDS, потенциальный код с двумя уровнями.
3) Хорошее (большое) отношение пропускной способности к требуемой полосе пропускания канала. Возможность применения гальванической развязки через трансформатор (т.е. код без постоянной составляющей). К примеру, соблазнительно выглядит кодирование 4B/5B, 8B/9B или 8B/10B.
4) Произвольный выбор скорости от 1MBit/s до потолка, например, 100MBit/s.
5) "Дальность" (как и скорость) зависит от реализации.
6) Ассинхронный. Чтобы была возможность использовать "один провод" и при большой дальности между абонентами не было критичности к задержке между шиной данных и синронизацией.
7) Передача пачками байтов (или слов), контроль ошибок (исправление необязательно).
8) Соединение точка-точка (как RS232), возможность расширения, например, соединение нескольких устройств по кольцу или через коммутатор (Switch).
9) Наращиваемость.

Зачем это нужно? Хотелось бы иметь собсвенные наработки на VHDL/Verilog и применять их где только возможно в силу универсальности.

Вот некоторая критика сущесвующих протоколов:

RS-232 и его братья. Плюсы: простота, любая скорость. Минусы: нельзя вырезать постоянную составлющую ибо допустимо 9 одинаковых бит подряд и даже больше в паузах, эквивалентое кодирование 8B/10B было бы эффективнее, к примеру.

ARINC-429 (используется в авионике, кодирование с возвратом к нулю). Плюсы: используется в области моей деятельности, прост. Минусы: трехуровневое кодирование (а хочется двухуровневое). широкий спектр, нельзя вырезать постоянную составляющую, низкие скорости (менее 100KBit/s).

MIL-1553 (т.н. Манчестер-2, так же "военный" и авиационный интерфейс). Плюсы: нет постоянной составляющей, это стандарт ГОСТ. Минусы: не самое эффективное кодирование, потому широкий спектр, не очень большая скорость (<1MBit/s), "тяжелость" стандартной обвязки.

Fibre Channel. Плюсы: Очень быстрый, то, что надо. Минусы: Реализуем только с помощью специализированных дорогих ИМС (на ПЛИС, полагаю, сложно), слишком сложный и узкоспециализированный, для простого межплатного обмена не подойдет.

PCI-Express. Минусы: слишком сложный, только для межплатного взаимодейсвия, на ПЛИС не реализуешь.

SPI. Минусы: синхронный, соединить две деревни по витой паре типа "полевка" невозможно.

Если ничего подобного не подвернется, возникла идея о реализации приемопередатчика типа 4B/5B или 8B/9B на VHDL/Verilog для ПЛИС. Если получится что-либо "достойное" результат можно "выложить" в сети и получится что-то типа "Open Serial Bus".... $-)

Не критикуйте за "Пионерство".

[yornik]

Мне кажется, уже начальная установка "Зачем это нужно? Хотелось бы иметь собсвенные наработки на VHDL/Verilog и применять их где только возможно в силу универсальности" неверна. Как и "2) Произвольный выбор реализации уровня "проводов" от банального TTL, до LVDS" - на диапазоне скоростей "от 1MBit/s до <...> 100MBit/s" особо выбирать не надо, при желании можно одним 3В КМОПом все делать, тут все же играют роль другие вещи, а не скорость. Но, поскольку Вы просили не критиковать за "Пионерство", то как мне видится подход к выбору последовательного интерфейса (на проводах или оптоволокне, в радио - другая насыщенность математикой):

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

2) Если скорость до 10Гбит/сек - вопросы решены, и с вариантами. Варианты "пляшут" от требований к физическому уровню. Даже если есть какая-то узкая "протокольная" специфика, все равно "мелочь пузатая" вроде IBM/Motorola/Philips/Intel предпочитает сбиваться "в мелкие стайки" и годами жевать спецификации "супер-пупер" интерфейса-протокола, прежде чем выплюнуть что-нить типа USB (вместо, условно, RS232 и EPP), FlexRay (вместо - опять же условно - CAN) или CameraLink (вместо аналогового видео). Выбор готового варианта, имхо, дешевле, чем изобрЕтение своего. И по сути всем начхать на "с точки зрения математики реализации оптимального приемника" - по сути, изначально цифровой сигнал так прост в работе и устойчив из-за того, что избыточен по полосе. Главное - работает и деньги приносит Хотя, скорее всего, скоро начнут вводить какой-нить график по ужесточению EMC, как по выхлопам авто (двигатели Евро2 в Росси делают, на Евро3 бабки на лицензии нашли, а на Евро4 пока еще нефти не напродавали) - чтобы заставлять покупать лицензии на новые ноу-хау...

3) Если нужна скорость от 10Гбит и выше - должно хватать денег на любые изыскания " с точки зрения математики реализации оптимального приемника ", но 100Гбит/с это уже не совсем вопрос для инженерного форума. Изобретите "универсальный приемопередатчик на VHDL/Verilog для ПЛИС за 20$, пригодный в диапазоне от 10 до 1000 ГИГАбит/сек" - и будет вам щасце однозначно (купил Xilinx фирму с RocketIO - и ваше решение с удовольствием купит )

Еще, на скоростях <100Мбит гальваноразвязку можно легко сделать ADuM-ами и при наличии постоянки. Да и неасинхронных последовательных интерфейсов, имхо, совсем немного "живых".

Все же не удержался от критики, похоже