Alex_AZ

На первый взгляд проблему решить удалось, фильтр работает, результаты очень похожи на правду. Прикладываю свои размышления и подход к построению фильтра. Критика приветствуется. За подборку литературы выражаю благодарность TSerg, надо будет ознакомиться. Example.doc

Возможно, я конечно усложняю решение. По Лагранжу, боюсь, что при существенно неравномерном распределении времени прихода отсчетов и интерполятор будет сильно ошибаться. Надо будет попробовать на записи реального сигнала.

Спасибо за вариант решения проблемы. Возможно им и воспользуюсь. Просто кажется, что должен быть какой-то математический аппарат для построения цифровых фильтров с неравномерным временем прихода отсчетов по заданному аналоговому прототипу. По идее, решение задачи связано с решением дифф. уравнений для исходного аналогового фильтра. А для него выходной сигнал однозначно определен в любой момент времени при задании конкретных начальных условий и входного сигнала. Несколько статей получилось нагуглить по запросу "non-uniform sample rate filter", но пока в голове полного понимания не складывается.

То есть предлагаете интерполировать полиномом на определенном интервале времени и затем рассчитать значения в требуемых точках?

В общем-то такой вариант можно использовать. Но видится, что при таком решении может существенно возрасти объем вычислений. Входные данные приходят сравнительно редко, но есть моменты когда частота прихода новых значений возрастает примерно в 30 раз. Не хочется запускать фильтр на частоте в 30 раз выше необходимой в обычном режиме.

Приветствую, уважаемые знатоки! Думаю, многие представляют и делали переход от аналогового прототипа фильтра к его цифровой БИХ реализации. Типовые решения, описанные в литературе предполагают, что частота сэмплирования данных постоянна. А мне сейчас пришлось столкнулся с задачей фильтрации сигнала, где временные интервалы между поступлением новых отсчетов непостоянны, при этом информация о времени прихода каждого отсчета есть. Для фильтра первого порядка все вроде бы ясно - можно модифицировать традиционную структуру фильтра исправляя коэффициенты фильтра в зависимости от интервала времени между приходом отсчетов. Для фильтров более высокого порядка сложнее - в традиционной структуре остается память о нескольких отсчетах выхода системы, интервал между которыми отличается от вновь принятого. И сейчас я не знаю можно ли как-то модифицировать эту структуру для решения своей задачи. Подскажите пожалуйста литературу или методики расчета структур, с помощью которых можно отфильтровать сигнал дискретизированный с непостоянным интервалом.

Можете в FPGA Editor'e в окне "Tools\Direct Routing Constraints" выделить по маске цепи, разводку которых нужно зафиксировать, и экспортировать в файл ucf.

Трассировщик будет стараться сделать так, чтобы данные на выходе второго триггера появились по второму фронту тактового сигнала. От Вас требуется правильно задать временные ограничения (Timing Constraints). Стоит заметить, что если входной сигнал схемы тактируется не от clk и находится в другом частотном домене, то первый триггер может захватить не те данные, которые ожидаете Вы.

Для себя, думаю, побалуемся, попробуем поработать с кодеками. А в товарное устройство поставим дискретные преобразователи. Вот этот момент куда серьезнее, спасибо, что внимание заострили. Чуть было не проглядел.

До сих пор как-то не доводилось работать с аудиокодеками. Сейчас начинаю новую разработку и стою перед выбором: установить отдельные многоканальные ЦАП и АЦП или (что заманчиво) заменить их одним корпусом - аудиокодеком. Но есть требование: аналоговые сигналы на выходе ЦАПа должны изменяться одновременно, а те, что на входе АЦП измеряться в один момент времени. Вопрос в следующем: если для дискретных ЦАПов и АЦП часто явно указывают одновременно(параллельно) ли в разных каналах производится преобразование из цифры в аналог, то для кодеков этой информации не нашел. В качестве последних рассматриваются TI PCM3168A и AD1938. Если кто-то может пояснить/уточнить/ткнуть носом, буду благодарен за соответствующую информацию. Вижу, что судя по структуре измерения/преобразования могут выполняться параллельно, но хотелось бы быть уверенным в этом.

