Jump to content

    

Viktuar

Участник
  • Content Count

    29
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Viktuar

  • Rank
    Участник

Recent Profile Visitors

215 profile views
  1. Странная идея использовать свертку. Сжимать изображения логично с помощью соответствующих алгоритмов, например, jpeg один из самых простых. А алгоритма обратной свертки, насколько я понимаю, не существует.
  2. Был у Ментора такой ресурс Verification Academy, если первый раз столкнулись, рекомендую, чтоб понять что это такое, какие виды покрытия бывают, как понять, чтовсе ok, и т.п.. Особенно если потом потребуется функциональное покрытие и пр. А по поводу симулятора - читайте описание, моделсим умеет такое, ну а схематик, скорее всего, придется переводить на код.
  3. Virtexы для массовых устройств дороговаты. А седьмые ультраскейлы вполне покупаются у нас, как раз с полтысячи ждем; может где-нибудь в Сибири есть с этим проблемы, но опять же из-за цены. Вы, наверно, с VHDL93 работали. В 2008 все гораздо человечней. Писанины не больше чем в SV.
  4. Полностью согласен, и по поводу VHDL тоже. А еще Machxo2 имеет встроенную конфигурационную флешь, встроенные генераторы частоты и pll. Есть версии с LDO, т.е. 1 внешнее питание. А еще бесплатный тулчейн с синплифаем, что, на мой взгдяд, большой плюс, особенно если используешь vhdl - xilinx до сих пор не сделал норм. поддержку 2008-го стандарта.
  5. Так-то оно так (хотя, кажется, для microblaze в S6 больше 90МГц не вытянуть), но в микроконтроллере помимо этого будет еще 1-3МБ флеша, 0.5-1МБ RAM, RTC, АЦП/ЦАП, компараторы. А к ПЛИС придется цеплять внешние микросхемы и организовывать интерфейсы к ним. Да и потребление будет больше на порядок, а то и два. Имхо, синтезируемый проц имеет смысл использовать только если нужна экзотическая периферия и чтоб сидела прямо на системной шине (thruput, latency и всё такое).
  6. ТС порекомендовал бы присмотреться к Lattice machxo и machxo2. Наверно, самое дешевое, что есть из близкого к его потребностям.
  7. А вы официальный дистрибьютор Xilinx? Если нет, то, действительно, проще выкинуть. Думаю, уже нет дураков покупать виртексы у непойми кого, проще эти $500*N сразу в шредер спустить - хоть время не потеряешь.
  8. MMC (eMMC)

    Может не хватает самих данных :biggrin:
  9. Карточка всегда питается от 3 вольт. Если вы переключаете интерфейс в UHS-1, т.е. хотите поднять частоту sdclk до 96-104 МГц, то должны напряжение драйверов со своей стороны изменить на 1.8В, а карточка изменит со своей стороны (у ней внутри LDO), но это никак не связано с объемом.
  10. Странно, что не популярная, Алексей. Мне казалось, что это вполне очевидно для большинства. :wacko: :wacko: :wacko: А чем аргументируют?
  11. Странно, у меня нормально работает synplify, под винду и с бесплатной лицензией. Пользуюсь версией 2017 года, но и в 2015, насколько я помню, все было в порядке с этим. У меня стоят и iCECcube2 и Diamond, может дело в этом? В Synplify когда выбираешь семейство, доступны и ice40 и родные латтисовские. :laughing: У встроенного rc генератора огромный джиттер, больше 10000ppm. И частота прилично различается в разных микросхемах. Если нужен точный (насколько?) клок, поставьте, лучше, внешний генератор с требуемыми параметрами, их сейчас полно всяких. mems генераторы бывают весьма экономичными.
  12. Разницы в инициализации между SDHC и SDXC нет. У SDXC, скорее всего, будет больший ток, особенно если карта более быстрая, например UHS speed class 3 против class 10. Вероятно дело в этом. Проверьте, что нет подброса земли и провала по питанию.
  13. Все в порядке, :disco: они обычно так себя и ведут. То, что в ответе на select приходит stat=stdby, тоже правильно. Карта сначала отвечает, а потом выполняет команду, т.е. ответ отражает состояние карты на момент получения команды. После Cmd7 запросите статус командой Cmd13 - тогда придет уже tran.
  14. Использую по прямому назначению, чтоб избегать инверсии приоритетов. Если в системе с десяток процессов и большинству нужен доступ к разделяемым ресурсам (таким как dma или в5ешняя память), то исключить возможность инверсии приоритетов (и контроля над тем, что происходит) неполучается без этого. Заводить для каждого общего ресурса отдельный поток и очередь сообщений - не вариант (т.к. таких ресурсов много, а ОЗУ всегда в дефиците, да и времени на переключение контекста жалко). А мютексы с наследованием приоритетов решают эту задачу отлично и без дополнительных расходов (ну почти).