Fourier

Спасибо за ответы. Несовсем понял... Наверное, нужно уточнить. Серверы - независимые устройства, географически разнесенные друг от друга (т.е. в один роутер, концентратор их не подоткнуть) Пока совет_4afc_ видится самым технически простым

Здравствуйте! Стоит задача объединить в сеть несколько удаленных устройств. Устройства являются TCP серверами и имеют доступ в глобальную сеть через GSM/GPRS. Единый пульт управления (клиент) опрашивает показания устройств. Хотелось бы чтоб устройства и пульт управления были объединены в виртуальную сеть. Т.е., например клиент имел ip-адреса 192.168.1.1, а сервера 192.168.1.2, 192.168.1.3 и т.д. Использования сторонних серверов нужно избежать, у клиента может быть статический ip-адрес. Подскажите технологии/протоколы, в направлении которых нужно копать.

В статье вроде супергетеродинный линейный приемник рассмотрен на фиг.3. (и квадратурный) Или это модель обработки ПЧ там нарисована. А так посмотрите Давенпорт В.Б., Рут В.Л. Введение в теорию случайных сигналов и шумов. Параграф 12.3 Там дано выражение для дисперсии отклика квадратичного приемника. Так что, наверное SNR надо оценивать с учетом этих выражений.

У Вас квадратурный приемник или квадратичный?))) Квадратурный прием увеличивает ОСШ на 3 дБ, на сколько я понимаю. За счет некоррелированности квадратурных сигналов.

КЗ нет. Мне тоже кажется, что сдохла. Попробуем заменить. Спасибо.

Нет обрывов нет, все сигналы на месте. Все звонится и проверяется осциллографом/мультиметром. Специально сняли микросхему и отследили все цепи вплоть до контактных площадок. Похоже или бракованная партия или какой-то скрытый деффект платы, или выходит из строя при монтаже. Отличие рабочих и не рабочей плат только в том, что на рабочих платах стоят микросхемы 11 года (ревизия B2), а на нерабочей - 13 Ревизия (B2). Надо было, конечно, считать регистры все... Поспешил я. Будем пробовать менять еще раз. Спасибо за ответ! 1) Частоту мерил, осциллографом правда. 25 МГц, визуально все ОК, сравнивал с рабочей платой. Все похоже вроде. На всякий случай менял кварц - не помогло. В общем буду разбираться после праздников. Отпишусь по результатам)))

1) Схема полностью содрана с SP605. 2) Кварц работает 3) Режимы я не знаю какие, так как собирал схему и код из кубиков, не вникая в детали (что считаю вполне оправданным) 4) По коду у меня вопросов нет У меня было три конкретных вопроса: 1) отличаются ли ревизии. Мне на него дали ответ: да отличаются. 2) не могли бы вы поделиться даташитом и ерратой. Мне ответили - нет, сам аккредитируйся у марвела)))) 3) какой ток должен течь через RSET. В даташите этого нет похоже. Может быть кто-то падение на этом резисторе замерял или может замерить на рабочей плате. 4) Может кто подскажет по процедуре заключения NDA с марвелом. Насколько длительный процесс и что для этого требуется. Всем большое спасибо за помощь! З.Ы. Спасибо за замечание. Может я действительно плохо сформулировал свои вопросы. xtp067_sp605_schematics_copy.pdf

да Это все понятно. У меня и USB отладочный на плате есть. Могу с FPGA считать и вывести все регистры в PUTTY. Надо сесть и сделать))) Проблема в том, что ток через RSET на рабочей плате течет сразу после подачи питания, т.е. до конфигурации. Даже если прошивка в ПЛИС не залита вообще. А на этой - нет. Я поэтому и пытался с железом разобраться, не теряя время на допиливание прошивки. Придется делать считывание. Меня все-таки ток через RSET интересует))).

Там подтягивающие резисторы в кристалле. проверял 4,99 кОм на выходе трансформатор, дальше разъем, дальше витая пара не совсем понял вопрос... дело в том, что PHY не работает совсем нет падения на резисторе RSET нет никаких клоков т.е. до среды передачи дело не доходит. грешен тем, что не считал состояния регистров до снятия микросхемы, так как надо корку было переписывать, а времени не было. Думал, что дефект платы и проблема как то решится быстро по наитию... не решилась. Может кто подскажет по процедуре заключения NDA с марвелом. Насколько длительный процесс и что для этого требуется.

