Существует много стандартный последовательных интерфесов от 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".... $-)

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

HDLC?
http://www.interfacebus.com/Design_HDLC.html
Есть во многих контроллерах и процах. Корки есть на opencores.org

В качестве модуляции выбрать MFM
http://www.pcguide.com/ref/hdd/geom/dataMFM-c.html

Ну или вообще RLL
http://www.pcguide.com/ref/hdd/geom/dataRLL-c.html
но у него с помехоустойивостью хуже.

C чего начинается разработка: от гайки М3 или от задачи?
Для чего нужен интерфейс?
Если устройство не за 0,5 долл, то оно как устройство должно интегрироваться с другими устройствами.
Отсюда задача - сделать интерфейс такой, чтобы потом не пришлось делать преобразователи с одного интерфейса на другой. Проектов приемопередатчиков типа 4B/5B или 8B/9B уже хватает.
Если не жалко 3 долл, то поставьте Ethernet трансивер как драйвер линии. и передавайте пакеты без головной боли. А МАС в вертекс-4 уже есть готовый.
Удачи!

Evgeny_CD, спасибо, почитаем.

iosifk, сейчас у меня нет конкретной задачи, просто хочется немного заняться "радиолюбительством", повторюсь, но задача чисто на "интерес". Практически можно было бы объеденить блоки еще не сущесвующей в природе РЛС. Приемопередатчик найти готовый было бы интересно, но где? opencores.org? Был бы признателен, если бы кто-ть дал открытый Verilog/VHDL проект. Vertex-4 это круто, полагаю для упращенного варианта 4B/5B хватит ПЛИС за 10$.

Кстати, брать чисто (Fast) Ethernet не очень удобно. Нет гарантии доставки пакетов, если включено несколько устройсв (все "кричат" как хотят и могут мешать друг-другу). Кроме того для Eth лучше использовать специальный чип для MAC уровня, а не заниматься радиолюбительством с ПЛИС.

P.S. Evgeny_CD, кажется FM/MFM/RLL это хорошие протоколы для передачи по радиоканалу, для записи на магнитный носитель, но низкочастотная часть полосы пропускания используется плохо, т.е. если бы сделали Fast Ethernet на MFM, но полоса пропускания витой пары 5 кат. 0-130 MHz (примерно) использовалась больше в области высоких частот, а хочется эффективно использовать и низкие частоты, табу только на постоянную составляющую, т.е. я склоняюсь к 4B/5B и т. п... Насчет спектров конечно я не уверен на 100%, это лишь домыслы.

Начните вот хотя бы с XAPP250 - Clock and Data Recovery With Coded Data Streams
http://www.xilinx.com/xlnx/xweb/xil_public...7&iLanguageID=1

Что касается МАС, то мой проект, который Вы называете "радиолюбительством" уже года 4 работает.
Краткое его описание у меня на сайте в статье о Fast Eth.
Удачи!

нiosifk, нет... радиолюбительством я называю разработку "своих" протоколов...
Почитаю... спасибо.

Инфа по кодированию

http://ariu.berdyansk.net/~andy/basic_lan_...06_06.shtml.htm
NRZI Метод кодирования 4B/5B

http://www.rhyshaden.com/encoding.htm
5B/6B много всего

http://dfe3300.karelia.ru/koi/net/nets08.htm#pmipmd
Функции уровня PMI. Квартетная канальная шифрация, кодирование 5B/6B. Функции уровня PMD. Очень медленно открывается.

http://www.frontiernet.net/~prof_tcarr/4B-5B/index.html
4B/5B Encoding Simulation written by Teresa Carrigan. JAVA аплет, который наглядно показывает работу 4B/5B и NRZI.

A random 16-bit pattern is generated. This is the data that we want to transmit on our 100Mbps network. Starting from the left-most bit, each set of 4 bits is replaced by its 5-bit 4B/5B equivalent. The 4B/5B encoding of the data is then transmitted over the network using NRZI transmission encoding. For each bit sent, both a synchronization clock pulse and the transmission waveform are displayed.

http://asics.chuckbenz.com/
open source 8b/10b encoder/decoder

Тогда уж лучше выбрать 5b/6b - он симметричный (кстати, полного его описания не нашел - есть у кого?).

А вообще все это очень быстро скатится к Витерби декодеру и прочей суровой теории цировых систем связи.

"open source 8b10b encoder/decoder на Verilog" - я так понял это лишь комбинаторная схема без триггеров (дишефратор) 8b->10b и 10b->8b по схеме IBM запатентованной в 1983 году в США. Интересно, это значит что все кто использует 8B/10B "должны" теперь IBM? По крайней мере в США? Или если использовать другую схему кодирования/декодирования, то IBM тут ни при чем? Интересно было бы найти оптимальную схему не просто дешифратора, а приемника и передатчика. Пока не нашел, если не найду еще через "пол года", займусь разработкой "jast for fun".

В Интернете действительно много разрозненный статей на тему кодирования типа 4B/5B которое используется для Fast Ethernet и 8B/10B которое во всех скоростный интерфейсах типа Fibre Channet, 1GBit Ethernet, PCI-Express... Но вот готовые исходники на HDL (даже много) попадаются только для UART (RS-232).

Полагаю 5B/6B не очень удобен, ведь все-равно нужно передавать байты, слова, и прочее кратное 8 бит. А вот 8B/9B выглядит неплохо, если посмотреть на биноминальное распределение числа единиц и нулей (если будет интерес позже поясню, чего насчитал), к тому же вроде бы нет технологии, которая уже запатентована.

