Перейти к содержанию
    

mikeT

Участник
  • Постов

    77
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о mikeT

  • Звание
    Частый гость
    Частый гость

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Посетители профиля

2 123 просмотра профиля
  1. Написал простой тест для улучшения понимания того, как работает симулятор SystemVerilog (Sheduling semantics). Исходные данные Проект состоит из трех частей: 1) в качестве DUT простейший модуль счетчика module counter ( input logic clk ); //--- logic ena = 0; logic [7:0] cnt = '0; //--- always_ff @(posedge clk) begin cnt <= cnt + 1; if(cnt == 1) begin ena <= 1; end end endmodule : counter 2) program observer - копирует состояние счетчика (подробности в коде) program observer ( //--- ref logic clk, //--- ref logic ena, ref logic [7:0] cnt ); //--- timeunit 1ns; timeprecision 1ps; //--- logic [7:0] ref_cnt1 = 'x; logic [7:0] ref_cnt2 = 'x; //--- initial begin forever begin @(posedge clk) begin if(ena) begin ref_cnt1 <= cnt; ref_cnt2 = cnt; end end end end endprogram : observer 3) модуль верхнего уровня module tb (); //--- timeunit 1ns; timeprecision 1ps; //--- parameter unsigned STOP_TIME = 80; //--- logic clk = 0; //--- initial begin fork forever begin #5ns clk = ~clk; end #(STOP_TIME*1ns) $stop(2); join_any end //--- counter counter_inst ( .clk ( clk ) ); //--- observer observer_inst ( //--- .clk ( clk ), //--- .ena ( counter_inst.ena ), .cnt ( counter_inst.cnt ) ); endmodule : tb Краткое описание эксперимента Observer только «наблюдает», т. е. я постарался исключить его влияние на состояние модуля counter или, другими словами, постарался исключить возможные переходы из Reactive region sets в Active region sets (IEEE Std 1800-2017, 4. Sheduling semantics). Если я все правильно понимаю, вся работа, выполняемая в program observer, будет происходить в Reactive region sets, ref_cnt2 - Reactive, ref_cnt1 - Evaluate RHS в Reactive, далее работа в Re-NBA. Т.е. по сути все события, которые обрабатываются в module counter должны были уже быть обработаны ранее (в Active region set, точнее в Active и в NBA регионах). В таком случае, я ожидаю увидеть диаграмму вот такого вида: Рис.1 И действительно, в Questa 10.4a картина именно такая. Меняю слово program на слово module (еще endprogram на endmodule) для observer. Теперь должно стать вот так: Рис.2 Снова все сошлось - теперь вся обработка идет в Active region sets и мы видим наблюдаемые значения с задержкой на один такт. Запускаю Questa 10.7c. Для варианта observer как module картинка такая же как на Рис.2, т. е. все по теории (если я ее правильно понимаю). А вот для варианта observer как program картинка по идее должна быть аналогична Рис.1, но в реальности мы получаем снова результат как на Рис. 2. Вопросы (1) Правильно ли я понимаю, что в соответствии со стандартом (конкретно, раздел Sheduling semantics), все должно быть именно так, как происходит при моделировании с использованием Questa 10.4a? (2) Если при моделировании на Questa 10.4a сделать описание портов program observer вместо таких program observer ( //--- ref logic clk, //--- ref logic ena, ref logic [7:0] cnt ); Вот такими: program observer ( //--- input logic clk, //--- input logic ena, input logic [7:0] cnt ); То получим диаграмму не похожую ни на одну из двух предыдущих: Рис. 3 Вот такое поведение я вообще объяснить не могу. Какая разница - ref или inputs в данном случае? Чтобы стало «правильно» (как на Рис.1) достаточно сделать вот такое объявление портов: program observer ( //--- input logic clk, //--- input logic ena, ref logic [7:0] cnt ); (3) Если мы используем теперь Questa 10.7c то при любых манипуляциях с портами (input, ref, …) вид диаграммы будет всегда один и тот-же и он совпадает с Рис. 2. Вопрос - кто работает правильно (10.4а или 10.7с) или вообще никто из них?
  2. Спасибо за подробный ответ. Если не секрет (а если секрет, то так и напишите ) кого рассматриваете в качестве производителей? SiFive, Codasip?
  3. Что означает фраза? а) Вы собираетесь писать код под какие-то RISC-V процессоры? Если не секрет, то какие? (производитель и ISA, т.е. например RV64IMDAV) б) Вы сами собираетесь разработать ядра RISC-V, скажем тот-же что и в примере выше RV64IMDAV с микроархитектурой типа "6-issue out-of-order 8 stage pipeline" в) оба пункта И какого размера команды этим всем занимаются?
  4. Имеются две практически идентичные реализации одного и того же проекта. Ниже приведены две таблицы с характеристиками Destination Clock Path (для обоих вариантов). Видно, что различие имеется только для параметра Setup_fdre_C_D: в одном случае он равен 0.076 ns, а в другом 0.033 ns. Отличия в реализации по сути только в одном: в первом случае триггер размещен в SLICEM, во втором в SLICEL. На данный момент мне неясны следующие моменты: что означает параметр Setup_fdre_C_D – это “настоящий” Tsetup для триггера или это какая-то “приведенная” величина (используемая в Xilinx Timimg Analysis) почему при практически идентичной структуре эти параметры имеют различные значения – это отличие обусловлено тем, что используются SLICEM/SLICEL или чем-то другим?
  5. Вы должны задать это все сами. Там не совсем так просто, но в документации написано все достаточно внятно. Кроме буферов там подцепляются т.н. overlapped events и т.д. Насчет этого ничего сказать не могу. Мы работали под виндой чистой. Попробуйте для начала тоже под "чистой" виндой потестить, а иначе вы рискуете бороться с проблемами не связанными собственно с сетью и сокетами (вашей реализацией), а связанными с реализацией сторонних фирм. Размер этого буфера влияет конечно, но после какого-то значения (скажем 8М по нашему опыту) уже не так сильно Это нормально, это же UDP.
  6. Попробуйте использовать WSASocket и все что с ним связано - это если делать под Windows. Суть в том, что можно организовать прием пачки пакетов как-бы "автоматически", т.е. без "дергания" механизмов синхронизации уровня пользователя. Ну и естественно, организуете свою буферизацию как бы вторым слоем. У нас стояла задача выжать предельную производительность при приеме 1Г потока с нашего железа на комп под виндой. Сначала я написал пробной тест с использованием обычных сокетов, но были проблемы с потерей пакетов, переупорядочиванием (даже на локал-хосте!) и, самое главное, загрузкой процессора. У нас пакеты не превышали обычную длину, т.е. 1472 байта. Был организован пул буферов (количество буферов естественно настраивается, но из практики их количество = 64-256). На каждый принятый пакет формируется сообщение (вроде бы там семафор используется, но это уже детали реализации) и управление передается следующему слою софта (следующему потоку). С WSA сокетами получается двухуровневая буферизация - на уровне WSA организуется пул "мега"-буферов каждый на 64 пакета (это вроде максимум, что WSA может позволить) и ОС дергается уже в 64 раза реже, чем при использовании обычных сокетов. Ну а далее все тоже самое - организуется еще один слой - ряд буферов, как и в первом случае, но теперь это уже буфера 64*1472 (все параметры есс-но задаются как минимум на уровне компайл-тайм), их количество у нас порядка 128. Скорость в установившемся режиме (гоняли сутками) удалось получить на уровне 99.7% или 99.8% от теоретического предела для 1Г. Стабильность высокая. Загрузка процессора небольшая. При грамотно написанном софте можно распараллелить задачу - как минимум аффиннити процессорам задать, но нам и этого не потребовалось. 100% исключить пропадания пакетов нельзя, да и сам UDP это не гарантирует. P.S. А вообще, мне тоже многие знакомы профи сказали "переходи на Линукс" :rolleyes:
  7. Насчет библиотек не подскажу, а по самим алгоритмам советую посмотреть очень хорошую книгу (для введения в проблематику) Active Computer Vision by Cooperative Focus and Stereo, Eric Paul Krotkov, 1989. В ней Глава 3, по-моему конкретно по теме. Вообще, сама тема "автофокус" очень серьезная и, несмотря на то, что этой проблемой занимаются давно, "волшебного" решения ("секретной формулы") нет. Не существует "идеальных" алгоритмов, все зависит от задачи. Сам алгоритм, по сути, разбивается на две части: (1) вычисление функционала фокуса, (2) поиск экстремума. Функционал фокуса - это параметр (по сути, число), который характеризует резкость изображения (выбранная зона кадра или весь кадр). Чем резче изображение, тем больше значение функционала фокуса. Если имеется алгоритм для вычисления функционала фокуса, вы можете попробовать найти подвижку оптики, при которой функционал фокуса будет максимальным, т.е. по сути требуется решить задачу поиска экстремума функции (неизвестной). Для ознакомления могу порекомендовать хорошую подборку алгоритмов функционала фокуса - Алгоритмы автофокуса. В реальности, к сожалению, примерно 95% из описанных в "научных" статьях (причем в солидных источниках) алгоритмов, оказываются на практике нерабочими, т.е. это классические "сферические кони в вакууме". Из реально работающих алгоритмов (в условиях зашумленности, перепада освещенности и т.д.) рекомендую обратить внимание на достаточно "старый" TENG (см. исходник по ссылке).
  8. А есть отзывы именно по поводу того, как Vivado HLS производит синтез с SystemC? Пробовал уже кто-нибудь?
  9. Начал изучать спецификацию шины Avalon и понял что плохо понимаю (даже на уровне терминологии) как использовать, например, BFM модели для верификации, что такое мониторы и т.д. Посоветуйте пожалуйста литературу, а точнее список книг/статей/мануалов, которые раскрывают все необходимые вопросы. В частности, что порекомендуете (и в каком порядке) из приведенного ниже списка: 1. SystemVerilog for Verification: A Guide to Learning the Testbench Language Features by Chris Spear and Greg Tumbush (2012) 2. Writing Testbenches using SystemVerilog by Janick Bergeron (2010) 3. Verification Methodology Manual for SystemVerilog by Janick Bergeron, Eduard Cerny, Alan Hunter and Andy Nightingale (2005) Очень хотелось бы не просто список (а тем более из полутора десятков источников), а что-то типа рекомендуемого плана изучения «от простого к сложному» + какие-то дополнительные темы (возможно отдельные книги) в виде уже «факультативного» освоения.
  10. Embedded C++

    Заинтересовало упоминание языка Ада в задачах, где требуется надежность и т.д. В свое время читал "общеразвивающую" инфу про то, что этот язык был специально создан по заказу МО США именно для сложных, высоконадежных систем, например, для ПО на каких-нибудь крылатых ракетах, истребителях... Полез сейчас в инет посмотреть (ради любопытства) "а на чем написано ПО для А-380, F-35?" Нашел инфу про F-35, про А-380 искать пока лень. Но насчет ПО для F-35 я был несколько удивлен, хотя и ожидал чего-то подобного. Если коротко, то на С++. Один из слайдов документа (ссылка ниже) содержит фотографию Joint Strike Fighter (F-35 Lightning II) и ниже подпись со стрелочкой, указывающей на самолет, "C++ inside". SafetyCriticalC++Presentation.pdf На других ресурсах по этой же теме (софт для F-35) приводятся данные что первоначально там была "солянка" из Ады, С, С++, ассемблера, но потом было решено все 100% кода перевести на С++. Документ достаточно интересный и, мне кажется, заставляет задуматься насчет использования С++ в эмбеддед и холиварах типа С vs. С++.
  11. Здравствуйте. Имеются отладочные комплекты DM37x Evaluation Module (на базе DM3730) и AM3517. Интересует работа только с ядром Cortex A8 (в случае с DM37x Evaluation Module), т.е. поддержка эмулятором двух ядер не требуется. На первом этапе нас интересует работа с голым железом, в дальнейшем с Linux. 1) Возможна ли работа с ними из под CCS 5.x (в частности 5.01) с помощью вашего эмулятора SAU100-USB (v.2)? 2) Если "да", то чем вариант SAU100-USB (v.2) хуже варианта SAU510-USB ISO PLUS JTAG Emulator? (!) Особенно интересует насколько SAU100-USB (v.2) "тормознутее" по сравнению с SAU510-USB ISO PLUS JTAG Emulator. Например, при просмотре дампа памяти, регистров и т.п. Заранее благодарю за ответы.
  12. У нас стоит подобный вопрос - именно для Cyclone IV. Тулз (Power Delivery Network) пока не использовали. На данный момент не спеша собираем инфу по имеющимся референс-дизайнам. Могу посоветовать посмотреть на плату кита DE2-115 (Terasic). В частности, по поводу VCCA, похоже там никто особо не заморачивался - стоит 4 конденсатора по 0.1мк и вроде все (хотя лучше проверьте, конечно сами). Я не призываю тупо копировать "как у Терасика" или "как сделал Вася". Просто привожу пример дизайна, выполненного достаточно солидной конторой. Можно у Альтеры посмотреть аналогичный кит, у них Терасиком ряд китов практически одинаковые, я даже не понимаю зачем их под двумя разными марками выпускать. Если что найдете интересного напишите пожалуйста в тему - думаю этот вопрос будет многим интересен.
  13. О как! Спасибо большое, а я тут собрался от Альтеры ответ типа "Да-Нет" получить. Понимаю, что был в этом вопросе весьма наивным. Думаем сейчас: 1. в Hyperlinx посмотреть, как вы и советовали. 2. на ките со Стратикс-3 глянуть живьем. похоже у всех альтер I/O 1.8V (non-referenced, JESD8-7) одинаково устроены.
×
×
  • Создать...