Заливали код, присланный дилером по технологии, описанной в OCTALFALC_V1.1_ES_Rev4.0 п.1 "Reduced Receiver Sensitivity in E1". И почему бы этому октальному фальку не нуждаться в перезаливке, если он примерно на два года старше, чем FALC56 2.2?

Да уж... С восмеренными дела не имел, видиммо к счастью ... Даже не предполагал, что с ними еще более запущено, чем с одиночными, ибо счетверенные вполне в этом отношении отработанные.
P.S.
А вообще с Infineon пора завязывать - не думаю, что сброс всего проводного направления неведомой инвестиционной штатовской компании хорошо аукнется....

Уважаемые!
А может кто-то поделиться errata на QuadFalc 2.1 и 3.1?
И может еще какой "скрытой" информацией?

-- Спасибо. Успехов!

А можно эту мысль поподробнее развить, а то до меня что-то плохо доходит? Какой сброс? Вроде только что вот MUNICH версии обновили, QUADFalc вышел 3.1? Но вообще я Infineon взял потому только, что они чувствительнее Dallas (что подтвердилось на испытаниях - мы сделали конкурентов на чипах Dallas примерно на 20%), а остальные плохо доступны.

А чего тут развивать - продали, за не перспективностью, и все стало туманее.

Посему пора ориентироваться на LIU + FPGA. Для массовых коротких дистанций вместо LIU почти любая самоделка - тогда еще не только независимее, но и дешевле.

Мы вобщем-то так и собираемся сделать в перспективе, однако с теоретической точки зрения я не понимаю, какая разница покупать LIU или полный фреймер (нам надо LH, поэтому без LIU не обойтись). Затем еще, HDLC контроллер на 256 каналов занимает в FPGA не очень мало места (больше 10000 LUT), то есть MUNICH получается просто выгоднее экономически. Я вообще этого дела раньше не касался, взял MUNICH с OctalFALC соединил и success c первого раза, а в FPGA там придется покувыркаться с отладкой и HDLC, и фреймера.

При таком подходе, в самом OctalFALC уже 24 HDLC контроллера оказались лишними , MUNCH - то зачем? Просто не захотелось PCI в FPGA поднять .

Зато получите определенную степень независимости и не будет той офигенной избыточности. Да и из Infineon что не собирай, все EWSD получается

Во-первых, 24 контроллера мало, а во-вторых новая версия MUNICH есть с PCI Express, причем распиновкой (кроме собственно PCI части) не отличается от PCI, что дало возможность сделать PCIe плату из PCI минимальным трудом.

Попробовал я наконец залить в эквалайзер данные, которые мне прислал дистрибьютор и ... пока ничего. чувствительность как была на уровне -15...-18 дБ так и осталась. Нужных -40 ну ни как не наблюдается. Пытаюсь понять в чем моя ошибка. Хотелось бы знать кому-нибудь удавалось у одиночного фалка поднять чувствительность перезаливкой эквалайзера? поделитесь опытом.

Тоже, все, как было, так и осталось, единственно, что на уровне, как уже писал, где-то -36...38dB

А по какому принципу определялась чувствительность у вас. Я для себя чувствительность определял исходя из отсутствия в принимаемом цифровом потоке ошибок. (т.е. что отправил то и должен принять), если же на ошибки забить и определять чувствительность исходя из потери фреймером синхронизации, то чувствительность в этом случае достаточно велика, как раз где-то 30 - 35 получается

Так и делалось, только поток был не плотным - редкие тестовые пакеты и небольшая нагрузка, но тот-же CRC4 был включен. Долго не гонял. Использовался правильный аттенюатор.

Если возможно, то вышлите и мне. Или, что наверное лучше, выложить на ftp.

Подскажите пожалуйста, как определить работоспособность чипа FALC56 v2.2
Хочу проверить правильность настройки Master Clocking Unit. Использую генератор с частотой 16.384 мгц
Выбрал значения для регистров GCM1..GCM8 из PDF. Настроил выводы CLK1 И СLK2 на выход с частотами 2.048 мгц
Но после запуска платы, на выводах CLK1 И СLK2 ничего не наблюдается . Может кто подскажет по поводу нюансов инициализации.
Или может проблема в генераторе

1. Проверить питание.(если питание одно, то вместо второго должен быть установлен конденсатор 0,47мкф на GND от вывода 74)
2. наличие входного CLK от вашего генератора

Errata sheet к FALC можно запросить в Симметроне у Прошина Федора

Спасибо за информации, оказывается не работал генератор на выводе MCLK, взял генерацию с другой платы, все заработало)))
Теперь нужно искать замену китайской подделке(((

Есть проблемка с FALC56, для проверки соединения постоянно шлю данные на вход XDI и смотрю на выходе RDO устройства абонента, данные идут
Но когда физически разрываю соединение между абонентами, то вижу, что данные продолжают приходить. Такое впечатление, что где включается функция LOOP-BACK, хотя при инициализации я ее везде выключил. Кто-нибудь может подсказать, как с этим бороться??

Добрый день)))

