AVR

Добрый день! Готов проект печатной платы бытового исполнения для PCI-Express x4, пока что бытового. Планарные размеры все идеально выдержаны, как раз чтобы погрешности производства всё не погубили. Толщина должна быть, насколько я понял из статей и прочих источников, 0.062 дюйма, это 1.575 мм. У Резонита есть опция 1.5 или 2.0 мм. Если задать толщину фольгирования 35 мкм, то из 1.5 оно не станет 1.57 (т.е. 1500+35+35), фольга входит в стек, его толщину т.е. Погрешность производства 1.5+/-0.3 мм! Огромная погрешность. Какова же тогда должна быть толщина платы чтобы при всех этих погрешностях ее не пришлось вбивать в разъем молотком или густо лудить оловом??? Один экземпляр еще допустимо пропустить через такой цирк, но при некоторых партиях уже недопустимо...

Спасибо, теперь процесс предельно понятен. Всё оказывается просто, я плохой "искун"

Вернулся к данной проблеме, уже полез за отдельным ActiveHDL, и тут обнаружил что в версии для Windows есть встроенный ActiveHDL Lattice Edition. Лицензия на Versa ECP3 есть. Получается, версии Windows и Linux не обладают равным набором возможностей, плохо. Попытки разобраться как воткнуть поддержку Lattice в Modelsim не привели меня к успеху, интернет всё же молчит на эту тему.

Прошу прощения что влезаю в разговор дяденек Какой локальный генератор стоит? Какова необходимость сидеть на локальном геныче?

Почитайте даташит на soft ip, у меня есть подозрения что для ПЛИС, в которых есть GX вариации, не увидели смысла добавлять версию soft ip, хотя "хотение внешнего PHY" вполне реальная возможность. У Cyclone 4 GX может не быть hard pci ip но ведь есть трансиверы, но поддерживается ли soft ip для обычного Cyclone 4? Смотрим Table 1–4. Device Family Support - везде G* (GX, GZ, GT). Сомневаюсь что интеловское PCI-e IP поддерживает не G* версии, Other device families No support

Очень жду ПЛИС от Миландра!!! Как первый шаг на длинном пути.

Смотрим, думаем. Почему бы нет.

Просто удалось установить факт НЕсоответствия. Кинулись сверять с evaluation версией симуляции ядра от Altera - видим фигу, как в 1-lane так и в 4-lane конфигурации. Сначала я думал что не хватает уровня интеллекта у меня, потом не удалось найти соответствие и коллеге. Просто тупо нет референса, хоть один проклятый пакет с нормальным заголовком, всё бы сразу стало ясно. Подозреваю заговор разработчиков стандарта, они специально не выложили то, что в других стандартах обязательно выкладывается для 100%-й однозначности. Винить я могу сколько угодно долго, но задачу надо решить. У других я смотрю всё без проблем работает на раз два. Я исхожу из того что не может быть такого, что ядро от огромной корпорации, выпущеное во множестве ревизий, быть так напрочь нерабочим и несоответствующим стандарту. Еще есть мысль, что имеющийся в доступе стандарт не соответствует! Но это вряд ли, тоже отбрасываю. Стоимость не узнавали, или я не помню, что-то в районе нескольких тысяч дойлеров. У меня уже есть Raspberry Pi 3 и к нему идет сенсор и он работает. Вот я и хочу подать ему на вход свой поток с ПЛИС. Но с сенсора я не могу снять данные. Как это сделать? На какой частоте оно работает? Подозреваю с такой, которая мне недоступна, уверен там максимальная фиксированная для любого разрешения, хотя для минимального разрешения и хватило бы всего 160 мегабит!

