Jump to content

    

dxp

Свой
  • Content Count

    3868
  • Joined

  • Last visited

Everything posted by dxp


  1. О, что-то знакомым повеяло: "трудник", "домхвон"... Ещё осталось дождаться "жып" и "элда". Уж не инкарнация ли тов. Сектера?
  2. Оно в wave.do файле (конфигурация вейвформа) живёт, пользовательские радиксы в начале файла: onerror {resume} radix define SDRAM_Command { "4'b1111" "INHIBIT", "4'b0111" "NOP", "4'b0011" "ACTIVE", "4'b0101" "READ", "4'b0100" "WRITE", "4'b0010" "PRECHARGE", "4'b0001" "AUTOREFRESH", "4'b0000" "LOAD_MODE_REG", -default hexadecimal } quietly WaveActivateNextPane {} 0 add wave -noupdate /lwir_tb/GMII_GTX_CLK add wave -noupdate /lwir_tb/GMII_TX add wave -noupdate /lwir_tb/GMII_TXEN add wave -noupdate /lwir_tb/GMII_RX_CLK add wave -noupdate /lwir_tb/GMII_RX add wave -noupdate /lwir_tb/GMII_RXDV ...
  3. Всё верно. Если Rэ мало, то отношение Rк/Rэ велико, т.е. коэффициент усиления большой. При этом глубина ООС от эмиттерного резистора мала, поэтому схема не очень стабильна на температуре и нелинейность усиления тоже больше, чем при сколько-нибудь значимой величине Rэ. Глубину ООС можно оценить по отношению Uэ/Uбэ, т.е. отношение падения на резисторе обратной связи к напряжению на переходе база-эмиттер - чем больше это отношение, тем стабильнее и линейнее схема, но как правило тут сложнее добиться большого коэффициента усиления, т.к. значительная величина Uэ "съедает" часть диапазона питания и для Uk (т.е. размах выходного сигнала) остаётся уже не так много. Чем больше падает на Uэ, тем меньше остаётся для Uk. Погоняйте схему в каком-нибудь спайсе, поварьируйте номиналы резисторов, посмотрите зависимость от падения на эмиттерном резисторе температурной стабильности и линейности усиления. Это увлекательно и познавательное дело.
  4. https://www.microchip.com/wwwproducts/en/KSZ9692 10/100/1000 Ethernet SoC Controller w/ ARM9 Core
  5. 5 коп. Логика внутри интерфейса синтезируется и работает. И на Quartus, и на Vivado. Раньше это использовал, но сейчас полностью от этого отказался. Ряд причин. 1. Если внутри интерфейса есть логика и интерфейс имеет больше двух портов (модпортов) и/или пробрасывается транзитом через модуль по иерархии, что стопудово получаются тонны предупреждений (на Q что-то типа "interface contains only dangling nets", а на V - "net does not used and will be removed", за точность текста не поручусь, но смысл понятен и примерно одинаков для обоих синтезаторов). По сути там синтезатор сначала создаёт все сигналы (модпорты и внутренние) во всех модулях, в которых так или иначе присутствует экземпляр интерфейса, а потом при оптимизации "видит", что сигналы эти не нужны и материцца на них. Поведение тупое, но повлиять на это нельзя. Хотя логика рожается правильно и всё работает. 2. Для параметризации количества портов использовали generate for для модпортов внутри интерфейса. Прекрасно работало. Хотя предупреждения из п.1 пёрли в полный рост. Но на Questa 10.7c это перестало работать - оказывается из языка выпилили возможность описывать модпорты внутри цикла generate. Обосновали это тем, что тут присутствует нарушение логики языка: цикл generate for создаёт ещё один уровень иерархии (ну да, там даже надо блок именовать, чтобы потом можно было ссылаться на сгенерированные модпорты), а это идеологически неверно - модпорт должен быть на том же уровне иерархии, что и основные объекты интерфейса. Вроде там ещё есть какое-то нарушение, но я запомнил только это. В общем, указанная версия квесты забривает. В итоге, пришёл к такому варианту. Да, интерфейсы - очень клёвая штука, и возможность описывать внутри логику - это просто киллерфича, но имеющиеся реализации используемого синтеза таковы, что пользоваться этим без проблем не получается. Итого, делаю так: интерфейсы делаю максимально простыми - точка-точка, т.е. два модпорта, никакой логики внутри, только проброс сигналов. Удобство в том, что просто все сигналы одним пучком. Пробовал вместо интерфейсов использовать структуры - парой: одна на ввод, другая - на вывод, но оказалось очень путано и неудобно - сигналы от разных шины по сути, а с интерфейсом удобно, всё в одном месте. Такой вариант синтезируется без проблем, прост в отладке, нет массы дурацких предупреждений не по делу. И очень важно, что без проблем синтезируются массивы интерфейсов! По крайней мере в V (в Q сейчас не работаю, не знаю, как там в свежих версиях). А это позволяет легко делать параметризованные кроссбары, правда не целиком средствами интерфейсов, а в виде модулей с массивами интерфейсов. Писанины примерно столько же (ведь интерфейс - это по сути недомодуль с дополнительными фичами), зато никаких проблем ни на симе, ни на синтезе.
  6. Ну, эти - да, уже программы, первая - веб приложение, вторая - нативное. Спайдер изрядно похож на оболочку матлаба. А ноутбук удобен для публикаций - например, тот же гитхаб умеет "рендерить" файлы .ipynb, в которые сохраняются сессии ноутбука. Достаточно перейти по ссылке на файл, и браузер покажет пересчитанную страницу. Преимуществом ноутбучного подхода по сравнению с чисто программой является то, что в ноутбуке можно делать гибридные документы - он состоит из секций разных типов: текстовые (язык разметки), графические (картинки, видео), вычислительные (питон код в полном объёме с графиками и диаграммами сразу). Таким образом, можно прямо хоть научные отчёты оформлять, при этом они "живые" - редактируешь секцию, она тут же пересчитывается. Вот тут пример, целый урок по питону оформлен в виде Jupyter Notebook страницы.
  7. Ну, питон - не расчётная программа, а ЯП. По идеологии очень похож на скриптовый язык матлаба, но будучи ЯП общего назначения как язык значительно мощнее и гибче. Матлаб исходно проектировался для математических расчётов - в особенности, для матричных вычислений (отсюда и название), питон сам по себе в этом вопросе вообще никакой, но к нему подтягивается пакет numpy, который внутри реализован на тех же пакетах BLAS, LAPACK, что и матричная математика матлаба, поэтому в этом вопросе тут где-то паритет. Питон силён библиотеками. Это вообще язык-фронтэнд: вся эффективность достигается путём грамотного управления ресурсами (встроенными средствами типа слайсов, enumerate и библиотеками) Несмотря на бесплатность, в питоновые средства серьёзно вкладываются солидные заведения вроде университетов. И существует тенденция уже не одного года, когда специалисты, много лет сидевшие на матлабе, переходят на питон + numpy + matplotlib и прочее. И это вопрос не только финансов, но и бОльших возможностей как самого ЯП, так и библиотек под него. Сильная сторона матлаба - обилие специализированных библиотек (тулбоксов) и налачие инструментов Simulink и HDL Coder. Но двое последних не имеют отношения к собственно языку, это скорее надстройки. В питоне таких инструментов нет.
  8. Так IPython - не это дополнение. Какая разница, написать в командной строке 'python' или 'ipython'? Запуститься консоль. Дальше вся работа одинакова - пишем команды, смотрим вывод программы. Там ничего изучать и осваивать не надо. А даже внешний вид уже куда приятнее.
  9. Но для интерактивной работы ведь нужна консоль. Штатная питоновая уж "слишком проста". IPython - та же консоль, но с наличием множества очень удобных плюшек, начиная от продвинутой системы word completion вкупе с историей команд (например, достаточно ввести пару букв команды и далее стрелка вверх перебирает из истории только те команды, которые начинались с этих букв) и заканчивая возможностью писать и редактировать целые блоки кода вплоть до функций (можно написать, отладить функции, а потом перенести её в исходник). Нумерованный ввод-вывод. Подсветка синтаксиса. Попробуйте - после этого желание пользоваться штатной консолью питона пропадёт.
  10. Не Jupyter, Notebook, а Jupyter Notebook. А вы пробовали IPython? И если отметаете это, то чем пользуетесь в качестве консоли?
  11. "да" означало в данном случае, что путь правильный - ставить анаконду. Потому что через pip там как-то криво ставилось. Правда, было это года два или три назад, может починили с тех пор, но сомнительно, а анаконда без вопросов вставала и всё работало замечательно. По сути это просто всё то же самое, собранное в одном пакете. Что избыточно? IPython?
  12. Так чтобы по отдельности не таскать эти либы, имеет смысл сразу накатить jupyter - он всё это тянет автоматом. При этом ещё предлагает прекрасную IPython консоль, в т.ч. и в QtConsole варианте, а также web приложение jupyter notebook. В линухах ставится всё pip install jupyter. Под вендами - да, путь - анаконда.
  13. Да. И это только защищает FIFO от over/underflow, чтобы логика этого устройства не поломалась, когда, например, происходит запись при установленном full, но не защищает от пропуска данных. Для корректной работы всего тракта надо обязательно пользовательскую логику увязывать с full. А вообще, SVA тут рулят со страшной силой.
  14. Если нужен счётный семафор, то лучше сразу сделать свой - там для этого есть штатный путь: отнаследоваться от TService и написать свою логику, подсматривая, как сделаны другие сервисы межпроцессного взаимодействия. Имхо, это будет прямой путь: проще и без костылей. За основу возможно подойдёт тот же TMutex, только вместо простого флага там счётчик завести.
  15. Насколько я понял, автор цитируемой фразы ("Для классов с инитом конструкторов - тольлько new/delete. Без вариантов!") имел в виду, судя по тексту самой фразы, что если у класса есть конструктор, то обязательно будет выделение памяти (вызов new). Что совершенно неверно и выдаёт непонимание на уровне азов.
  16. Такой безобразный синтаксис кастов введён специально, чтобы это выделялось на общем фоне, и программисту было напоминание лишний раз подумать, надо ли делать ручное преобразование типа или эта необходимость возникла из-за ошибки проектирования. И это видные места, где может быть проблема.. Прежний (сишный) синтаксис в этом плане плох - он не выделяется из кода. К тому же он усугубляет и без того злоупотребление скобками, чем и так грешат C/C++. Ну, и в С++ static_cast и reinterpret_cast - это разные уровни кастования - например, static_cast не позволит целое преобразовать к указателю, т.е. как бы разные уровни severity, а сишный вариант не различает их - объединяет оба.
  17. Т.е. получается, что: "для производства вполне достаточно : сборка-гербер-перечень элементов (спецификация)...а-и-всё" таки недостаточно для производства, а помимо сборочных чертежей, герберов и перечня/спецификации ещё нужно разработать и предоставить производству тестовые стенды, инструкции по настройке и проверке и прочую технологическую шнягу. Которая-таки тоже разрабатывается и нередко сложность и стоимость разработки тестовых стендов и ПО для них превышает по сложности и трудоёмкости само изделие.
  18. А проверку (прогон тестов) плат после выхода с монтажной линии на контрактном производстве, а также тестирование конечных изделий (тоже прогон всех необходимых тестов) - это тоже КП делает или вы сами?
  19. Таймер делать не стали, просто анализируем тракт передачи - как только он пустеет, генерируется прерывание. Так получается и проще, и даже быстрее реакция
  20. Рабочая схема. Пробовали её, но в итоге нам удобнее оказалось генерировать прерывания по порогу заполнения выходной очереди: драйвер задаёт порог через регистр в дивайсе, и тот мечет прерывания на каждые эн пакетов. Очень эффективный способ получился, особенно на коротких пакетах (т.е. когда их очень много).
  21. Правила не запрещают вступать в дискуссию с участниками, имеющими статус "Модератор". Правила запрещают публично обсуждать действия модераторов. Это элементарная субординация - как в армии не разрешается спорить с командиром при посторонних - это называется пререкания, что является грубым нарушением воинской дисциплины.Если это убрать, порядок вообще сразу закончится. Точно так же и на любом публичном модерируемом ресурсе вроде форума: если допустить публичные обсуждения действий модераторов, то модератор лишается зримого преимущества от служебного положения и не сможет эффективно исполнять свои обязанности. Мгновенно наступит балаган и ресурс превратится в помойку. Если не согласны с действиями командира модератора, обращайтесь выше "по команде". И так далее в "суды высшей инстанции". В простых случаях можете попытаться выяснить лично у модератора через ЛС - возможно, докажете ему его неправоту и он снимет взыскание. Но ни в коем случае не обсуждать публично действия модераторов. Это недопустимо. Такие правила действуют везде, где администрация преследует наведение порядка в следовании правилам. Ещё до появления интернет-форумов точно так же было (и есть) на FIDO эхах. Т.ч. это никакой не концлагерь, а на самом деле форум с очень даже либеральной администрацией и модерацией.
  22. @Gradient, не понял вопрос: что всё запустить? Сама ртось же очень мелкая, в этом монстрике потреблённые ею ресурсы почти не видны.
  23. У нас в организации человек работает с STM32H750. Всё штатно.
  24. В Vivado генерите корку PCIe с нужными параметрами. На ней ПКМ->Open IP Example Design. Тут сгенерит вам рабочий проект. Проект умеет только PIO режим (запись/чтение одиночных слов с хоста). Но линк поднимается и корка полнофункциональная, из неё торчат AXI4-Stream порты - можно наворачивать свою функциональность на уровне TLP сколько душе угодно.
  25. Там диаграмма - это текстовый конфиг, который храните, если хочется, в блокноте. Это не рисование в графическом редакторе. Если надо оперативно вставить, то просто открываете ссылку, вставляете из блокнота текст, мгновенно получаете диаграмму. И далее - либо в этой же проге сгенерить png, либо сграбить с экрана и вставить куда-там-надо. Зато читабельность диаграммы на три порядка выше. И подредактировать - прямо тут же на лету правкой символов в конфиге.