[EDConfident 0]

Добрый день!

Наша компания ищет разработчика или группу разработчиков для доработки программно-аппаратного комплекса.

Краткое ТЗ:

У нас есть программно-аппаратный комплекс. Работа над проектом построена таким образом, что внутри компании, силами штатных специалистов, мы занимаемся лишь программной составляющей проекта (программный код для архитектуры х86). А вот всё что связано с "железом" (схемотехника, код конфигурации FPGA) - делал по договору подрядчик. Наш проект — это плата расширения для ПК, поэтому особенно важен вопрос совместимости с разными компьютерами. И, некоторое время назад, мы столкнулись с проблемой, что наша плата несовместима с рядом новых систем – а именно со всеми, которые основаны на процессорах AMD Ryzen и Intel Сascade Lake для слота FCLGA3647. Мы уверены, что проблема не в нашей программной части, т.к. наш код даже не вычитывается из PCI Option ROM. "Аппаратный" подрядчик же - "разводит руками", утверждая, что ничего с этим сделать не может и у них всё правильно. Тем не менее проблема есть и это критично для нас. Но у нас в штате нет специалистов, которые разбираются в "железе" и FPGA. Поэтому ищем другого подрядчика, который сможет решить вопрос с совместимостью.
Наш программный комплекс имеет аппаратную составляющую в виде 3х плат-носителей, которые различаются форм-факторами: есть PCIe, mini-PCI, М.2. c ключами AE. Схемотехнически они очень близки, проблема с совместимостью проявляется идентично. Все платы основаны на FPGA Intel Cyclone IV GX15 EP4CGX15BF14C6N. Для «заливки» кода конфигурации предусмотрен разъём JTAG. Вся конструкторская документация на платы – принципиальная схема, BOM и т.д. имеется. Так же есть код конфигурации FPGA (КК) для этой платы, как в виде готового jic-файла, так и в виде исходных текстов для Quartus на VHDL.

 

Соответственно, проблема связана либо со схемотехникой, либо с КК, либо с тем и другим.

Поэтому от исполнителя требуется:

1)      Выяснить в какой составляющей комплекса содержится ошибка, приводящая к несовместимости с AMD Ryzen и Intel Сascade Lake для слота FCLGA3647.

2)      Если проблема с КК – требуется доработать КК для устранения проблемы.

3)      Если проблема со схемотехникой – найти решение, как это можно исправить.

Естественно, для нас более предпочтительным был бы вариант, чтобы исправление проблемы осуществлялось обновлением КК, т.к. уже выпущена большая партия плат. Так же, более-менее приемлемым вариантом было бы, если нашёлся способ «отремонтировать»  уже имеющиеся платы, например, перепаяв какие-то отдельные компоненты. Ну и в крайнем случае – допускается переразводка печатных оснований.

Территориально находимся в Санкт-Петербурге.

Ждем предложения по срокам и стоимости.

 

Контакты:

[email protected] Станислав Вихров

[email protected] Евгений Дмитриев

 

 

[gerber 7]

4 часа назад, EDConfident сказал:

Мы уверены, что проблема не в нашей программной части, т.к. наш код даже не вычитывается из PCI Option ROM.

А как вы определяете сей факт, если у вас нет в штате "аппаратчиков"? Определить это можно, только подключившись к FPGA "чипскопом" (или как там у Альтеры...)

Тут 2 варианта:

1) код вычитывается, но ему просто не передается управление, смотреть в сторону UEFI и цифровой подписи содержимого Boot ROM плат расширения,

2) код не вычитывается. Тут, видимо, вряд ли что-то можно сделать, просто на данной платформе функция PCI Boot ROM Extension урезана за ненадобностью.

Вообще говоря, это анахронизм x86 платформы, идущий со времен DOS-а, когда код, спрятанный в BIOS Extension, позволял упростить драйвера сетевых/видео карт. Сейчас это вряд ли кому нужно, драйвера в ОС подхватывают сложное железо и без таких заморочек.

[Baza 24]

Девайс ID  корректно получен в консорциуме PCI, или слеплен от балды?
вангую, что дело будет только в этом.

