mikeT

Написал простой тест для улучшения понимания того, как работает симулятор 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с) или вообще никто из них?

Спасибо за подробный ответ. Если не секрет (а если секрет, то так и напишите ) кого рассматриваете в качестве производителей? SiFive, Codasip?

Что означает фраза? а) Вы собираетесь писать код под какие-то RISC-V процессоры? Если не секрет, то какие? (производитель и ISA, т.е. например RV64IMDAV) б) Вы сами собираетесь разработать ядра RISC-V, скажем тот-же что и в примере выше RV64IMDAV с микроархитектурой типа "6-issue out-of-order 8 stage pipeline" в) оба пункта И какого размера команды этим всем занимаются?

xc7a200tfbg676-2

Имеются две практически идентичные реализации одного и того же проекта. Ниже приведены две таблицы с характеристиками 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 или чем-то другим?

Написал вам в личку.

Вы должны задать это все сами. Там не совсем так просто, но в документации написано все достаточно внятно. Кроме буферов там подцепляются т.н. overlapped events и т.д. Насчет этого ничего сказать не могу. Мы работали под виндой чистой. Попробуйте для начала тоже под "чистой" виндой потестить, а иначе вы рискуете бороться с проблемами не связанными собственно с сетью и сокетами (вашей реализацией), а связанными с реализацией сторонних фирм. Размер этого буфера влияет конечно, но после какого-то значения (скажем 8М по нашему опыту) уже не так сильно Это нормально, это же UDP.

Попробуйте использовать WSASocket и все что с ним связано - это если делать под Windows. Суть в том, что можно организовать прием пачки пакетов как-бы "автоматически", т.е. без "дергания" механизмов синхронизации уровня пользователя. Ну и естественно, организуете свою буферизацию как бы вторым слоем. У нас стояла задача выжать предельную производительность при приеме 1Г потока с нашего железа на комп под виндой. Сначала я написал пробной тест с использованием обычных сокетов, но были проблемы с потерей пакетов, переупорядочиванием (даже на локал-хосте!) и, самое главное, загрузкой процессора. У нас пакеты не превышали обычную длину, т.е. 1472 байта. Был организован пул буферов (количество буферов естественно настраивается, но из практики их количество = 64-256). На каждый принятый пакет формируется сообщение (вроде бы там семафор используется, но это уже детали реализации) и управление передается следующему слою софта (следующему потоку). С WSA сокетами получается двухуровневая буферизация - на уровне WSA организуется пул "мега"-буферов каждый на 64 пакета (это вроде максимум, что WSA может позволить) и ОС дергается уже в 64 раза реже, чем при использовании обычных сокетов. Ну а далее все тоже самое - организуется еще один слой - ряд буферов, как и в первом случае, но теперь это уже буфера 64*1472 (все параметры есс-но задаются как минимум на уровне компайл-тайм), их количество у нас порядка 128. Скорость в установившемся режиме (гоняли сутками) удалось получить на уровне 99.7% или 99.8% от теоретического предела для 1Г. Стабильность высокая. Загрузка процессора небольшая. При грамотно написанном софте можно распараллелить задачу - как минимум аффиннити процессорам задать, но нам и этого не потребовалось. 100% исключить пропадания пакетов нельзя, да и сам UDP это не гарантирует. P.S. А вообще, мне тоже многие знакомы профи сказали "переходи на Линукс" :rolleyes:

