flammmable

0) флешка - кастомное устройство? 1) сколько раз в жизни вы лично пихали флешку в десктоп? 2) сколько раз в жизни вы лично пихали флешку в китайский смартфон? 3) сколько раз в жизни вы лично пихали флешку в сервер хранения данных? 4) сколько раз в жизни вы лично пихали флешку в стойку управления станком с ЧПУ?

- Тач-пады, тач-скрины и планшеты возможно упаковать в один тип. - Крутильники, джойстики, джойпады и кучу прочей ереси - в Vendor specific. Всё равно им нужно дополнительное ПО. Если "делать универсально" между клавиатурой и мостом I2C, то чего бы туда и Billboard и IrDA не докинуть? ...с точки зрения наличия "дискетки, прилагающийся у устройству" вещь сугубо идентичная. И от того что называется "не драйвер, а DLL", не перестанет требовать "дискетку". Немного оффтоп, но кросс-платформенность - это фетиш и бич современной индустрии. Объективно, нет такого приложения (и нет такого кастомного устройства), которое бы требовалось бы запустить одновременно на ... 1) десктопе Макбук 2) китайском смартфоне 3) сервере хранения данных 4) стойке управления станком с ЧПУ 5) коммуникационном спутнике, запущенном 10-15 лет назад Поэтому "прилично работать на разных ОС с разными устройствами", вообще говоря, не_нужно.

Так изначальный вопрос в том, зачем в классе HID делать склад всего-и-вся, перегружать его сверх всякой меры и, по факту, всё равно прикручивать кастомные драйверы, когда можно было бы сделать классы Mouse и Keyboard, а всё прочее сложить в "прочее"? Ковыряюсь сейчас с FT260Q (USB-I2C/UART), который внезапно не CDC, а как раз HID и к которому приложена отдельная DLL-ка - драйвер, по факту. И думаю, какой в этом был толк - так расширять функционал HID, чтобы в него можно было впихнуть что угодно и даже I2C?

Причём здесь мышка и драйвер? "Mass storage", "CDC" и "Hub" вынесены в отдельные классы и не требуют (при адекватности производителя) дискеты с драйвером. Почему бы и мышь не вынести в отдельный класс? И клавиатуру.

Глядя на список классов устройств USB у меня возникает ряд вопросов: 1) Зачем нужен класс "Audio/Video Devices" (10h), если есть "Audio" (01h) и "Video" (0Eh)? 2) В чём идеологическая разница между классами "Miscellaneous" (EFh) и "Application Specific" (FEh), когда они оба как бы создают раздел "Прочее"? 3) Зачем класс "Human Interface Device" (03h) такой "развесистый", если есть класс "Vendor Specific" (FFh), где можно ваять что угодно? 4) Почему для принтеров есть отдельный класс "Printer" (07h), а клавиатуры и мыши спрятаны внутрь класса "Human Interface Device" (03h)? 5) Почему "Billboard Device Class" (11h) вынесен в отдельный класс, а, к примеру, "IRDA Bridge device" спрятан внутрь класса "Application Specific" (FEh)? Почему для рекламного щита есть отдельный класс, а для USB-вентилятора, USB-фонарика и USB-подогревашки для чашки с кофе отдельного класса нет? В общем, почему список классов устройств USB такой странный и какие, на ваш взгляд, классы наиболее бесполезные?

Спасибо!

В ModelSim/QuestaSim возможно написать код: $display("Time: %0d ns", 123); ...который выведет строку: # Time: 123 ns ...в консоль. Если щёлкнуть по этой строке, то в окне просмотра временных диаграмм курсор переместится на 123-ю наносекунду. В Aldec Active-HDL при щелчке по данной строчке активируется редактор кода и курсор переместится на строчку с $display(...) В Vivado при щелчке по строке не произойдёт ничего. Я поспрашивал на форуме Xilinx и на EDAboard - там не густо с ответами. Правильно ли я понимаю, что в Vivado и Active-HDL нет этой удобной особенности, что есть в ModelSim?

The ModelSim*-Intel® FPGA edition software includes the base features of ModelSim* PE Я нашёл табличку, где assertion имеются только в версии DE, а в PE и SE - отсутствуют. Если Starter Edition - это урезанная PE, тогда понятно. Сейчас Quartus переходит на QuestaSim, любопытно, там-то появится возможность использовать assertion? Спасибо всем за разъяснения.