Да дело в том, что у инженеров не всегда достаточно компетенции и времени (может быть первое вытекает из второго) ))) А не в том, что они хотят или не хотят. Спасибо за ссылку)))

ну а как xilinx SP605 серией гонит? Серии кстати не будет))) Теория функционала плотности? Дискретное преобразование Фурье?)))

Спасибо. PQFP коммерческого диапазона, на габариты наплевать

Спасибо большое! Это в еррате? По какой причине рекомендуют. если не затруднит ответить))) Там по току через RSET нет инфы? Но сейчас пока не попробовать. Так как микруха снята, а нам ее не поставить.

По неопытности, наверное. Схема была передрана с SP605, на которой все было отлажено. На макетном образце все работало. Потом еще три платы сделали - вопросов не было. Вот на четвертой произошла вышеописанная ситуация)))

Нет, jtag не подключен. Не подскажите какой ток через резистор RSET течет в нормальном режиме работы в Ваших девайсах? Меня смущает, что на рабочей плате на нем падает 1,3 В. Причем сразу после подачи питания, до конфигурации. А на нерабочей ноль.

ничего так у меня и не получилось запустить... сняли микросхему, плата в порядке вроде. все сигнала от FPGA доходят. прежде чем менять микросхему (для замены надо ехать в мск, так как у нас никто не умеет ставить такие микрухи) надо читать errata, но у меня нет доступа. Может кто-нибудь поделится даташитом и ерратой на ревизию B2E, а лучше на все ревизии. Заранее спасибо

Сегодня удалось рентгеном посмотреть. Деффектов в первом приближении не обнаружили. В общем, пока я в растерянности полной.... Завтра буду допиливать корку для считывания ревизии и т. д. Спасибо за совет. Завтра попробую. Правда корка, которую я использую RESETn выставляет в ноль сразу после запуска на 60 мс. А Вы имеете в виду выставить в единичку, потом в ноль и потом снова в единичку? Т.е. сделать "пересброс")))? Меня только вот смущает, что ток через RSET не идет... С чем это может быть связано?

На чипе рабочей платы написано 88E1111-CAA G370123.1 1120 B2E На нерабочей 88E1111-CAA G3CV 5371A.1 1319 B2E (или 82E) Т.е. похоже ревизии одинаковые, хотя на нерабочей не понятно, что написано толи B2E то ли 82E.

В том то и проблема, что корпус BCC, 96-Leads. Так как в промышленном исполнении PQFP нет