Насчет библиотек не подскажу, а по самим алгоритмам советую посмотреть очень хорошую книгу (для введения в проблематику) Active Computer Vision by Cooperative Focus and Stereo, Eric Paul Krotkov, 1989. В ней Глава 3, по-моему конкретно по теме. Вообще, сама тема "автофокус" очень серьезная и, несмотря на то, что этой проблемой занимаются давно, "волшебного" решения ("секретной формулы") нет. Не существует "идеальных" алгоритмов, все зависит от задачи. Сам алгоритм, по сути, разбивается на две части: (1) вычисление функционала фокуса, (2) поиск экстремума. Функционал фокуса - это параметр (по сути, число), который характеризует резкость изображения (выбранная зона кадра или весь кадр). Чем резче изображение, тем больше значение функционала фокуса. Если имеется алгоритм для вычисления функционала фокуса, вы можете попробовать найти подвижку оптики, при которой функционал фокуса будет максимальным, т.е. по сути требуется решить задачу поиска экстремума функции (неизвестной). Для ознакомления могу порекомендовать хорошую подборку алгоритмов функционала фокуса - Алгоритмы автофокуса. В реальности, к сожалению, примерно 95% из описанных в "научных" статьях (причем в солидных источниках) алгоритмов, оказываются на практике нерабочими, т.е. это классические "сферические кони в вакууме". Из реально работающих алгоритмов (в условиях зашумленности, перепада освещенности и т.д.) рекомендую обратить внимание на достаточно "старый" TENG (см. исходник по ссылке).

А есть отзывы именно по поводу того, как Vivado HLS производит синтез с SystemC? Пробовал уже кто-нибудь?

Начал изучать спецификацию шины 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) Очень хотелось бы не просто список (а тем более из полутора десятков источников), а что-то типа рекомендуемого плана изучения «от простого к сложному» + какие-то дополнительные темы (возможно отдельные книги) в виде уже «факультативного» освоения.

Заинтересовало упоминание языка Ада в задачах, где требуется надежность и т.д. В свое время читал "общеразвивающую" инфу про то, что этот язык был специально создан по заказу МО США именно для сложных, высоконадежных систем, например, для ПО на каких-нибудь крылатых ракетах, истребителях... Полез сейчас в инет посмотреть (ради любопытства) "а на чем написано ПО для А-380, F-35?" Нашел инфу про F-35, про А-380 искать пока лень. Но насчет ПО для F-35 я был несколько удивлен, хотя и ожидал чего-то подобного. Если коротко, то на С++. Один из слайдов документа (ссылка ниже) содержит фотографию Joint Strike Fighter (F-35 Lightning II) и ниже подпись со стрелочкой, указывающей на самолет, "C++ inside". SafetyCriticalC++Presentation.pdf На других ресурсах по этой же теме (софт для F-35) приводятся данные что первоначально там была "солянка" из Ады, С, С++, ассемблера, но потом было решено все 100% кода перевести на С++. Документ достаточно интересный и, мне кажется, заставляет задуматься насчет использования С++ в эмбеддед и холиварах типа С vs. С++.

Здравствуйте. Имеются отладочные комплекты 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. Например, при просмотре дампа памяти, регистров и т.п. Заранее благодарю за ответы.

У нас стоит подобный вопрос - именно для Cyclone IV. Тулз (Power Delivery Network) пока не использовали. На данный момент не спеша собираем инфу по имеющимся референс-дизайнам. Могу посоветовать посмотреть на плату кита DE2-115 (Terasic). В частности, по поводу VCCA, похоже там никто особо не заморачивался - стоит 4 конденсатора по 0.1мк и вроде все (хотя лучше проверьте, конечно сами). Я не призываю тупо копировать "как у Терасика" или "как сделал Вася". Просто привожу пример дизайна, выполненного достаточно солидной конторой. Можно у Альтеры посмотреть аналогичный кит, у них Терасиком ряд китов практически одинаковые, я даже не понимаю зачем их под двумя разными марками выпускать. Если что найдете интересного напишите пожалуйста в тему - думаю этот вопрос будет многим интересен.

О как! Спасибо большое, а я тут собрался от Альтеры ответ типа "Да-Нет" получить. Понимаю, что был в этом вопросе весьма наивным. Думаем сейчас: 1. в Hyperlinx посмотреть, как вы и советовали. 2. на ките со Стратикс-3 глянуть живьем. похоже у всех альтер I/O 1.8V (non-referenced, JESD8-7) одинаково устроены.