Указанно ли где-нибудь, что бесплатная версия ModelSim-Altera не поддерживает assertion? Просто вот здесь (https://www.intel.com/content/www/us/en/software/programmable/quartus-prime/model-sim.html) ...вся разница заключается в количестве строк и скорости.

Я отодвигал этот момент как мог, желая вносить изменения в локальный modelsim.ini самого проекта. Но скрепя сердце, раскомментировал строчку msgmode = both в файле modelsim.ini из папки modelsim_ase. Однако, результатов это не дало. Я набросал тестбенч с ассертом: module testbench (); reg A = 0, B = 0, C = 0; initial begin forever begin #(500000); A = ~A; end end initial begin #(1250000); B = 1; #(1000000); C = 1; #(1000000); B = 0; #(1000000); C = 0; end property is_equal_p; @(posedge A) B ##0 C; endproperty is_equal_check: assert property (is_equal_p); endmodule ...ожидая увидеть картинку с диаграммами и маркерами, как в руководстве "ModelSim® SE User’s Manual". Но никаких маркеров не появилось. Возможно ли в ModelSim-Altera вывести маркеры assert-ов? И если да, то как?

Я хочу вывести в симуляции ModelSim-Altera, запускаемой из Quartus диаграмму состояния утверждения (assertion). Intel сообщает: Я открываю файл "..\simulation\modelsim\modelsim.ini" и нахожу там следующий текст: Я попробовал раскомментировать последнюю строчку (удалить точку с запятой), но каждый раз при запуске симуляции файл modelsim.ini переписывается заново. Есть ли какая-нибудь возможно обеспечить вывод диаграмм утверждений путём 3-4-5 нажатий мышкой в какой-нибудь настройке Quartus? Или тут только переписать с нуля весь скрипт запуска симуляции и добавить туда -msgmode both ?

Смотрю сейчас как сделано у Микрона в его модели SDRAM. Там сначала в переменной фиксируется время, а потом дельта между текущим и зафиксированным временем сравнивается с временным параметром. Типа того: RFC_chk = $time; ... if($time - RFC_chk < tRFC) begin $display("не соблюдён временной параметр tRFC (но только по-английски)!!111"); end Но это как-то наколеночно всё. Я почитал про утверждения в SystemVerilog. Там в property всегда фигурирует тактовый сигнал. property delay_in_clocks @(posedge clk) a ##100500 b endproperty delay_chk: assert property(delay_in_clocks); То есть всё равно получается квантование по времени, а внутри квантов - что угодно. В VHDL вроде бы есть "wait for (...) until (...)". Но в SVA, как я понимаю, решили провести четкую грань с надписью "здесь тебе не анализ времянок, у нас всё синхронно, пшол прочь". Если так, то это несколько печально. <через некоторое время> Вот здесь приводят пару любопытных примеров.

Люди посоветовали использовать fork/join_any. Пойду пробовать. <через некоторое время> Нет, fork/join_any - это те же яйца, только в профиль. Оно не отреагирует на бесконечно малый импульс. Есть мысль насчёт чего-то вроде такого: ... input x_in ... parameter DETECTION_WAIT = 1000; reg x_in_fix; always @(x_in) begin x_in_fix <= x_in; #(DETECTION_WAIT) x_in_fix <= x_in; //на этом месте - любая пустышка, только чтобы данный always подержать на время DETECTION_WAIT end always @(x_in ^ x_in_fix) begin $display("catched!!"); end То есть заXORить вход с копией самого себя, причём копию "замораживать" после фронта на заданное время. Но как-то уж больно много слов. Неужели в симуляции SystemVerilog нет более изящного способа выразить относительно простую мысль: "следи за фронтом N времени, а потом - не следи"?

Или поставьте начальное значение для counter: reg [MAX_COUNTER-1:0] counter = 0; Есть доводы против того, чтобы так делать, но в данном случае это сработает ))))))

Допустим, ко входу модуля, который играет роль внешнего (по отношению к ПЛИС) окружения в тестбенче, подключена линия. И после прихода фронта по этой линии модуль должен определить, что в течение N наносекунд логическое состояние на этой линии больше не изменялось. Технически, наверное, можно сделать цикл внутри always с паузами в 1нс и проверкой "что там с состоянием?". Но это выглядит весьма костылеподобно. Раз уж в SystemVerilog есть отдельные циклы foreach и repeat, то и тут, кажется, должно быть элегантное, надёжное и простое решение. Оно есть?

