ilynxy

Дано: витая пара + трансформатор + обычный 10/100 phy. Понятно, что скорость 100Мбит максимум. А хотелось бы немного больше (ну скажем 200Мбит). Гигабитный phy не вариант (жрёт много и ещё две пары надо). Вот почему нет ничего в промежутке 100М - 1G? Собственно вопрос: а нет ли таких хитрых PHY чтобы частоту можно было регулировать на внутренней PLLке или снаружи можно было подавать? Или пусть даже это будет SERDES 10 бит, но штобы его можно было нацепить на трансформатор. То есть мне надо сохранить совместимость со 100 Мбит ethernet на физическом уровне, но, при случае, если на другой стороне будет такой же хитрый phy, задирать частоту.

Назовём это "сниффер траффика FC". С режимом N_port так и не разобрался, было принято волевое решение о подключении "в разрыв"/"в разветвитель" (то бишь просто пассивный слушатель на линии), что значительно упростило жизнь.

По поводу цифрового фильтра и функции freqz: фильтр и децимация реализованны в чёрном ящике и нужно получить "натурные" результаты, я не анализирую коэффициенты фильтра (с ними всё понятно), а показываю (чтобы убедиться, что я понимаю правильно), что методика измерения путём подачи на вход ступеньки и затем дифференцирования ответа чёрного ящика (для получения АЧХ, например) неприменима для нестационарной (not time-invariant) системы, коей является дециматор. Более того, даже привожу функцию которая описывает соотношение между "ожидаемым" и "измеренным" результатом. А по поводу вставки нулей между коэффициентами фильтра -- результат будет отличаться от дифференциала децимированного ответа на ступеньку. КИХ фильтр, как его не крути, будет линеен и стационарен. А вот децимация уже нестационарная (на пальцах: меняется "дельта" времени). Ещё раз: я спрашивал про неприменимость метода "ступеньку на вход -> дифференциал -> FFT" для построения АЧХ произвольной системы (в частности нестационарной), а не про анализ характеристик фильтра.

Виноват, исправлюсь. Я имел ввиду linear time-invariant (LTI), использовал только термин linear, забыв про time-invariant. По русски это, если верить Википедии, переводится как "линейная и стационарная". То есть операция децимации линейная, но не стационарная. Так правильней, наверное. И, да, после добавления в конец скрипта, вот этих строк: x_diric = [0:0.001:1]; y_diric = 20*log10(diric(x_diric*pi,k)); plot(Fx, PRy, Fx_decim, PRy_decim, x_diric, y_diric); В моей голове всё окончательно уложилось. Собственно передаточная функция фильтра "бегущее среднее" (знакома по расчётам CIC фильтров).

http://electronix.ru/forum/index.php?showtopic=61830 А вот товарищи давно уже сделали правильный вывод. Но сразу эту ветку я не нашёл. Просто для меня несколько контринтуитивно, что децимация является нелинейной операцией. Ну подумаешь повыкидывали отсчеты, делов то )

Спасибо за наводку про LTI. Действительно дециматор не является LTI поэтому применять дифференциацию функции Хэвисайда неправомерно, сначала нужно привести в тот же временной домен (interpolate), что приведет (в идеале) к недецимированному сигналу. Значит остается только один способ - ГКЧ. Спасибо всем, в голове всё уложилось.

Возможно я что-то плохо понимаю. Вот как я это представляю: а) у меня есть чёрный ящик с передаточной функцией y = H(x); б) мне необходимо получить АЧХ и ФЧХ этого чёрного ящика; в) в идеальном моделировании на вход подаётся дельта-функция и по ответу делаются выводы в1) в неидеальном мире дельта-функцию имитировать сложно, более того, я знаю, что чёрный ящик содержит АЦП и КИХ-фильтр, поэтому я принимаю решение подать на вход функцию Хэвисайда. Исходя из того что дельта-функция d(x) есть производная от функции Хевисайда Hevi'(x), я делаю предположение что, y = H(d(x)) = H'(Hevi(x)). Иными словами, ответ передаточной функции на дельта импульс равен дифференциалу ответа передаточной функции на функцию Хэвисайда. Очевидно, что это неверно в общем случае. Однако во множестве источников предлагается такой метод, наряду с использованием генератора качающейся частоты (теста синусоидами на разных частотах). Характер полученной АЧХ я могу объяснить и понимаю, почему он получается "заваленым". После децимации дифференциал от функции Хевисайда получается усреднённым по степени децимации (то есть усреднение по двум отсчётам в случае децимации в два раза или по четырём в случае децимации в четыре раза). И выходная характеристика получается произведением АЧХ КИХ фильтра и АЧХ "усреднятеля по двум/четырем/n-отсчётам" (это sinc функция). Собственно завал на графике и есть спад sinc функции. Отсюда возникает вопрос: а как всё-таки правильно исследовать АЧХ/ФЧХ чёрного ящика имея генератор сигналов и осциллограф/рекордер? Если исследовать дельта-функцией, то какой длительности она должна быть? Если исследовать функцией Хэвисайда, то по очевидным причинам дифференциал ответа на функцию Хэвисайда в общем случае не равен ответу на дельта-функцию. Если исследовать с помощью ГКЧ упираемся в неидеальность генератора (всё-таки сгенерировать ступеньку с условно бесконечным спектром несколько проще чем синусоиды на разных частотах). Если честно, я не понял, что именно нарушено? Грамматика, содержание?

