AVR

Действительно получилось, плата работает! Не могу скрыть своей радости. Теперь я чувствую себя настоящим мужчиной - работает самодельная PCI-E плата! Несмотря на x2, пары правильно развернулись, и оно определилось в режиме x1 в райзер карте. Если получится потом проверить x2, надеюсь x2 тоже удастся запустить и будет работать. Это следующий шаг.

Это серьезно так? т.е. если прошивка польется по JTAG, первая ПЛИС схватит последний бит своей конфигурации и дальше просто пропустит наружу и следующий же бит польется в следующую ПЛИС?

Укажите init=/your/program в аргументах командной строки ядра Linux и ничего кроме Вашей программы в этой системе работать не будет. В таком случае, не ясно что будет с драйверами, будут ли они работать те что полагаются на udev и многое другое. Но so-библиотеки возможно еще будут работать. Можно просто написать свой init-скрипт и всё же загружать, но только то что надо А вообще, рекомендую Open Embedded или Buildroot - тогда лишнего не будет, если это для реального продакшена. А если так, чтобы память не жралась ГУИшкой, то первый же ответ на askubuntu годится

Оказывается, у альтеровских PCI-E, как и у Xilinx, есть штатный пример. У альтеры он называется chaining_dma. Его более чем достаточно для проверки работоспособности платы. Не знал о его существовании, вот он как раз использует указанные мной VID/PID и число дорог. Я пробовал это всё на Quartus 13.1, т.е. на довольно старом. Удалось развести на x2 для аналогичной ПЛИС как у меня! Всё отлично разводится, задействует x2! Я этот демо проект просто укажу свои пины и надеюсь получится.

Выставил ПЛИС пожирнее чтобы было 4 транса, настроил x4, есть tx_out0..3 - вроде всё нормально должно быть. Но снова ошибки разного рода, которые говорят что не у меня проблема, а что-то с ядром не так. Буду пробовать последний quartus 19.1, там еще есть поддержка cyclone 4 gx

Для x2 оно и не позволяет задать 62.5 МГц, только 125. Примеры есть на x8 и x4, на x2 не нахожу. Оригинальный код работал на x1. Попробовал пересоздать заново - результат тот же, только x1. Буду еще пробовать комбинации soft-ip, потому что сейчас hard ip. Еще в документации заметил, типа если используется x1 то второй трансивер может работать с любой другой скоростью независимо.

Спасибо, это была действительно хорошая идея, но квартус пошел ругаться так: Error (176201): Can't place pin tx_out1 with differential I/O standard -- no legal location available on target device Error (169001): Pin N4 does not support I/O standard 1.5-V PCML for tx_out1 Error (169001): Pin M6 does not support I/O standard 1.5-V PCML for tx_out1 Error (169001): Pin N8 does not support I/O standard 1.5-V PCML for tx_out1 Самое важное что оно просто не желает использовать второй канал, еще на этапе Analysys & Synthesis, т.е. оно сразу говорит "мне хватит одного": Total GXB Receiver Channel PCS 1 / 2 ( 50 % ) Total GXB Receiver Channel PMA 1 / 2 ( 50 % ) Total GXB Transmitter Channel PCS 1 / 2 ( 50 % ) Total GXB Transmitter Channel PMA 1 / 2 ( 50 % ) Пробовал вовсе убрать указание типа стандарта на выводах, проект собрался, но RTL говорит что ничего нет:

Да вроде в одном банке сидит: На с чет не могут от одного refclk сомневаюсь, вроде как допустима группа из как минимум двух в то и более, у Xilinx читал доки на трансиверы, у Alteraintel тоже наверняка так же гибко.

