Перейти к содержанию

    

prostoRoman

Участник
  • Публикаций

    31
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о prostoRoman

  • Звание
    Участник

Контакты

  • Сайт
    http://
  • ICQ
    474036209
  1. Нажать кнопку "Autodetect". Или смотреть схему в части организации цепочки JTAG.
  2. Указывайте обозначение целиком. 7125 - судя по всему видео-ЦАП - не подходит. 1339 догадываюсь о чём речь, но по "1339" её не найти...
  3. Кажется, может быть достаточно широкошинного ОЗУ, например использования ПЛИС в качестве некоего моста или коммутатора потоков данных.
  4. емнип, чипы с такими нормами Альтера делала только у Интел, а после слияния и подавно, не? Патентуйте свой вариант.
  5. Отключать питание - не? Не нужно искать производителя, обманувшего закон природы - можно нарваться на обман покупателя. (ток утечки ячейки SRAM побороть тяжело, нужно искать спец. семейства) PS: Интел давно пошла в сторону производительности :biggrin:
  6. Самое критичное место в цифровых схемах - это момент смены состояния выхода. Обусловлено тем, что за малое время переключения выхода (до наносекнд и менее) необходимо перезарядить линию и входные ёмкость подключенных к ней элементов (в сумме до сотен пикофарад и более). Таким образом из школьной формулы можно оценить, что при фронте в 1 В/нс для перезарядки ёмкости в 100 пф требуется ( [Ф] = [Кл]·[1/В] = [А]·[с]·[1/В] -> [Ф]·[В] = [А]·[с] -> [А] = [Ф]·[В]/[с] ) 0,1А импульсного тока. И всё бы ничего, но десяток таких ног создаёт на оммическом и индуктивном сопротивлении выводов питания м/с напряжения, достаточные для сбоя цифровой схемы. Оттого и ограничения...
  7. Увеличение статического потребления с уменьшением техпроцесса - это естественное физическое свойство кремниевой микро- и наноэлектроники. Частично или полностью оно может быть компенсировано снижением напряжения питания, но в случае ~1V дипазона снижать дальше слишком трудно при сохранении рабочих частот, вот и растёт потребление. Динамическое потребление должно падать с уменьшением техпроцесса, но тут многое зависит от оптимизации техпроцесса (изделия семейств LP) и оптимизации схемы (тут могут быть и мены типов шин, добавление функциональных блоков к ядру, увеличение кэшей и тд. и т.п.).
  8. Это же есть в разделе "Указания по применению" ТУ. На практике - проблема не тут.ПС: ОП не видел, но 90% что "лишних" резисторов там нет. И даю 100%, что схема ОП не будет ни каким аргументом.
  9. Ещё раз посоветую Вам произвести декомозицию проблемы, сделайте и отладьте простые вещи. Если ресурсы позволяют: 1. Сделайте генератор видео из фреймбуфера. (то, что у Вас на схеме VGA_SYNC_GEN + кусок ОЗУ с картинкой) 2. Сделайте и отладьте свой скайлер. 3. В тупую соедините это дело и посмотрите что Вас не устраивает. 4. Итеративно добавляйте функционал: двойную/тройную буферизацию, синхронизацию и т.д. И не пытайтесь синхронизировать заведомо не синхронные вещи. Ваш входной поток (пиксельрейт) в общем случае не только будет не иметь константного коэффициента с выходным, но и будет плавать во времени и т.д.
  10. У Вас кадровые частоты всегда равны? Если да, то так существенно проще синхронизировать начало вывода картинки с окончанием получения исходной. Тогда может пересмотреть архитектуру формирования вывода? Что если сделать так: 1. По поступлению входного кадра формировать пиксель выходной кадр изображения в выходной буффер (допустим с двумя портами: первый на запись, второй на чтение). 2. Простенькая схема формирования выхода со своим, в общем случае, независимым пиксельклоком формирует выходные сигналы стандартным образом. Если кадровые равны - начало вывода подсинхронизировать к окончанию масштабирования кадра. Если нет - то зависит от задачи. Если транслируется гуй - то можно выводить полкадра старого. пол кадра нового, если качественное видео - тогда всё сложнее. Нужна межкадровая интерполяция.
  11. да я Вам больше скажу, можно даже отправить бумагу за подписью Генерального многотысячного почтового ящика, и вам предёт ответ от менеджера маркетингового отдела, что таки да, работы ведутся и ожидаются такие-то сроки. (да, они так могут) Но и что с того? В те сроки, если вы напомните о себе, они вам скажут, что работы идут, ожидается следующая ревизия и т.д... Короче так и останется "проблема на вашей стороне". Правда, это будет не так или не совсем так, если это ОКР по гос.заказу и т.д. с финансовым риском для них. Тогда, вероятно, работа и м/с будут. Хоть сырые и позже, но будут. И сэмплы и т.д. Но спросить - ни что не мешает ;)
  12. не стОит так уж верить презентациям Миландра... обещанное в них скорее НЕ сбываются. Если разработка серьёзная и нет желания объясняться, что не выполнили её из-за кого-то, лучше использовать проверенные решения. Как минимум, присутствующие в ограничительных перечнях. А это. и вправду, дают. И не на время, а на всегда. Ещё бывала практика давать удалённый доступ к прототипу - круть!
  13. немного оффтоп. Что-то они там интересно рисуют... Ответвления и Rs надо бы местами поменять...
  14. Ещё LC-цепочки... Сейчас на smd тоже можно собрать.