Доброго всем. Уважаемые! Поясните пожалуйста, почему после децимирующего FIR "классический" анализ ответа фильтра на ступеньку (единичная функция) выдаёт неправильные результаты. А анализ ответа на ГКЧ (или просто на набор синусоид) -- правильные. Вот код MATLAB, где я моделирую подобное измерение: % классическая ступенька x = [zeros(1, 1024*m) ones(1, 1024*m)]; % Фильтр на ~1/4 исходной полосы, с подавлением 100 dB Fp = 0.20; Fst = 0.25; Ap = 0.0001; Ast = 100; hf = design(fdesign.lowpass('Fp,Fst,Ap,Ast', Fp, Fst, Ap, Ast)); % Фильтруем сигнал y = filter(hf, x); % Децимируем в 4 раза (имеем право, теорема Котла не нарушена, отрезали % всё что выше с помощью FIR фильтра) k = 4; y_decim = downsample(y, k); % классика жанра: FFT от дифференциала ответа на ступеньку PRy = 20*log10(abs(fft(diff(y)))); % и для децимированного сигнала PRy_decim = 20*log10(abs(fft(diff(y_decim)))); % Рисуем спектр Fx = [0:length(PRy)-1] / length(PRy) * 2; Fx_decim = [0:length(PRy_decim)-1] / length(PRy_decim) / k * 2; plot(Fx, PRy, Fx_decim, PRy_decim); И получается, что после децимации дифференциал ответа на ступеньку даёт завал АЧХ в конце где-то на 3 dB. Если поэкспериментировать с децимацией (например, сделать в два раза), то завал уменьшится. Собственно вопрос: почему так происходит? И попутный вопрос: как исследовать характеристики фильтра "в живой природе"? Получается, что если фильтр децимирующий, то исследовать его характеристики методом подачи "единичной функции" нельзя? В более общем случае: если я не знаю характеристики системы и мне нужно построить её АЧХ, то я не имею права исследовать воздействуя на неё единичной функцией и получая спектр дифференциала ответа?