[gerber 7]

1 час назад, Baza сказал:

Девайс ID  корректно получен в консорциуме PCI, или слеплен от балды?
вангую, что дело будет только в этом.

Наверное, Vendor ID ?

Вряд ли дело в этом, хранить в BIOS весь перечень вендоров? А обновлять его как?

Если что и может влиять - это класс PCI устройства, я видел, что некоторые мат. платы не работают с BIOS Extension, если устройство произвольного класса. Точно работают, к примеру, сетевые контроллеры.

[EDConfident 0]

20 часов назад, gerber сказал:

А как вы определяете сей факт, если у вас нет в штате "аппаратчиков"? Определить это можно, только подключившись к FPGA "чипскопом" (или как там у Альтеры...)

если точнее - вычитываются первые 4 байта opt-roma, о остальные байты- 0xFF. Понять это можно несколькими способами - например, посмотреть в соответствующей области ОЗУ ПЭВМ. Ну или через отладочную прошивку системной платы ПЭВМ - посмотреть в логе, что было вычитано из платы расширения PCIe.

 

20 часов назад, gerber сказал:

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

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

 

4 часа назад, Baza сказал:

вангую, что дело будет только в этом.

это вряд ли. проблема идентично проявляется на самых разных системных платах от разных производителей, если там установлен райзен. более того, если AMD Ryzen на тех же системных платах заменить, например, на AMD A8 - то всё начинает работать корректно. Так же класс PCI-устройства тут тоже вряд ли влияет.

 

Повторюсь проблема в вычитке PCI-Opt-ROM. Биос системной платы корректно вычитывает первые 4 байта, а вместо остальных - вычитывается 0xFF. Так как первые 2 байта содержать magic - он читается правильно, BIOS системной платы думает что opt-rom корректные, начинает его обрабатывать - и, в результате, виснет.

[Baza 24]

19 hours ago, EDConfident said:

Повторюсь проблема в вычитке PCI-Opt-ROM. Биос системной платы корректно вычитывает первые 4 байта, а вместо остальных - вычитывается 0xFF. Так как первые 2 байта содержать magic - он читается правильно, BIOS системной платы думает что opt-rom корректные, начинает его обрабатывать - и, в результате, виснет.

Тогда только смотреть различия в регистрах камней
может райзен уже не поддерживает низкоуровневые 16 и 32 битные инструкции.

попробуйте написать Роману  https://github.com/applerom

 

[novartis 0]

On 1/27/2021 at 5:02 PM, EDConfident said:

если точнее - вычитываются первые 4 байта opt-roma, о остальные байты- 0xFF. Понять это можно несколькими способами - например, посмотреть в соответствующей области ОЗУ ПЭВМ. Ну или через отладочную прошивку системной платы ПЭВМ - посмотреть в логе, что было вычитано из платы расширения PCIe.

Я в 2013 году разбирался с Bar Expansion 

Если Bar Expansion у Pcie устройства разрешен, то bios прочитает первые 4 байта этого бара, если там  0x55aa (вот сейчас уже не помню, может и 0xaa55), bios поймёт, что у вас действительно option rom, и bios его прочитает весь. Если же в памяти будут другие начальные байты, то bios все вычитывать не будет.

Нужно убедиться, что процесс чтения Бара происходит корректно. Это вопрос к вашим разработчикам проекта для ПЛИС, пусть добавят signal tap и покажут, какие запросы приходят по pcie (должен прийти запрос на чтение Bar Expansion) и как они отвечают на эти запросы. "посмотреть в соответствующей области ОЗУ ПЭВМ" - это не то, это уже результат, а как пришли к этому результату можно понять только через signal tap.

Вполне возможно, что старые процессоры читают по 32 бита за раз, а новые процессоры по 256 бит, а на такой вариант запроса у ваших разработчиков проекта для ПЛИС не корректно формируется ответ с данными.

Если тут все будет в порядке, то надо читать документацию на AMD Ryzen и Intel Сascade Lake, смотреть как там устроена работа с option rom.