Mad_kvmg

Мощно

Как-то казалось, что наоборот, что внешней DDR4 - "заземлил" старшие биты и управления банками и всё, а вот можно ли внутреннему контроллеру редуцировать шину адреса, тут вот вивада должна иметь что сказать.

Всем привет! Нет Vivado под рукой, сам бы проверил, но может кто сталкивался с подобным вопросом. Очень нужно сэкономить выводы ПЛИСки, есть внешняя DDR4, допустим мне достаточно всего 10 бит шины адреса, могу ли я оставшиеся выводы не задействовать под DDR контроллер, Vivado позволит такие фокусы? Спасибо!

Очень приблизительно https://blogs.synopsys.com/breakingthethreelaws/2015/02/how-many-asic-gates-does-it-take-to-fill-an-fpga/

https://www.fpgadeveloper.com/topics/ssd-storage/ Там для MPSoC, но куда копать должно быть понятно.

Всем, привет! Озадачился тут вопросом подбора высокопроизводительного энергонезависимого накопителя для FPGA (MPSoC). Посмотрел в сторону SD карт, очень много информации, тут и benchmarks results и reference designs и куча IP Cores, от полного до частичного offload'а NVMe стэка на железе, причём от нескольких производителей. Дальше решил посмотреть, что творится с CompactFlash. И вообще ничего, вот прям от слова совсем... А стандарт-то развивается ( https://www.compactflash.org/cfexpress ) последние релизы CFExpress полностью утилизируют PCIe шину, обеспечивая отличную производительность. Кто-нибудь в курсе, что не так со связкой CompactFlash - FPGA?

Задавать глупые вопросы не страшно, не уметь находить нужную информацию вот это не очень. Если новичок, то нет ни чего лучше чем пройти по уже готовому примеру. Возьмите TRD (Targeted Reference Design) для Zynq и пройдите его по шагам и большинство вопросов вида куда нажать отпадут сами собой. А уже с какими то деталями возвращайтесь сюда, тут вам эксперты подскажут.

Да вообще прекрасное объявление Откуда-то считывают минуты и еще CUAD какой-то придумали.

ТС, я готов участвовать в стартапе писать в Гите на KiCAD.

list list_int; assign list_int = list'(signal);

В долгосрочной перспективе, если вы собираетесь оставаться в мире программируемой логики, лучше изучать HLS. HLS compliler? Тут во многом зависит от того на какой платформе вы работаете, если Xilinx, то добро пожаловать в дивный мир Vitis HLS У Intel свой тулчейн, так же есть вендер независимые инструменты, такие как MG, ах да siemens, Catapult HLS

Я так понимаю, что вы запустили 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, ну и что будет с планированием потоков данных на хосте.

По дефолту Alveo идет с предустановленным дизайном, который подразумевает работу только с стеком XRT и Ethernet там действительно нет. Идеология kernel flow гоняет данные строго память хоста -> карта -> память хоста, сеть туда ни как не пристыковать. По другому маршрут IP flow вы сознательно отказываетесь от всех благ XRT и вся FPGA ваша. Если вы где-то из закромов Xilinx вытащили ref des с 100G CMAC и там все мигает, ну на базе него и развивайте свой проект в чем проблема то? Кабель и трансиверы вы правильно подобрали? Или 100G в 10G засунули? Там нужен brackout кабель.

Очень хочется посадить джуниора/мидела ковырять это направление. Настроил и выложил бы кто-нибудь хороший образ с настроенным окржением для разработки на Chisel, пожал бы ему руку и поставил пиво

А ссылочку

Сode coverage очень слабая метрика, мало что говорящая о функциональной корректности, строка (или условие) кода может быть покрыта много раз, но само по себе это не говорит, что при этом не возникало ошибок. Вам же для DO, тогда есть два варианта. Напишите тест который загонит модуль в неправильное состояние в котором отработает непокрытый переход. Кстати, тестовые сценарии корректного выхода из состояния ошибки тоже важны, казырнете перед аудитором. Для итогового репорта сольете два отчета кодового покрытия в один. Но а если готовы с этим дальше жить всю оставшуюся жизнь, то просто добавите exclude на этот переход и тогда он не будет портить общей картины репорта о покрытии, а кто уж там будет разбираться покрыли вы when other или нет...

Шину можно, а вот порт так объявлять нельзя. assign debug = {test_vector[10:7],test_vector[3:0]};

Добра и Вам. Вопрос инструментария не первостепенный, нужно начать со стандартов. В оригинальном стандарте 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, то есть, грубо говоря инструмент должен быть сертифицирован для использования в маршрутах проектирования электроники от надежности функционирования которой зависят жизни людей.

Это не так. Ширина слова (скорость) чтения переменная величина от 1 до 10 байт, зависящая от входных данных. Для каждого набора входных данных это распределение будет свое.

Коды Rice, на одну запись в 8 байт может быть 8 чтений по одному байту, а может и все 8 байт будут прочитаны.

Естественно пишем только тогда, когда есть место для записи. Глобальная задача этой схемы, чтобы данные всегда были готовы к чтению. Но достичь этого с таргетом 250МГц не удалось, пришлось уже пожертвовать тактом, опуская сигнал готовности чтения при записи новой порции данных, но даже при этом допущении это "больное" место в дизайне.

Ну записать то надо в "хвост", а где этот "хвост" начинается величина переменная, зависящая от того сколько было прочитано :)

Сторона записи всегда готова отдать 8 байт, кроме последнего слова, которое может быть от 1 до 8 байт.

Всем привет! Да запись блокирует чтение, в идеале, хотелось бы и читать и писать одновременно, но тогда с таймингом совсем печалька. Ситуация осложняется еще тем, что данные закрыты кодами Rice, то есть, значение read_num формируется из бит регистра reg. Если все же пожертвовать тактом и запретить одновременное чтение и запись, то можно кое какую оптимизацию сделать путем подсчета разности (16-reg_occ) при чтении, тогда к моменту записи разность можно брать уже с регистра. Но не сильно это помогло. Mux'ы конечно наше все и без них никуда, но собственно обратился к коллективному разуму с расчетом на то, что может быть у меня уже глаз замылился и не вижу как записать в "хвост" новую порцию данных без двойного сдвига, "облегчив" mux по входу.

Всем привет! Такая вот задачка как в школе про бассейн с водой и двумя трубами, только другая. Есть регистр 16 байт. С одной стороны из него производится чтение от 1 до 10 байт, с другой стороны запись от 1 до 8 байт. Накидал вот такой вариант assign reg_occ_switch = (write) ? reg_occ + write_num : (read) ? reg_occ - read_num : reg_occ; always_ff @ (posedge clk) reg_occ <= reg_occ_switch; always_ff @ (posedge clk) begin if (write) begin reg <= {input_data,reg << (16-reg_occ)} >> (16-reg_occ) ; end else if (read) begin reg <= reg >> read_num; end end Можно ли что-то покрутить со сдвигом при записи, уж больно жирный мультиплексор получается?