В общем, как и ожидалось, дело было не в ядре MIG, а в неправильной частоте тактирования. Тестбенч сгенерил в ISE, а слона в виде строчки `timescale 1ns / 1ps я и не приметил. На verilog перешел совсем недавно и о таком задании модельного времени не знал, думал что шаг времени - 1ps. Соответственно, замена 1ns на 1ps (ну или деление всех констант времени на 1000) сняла вопрос. А SYSRST держался дольше положенного, т.к. в блок встроена задержка (счетчик) и времени для снятия внутреннего сброса в связи с упомянутыми выше обстоятельствами требовалось в 1000 раз больше.

Сгенерил для Spartan-6 MIG-блок для работы с памятью DDR3. Запускаются модельки из папок example_design\sim\functional и user_design\sim. Ладно, поверим, что xilinx'овские тестовые паттерны отрабатываются нормально. Хочется попробовать написать свои. Подключаю к проекту ISE файлики из папки user_design\rtl, пишу тестбенч. И - "нихт вобла"(с). Поковырялся в симуляторе - вижу, что не выставляется сигнал calib_done. Изучение вопроса показало, что не опускается в 0 сигнал сброса SYSRST блока MCB. Дальше пока не ковырялся. Если кто-нибудь моделировал работу MIG, подскажите пожалуйста, как. Может параметры блока какие-то для режима симуляции сменить нужно? А то пытаюсь работать с этим блоком в первый раз и чувствую, что не в ту степь иду.

Спасибо. Под словами "данные пишутся напрямую" подразумевается DMA? Если не секрет, драйвер самодельный или от Cypress? Просто пока сомневаемся на каком интерфейсе остановиться: pci-e или usb 3.0. Хотелось бы "на берегу" понять какие могут встретиться подводные камни.

А не подскажите, как сильно возрастает загрузка процессора ПК при передаче данных по USB 3.0 (с cypress на комп) на таких скоростях? И конфигурацию тестового ПК.

Было похожее. Лечилось удалением данных для симуляции (Delete simulation data) для этой библиотеки с последующей ее перекомпиляцией.

Если у кого-нибудь есть возможность достать полноценную документацию (а не те 2 листа рекламы в pdf, которые повсюду в инете) на микросхему TDA10048HN, помогите пожалуйста.

Большое спасибо за ответы. Еще один вопрос от глупого меня: констрейны OFFSET используются разводчиком как указание к действию или служат только для проверки выполняются/не выполняются для разведенного дизайна(в смысле развел дизайн, проверил и успокоился)? Если первое, то какими средствами он этого добивается? Только управлением задержками на пинах или еще может варьировать задержки распространения сигналов по внутренним цепям ПЛИС? Правильно ли пропускать тактовый сигнал через линию задержки в IDELAY блока ILOGIC?

Можно, вроде бы все адекватно ISE понимает. На всякий случай можно проверить выполнение констрейнов после PAR'a.

1) Посмотрел в FPGA Editor'e - сигнал идет по пути pad->ILOGIC(где защелкивается триггером IFF1 reg_adc_data1[9] по fpga_clk)-> регистр adc_data1[9]. Т.е. сигналы защелкиваются в pad'ax, хотя явно я ему и не говорил размещать там эти регистры. Надо будет на всякий случай все-таки прописать IOB констрейнты. 2) Не нашел никакой логики в путях синхросигналов. Разводка синхросигнала сделана как описано в приложении bufgmux_sch.jpg. Здесь в ILOGIC - входной буфер(ibufgds). На всякий случай положу еще файл с проектом top.ncd(положил как top.txt, т.к. не разрешает выкладывать ncd-файлы) Да, и еще, Levels of Logic = 2 - это значит, что сигнал где-то проходит через 2 логических элемента? top.txt

Появилась проблема связанная с отсутствием знаний/опыта написания временных констрейнтов. Нужно читать данные с АЦП. Данные приходят через 4,4 нс после тактового сигнала (источник тактов - тактовый генератор, который раздает такты на плис и ацп). На плис данные приходят через 4.4нс после соответствующего восходящего фронта тактового сигнала(период 5нс). Констрейнты пишу так NET "FPGA_CLK2_p" TNM_NET = "FPGA_CLK2GRP"; TIMESPEC "TS_FPGA_CLK2GRP" = PERIOD "FPGA_CLK2GRP" 5 ns HIGH 50%; NET "ADC_D_p[*]" TNM = "ADC_DATA_port"; NET "ADC_D_n[*]" TNM = "ADC_DATA_port"; TIMEGRP "ADC_DATA_port" OFFSET = IN 0.6 ns BEFORE "FPGA_CLK2_p"; В ответ от Timing Analyzer'a получаю следующее И так для каждого разряда АЦП с разницей примерно 100пс между максимльным и минимальным Slack'ом. 1) Вопрос - я чего-то не дописал (или написал неправильно) в констрейнтах? 2) Отчего такое большое время Tidockd, причем одинаковое для всех разрядов АЦП? Судя по данным в даташите Tidockd (D pin Setup/Hold with respect to CLK IOBDELAY_TYPE = DEFAULT - см. стр 26. даташита во вложении) изменяется в диапазоне -5,99..7,63ns (для SpeedGrade = 11). Что мешает PAR'у поставить нужные значения? Может нужно что-то где-то указать. Или я неправильно интерпретирую документацию? ПЛИС - Virtex4 vsx55 Синтезатор Leonardo MAP и PAR - в ISE XC4DataSheets.pdf

Спасибо за ответ. Идея подключить BUFGMUX напрямую к буферам интересная. По крайней мере Timing Analyzer больше не ругается. Может, конечно, будут косяки с тактированием из разных источников - часть схемы от BUFG, другая - от BUFGMUX при передаче данных между этими доменами? В крайнем случае перейду на фифо.

Приветствую. Есть такая задача - нужен контроллер памяти SSRAM. Рабочая частота - до 200 МГц. Режим работы памяти - пишем отсчеты сигнала с АЦП(работает в зависимости от режима на частотах 150-200МГц), затем медленно сливаем их контроллеру USB, который работает на 50 МГц. Но желательно обеспечить возможность писать в память по тактам usb или читать по тактам АЦП. Схематический набросок решения можно посмотреть во вложении. Тактовую частоту работы памяти выбираю с помощью BUFGMUX. Регистры на схеме - некоторая абстракция. По такой схеме идет обмен данными между доменами adcClockDomain, memClockDomain и usbClockDomain. Захватываю данные по падающему клоку, т.к. задержка тактового сигнала при переходе через bufgmux, как мне кажется может испортить сигнал при передаче его из adcClockDomain в memClockDomain. Написал констрейны на тактовые сигналы, на задержки распространения из adcClockDomain в memClockDomain (from-to 2.5ns) и обратно. Аналогично с usbClockDomain и memClockDomain. Теперь со всей этой фигней на борту пытаемся взлететь.(с) 1) Работает сие чудо довольно нестабильно. Бывают пропуски отсчетов. Timing Analyzer ругается на цепи (сигналы статуса, не данные), которые идут из memClkDomain к adcClockDomain. Может я какие-нибудь констрейнты упустил из внимания? До сих пор вообще временными ограничениями на дизайн не пользовался, т.к. проекты были сравнительно низкочастотными и хватало area-констрейнтов, так то просьба сильно не пинать и если нужно, ткнуть мордой в полезную для образовательных целей инфу. 2) Можно ли поставить на выход bufgmux dcm/pmc и передавать данные между adc и mem доменами строго по возходящему фронту тактового сигнала и аналогично между mem и usb доменами? Т.е. привязать по фазе такты adc и mem во время работы с памятью из домена adc и аналогично с usb и mem. Если можно, то как? Дополнительные сведения: девайс - xilinx virtex4 vsx55, синтезатор - Leonardo, MAP-PAR - ISE.

Почему-то не хочет работать "Run ISE Place&Route with ExloreAhead" в PlanAhead. При запуске PAR'a из PlanAhead'a делает инициализацию, потом статус меняется на Queued и все... Больше ничего не происходит. Никаких сообщений и т. д. В хелпе к PlanAhead'у нашел такую запись Что это за $XILINX variable? Если переменная среды (environment variable), то установлена правильно - содержит путь к ISE 10.1 PAR не работает ни с ISE 10.1, ни с ISE 8.1 Подскажите плиз, может что не так делаю?

Посмотрите на сайте Бутис-М, может оно? http://www.butis-m.ru/

Сам в ActiveHDL для этих целей пользую встроенную библиотечку aldec. Библиотека - aldec.rar Руководство по ней - MANUAL.rar