Добрый день всем! Есть PG260 MIPI CSI-2 TX Transmitter Subsystem 2.0. К нему же идет PG202 MIPI D-PHY v4.0 которое бесплатно. Вот как бы мне попробовать в симуляторе эту связку? На первый компонент требуется лицензия. Я готов запросить лицензию от имени предприятия. Но могу ли я пока одним глазком посмотреть как это работает? Подскажите в личку если что ;) Запрашивали лицензионную IP для альтеры но мои симуляции доказывают что по какой-то причине битстрим этого ядра идет полная туфта, в это сложно поверить, но мы с коллегой не видим в этом потоке ничего чтобы совпадало со стандартом! Хотим посмотреть что извергнет из себя IP ядро от Xilinx аналогичного назначения. Кстати, D-PHY симулится, запускается, но выдает пустой результат, ему нужно еще сделать полноценный тестбенч с клоками резетами данными и управляющими сигналами, это один из вариантов. Помогите, кто разобрался с MIPI CSI-2 D-PHY, сжальтесь надо мной, намекните как расколоть этот стандарт, поделитесь битстримом... Не могу получить нормальный пример, совпадающий со стандартом. Хотя сам стандарт до дыр прочитал, сделал свою реализацию, но потом понял почему она не соответствует. Вот ищу теперь с чем бы мне сравнить...

Регистрацию восстановил, а ссылка не работает. Кто-нибудь знает, куда они спрятали эту книгу? Нужна самая последняя версия...

На правах моего дилетантского предположения, для оптики не используется CDR? Быть может там уже и не требуется так жестко следовать целевой частоте, хотя буферы не бесконечны и большую разницу не потянут.

Погонял я эту реализацию из этого файла. Понял как мне надо байты переставить. С моей реализацией видимо сходится - уже хорошо. Однако как бы я не изворачивался, переворачивал байты биты, порядок, как бы не возвращал порядок бит ECC - я всё еще не могу получить нормальное ECC для заголовков, я вообще заголовков корректных не вижу, хотя структура данных регулярная и старт-последовательность корректная. Это меня пугает. Не понимаю на что теперь опереться. Битовая последовательность корректно начинается, байты на передачу совпадает с тем что скушал мой парсер из симуляции. Я в тупике. Где бы еще референс потоки взять? Альтеровская документация на их ядро тупо ничего полезного не сообщает.

Спасибо, попробую сравнить это с моей реализацией. Хотя у себя я пробовал биты в разных направлениях, но я склонен к таким ошибкам, подобные задачи сопоставления битов и байтов даются мне крайне тяжело если нет референса, только усидчивость спасает...

Насколько производительно такое типовое решение? Или ТСу не надо быстро? Я не увидел "подскажите способ медленного TCP/IP" :)

Прошу помощи! Просимулил IP ядро MIPI CSI-2 от альтеры. Линии high speed поймал в файл. Анализирую скриптом на Python. Так начинается поток: 1110000000000000000000000000000000000000000000000000000000000000000000111010111100000100000000100000011000000001000001010000001100000111000000001000010010000010100001101000000110000101100000111000011110000000010001000100001001000110 Если найти синхробайт и перевести это в массив байт, выходит вот что: hdr(32)= 01111000001000000001000000110000 data(5164) orig: 1E 04 08 0C 10 14 18 1C 20 24 28 2C 30 34 38 3C 40 44 48 4C data(5164) swap: 78 20 10 30 08 28 18 38 04 24 14 34 0C 2C 1C 3C 02 22 12 32 Тут у меня swap это байты с перевернутым ходом бит (0x10 и 0x08 очевидный пример). Почему я уверен что это правильные байты? Хоть и IP ядро зашифровано по самые помидоры, но единственное что там открыто это байты на передачу, там есть тестовая реализация передающей части. Их я и увидел в симуляторе, и... они именно такие, какие извлекает мой скрипт. В чем состоит моя проблема? Я не могу посчитать ECC, не могу понять где тут заголовок. И вроде стандарт четко всё описывает. Причем у меня на Python есть ECC как по 24 битам так и по 64 битам. Правильно считает синдром, умеет корректировать ошибку, детектировать две ошибки. Корректность реализации ECC я установил из примера в стандарте. Но к сожалению, в стандарте не вижу нормального тестового вектора. Такой вектор есть для подсчета CRC16 - тут у меня всё сходится, считается верно. Но от ECC я уже в панике, работа завязла. И ни в каких проектах с гитхаба, будь то TX/RX, не могу увидеть что и как они считают для ECC. Что можно предпринять, что еще попробовать? Что-то в каком-то режиме может запустить?