Технически, (наивную) логику приёма данных по UART можно сделать следующей: 1) Ждём нисходящий фронт 2) Отсчитываем 0,5+1 длительности бита 3) Производим замер, ждём 1 длительность бита, повторяем N-1 раз 4) Символ успешно принят, снова ждём нисходящий фронт В подобном подходе нет проверки "а точно ли нисходящий фронт - это фронт от старт-бита?" И нет проверки "а точно ли это символ, отправленный по всем правилам, со стоп-битом в нужном месте?" Конечно, эти две проверки можно добавить. Но тогда возникает вопрос, а почему эти проверки стоит добавить, а проверку на второй стоп-бит - не стоит? А если добавить и её, то стоит ли добавить проверку на 1,5 стоп-бита? Если ответы "нет и нет, эти проверки не нужны", то тогда так ли уж нужны первые две проверки?

В редакторе кода Quartus Prime 17.0 была удобная вещь. Можно двойным щелчком выделить слово и одновременно подсветятся все вхождения этого слова выше и ниже по тексту. Она не работала при включённом по Ctrl+F поиске, но в целом была весьма полезной особенностью. На днях я установил Quartus Prime 21.1.0. Начал редактировать код, двойным щелчком выделил слово, скопировал, вставил и... оно вставилось в количестве N=11 штук подряд. Спустя непродолжительное время я выяснил, что копирование с умножением происходит для разных слов на разное значение N. Вдруг пришло озарение: двойной щелчок теперь не просто подсвечивает слова по всему тексту. Он их на самом деле выделяет. А потом, по Ctrl+C происходит копирование всех вхождений данного слова. Так что теперь если вам нравится выделять слова для копирования двойным щелчком, просто откройте при помощи Ctrl+F строку поиска и не закрывайте её. А если вам нравится по двойному щелчку выяснять все вхождения слова, то не пытайтесь их копировать. Отрадно, конечно, что у Intel/Altera наконец-то дошли руки и до таких мелочей типа редактора кода (так, может ещё и тип real в синтезатор с SystemVerilog добавят), но несколько удручает, что подобное начинание решено было предварить, видимо, распитием водки.

Так и сделаю.

Я создал в Quartus тестбенч через Settings->EDA Tool Settings->Simulation->NativeLink settings и установил селектор в положение "Compile test bench". Затем запустил симуляцию через Tools->Run Simulation Tool->RTL Simulation. После того, как ModelSim открылся и всё просимулировал, я настроил некоторые параметры отображаемых сигналов в окне: порядок в древе, тип данных, цвет и т.д. Затем я нажал Ctrl+S и сохранил настройки дорожек в файл wave.do. Затем я вернулся в настройки NativeLink settings и в строке Use script to set up simulation вписал путь к wave.do. При повторном запуске симуляции свойства отдельных отображаемых сигналов были успешно установлены в соответствии с файлом wave.do. Однако сама симуляция не запустилась, пришлось отдельно нажать Simulate->Run->Run -all. Я попробовал вставить команду run -all в сам файл wave.do - тогда при запуске из Quartus настройки отображения сигналов выставились верно и сама симуляция запустилась автоматически. Но когда я слегка поменял настройки ещё раз и сохранил их в wave.do, файл закономерно переписался с нуля и run -all исчез. Я понимаю, что в Quartus, в NativeLink settings есть пункт Script to compile test bench, который позволяет устроить буйство скриптинга, но возможно ли сохранять настройки отображения сигналов и осуществлять автоматический запуск более штатными средствами?

Огромное вам спасибо! Могу я поинтересоваться, какой именно раздел IEEE1800 почитать по теме?

Ммм. Если делать возврат в одну строчку (через имя функции, либо через return), то всё ок: function int my_func(); //my_func = PARAM_A/PARAM_B; return PARAM_A/PARAM_B; endfunction Но если возвращать значение переменной внутри функции, то не ок (синтезатор ругается на неконстантность выражения, даже если res объявлен, как const int res): function int my_func(); int res = PARAM_A/PARAM_B; my_func = res; //return res; endfunction Спасибо, за то, что попробовали на своей среде и подковырнули данную проблему. Может я сейчас и доколупаюсь до сути происходящего.

Это Quartus? Версия Pro или Standard/Lite?

На localparam синтезатор Quartus говорит тоже самое, что и на parameter. localparam FUNC_RESULT = my_func();

Спасибо! Надо будет ознакомиться.

И, повторяя основной вопрос самого первого поста: где тот авторитетный документальный источник, которым может подтвердить это предположение?