Добрый день. Проконсультируйте пожалуйста по вопросу миграции с Cypress SX2 на FX2LP в режиме Slave FIFO. Что есть: FPGA <-> SX2 SSOP56. Всё радостно работает и вполне устраивает, кроме температурного диапазона (хотя все использованные чипы SX2 работают на -40 °C, что удивительно) и потребления (что косвенно объясняет почему оно работает на -40 °C -- видимо быстро разогревается, ибо лопает как не в себя). И устарел чип лет десять назад. Хотелось бы: FPGA <-> FX2LP SSOP56. После перелопачивания интернетов и этого форума так и не удалось найти информации по взаимодействию мастера (FPGA) и FX2LP (в режиме Slave FIFO). С обменом bulk пакетами по USB endpoints всё понятно (ничем не отличается от SX2). Но совершенно непонятно, как, к примеру, проинформировать мастера о возникновении события SET_CONFIGURATION/USB_CONNECT/USB_DISCONNECT или как мастер может установить/сбросить STALL на какой-нибудь endpoint. Это необходимо для реализации протокола обмена по USB и общего функционирования устройства. В SX2 для этого есть командный интерфейс (дополнительная нога ADDRESS[2] для адресации и INT#, RDY для квитирования событий) -- события приходят и состояние endpoint'ов управляется. В FX2LP такого интерфейса нет. Есть 3 (или 4) свободные ноги GPIO, но после беглого прочтения datasheet и TRM сложилось впечатление, что один-в-один как SX2 интерфейс не реализовать (или есть варианты?) В голову приходит только идея применить неиспользуемые FIFO (поскольку для передачи данных по USB задействовано всего два endpoint'а) для реализации двустороннего обмена между 8051 <-> FPGA: мастер пишет в одно FIFO команду (некую определённую последовательность байт) и ожидает в другом FIFO подтверждение и статус выполнения этой команды, в это же FIFO вываливаются коды необходимых событий, а мастер мониторит состояние этого FIFO. Собственно вопрос: как правильно (и с минимальными затратами) организовать обмен между мастером и FX2LP? И реализуема ли идея предложенная выше?

Добрый день. Возникла проблема с реализацией приёмника FC фреймов Class 3. Соорудил приёмопередатчик FibreChannel 1Gb на Cyclone IV GX + какой-то узкоглазый оптический конвертер (Optronic). Задача -- принимать кадры Class 3. Реализовал машину из FC-FS-2, раздел 7 FC_Port state machine: битовая синхронизация успешно, link protocol поднимается до AC (active state). Затем внешнее устройство посылает некий фрейм Class 3 (SOFi3-EOFt), на что я отвечаю R_RDY (если я правильно понял раздел 17.5 buffer-to-buffer control), в остальных случая Idle. И вот тут случается непонятная мне вещь: через некоторое время (предполагаю, что на отправителе происходит E_D_TOV) линия переходит в Link Reset и переинициализируется. Затем всё повторяется. Собственно вопросы: 1. Что минимально необходимо для реализации приёмной ноды FC для фреймов Class 3? 2. Нужно ли обрабатывать BB_SCr и BB_SCs? 3. Когда "правильно" отправлять R_RDY? После приёма SOF, в течении фрейма, после приёма EOF? В документации никакой конкретики нет, а точнее я сделал вывод что всё равно когда. Всё ещё усугубляется тем, что железки-сендера на столе для отладки у меня нет (а если и будет, то залезть в неё и посмотреть почему происходит reset link не могу). Есть какой-то HBA в PCI-порту, который в принципе делает всё что надо, но, насколько я понимаю, для поднятия линка ему требуется нечто большее чем просто отвечать R_RDY на его фреймы Class 3. Буду рад любому указанию на возможные грабли и/или толковую документацию.

Есть PHY Marvell 1112 с интерфейсом SGMII, подключен к Cyclone IV GX, трансивер сконфигурирован в GIGE. Физически линк поднялся, байты туда-сюда шлёт. Вопрос: насколько точно нужно следовать протоколу Ethernet? Например: 1. нужно ли отправлять "правильные" IDLE последовательности, в зависимости от running disparity (/I1/ или /I2/). Однако на деле работает если просто отправлять /I2/ (этого достаточно для синхронизации SGMII линка), может быть PHY сам распознаёт (про то, что GIGE правильно подменяет IDLE кодовые группы в зависимости от чётности написано в даташите на трансивер)? 2. нужно ли правильно формировать End_of_packet? То есть /T/R/ или /T/R/R/ в зависимости от "количества байт". На деле, опять же, работает если просто делать /S/<d>...<d>/T/, PHY сам формирует правильную терминирующую последовательность? 3. если PHY выдал мне SOP, потом данные, а тут вдруг /V/ (Error_propagation), то придёт ли EOP? То есть следует ожидать такого поведения /S/... /V/ ... /T/ или такого /S/ ... /V/? Если взять интерфейс GMII, то генерацией "правильных" idle/sop/eop занимается PHY и помогать ему не надо (да и нечем). SGMII работает так же? Или он ближе по идеологии к простому "преобразователю уровней" и надо полностью следовать протоколу, а то, что "и так работает" — счастливая случайность? Нигде не могу найти подробное описание взаимодействия по протоколу SGMII. Бумага от Cisco не содержит ровным счётом никаких деталей на этот счёт(единственно оттуда почерпнул про autonegotiation PHY-MAC/config_reg). Да, можно написать машинку, которая будет полностью соответствовать стандарту 802.3, чтобы быть спокойным исходя из предположения, что PHY простой преобразователь уровней, но надо ли и не будет ли это проблемой? UPD: Почитал внимательно бумагу Cisco — требуется полнценная реализация. Просто при беглом чтении не заметил, что там ссылки на диаграммы состояний из 802.3. Будем знать, извиняюсь за asking before googling.

Спасибо за ответ. Насчёт 100МГц DDR я даже не сомневаюсь — на Cyclone III успешно запускал RGMII (125MHz x 4 bit, DDR), да и по даташиту на Cyclone IV обещают 250 MHz DDR (но это наверное только при хорошей погоде). В предстоящей битве меня пугают пару вещей. Первая — переключение асинхронный/синхронный интерфейс. При этом "привычные" ноги меняют своё значение: например !WE становится CLK. Как щаз вижу мультиплексированние клока высокой частоты и сопутствующие огороды констрейнов. Второе — при чтении микросхема сама генерирует клок сопровождения данных DQS (но этого мало, он ещё и двунаправленный, при записи, наоборот, нужно на нём генерировать сопровождающий клок), причём временные характеристики этого клока и данных не слишком удобные (не утверждаю — беглое чтение даташита), как бы не пришлось его поворачивать на PLL, чтобы втиснутся в констрейны из-за задержек входных/выходных пинов. Всё это очень напоминает DDR память, но увы и ах, я с ней никогда не работал поэтому смотрю на этот интерфейс как баран. Ну попытка не пытка, попробую разобраться =).