Вы правы, но как тогда понять стандарт (в моем случае это JESD8-7) - там нет ничего про динамику. И Альтера просто ссылается в таблице (где приведены возможные I/O стандарты) на этот самый JESD.. Допустим я все это смоделирую и все окажется ОК. А через полгода Альтера чуть-чуть изменит технологию и все станет "немножко не так", но приписка "все по стандарту JESD8-7" останется. Я к тому, что должно же быть какое-то четкое руководство или, точнее сказать, договоренность типа "это 1.8 В и это 1.8 В и они стыкуются". Ну а по частотам в приниципе написано отдельно типа "это работает до 150МГц, а это до 133 МГц " (цифры условные).

Вопрос по совместимости I/O 1.8V Altera Cyclone IV и LPSDR SDRAM 1.8V (Micron) Мы хотим подключить LPSDR (Mobile Low Power SDR) SDRAM с питанием 1.8В к Cyclone IV. Столкнулся с такой проблемой: Согласно документации на данный Циклон он поддерживает I/O стандарт 1.8-V LVTTL/LVCMOS (JESD8-7). В даташите в частности приводятся значения Vol max = 0.45V, Voh min = 1.35V (при питании банка 1.8). Но для LPSDR SDRAM указаны Vil max = 0.3V и Vih max = 1.44V (при питании 1.8). То есть в наихудшем случае FPGA не стыкуется с LPSDR SDRAM. Понятно, что данные по выходу для ПЛИС приведены для граничных условий (ток 2мА и т. п.) и реально при работе на меньшую нагрузку «0» будет меньше чем 0.45, а «1» выше чем 1.35. Более того, стандарт JESD8-7 (сейчас используется реально JESD8-7A) определяет на самом деле два диапазона — Normal Range и Wide Range. Значения, приведенные в стандарте для Normal Range в точности равны тем что приведены в даташите на Циклон 4 (ток нагрузки 2 мА). А вот значения, приведенные для Wide Range (ток нагрузки 100мкА ) полностью обеспечивают стыковку с LPSDR SDRAM 1.8V. В связи с этим пара вопросов: (1) Означает ли ссылка на то что Циклон 4 поддерживает стандарт JESD8-7 то, что ПЛИС при нагрузке равной 100 мКа на пине будет гарантированно обеспечивать то что написано в JESD8-7 Wide Range (уровни напряжений, указанные в стандарте)? (2) Есть ли у кого опыт практического использования такого рода «связки» - LPSDR SDRAM 1.8V – Altera Cyclone IV 1.8V? На самом деле, как я посмотрел - для Cyclone II, III, V и вроде бы всех Stratix для этого режима приводятся все те-же самые значения что я привел выше для Циклона 4. Может быть какие-то ссылки на референс дизайны кинете. Я довольно долго искал в инете, но ничего подходящего не нашел.