А я некоторое время использовал Cocotb фреймворк - он для тестирования FPGA. Надо сказать это очень классный инструмент с кучей библиотек что есть в питоне, но он оказался неразвитым в полной мере. Не хватало штатного режима чтобы запустить 8 симуляторов на 8 ядрах и объединять результаты через некий пул - пришлось велосипедировать. Симуляторы не параллелятся, так что при куче ядер и памяти до дури - это было важно. Правда было немного трудновато с возвращаемыми значениями (например, функция чтения RAM), как назло документация не раскрывала этого важного ньюанса - решил через raise. Но это всё было туго и неочевидно, не то что ждешь от развитого инструмента. На момент применения, была не полная поддержка Python 3, и под Windows было очень тяжело скомпилировать, не помню даже как удалось. Это нужно было для коллег, а на Linux вообще легко было. В общем, судя по коммитам Cocotb продолжает развиваться, и я надеюсь однажды там будет всё гораздо проще - подключил указал и полетело. Два года назад было туговато... Но мне понравился Cocotb очень, это восхитительно иметь такую связь Python и HDL-симулятора. Жаль разворачивать у коллег очень тяжело, пока что это инструмент для себя не для работы в коллективе - вот это огромный минус, увы.

ПЛИС какого производителя применяется? Почему бы не использовать из готовых библиотек? Я работал с sin/cos Lattice Xilinx - везде всё нормально работает. Не советую работать без симулятора, потому что вычисление тригонометрии это кандидат номер 1 на проверку в симуляторе.

Добрый день! Пытаюсь перетащить старый проект Cyclone IV GX x1 на самодельную плату с x2. Проверил при помощи diff что действительно у ядра добавилась вторая пара (и неиспользуемые мной PIPE линии). Компилирую с одной парой - всё верно. Добавляю вторую пару - пишет ошибку что нельзя использовать пины трансивера для обычных IO а в статистике компиляции пишет что задействован лишь один трансивер, хотя в ep4cgx15 ровно два трансивера и есть, и статистика копиляции показывает что трансиверов задействовано 1/2. Не очень понятная ошибка, можно ли ее как-то преодолеть? Также можно пока смириться с режимом x1, но у меня пары перепутаны. По стандарту оно допускает порядок 1-0 вместо 0-1, но будет ли это работать если оставить лишь пару 1? Сомневаюсь что подхватит. Важно уточнить что по распиновке в ep4cgx15.pdf у меня всё в настройках правильно и плата разведена верно, что TX то у меня TX, а что RX то RX, всё как надо указано на P-половинку диффпары трансивера.

Рад что нашлось решение по фен-шую, но я имел ввиду что заменить массив и сам generate на что-то иное. Наверное чем дальше, тем неудобнее будет мое решение.

Раз эксперты говорят нельзя, попробую предложить еще одно решение, возможно о котором не часто вспоминают. Если возможности языка не позволяют что-то, почему бы это не генерировать... скриптом?! Ну языке Python или кому что ближе и приятнее. Вот я на Python никогда не стесняюсь что-то вспомогательное генерить рядом с верилогом.

Предлагаете вручную выпилить работу с I2C? В принципе это вариант. Попробую его обязательно и отпишусь. Lattice поставляет платы для подключения Crosslink к Raspberry конкретно и именно такая плата переходник у меня сейчас. Там ноль информации про I2C, документация молчит. Завтра первый рабочий день, буду пытать техподдержку, явная же проблема тут в наличии Меня просто смущает что MIPI CSI-2 D-PHY это интерфейс, неразрывно связанный с CCI(I2C), но ядро Lattice Crosslink вообще не считает нужным выбросить наружу SDA/SCL. Мне в личные сообщения человек подсказал что на Jetson TX2 от Crosslink принималось вообще без I2C, видимо у Raspberry это явно не так, о чем писали мне выше

./raspiraw -f 25 -w 640 -h 480 Using i2C device /dev/i2c-0 RaspiRaw: Probing sensor ov5647 on addr 36 RaspiRaw: Probing sensor imx219 on addr 10 RaspiRaw: Probing sensor adv7282 on addr 21 RaspiRaw: No sensor found. Aborting Но шлейф подключен, кадры генерируются (смотрю на светодиодах), клоки на плате есть. Оно хочет I2C. С штатной камерой Raspberry работает нормально. Тут что угодно может быть не так