Здравствуйте! Имеется плата со спартаном 6 и marvell 88E1111. За основу взята эта корка, без вникания в детали. Было изготовлено несколько плат, все работало сразу после монтажа. Я считал, что прошивка полностью отлажена и отработана. Однако, из последних двух плат Ethernet на одной не запустился (((. На рабочей плате стоит марвелл 2011 года, а на не рабочей 2013. Пытались проанализиоовать неисправность: питания в порядке, замыканий вроде нет, задающий кварц работает. Однако, нет сигнала RX_CLK, TX_CLK. Так как рентгена нет, а плата 12 слойная проанализировать все детально не получилось. Решили заменить марвелл, отправили в контору, которая занимается монтажом. Однако, после замены та же ситуация: Ethernet молчит, RX_CLK, TX_CLK нет, конфигурация вроде проходит (корка вырабатывает сигнал ready). Так же заметил, что на 5 кОм резисторе RSET падение напряжения нулевое, когда на исправной плате 1,3 В (даже до конфигурации ПЛИС и при отключении клока 25 МГЦ). Вопрос следующий: Может ли это быть связано с ревизией марвела, или стоит грешить на неисправность в железе или печати? Вроде все перепроверил, что мог... Отключал на рабочей плате в прошивке все сигналы кроме reset, mdio и mdc: RX_CLK, TX_CLK в норме, падение на резисторе RSET - 1,3 В. Такое ощущение, что в печати оторван или RSET или COMA...

Вот констрейны на частоту # ADC DCO NET "ADC_DCO_P" TNM_NET = "ADC_DCO"; NET "ADC_DCO_N" TNM_NET = "ADC_DCO"; TIMESPEC TS_ADC_DCO = PERIOD "ADC_DCO" 120 MHz HIGH 50 %; Вот на данные #PIN "ADC_D_*" TNM = "GRP_ADC_DATA"; #TIMEGRP "GRP_ADC_DATA" OFFSET = IN 3 ns BEFORE "ADC_DCO" RISING; #TIMEGRP "GRP_ADC_DATA" OFFSET = IN 3 ns BEFORE "ADC_DCO" FALLING; Ошибок временных нет. P.S. прошу прощения констрейны данных закомментированы оказались. Но вся логика без временных ошибок, включая тот дикий сумматор на 11 элементов, который надо бы переделать. Все похоже оказалось несколько проще))) На борту стоит дистрибьютер AD9515. OUT0 - LVPECL тактирует ЦАП, а OUT1 сконфигурированный как LVDS - АЦП. Так вот оказалось, что peak-to-peak OUT1 по одной линии диффпары порядка 2.5 В, а по второй - 1.4. Причем эти уровни изменяются при нагреве. Т.е. это совсем не дифф.пара и совсем не LVDS(((( Так пока и не разобрался в чем причина, вроде схема по даташитам сделана. На второй плате работает все норм во всем диапазоне температур. Замена микросхемы эффекта не дала, хотя есть подозрение что монтажница повторно установила неисправную. Вот собственно говоря схемы. Дистрибьютер АЦП

Угу, мне тоже странно. Виснет кусок схемы, который вычисляет корреляцию с кодом Баркера. module bin_correlator # ( parameter SPS = 40, parameter CODE = 11'b11100010010, parameter CODE_WIDTH = 11, parameter TRESHOLD = SPS*CODE_WIDTH - 2*CODE_WIDTH ) ( input in_clk, input in_data, input in_reset, input in_enable, output reg out_threshold, output reg out_peak, output reg [CODE_WIDTH - 1 : 0] out_data ); // Ширина регистра с задержанными данными localparam D_WIDTH = SPS*(CODE_WIDTH + 1); localparam SUM_WIDTH = 8; localparam MUL_WIDTH = 10; // Буфер для сохранения задержанных двоичных данных reg [D_WIDTH - 1 : 0] delayed_buf; // Буфер с суммами на отсчет reg signed [SUM_WIDTH - 1 : 0] sum_buf [CODE_WIDTH-1 : 0]; // Буфер с корреляционными произведениями reg signed [SUM_WIDTH - 1 : 0] corr_mul_buf [CODE_WIDTH-1 : 0]; // Буфер, хранящий значения вычисленных ВКФ reg signed [MUL_WIDTH - 1 : 0] sum_mul; // Буфер с добавками к сумме reg signed [2 : 0] add_buf [CODE_WIDTH-1 : 0]; // Буфер с кодом свертки reg [CODE_WIDTH-1 : 0] code = CODE; reg _is_old_threshold; reg signed [MUL_WIDTH - 1 : 0] _old_corr_func; // reg signed [MUL_WIDTH - 1 : 0] _corr_func; // wire _is_threshold = (_corr_func >= TRESHOLD); integer i; initial begin reset_task(); end always @(posedge in_clk) begin if(in_reset) begin reset_task(); end else begin process_task(); end end // Процесс обработки данных task process_task; begin // Сдвиг данных в регистр delayed_buf <= {delayed_buf[D_WIDTH - 2 : 0], in_data}; sum_mul = 0; // Вычисление сумм на символ for(i = 0; i < CODE_WIDTH; i = i + 1) begin // Вычисление добавки к символу add_buf[i] <= $signed({delayed_buf[i*SPS], 1'b1}) - $signed({delayed_buf[(i + 1)*SPS], 1'b1}); // Вычисление суммы на символ sum_buf[i] <= sum_buf[i] + add_buf[i]; // Вычисление значений символа out_data[i] <= $signed(sum_buf[i]) < $signed(0); // Вычисление корреляционных произведений corr_mul_buf[i] <= code[i] ? -sum_buf[i] : sum_buf[i]; // Выисление суммы корреляционных произведений sum_mul = sum_mul + corr_mul_buf[i]; end // _corr_func <= sum_mul; // out_threshold <= (sum_mul >= TRESHOLD); // Save old Function State _old_corr_func <= _corr_func; // Save old threshold state _is_old_threshold <= _is_threshold; // Correlation Peak out_peak <= (_is_old_threshold) & (_corr_func < _old_corr_func); end endtask // Процесс сброса task reset_task; begin code <= CODE; for(i = 0; i < SPS*CODE_WIDTH + 1; i = i + 1) begin delayed_buf[i] <= 1'b0; end; for(i = 0; i < CODE_WIDTH; i = i + 1) begin sum_buf[i] <= SPS - 1; add_buf[i] <= 0; out_data <= 0; end end endtask endmodule

Спасибо за совет. Я так и сделал сейчас, правда еще есть схема мониторинга состояния DCM и сброса при отсутствии захвата. Но в первом приближении косяк остался, завтра буду продолжать разбираться, может что-то не корректно сделал. Еще вопрос до кучи))) Чем отличается STATUS[1] от INPUT_CLK_STOPPED Clocking Wizarda. Не могу нигде найти. По тестбенчам они совпадают вроде. P.S. А ничем и не отлчаются они assign INPUT_CLK_STOPPED = status_int[1]; Подскажите, пожалуйста, а можно ли и захват данных сделать от DCM, так как у меня BUFG дефицит. Если делать так как Вы говорите, по моему, нужно 2 BUFG на ввод дифф. тактовой пары, от них на IDDR2 синхронизацию подать и их же завести на вход DCM, плюс один BUFG - выход DCM. Или я что-то не так делаю))) Буду очень рад советам. Вот старый вариант кода сбора данных (без DCM, который отказывает на морозе). От out_dclk тактируется остальная логика. Покритикуйте, пожалуйста. Может где подводные камни есть. module ad9613_rx # ( parameter DIFF_TERM = "FALSE" // Parameter to enable internal differential termination ) ( // Данные input [ADC_WIDTH - 1 : 0] in_data_p, input [ADC_WIDTH - 1 : 0] in_data_n, // Синхронизация input in_dco_p, input in_dco_n, input in_adc_or_p, input in_adc_or_n, // Выходы output out_dclk, output reg [ADC_WIDTH - 1 : 0] out_data_0, output reg [ADC_WIDTH - 1 : 0] out_data_1 ); localparam ADC_WIDTH = 12; wire w_dco_p; wire w_dco_n; wire w_dco_bufg_p; wire w_dco_bufg_n; wire [ADC_WIDTH - 1 : 0] w_rx_data_in; wire [ADC_WIDTH - 1 : 0] w_rx_data_in_fix; wire [ADC_WIDTH - 1 : 0] w_rx_data_0; wire [ADC_WIDTH - 1 : 0] w_rx_data_1; // Выходной клок assign out_dclk = w_dco_bufg_p; parameter [ADC_WIDTH - 1 : 0] RX_SWAP_MASK = 12'h0000; // pinswap mask for input bits (0 = no swap (default), 1 = swap). Allows inputs to be connected the wrong way round to ease PCB routing. genvar i; // Входной буфер для клока (формирует дифференциальные сигналы IBUFGDS_DIFF_OUT IBUFGDS_DIFF_OUT_ADC_DCO ( .O(w_dco_p), // Buffer diff_p output .OB(w_dco_n), // Buffer diff_n output .I(in_dco_p), // Diff_p buffer input (connect directly to top-level port) .IB(in_dco_n) // Diff_n buffer input (connect directly to top-level port) ); // Заводим в глобальную шину синхронизации BUFG BUFG_ADC_DCO_P ( .O(w_dco_bufg_p), // 1-bit output: Clock buffer output .I(w_dco_p) // 1-bit input: Clock buffer input ); BUFG BUFG_ADC_DCO_N ( .O(w_dco_bufg_n), // 1-bit output: Clock buffer output .I(w_dco_n) // 1-bit input: Clock buffer input ); // Генерация входных буферов generate for (i = 0; i < ADC_WIDTH; i = i + 1) begin : loop0 // Входной дифф. буфер IBUFDS #( .DIFF_TERM (DIFF_TERM)) data_in ( .I (in_data_p[i]), .IB (in_data_n[i]), .O (w_rx_data_in[i]) ); // При необходимости проводим инверсию данных assign w_rx_data_in_fix[i] = w_rx_data_in[i] ^ RX_SWAP_MASK[i]; // Invert data signals as required // DDR IDDR2 #( .DDR_ALIGNMENT("C0") // Sets output alignment to "NONE", "C0" or "C1" ) IDDR2_D0D1 ( .Q0 ( w_rx_data_0[i] ), // 1-bit output captured with C0 clock .Q1 ( w_rx_data_1[i] ), // 1-bit output captured with C1 clock .C0 ( w_dco_p), // 1-bit clock input .C1 ( w_dco_n), // 1-bit clock input .CE (1'b1), // 1-bit clock enable input .D (w_rx_data_in_fix[i]), // 1-bit DDR data input .R (1'b0), // 1-bit reset input .S (1'b0) // 1-bit set input ); end endgenerate // Защелкиваем выходные данные always @(posedge out_dclk) begin out_data_0 <= w_rx_data_0; out_data_1 <= w_rx_data_1; end endmodule