Пытаюсь приладить к falc56 оптический интерфейс, кодировка для передачи данных по оптике используется NRZ
Есть вопрос, как синхронизировать прием данных в NRZ кодировке, что нужно подавать на вход RCLKI для синхронизации входного потока???

Владимир

По поводу буфера HDLC подскажите, пожалуйста, не совсем понятно. Написано в даташите, что доступ к фифо может быть как 8и, так и 16и битный. На схеме битность шины выбирается раз и навсегда. Каким же образом передавать по HDLC нечетное количество байт? Или таких случаев не бывает?

Добрый день

Есть проблемка, касательно использования фреймера PEF22554. Фреймер железно работает с кодировкой NRZ (восстановление синхронизации осуществляется внешней схемой). Но отказывается работать с кодировками HBD3 и CMI. Переодически сыплются ошибки. Шлю на вход последовательность из 2-х фреймов, получаю полный бред. Портится вся посылка, даже нулевые тайм слоты портятся. Иногда получается принять правильные данные. Думаю проблема в инициализации. Может у кого-нибудь остался работающий код инициализации??

Буду примного благодарен

Владимир (nordice@mail.ru)

А может кто-то поделиться последним errata на QuadFalc 2.1?
muhamatnabeev@yandex.ru

нужна именно errata? Есть Datasheet & DeltaSheet:

Видимо да, нужен именно "Errata Sheet". Так как:

Datasheet и DeltaSheet у меня уже есть. Спасибо.

Подскажите пожалуйста, есть FALC v.2.2, соединил 2 таких FALC'а проводами, циклически отправляю 2 байта по HDLC с одного FALC'а на другой, все приходит. Теперь я хочу посмотреть "сырые" данные по HDLC (структуру фрейма с флагами, CRC и т.д.), для этого на приемном FALC'е выбрал режим "No HDLC framing mode" (регистр MODE, биты MDS(2:0) = 111) - в результате получаю первый раз прерывание RPF (хотя фрейм по идее короткий), в RFIFO случайные 4 байта + 28 байт 0xFF. Затем все время прерывания RPF и в RFIFO 32 байта 0xFF. Что я делаю не так?

P.S. Читаю все время только младший байт RFIFO (он же на самом деле 16-разрядный). Структуру фрейма хочу посмотреть, т.к. нужно состыковаться с АТС по протоколам DSS/LAPD.

3-ий день впустую... Нет сверхцикловой синхронизации (в 16-м таймслоте), при этом цикловая есть. В чем может быть дело? Не знаю, что уже пробовать...

Может у кого есть errata на PEF 2256 H v. 2.2?

Тут такое дело, старая железяка выпускалась очень долго на falc56 v1.2 , наконец то они закончились нужно переехать на falc56 v2.2

Подскажите следующее:
Имеется Version 2.2 Data Sheet, Rev. 1.1, June 2005 Это последний DS ?

Поделитесь пожалуйста эрратами и калькулятором для расчета частоты на anteynet@ukr.net. Спасибо.

Мне тоже еррата и калькулятор на 2.2 не помешают, буду вам очень благодарен: shp_a_tut.by

Если кому интересно, то могу рассказать о своих приключениях с QFALC. Я в одной крупной компании сопровождал некое устройство с QFALC на борту. За время сопровождения (около 10 лет) мы два раза делали обновление: сначала с V1.1 на V2.x, потом на V3.x (точные номера не помню - давно это было). Второе обновление прошло более/менее гладко, но в серию не пошло. А вот с последним обновлением случился казус - устройство начало жутко сбоить по каналам T1/E1. Причем разные чипы вели себя по разному. Для решения проблемы я поехал на родину устройства, где встретился с инженером из Lantiq - компании, которой была продана эта продуктовая линейка. Проблема была найдена практически сразу - signal integrity. В общем это было основной версией с самого начала, но нужны были доказательства.
Так вот, инженер Lantiq рассказал забавную историю развития FALC-ов. Первое поколение FALC-ов разрабатывалось в виде схемы из набора "логических элементов", второе - оптимизация и использование новых "логических элементов". А вот в последней версии всё было переписано на HDL с сохранением совместимости. Но совместимость сохранилась не до конца. В нашем случае уменьшилась нагрузочная способность выходных буферов со стороны системной шины. В результате с фронтами случилась беда, которую мы увидели на жутко дорогом осциллографе - некоторые фронты имели небольшой провал посередине, в результате чего MPC8260 стал воспринимать один фронт за два. Проблема была исправлена транзистором - благо частоты там невысокие. Я почти две недели провел с инженером Lantiq - мы прошлись по инициализации и довольно много там исправили, хотя до этого все настройки выверялись в течение многих лет.

А так мне очень нравилось семейство FALC-ов. Неубиваемые чипы. До сих пор их вспоминаю, а также всю канувшую ATM-скую линейку Infenion:)

Поделитесь, пожалуйста, следующей информацией: datasheet, errata и калькулятор для FALC56 v2.2 на email svk9@bk.ru. Буду очень признателен, информация нужна срочно.

Всем привет! Подскажите, это последняя версия PEF2256 H Version 2.2 (Rev. 1.1, June 2005)?