Использую в своих проектах микросхемы NAND flash от samsung K9WA* и подобные. Но с недавних пор выросли требования к пропускной способности: в скорость чтения/записи страниц не упираюсь, но параллельный асинхронный интерфейс flash памяти стал узким местом (если верить даташиту то пик ~40 МГц x 8 бит). Сейчас шина данных распараллелена на 4 микросхемы (32 бита), что в теории может дать ~150 МБайт/сек, а на практике (с учётом циклов адреса и прочего управления) у меня получается ~120 МБайт. Дальше параллелить уже не могу и вообще асинхорнные интерфейсы не комильфо, а хотелось бы не менее 200 МБайт/сек. Вот такие есть микросхемы MT29F* у Micron (аналогичные у других производителей). У них есть режим работы: синхронный интерфейс DDR типа, обещают 200 MT/s per pin, что меня очень устраивает. После беглого чтения даташита выяснилось, что после включения питания микросхемы по умолчанию находятся в асинхронном режиме и, чтобы их перевести в синхронный надо выдать некоторую последовательность команд. Собственно вопросы: - есть у кого положительный опыт прикручивания подобного интерфейса к ПЛИС (Cyclone IV или стоит выбрать другую)? - какие ожидаются грабли (например про переключение асинхронный/синхронный интерфейс и сможет ли ПЛИС обеспечить 200 MT/s в DDR)? - есть ли что-то готовое, что можно посмотреть/использовать? Готовые контроллеры, вроде mass storage, скорее всего, не подойдут, поскольку есть свои требования к корректирующим кодам, распределению информации и т.п. Интересует собственно самый низкий уровень: "записать байт/считать байт".

Подскажите пожалуйста, где можно добыть документацию FC-AE-ASM, FC-AV (ARINC-818) и связанных с ними. Покопался в интернете (безуспешно пытался что-то скачать с сайта http://www.t11.org), поискал на форуме и ничего не нашёл (если я плохо ищу дайте, пожалуйста, прямую ссылку). Интересует описание содержимого фреймов: где какие байты и что они означают (т.е. видимо уровни FC-2 — FC-4, пока не силён в терминологии).

Подскажите пожалуйста, можно ли так исхитриться чтобы сделать, детектор уровней на LVDS шине? Вот типовая схема Bus LVDS из an522.pdf. Хотелось бы определять состояния на пинах когда 'p = 1 и n = 1' или 'p = 0 и n = 0'. Quartus обязательно требует, чтобы такие пины были подключены к дифференциальному приёмнику, если я пытаюсь подключить какую-либо логику до дифф-приёмника оно ругается страшными словами. Кажется, подобным образом сделано определение состояния reset на USB-шине (когда обе сигнальные линии в одном состоянии). То есть, грубо говоря, помимо дифференциального LVDS приёмника на этих ногах, хотелось бы ещё TTL приёмник. Возможно для этого можно использовать дополнительно две ноги ПЛИС и подключить их снаружи через согласующие резисторы (правда пока плохо представляю как согласовать и чем это чревато), но может быть есть способ этого избежать?