Jump to content

    

Mad_kvmg

Свой
  • Content Count

    409
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Mad_kvmg

  • Rank
    Mad_max
  • Birthday 05/07/1985

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

3751 profile views
  1. Задавать глупые вопросы не страшно, не уметь находить нужную информацию вот это не очень. Если новичок, то нет ни чего лучше чем пройти по уже готовому примеру. Возьмите TRD (Targeted Reference Design) для Zynq и пройдите его по шагам и большинство вопросов вида куда нажать отпадут сами собой. А уже с какими то деталями возвращайтесь сюда, тут вам эксперты подскажут.
  2. Да вообще прекрасное объявление Откуда-то считывают минуты и еще CUAD какой-то придумали.
  3. ТС, я готов участвовать в стартапе писать в Гите на KiCAD.
  4. В долгосрочной перспективе, если вы собираетесь оставаться в мире программируемой логики, лучше изучать HLS. HLS compliler? Тут во многом зависит от того на какой платформе вы работаете, если Xilinx, то добро пожаловать в дивный мир Vitis HLS У Intel свой тулчейн, так же есть вендер независимые инструменты, такие как MG, ах да siemens, Catapult HLS
  5. Я так понимаю, что вы запустили xbtest gt mac test case и убедились, что сеть работает. Бинарник естественно взять за основу не получиться, но CU для этого теста построен на стандартном Ethernet Subsystem IP а его уже можно взять за основу. Что такое стандартная схема? Что вы называете шелл, xbtest? Прочитайте тут overview стандартная подсистема это PCIe Endpoint, DMA, AXI инфраструктура и планировщик. Дальше вы делаете свои kernels используя ресурсы FPGA. Если это родной пример (суть которого не ясна) от Xilinx и не работает, то надо к Xilinx и обратиться. На forum писали, там достаточно шустро отвечают. Раньше можно было отдельный issue открыть, там прям отдельного инженера к задаче прикрепляют. Как я понимаю вы хотите принимать/отправлять данные из сети попутно их как-то обрабатывать своим kernel (RTL) и при этом пользоваться все блага XRT? Возможно Alveo не самый хороший выбор для такой задачи, это все же data center acceleration card (память -> карта -> память), а вам нужен SmartNIC. То есть, out of the box это не взлетит. IMHO, есть два пути. 1. Отказаться от kernel flow и вернуться к IP flow. Собираем железячный дизайн, собираем software стек драйвера kernel, userspace все как в старые добрые. И тогда все в ваших руках и под вашим полным контролем, без всяких там шеллов. 2. Копать xbtest gt mac test case исходники, если вообще их можно достать. Смотреть как kernel c GT работает, смотреть как ему подсунуть поток от другого kernel, а не с DMA, ну и что будет с планированием потоков данных на хосте.
  6. По дефолту Alveo идет с предустановленным дизайном, который подразумевает работу только с стеком XRT и Ethernet там действительно нет. Идеология kernel flow гоняет данные строго память хоста -> карта -> память хоста, сеть туда ни как не пристыковать. По другому маршрут IP flow вы сознательно отказываетесь от всех благ XRT и вся FPGA ваша. Если вы где-то из закромов Xilinx вытащили ref des с 100G CMAC и там все мигает, ну на базе него и развивайте свой проект в чем проблема то? Кабель и трансиверы вы правильно подобрали? Или 100G в 10G засунули? Там нужен brackout кабель.
  7. Очень хочется посадить джуниора/мидела ковырять это направление. Настроил и выложил бы кто-нибудь хороший образ с настроенным окржением для разработки на Chisel, пожал бы ему руку и поставил пиво
  8. Сode coverage очень слабая метрика, мало что говорящая о функциональной корректности, строка (или условие) кода может быть покрыта много раз, но само по себе это не говорит, что при этом не возникало ошибок. Вам же для DO, тогда есть два варианта. Напишите тест который загонит модуль в неправильное состояние в котором отработает непокрытый переход. Кстати, тестовые сценарии корректного выхода из состояния ошибки тоже важны, казырнете перед аудитором. Для итогового репорта сольете два отчета кодового покрытия в один. Но а если готовы с этим дальше жить всю оставшуюся жизнь, то просто добавите exclude на этот переход и тогда он не будет портить общей картины репорта о покрытии, а кто уж там будет разбираться покрыли вы when other или нет...
  9. Шину можно, а вот порт так объявлять нельзя. assign debug = {test_vector[10:7],test_vector[3:0]};
  10. Добра и Вам. Вопрос инструментария не первостепенный, нужно начать со стандартов. В оригинальном стандарте DO-254 приведен большой список того на что у вас в компании должен быть стандарт (текстовое описание как вы это делаете). Что касается стандарта жизненного цикла разработки электроники класса А и еще ряда стандартов, то для вас их могут разработать третьи компании. Прямую ссылку давать не буду, компания барс, найдете в интернете. С ними стоит поговорить, они много чего полезного могут рассказать про сертификацию по кт-254. К сожалению, в части программируемой логики за вас они стандарты сделать не смогут, может что и изменилось, но 5 лет назад все, что они смогли сказать относительно стандарта верификации FPGA, это то, что там применяются эвристические методы Стандарты и методики проектирования и верификации FPGA проектов придется разрабатывать самим. Касательно стандарта верификации, то прямо подробно все расписываете как каждый IP core в вашем проекте вы тестируете. Как составляете test plan, что в него входит, какие технологии применяете direst tests, CRT, error injection. Как выглядит отчет о верификации IP Core. Какую метрику используете для оценки качества верификации SVA coverage, code/functional coverage. В итоге у вас получается следующая картина. Для каждого IP Core у вас есть исходные требования (текстовое перечисление, что модуль должен делать, а что нет) которые трассируются к проектным спецификациям и test plan на разработку RTL и VIP. Дальше эти требования трассируются к исходному коду RTL и VIP. Что бы аудитор мог тыкнуть пальцем в любое требование и вы ему показали как это требование реализуется и проверяться (текстовое описание реализации в спецификациях и конкретные строки кода в исходниках). И наконец требования трассируются к логам (отчетам) о проведении тестирования. То есть, полный цикл: что требуется -> как это реализуется и проверяется -> что получилось по факту. Есть много разного софта который поможет автоматизировать различные стадии этого процесса. В Questasim есть verification management (как то так называется) он может втягивать в себя test plan и графически отображать прогресс верификации и печатать репорты. Но не забывайте, в DO-254 есть такое понятие как tool assessment, то есть, грубо говоря инструмент должен быть сертифицирован для использования в маршрутах проектирования электроники от надежности функционирования которой зависят жизни людей.
  11. Это не так. Ширина слова (скорость) чтения переменная величина от 1 до 10 байт, зависящая от входных данных. Для каждого набора входных данных это распределение будет свое.
  12. Коды Rice, на одну запись в 8 байт может быть 8 чтений по одному байту, а может и все 8 байт будут прочитаны.
  13. Естественно пишем только тогда, когда есть место для записи. Глобальная задача этой схемы, чтобы данные всегда были готовы к чтению. Но достичь этого с таргетом 250МГц не удалось, пришлось уже пожертвовать тактом, опуская сигнал готовности чтения при записи новой порции данных, но даже при этом допущении это "больное" место в дизайне.