Jump to content

    

dxp

Свой
  • Content Count

    3875
  • Joined

  • Last visited

Community Reputation

0 Обычный

4 Followers

About dxp

  • Rank
    Adept

Информация

  • Город
    Array

Recent Profile Visitors

9048 profile views
  1. У STM32H750 мегабайт оперативы (при 128 флеши), тоже есть TQFP корпус, цена 6-7 долл. 480 МГц, кстати, как раз программу из ОЗУ пускать.
  2. Хорошую конвекционную за три килобакса будет непросто найти. Тоже искали, в итоге купили такую, но это не 3к.
  3. 5 копеек. Уже публиковали ссылку, но времени много прошло, не найти, поэтому ещё раз. Мы используем систему сборки, подробно описанную тут. Там же лежит тестовый проект-"болванка", который использует эту систему, он полностью рабочий, хотя по логике почти пустой. В двух словах: проект синтезатора, скрипты для симулятора и прочее - всё это есть продукт генерации из небольшого количества конфигурационных скриптов - один makefile и несколько tcl. Вся эта конфигурация компактно хранится в своей отдельной директории. Конфигураций может быть сколько угодно (система сборки благополучно родит соответствующее количество проектов для синтеза и симулятора (хотя симулятор у нас используется в т.н. non-project mode, т.е. там по сути скрипты запуска). Новую конфигурацию очень легко склонировать из любой имеющейся путём копирования в отдельную директорию и правки makefile (обязательно) и некоторых tcl скриптов - операция несложная и нетрудоёмкая (небольшой объём правок по готовому). Кстати, тема с конфигурациями очень удобна для организации, например, разработки и тестирования отдельных модулей в составе проекта - создаётся просто отдельная конфигурация, где указаны только нужные файлы (разрабатываемый исходник, тестбенч, модели и т.д.), под это система рожает проект синтезатора и симулятора. После моделирования и отладки в симе можно (и нужно) прогнать ещё и синтез (без P&R, ессно - только синтез), тут как правило вылезают свои нюансы. Проект для синтеза рожается за 6 секунд. Получается, что сам по себе проект вивады никакой особой ценности не представляет - его можно прибить и родить заново тут же. Иногда так делаю, когда вивада, бывает, начинает глючить или в процессе экспериментов что-то сломал в проекте. Под контроль версий, естественно попадет только директория с конфигурациями (и исходниками - они в своей директории), все эти проекты вивады и прочее - ложатся в отдельную директорию build, которая игнорируется. Итого, в историю git попадает только очень ограниченное количество небольших файлов.
  4. На одном из семинаров, которые он проводил, ему задали этот вопрос про интерфейс, он ответил что-то вроде: "Моя программа, как хочу так и делаю". С улыбкой, конечно.
  5. Там не только техпроцессы другие, там они и архитектурно отличаются весьма заметно.
  6. О, что-то знакомым повеяло: "трудник", "домхвон"... Ещё осталось дождаться "жып" и "элда". Уж не инкарнация ли тов. Сектера?
  7. Оно в 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 ...
  8. Всё верно. Если Rэ мало, то отношение Rк/Rэ велико, т.е. коэффициент усиления большой. При этом глубина ООС от эмиттерного резистора мала, поэтому схема не очень стабильна на температуре и нелинейность усиления тоже больше, чем при сколько-нибудь значимой величине Rэ. Глубину ООС можно оценить по отношению Uэ/Uбэ, т.е. отношение падения на резисторе обратной связи к напряжению на переходе база-эмиттер - чем больше это отношение, тем стабильнее и линейнее схема, но как правило тут сложнее добиться большого коэффициента усиления, т.к. значительная величина Uэ "съедает" часть диапазона питания и для Uk (т.е. размах выходного сигнала) остаётся уже не так много. Чем больше падает на Uэ, тем меньше остаётся для Uk. Погоняйте схему в каком-нибудь спайсе, поварьируйте номиналы резисторов, посмотрите зависимость от падения на эмиттерном резисторе температурной стабильности и линейности усиления. Это увлекательно и познавательное дело.
  9. https://www.microchip.com/wwwproducts/en/KSZ9692 10/100/1000 Ethernet SoC Controller w/ ARM9 Core
  10. 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 сейчас не работаю, не знаю, как там в свежих версиях). А это позволяет легко делать параметризованные кроссбары, правда не целиком средствами интерфейсов, а в виде модулей с массивами интерфейсов. Писанины примерно столько же (ведь интерфейс - это по сути недомодуль с дополнительными фичами), зато никаких проблем ни на симе, ни на синтезе.
  11. Ну, эти - да, уже программы, первая - веб приложение, вторая - нативное. Спайдер изрядно похож на оболочку матлаба. А ноутбук удобен для публикаций - например, тот же гитхаб умеет "рендерить" файлы .ipynb, в которые сохраняются сессии ноутбука. Достаточно перейти по ссылке на файл, и браузер покажет пересчитанную страницу. Преимуществом ноутбучного подхода по сравнению с чисто программой является то, что в ноутбуке можно делать гибридные документы - он состоит из секций разных типов: текстовые (язык разметки), графические (картинки, видео), вычислительные (питон код в полном объёме с графиками и диаграммами сразу). Таким образом, можно прямо хоть научные отчёты оформлять, при этом они "живые" - редактируешь секцию, она тут же пересчитывается. Вот тут пример, целый урок по питону оформлен в виде Jupyter Notebook страницы.
  12. Ну, питон - не расчётная программа, а ЯП. По идеологии очень похож на скриптовый язык матлаба, но будучи ЯП общего назначения как язык значительно мощнее и гибче. Матлаб исходно проектировался для математических расчётов - в особенности, для матричных вычислений (отсюда и название), питон сам по себе в этом вопросе вообще никакой, но к нему подтягивается пакет numpy, который внутри реализован на тех же пакетах BLAS, LAPACK, что и матричная математика матлаба, поэтому в этом вопросе тут где-то паритет. Питон силён библиотеками. Это вообще язык-фронтэнд: вся эффективность достигается путём грамотного управления ресурсами (встроенными средствами типа слайсов, enumerate и библиотеками) Несмотря на бесплатность, в питоновые средства серьёзно вкладываются солидные заведения вроде университетов. И существует тенденция уже не одного года, когда специалисты, много лет сидевшие на матлабе, переходят на питон + numpy + matplotlib и прочее. И это вопрос не только финансов, но и бОльших возможностей как самого ЯП, так и библиотек под него. Сильная сторона матлаба - обилие специализированных библиотек (тулбоксов) и налачие инструментов Simulink и HDL Coder. Но двое последних не имеют отношения к собственно языку, это скорее надстройки. В питоне таких инструментов нет.
  13. Так IPython - не это дополнение. Какая разница, написать в командной строке 'python' или 'ipython'? Запуститься консоль. Дальше вся работа одинакова - пишем команды, смотрим вывод программы. Там ничего изучать и осваивать не надо. А даже внешний вид уже куда приятнее.