Задача кодирования и оптимального приема достаточно сложная, потому и такой интерес.

Вот примерно то, что хотелось бы (подобно HDLC):
1) Передача идет пакетами, начало пакета начинается со слова, которое не используется для кодирования данных и имеет хорошие автокорреляционные свойства, например код Баркер-7, 11 или 13.
2) При использовании выбранного кодирования можно реализовать фазовую автоподсройку для снятия ограничения на длину пакета при заданной погрешности расхождения генераторов приемника и передатчика.
3) прилепить контрольную сумму в конец.
4) Паузы можно чем-то забить для контроля линии
5) Как адресовать несколько устройств без коллизий, это второй вопрос
ну и т.д. и т.п.. и все такое...

Неужели нет реализаций чего-дибо подобного с отрытым кодом или какой-либо стандарт, который хорошо описан с точки зрения математики реализации оптимального приемника? Конечно на первый взгляд фазовая подстройка и вычисления корреляции в ПЛИС за 10$ не влезет, но это и обсуждается...

Сообщение отредактировал Alex Zorg - Jan 23 2006, 15:53

Alex Zorg
Я уже приводил пример приёмопередатчика TAXIChip в соседней ветке.
Всё до безобразия просто :
1.Кодировка байтная - две тетрады 4b/5b (или 8b/10b – типа HotLink);
Для TAXIChip можно «вырезать» 8 кодов для передачи управляющей информации:
Межкадровый флаг, внутрикадровый флаг + флаги управления потоком(опционально).
2.Вся последовательность данных разбивается на кадры, кадры на ячейки – кадр может быть произвольного размера, ячейка определяется ёмкость приёмопредатчиков и качеством линий. Формат ячейки : (SYNC or FLAG):(ADDR):(DATA). Для point-to-point ADDR можно выкинуть.
3.Кодировка 4b/5b имеет хорошие свойства восстановления битовой синхронизации.
4.Введение контрольной суммы определяется вероятностью появления ошибки в канале. Обычно для внутри и межплатного обмена достаточно 8-ми бит CRC.
5.Паузы внутри и между кадрами заполняются микроячейками: (SYNC or FLAG).
6.В FPGA за $10 «влезает» 4-х канальный подобный приёмопередатчик и ещё место остаётся. Тактовая – до 100 МГц, приведённая битовая скорость – до 25 Мбод на канал.

Мне кажется, уже начальная установка "Зачем это нужно? Хотелось бы иметь собсвенные наработки на 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-ами и при наличии постоянки. Да и неасинхронных последовательных интерфейсов, имхо, совсем немного "живых".

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

ASN
На соседнюю ветку уже попал, как-то """странно""" у меня работает поиск в форуме, не получается найти то, что 100% уже есть.
Все звучит логично, именно такой интерфейс и хочется иметь. Пункт 6 звучит оптимистично. Как только появится время, место того чтобы "собирать марки", хочу попробовать собрать (смоделировать на ПЭВМ) приемопередатчик канального уровня, почитывая умные варезные отсканированные книжки в DjVu (совесть конечно будит мучить). Что-то уже слышал про "Шину TAXI", видимо это про TAXIchip. Еще, чтоб было все "по взрослому", можно добавить скремблер, чтоб спектр был поровнее, полагаю, это не очень дорого с точки зрения ресурсов ПЛИС. Вдруг что-то получится, тогда это будет Open Sorce проект.

yornik
Речь дейсвтивельно о интерфейсе "для проводов". Желательно работать с ограниченнием полосы пропускания, но не в ущерб простоты (точнее дешивизны в 10$ за ресурс ПЛИС). Отслеживать адаптивно переотражения в канале связи, использовать многопозиционную молуляцию, восстанавливать ошибки, и т.д. и т.п. (т.е. разрабатывать "модем" и все такое) я пока не собираюсь. Хоть и у меня радиолюбителшьские замашки, буду конечно искать что-то похожее (типа TAXI) на то, что интересно получить, и если оно есть, то с одной стороны можно что-то "передрать", а если нет, то напротив, почувствовать себя "пионером". Насчет ЭМС - забавно. Вот и мне почему-то взбрело, что Манчестер-2 слишком фонит (жирный спектр), лучше 4B/5B...8B/10B и еще и скремблер. Может мы друг друга не поняли, но я говорю о 10...100 Mbit/s, т.е. десятки мегагерц, а не гигагерц! Конечно понятно, что для 100 MBit/s, в приемнике асинхронного сигнала, ""по теореме Кательникова"" тактовая будет в 2...4 раза больше, а как рекомендуется в 8...12. Насколько в дещовых FPLD'шках можно на кристале иметь 1ГГц, я не знаю, тоже вопрос. Для 1Гбит/сек и выше, конечно, FPLD за 10$ не пойдет, на кристале ведь нужно иметь уже 10ГГц! А как Вы пишите 10...100Гбит/сек, так таких даже специализированный ИМС еще нет, насколько я понимаю, процессоры еще 10ГГц еще не перепрыгнули, а тем более 100! Кто-то из нас очепятолся. Выше 1ГБит/с сегодня если и возможно, так это засчет раскидывания потока по нескольким паралельным последовательным каналам, ну, например PCI-Express. На критику буду нарываться до тех пор, пока кто-нибудь не подкинет подробное описание то, что захотелось "придумать".

Сообщение отредактировал Alex Zorg - Jan 24 2006, 16:27