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

    

Kluwer

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

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

  • Посещение

Репутация

0 Обычный

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

  • Звание
    Местный

Контакты

  • Сайт
    http://havukosken.ru/
  • ICQ
    0

Посетители профиля

2 119 просмотров профиля
  1. Ну, приходите ко мне на лекции, тем более в СПб живёте, я вам расскажу про Френелевские, Фраунгоферовские, "дальние" и "ближние" зоны. Как раз читаю эти темы третьекурсникам :) Ибо то, что вы написали - это, простите, какие-то ваши внутренние представления, с учебниками по электродинамике и распространению радиоволн они как-то вообще никаки не стыкуются :)
  2. Из этой статьи, я так понял, что модель работает на частотах от 20МГц. Если речь идёт о 20МГц, то длина волны около 15м. Соотвественно, для антенны, работающей на такой длине волны, "ближняя" (френелевская) зона может простираться на десятки метров, поэтому, вероятно, авторы и подстраховались километром.
  3. Сравнивать не сравнивал, но c LwIP реально много работал. Мне там нравится, что всё доступно, структурировано и понятно. Нужно свой протокол поднять - пожалуйста, нужно DHCP включить - пожалуйста. Я бы даже сказал, что LwIP-стек - это редкий случай софта, написанного прямыми руками, отлично отдокументированного и где не надо неделями сидеть, распутывая хитросплетения кода какого-нибудь чокнутого перфекциониста, что бы написать простые вещи.
  4. Свою толику добавлю. 2-3 часа для серъёзного проекта для 5го "Стратикса" - это совсем не катастрофа. У нас был проект для 4го "Стратикса", к-рый по 6 часов собирался! Правда, было это уже почти 8 лет назад и компы тогда по-ленивей были. А так, да: 1) более мощный комп (лучше нормальный, а не ноут: ноуты при перегреве часто понижают частоту проца никак об этом не сообщая), важнее число ядер, нежели частота. Мощную КУДовую видеокарту с поддержкой "openCL" тоже не помешает и ssd-диск; во время работы сборщика старатся ему не мешать: повырубать весь навесной софт, желательно даже отрубить сеть. Ну и уж точно на том же компе не стоит смотреть одновременно порнуху в HD-качестве :) 2) настройки проекта (ставить "нормальные усилия"; если не нужно по клокам "тапку в пол", то ставить оптимизацию "баланс" и т.д.); 3) таймквесты старатся использовать в максимально щадящем режиме. Не нужно, например, фильтру, работающему на 200МГц выставлять требования в 300МГц (знаю таких любителей: "а чё? В даташите сказано, что и на 450 должон работать!"); 3) разбиение проекта (создать партишины, поставить всем "пост-фит" и т.д), иногда осмысленен "лоджик-лок" (хотя и не люблю этот инструмент-костыль); также часто имеет смысл 4) кодчекинг. Если есть процессор в системе, или на борту плисины, то всё что можно - пихать в него. Во всяких мегафункциях давать сборщику по-меньше самодеятельности (минимум опций в положении "авто"). Если DSP-мегафункции сразу включать "распихивать по DSP-блокам". Не лениться проверять весь код на наличие всяких глупостей, типа немерянных коммутаторов и прочего мусора.
  5. Спасибо, но, к сожалению, это пример с НИОСом. Нам нужно без софтовых процессоров.
  6. Обычный DDC на ПЛИС

    А разработчиков аналогового фронт-энда нельзя там пнуть? Типа, ребята, перенесити промежуток на 60МГц, или, например, на 300? И корректирующий фильтр такого невменяемого порядка (180!!) рельно осмысленно ставить? Не проще на обычных КИХ-фильтрах со ступенчатым понижением частоты давить?
  7. Коллега, Иосиф прав абсолютно, если у вас шина (а не один бит), то тут никакая абсолютно асинхронщина не допустима. Я даже не буду объяснять почему, полно лит-ру по этому вопросу. Причём, если у вас переход шин, то варианта, по-сути, только два: а) навороченный автомат в стиле связнЫх протоколов (а в реальности вы, скорее всего, по-просту поставити стэк (Фифошку); б) жёсткая завязка клоков на ФАПЧе (PLL). В вашем случае, чтения потоковых отсчётов с ацп, скорее всего, вообще только второй вариант доступен. Соотвественно, клок должен быть тот же, что используется ацп (сам он генерит, или внешний), дальше (например, у вас квадратурный детектор с последующим прореживанием (децимацией) либо генерите дочерние клоки на ФАПЧ (в sdc можно их объявить автоматически derive_pll_clocks), либо делите на регистрах (только не на логике!) и тащите либо кратные частоты как таковые, либо тащите исходный клок с прореживающими стробами (каждый вариант имеет свои достоинства и недостатки). Только так, иначе метастабильности приведут к тому, что вы будете бегать вокруг девайса с криками "да это мистика какая-то! как такое может быть вообще?!" :).
  8. Ну, я не знаю какой у вас камень используется, но, например, в Стратиксах, вот есть такая тема, например: Stratix ... LVDS transmitters support programmable pre-emphasis and programmable VOD. Pre-emphasis increases the amplitude of the high frequency component of the output signal, and thus helps compensate for the frequency dependent attenuation along the transmission line ... Ну, по-моему, если по входу вам помогла терминация, то это возможно говорит о том, что у вас на плате проблемы. Например, погонные ёмкости очень большие, не нагружен грамотно приёмник lvds-линии с вашей плисины и т.д. и т.п.
  9. Да тут в том и проблема. Проект разросся до колоссальных размеров, 3 плисовода разного уровня одновременно копошатся в здоровенной каменюге и даже со всеми оптимизациями и Post-fit -партишинами, малейшее телодвижение - и 1,5 часа пересборки. Есс-но, всё что можно моделируется, делаются упрощённые подпроекты, сигнальная часть вообще вся из DSP builder'а и т.д., но всё равно всё не промоделируешь, да и у Квартуса и Моделсима несколько "разные взгляды" на то, что правильно, а что нет. И вываливается в результатет сборки типично под 2 тысячи варнингов, не всегда и уследишь. Да и смотрю в репорты, да, если шина имеет большую разрядность, чем порт, то он ругается действительно, типа "truncated value with size xx to match size of target (yy)". А вот в обратной ситуации молчит, как партизан. Да и нам бы очень желательно, что бы уровень такого вот варнинга можно было поднять до еррора. Что бы он вообще прекращал сборку в случае подобного несовпадения.
  10. Коллеги, не могу найти нужных настроек в Квартусе, что бы он более жёстко проверял правила в hdl-коде наподобие Ксайлинксовского ISE/Вивадо. Ну, например, что бы выкидывал ошибки, если используется не объявленный провод, или если входная разрядность не соотвествует входной (а не забивал молча нулями старшие разряды) и т.д. и т.п.
  11. Да, это, похоже, информация в нужном направлении, спасибо.
  12. У них явно опечатка какая-то на сайте. Ни одна версия не работала никогда вот только с одной-единственной версией Матлаба. Мы штатно юзаем не 18, но недавно пришлось использовать 18ую, делали сжатие сигналов в ДСП-билдере, на базе вообще версии 8.1.0 (2013а) всё прекрасно работало. Единственно, по началу генерация кода из модели шлёпалась пока Java-машину не обновили. После этого и генерация в лёт.
  13. Кстати, да, по собственному опыту если всё начинает рушится после подключения, или каких-то телодвижений в СТП - это 100% неправильные или вообще отсуствующие врЕменные ограничения. По-хорошему, после первого эскизного набора проекта, если ожидаются тактовые частоты выше 40-50МГц нужно сесть, не поленится и потратить время на грамотное заполнение sdc'шника. Иначе начинаются битвы с "песочным человеком" :(
  14. Коллеги! Работаем сейчас над здоровенным проектом для альтеровской плисины и есс-но всё, что только можно вытащить для внешних настроек через MCE, вытаскивается наружу. Но, в результате в окне MCE уже просто каша из различных параметров и массивов. Хотелось бы научится ваять собственный софт, что бы мимо MCE подключатся к jtag-серверу и закачивать/выкачивать выбранные параметры и представлять их в удобном нам виде. Вот никто не сталкивался с такой задачей или, хотя бы, может указать направление поиска информации?