Здравствуйте. Попробовал сделать простейший проект с использованием Matlab EDA Simulator Link + Questa и обнаружил что результаты моделирования радикально зависят от версии используемой Questa. Проект следующий: имеется модуль верхнего уровня на SystemVerilog, в котором генерируется сигнал тактовой частоты и реализован регистр (код показан ниже). always_ff @(posedge сlk) begin out_data <= m_data; end Значение m_data формируется инстанцией модуля, интерфейс модуля приведен ниже. module slon_tb ( //--------------------------------- input wire clk, output reg [3:0] data_out ); Этот модуль реализован в виде функции на Матлабе согласно методике «Using a MATLAB Function as a Component», описанной в доках к Matlab EDA Simulator Link. В качестве условия запуска этой функции используется условие –rising clk (задается с помощью функции matlabcp). Собственно функционал модуля представляет собой простой счетчик. Теперь о самой проблеме: при работе с Questa 6.4c все функционирует правильно – значение на выходе регистра запаздывает на единицу по сравнению со значением с выхода счетчика. Но при моделировании с Questa 6.6c или c Questa 10.0b значения на выходе счетчика и регистра совпадают – получается что модуль, реализованный на матлабе вычисляет новое значение своего выхода и это новое значение сразу же использует блок always_ff регистра. Каких-либо ошибок или варнингов при этом не выдается (ни Матлабом, ни Квестой). Как я понимаю проблема в том, что симулятор (Квеста) некорректно обрабатывает очередь событий в момент очередного фронта клока или, точнее, неправильно размещает события в очереди. Сталкивался ли кто-нибудь с чем-нибудь подобным? Я только начал разбираться с этим пакетом, и, возможно, что-то не понял, поэтому был бы очень признателен за помощь.

1) Хорошо. Насчет использовать драйвер от Cypress - обязательно прикину такую возможность. Спасибо за совет. Мне нужно именно "для дома, для семьи", единственное требование чтобы скорость передачи данных была не хуже 30 МБ в секунду. 2) Если я Вас правильно понял, то в общем случае для девайса типа ISP1761 необходимо писать драйвер самим?

Драйвер для Cypress, насколько я понимаю, предназначен именно для Cypress - по крайней мере по API это четко видно: все приспособлено под конкрентые особенности Cypress FX2LP, например под набор EndPoints, специфичных только для данной микросхемы. Вопрос был именно про правильную работу с ISP1761 и FX2LP я указал только для примера того как фирма-производтель микросхемы проводит политику поддержки путем предоставления бесплатного и весьма приличного драйвера.

Имеется плата с ISP1761 на борту. Подскажите как работать с этим девайсом со стороны хоста, на котором стоит винда (конкретно XP). Мы работаем с Cypress FX2LP - для него имеется драйвер от самого Cypress, для ISP1761 подобного драйвера и API для него я что-то не нашел. Или предполагается использование каких-то стандартных драйверов, входящих в соствав ОС? Вариант с написанием драйвера самим как-то не очень привлекателен. Задача состоит в передаче потоков данных с устройства на хост и с хоста на устройтсво.

Большое спасибо за развернутый ответ. Все правильно поняли :rolleyes: Именно про это (то, на что Вы ответили) я и спрашивал. Еще раз спасибо. Планирую спокойно поизучать все это.

... Я правильно понял, что Simulink HDL Coder генерирует именно код на HDL, а не какие-то кубики из готовых библиотек? Как на Ваш взгляд этот код по сравнению с человеческим? Какова эффективность такого описания? Можно чуть подробнее про EDA Link for ModelSim? Еще несколько вопросов - для каких систем, на Ваш взгляд, такой подход не очень подходит? Насколько просто (грубо говоря сколько времени требуется) разобраться с этим инструментарием при условии что с матлабом и симулинком дружу очень давно и много с ними работаю (правда с симулинком меньше значительно)? И какие подводные камни можете указать?