Здравствуйте! Имеется плата с АЦП, ЦАПом и Spartan-6 на борту. Тактирование АЦП и ЦАП осуществляется синтезатором через дестрибьютер тактовых сигналов, частота дискретизации 125 МГц. Дифф. тактовый сигнал от АЦП заводится в глобальную шину синхронизации и используется для синхронизации модулей ЦОС. Сигнал сброса на эти модули естесственно выдается с задержкой после включения. Проводили испытания на климат и на морозе плата стала сбоить. Я сделал тестовую прошивку с возможность сброса части логики и оказалось, что сбоит логика тактируемая этим сигналом при прогреве платы во время работы. Начал экспериментировать - замыкать входы синхронизации и действительно при кратковременном пропадании тактового сигнала логика перестает работать навечно. Предполагаю, что при прогреве платы происходит кратковременное изменение фазы или частоты схемы тактирования. Однако, повторный сброс части логики ПЛИС решает все проблемы. Подал клок АЦП на DCM и стал мониторить его сигналы LOCKED, STATUS, CLK_VALID, CLK_STOPPED. Сделал конечный автомат, отслеживающий их и формирующий сброс. И снова стал замыкать дифф. пару. В 90 процентах случаев конечный автомат вырабатывает корректный сигнал сброса и работа логики восстанавливается. Однако, иногда при кратковременном пропадании клока все сигналы DCM говорят о том, что все хорошо, а логика моя не работает, поскольку я ее не сбросил. (((( Ну об этом и UG382 говорит, как я понял, типа не рассчитывайте особа на сигналы состояний DCM. Вырабатывать сброс периодически не хочется. Вопрос в следующем: как можно железно отследить кратковременные сбои тактирующего сигнал и сформировать сигнал сброса для логики тактируемой им? Конечно, можно и с задающей схемой еще поковыряться, но мне не нравится такой расклад: клок пропал - все перестало работать на вечно, даже после его восстановления((((( Заранее спасибо

Всем спасибо за ответы! eugen_pcad_ru Ну, наверное, можно и его использовать. Для начала, определив полосу сигнала one_eight_seven А какие? Я только Герцеля знаю. Ссылочками не поделитесь. stealth-coder Надо понимать, что дополнение нулями во временной области это просто ИНТЕРПОЛЯЦИЯ в частотной, а не повышение точности в смысле увеличения количества информации, 100500 миллионов дополнительных нулей никакой информации не несут, т.к. сгенерированы искусственно, а не получены из источника. Это понятно. Но насколько я понимаю, это самая эффективная интерполяция. Особенно для коротких сигналов. Вот примерчик. Точек в исходном сигнале, по моему или 16 или 32. Истинная частота - 0,231. На первом рисунке результат БПФ На втором интерполяция кубическими сплайнами На третьем - дополнением нулями. Кубические сплайны сильно смещают оценку