Мне представляется, что Ваша аналогия некорректна. Но спорить не буду. Не нравятся мои примеры - у Вас есть возможность внимательнейшим образом изучить соответствующие законы, все это есть в открытом доступе. Если кратко: с 3-й формой проблем вообще нет. Можете провести анкетирование, построить модель и сравнить вероятности "невыезда при наличии 3-й формы" и "смерти от наезда автомобиля". По моим прикидкам - второе намного более вероятно. Также можно рассмотреть проблему "смерть от прямого попадания метеорита в голову", контрпримеры высказыванию "в меня и моих знакомых метеорит не попал" также имеются. Ну... Выдают чОрный плащ, возможность нажать на пусковую кнопку "Тополь-М" (не чаще 1 раза в год, правда :( ) и еще много чего (ну Вы же сами понимаете - секретно все очень) Сейчас, я кстати тоже работаю на ВПК и вообще никакой формы нет и не требуют. Даже ДСП нет, а это вообще не форма. Хотя, имхо, сейчас разработки более "приближены" к "форме", чем та разработка из-за которой я получил форму 2.

По поводу форм допуска - не так страшен черт, как его малюют. С конца 90-х годов (с 96 примерно) у меня была 3-я форма допуска ("допуск к секретным сведениям", если я не ошибаюсь), а с 99 (точно не помню) 2-я форма ("допуск к совершенно секретным сведениям"). Работа 100% была связана с разработками для ВПК и некоторых "трехбуквенных" контор. В 2000 году я уволился из конторы где работал и устроился на работу в коммерческую фирму, также занимающуюся разработками, но уже в области телекома. По работе требовались частые и продолжительные (по несколько месяцев) командировки за границу - в одну из стран НАТО. Единственная проблема при получении загранпаспорта была в том, что срок выдачи затянули, но ОВИР по истечении "официального" срока честно выдал бумажку "рассмотрение ваших документов задерживается ФСБ" или что-то в этом роде. После этого проблем не было - ездил за границу столько, что листы в первом загранпаспорте просто кончились раньше срока действия паспорта - так много было виз и отметок о пересечении границы. Визы были и туристические и рабочие. Была возможность вообще "там" насовсем остаться или как минимум получить вид на жительство. Выезжал и через Москву и через Питер. Это все, несмотря на то, что 2-я форма официально "невыездная", причем "срок" висит 5 лет (по закону в некоторых случаях может быть увеличен), то есть я был "невыездным" до 2005 года. Никаких "отчетов", "докладов" и прочего никакая "гэбня" с меня не требовала, хотя поездки были не в одну страну и даже не на один континент :rolleyes:. В 2005 или даже раньше я сменил загранпаспорт и опять никаких проблем не было, на этот раз даже срок рассмотрения не затянули. Родственников и "волосатых лап" в " кровавой гэбне" у меня нет, я самый обыкновенный человек. Механизм "невыезда" на самом деле такой: (я рассказываю так, как мне объясняли компетентные люди из компетентных органов 10 лет назад): 3-я форма вообще проблем не создаст для выезда. 2-я (1-я тем более) может создать реальные проблемы, если вы в процессе работы имели дело с "реальными секретами" - а что считать реальным а что нет - тут уже либо как руководство вашего предприятия решит, либо если эти работы попадают в какие-то ранее утвержденные списки "это секретно - за границу не выпускать". Сама по себе форма 2 не означает, что человек является секретоносителем, это просто допуск - именно так и было в моем случае. ФСБ, получив от вас анкету, просто рассылает запросы по всем местам вашей работы, где была секретность. Руководство вашего предприятия отвечает ФСБ насчет вас - "знает главную военную тайну или нет". Делается все это есс-но через 1-й отдел. Если ответ "не знает", то ФСБ само без очень серьезных причин ваш выезд в страны "свободы, демократии и либеральных ценностей" не запретит. И, даже если вы реально имели дело с чем-то "секретным", то руководство все равно может написать ответ в ФСБ "можно выпустить". Если вы поступаете на работу в контору типа той, которую представляет топикстартер, то никто вас без вашего желания не "подпишет" на форму "допуск к сведениями особой важности (1-я форма)" и уж тем более никак не получится сделать это втайне от вас. Реально даже ДСП вы не получите без вашего согласия. Я знаю несколько примеров, когда люди с 3-й формой просто "посылали" руководство когда оно хотело оформить им 2-ю форму - именно по причине, чтобы не иметь проблем с выездом за границу. Т.к. работники (из этих примеров) были достаточно ценны для предприятия, то давления "получай 2-ю форму или будут неприятности" на них не было. Знаю еще, как минимум 2-х человек, которые также выезжали за границу со 2-й формой, причем у них ситуация была более сложная - "знали секреты" :rolleyes: