Infineon PEF24624, 22622, SCI интерфейс - SCDO=1 Опции

[_4afc_]

При доступе к Socrates 24624 со стороны контроллера - выход SCDO всегда равен 1.
По документации он связан со входом SCDI через логическое И.

Тестироваал так - SCDI=0, SCCK=1..3MHz.
Пытался загнать код 7E - без изменений.

Где-то читал, что выход вроде отключен изначально, и надо сначало его включить -
вопрос как - через JTAG или SCI ?

Собственно нужно проверить работает ли данный чип, а то плату изготовили,
а с какой стороны к ней подступиться - вопрос.

[grv]

При доступе к Socrates 24624 со стороны контроллера - выход SCDO всегда равен 1.
По документации он связан со входом SCDI через логическое И.

Тестироваал так - SCDI=0, SCCK=1..3MHz.
Пытался загнать код 7E - без изменений.

Где-то читал, что выход вроде отключен изначально, и надо сначало его включить -
вопрос как - через JTAG или SCI ?

Собственно нужно проверить работает ли данный чип, а то плату изготовили,
а с какой стороны к ней подступиться - вопрос.

Рад бы помочь,но что то не помню таких ног у 22622.
Ксати не поделитесь даташитом на 24624 ? Поставшики с зимы завтраками кормят, ничего толком ответить не могут, на сайте как полагается информации 0 целых хрен десятых. Я даже не знаю это то что надо или нет, интересует 4,6Мбит по паре, т.е. то же что и 22622 но на скорость DSL в два раза выше.

[_4afc_]

Рад бы помочь,но что то не помню таких ног у 22622.
Ксати не поделитесь даташитом на 24624 ? Поставшики с зимы завтраками кормят, ничего толком ответить не могут, на сайте как полагается информации 0 целых хрен десятых. Я даже не знаю это то что надо или нет, интересует 4,6Мбит по паре, т.е. то же что и 22622 но на скорость DSL в два раза выше.

Я не качал док по 22622, а в 24624 это последовательный интерфейс к контроллеру ( параллельного нет пока)

24624 v1.2 теоретически может до 6.3 Мбит, а следующая версия - в два раза быстрее.
На практике всё зависит от версии фирмвары.

В октябре были свободно доступны в инете следующие файлы:

EASY_24624_Toolbrief.pdf
meyer-berg_2.pdf
SDFE4_2_Rev3_V12_UM_SysDescription.pdf
* SDFE-4_ds1_v11usersmanual.pdf
sdfe-4-2-1-pb.pdf
* socrates_16Bis_rev6.pdf

ищите гуглом (сегодня не откликаются, но неделю назад ещё лежали...)
* помечанные - лежат и сейчас

По поводу документации (NDA) и тех.характеристик - позвоните Виталию Шмелёву (ИНТЕХ)
(495) 797-55-35

Сообщение отредактировал _4afc_ - May 15 2006, 06:53

[grv]

Рад бы помочь,но что то не помню таких ног у 22622.
Ксати не поделитесь даташитом на 24624 ? Поставшики с зимы завтраками кормят, ничего толком ответить не могут, на сайте как полагается информации 0 целых хрен десятых. Я даже не знаю это то что надо или нет, интересует 4,6Мбит по паре, т.е. то же что и 22622 но на скорость DSL в два раза выше.

Я не качал док по 22622, а в 24624 это последовательный интерфейс к контроллеру ( параллельного нет пока)


24624 v1.2 теоретически может до 6.3 Мбит, а следующая версия - в два раза быстрее.
На практике всё зависит от версии фирмвары.


В октябре были свободно доступны в инете следующие файлы:

EASY_24624_Toolbrief.pdf
meyer-berg_2.pdf
SDFE4_2_Rev3_V12_UM_SysDescription.pdf
* SDFE-4_ds1_v11usersmanual.pdf
sdfe-4-2-1-pb.pdf
* socrates_16Bis_rev6.pdf

ищите гуглом (сегодня не откликаются, но неделю назад ещё лежали...)
* помечанные - лежат и сейчас

По поводу документации (NDA) и тех.характеристик - позвоните Виталию Шмелёву (ИНТЕХ)
(495) 797-55-35

Т.е. чо то типа SPI ?

Наелся в свое время обещаний инфинеона..
То что они пишут в Product brief работает на половину треть из которой работает не так как описано в datasheet

Кое что нашел, остальное возьмем по нда.

Вы брали оценочную плату или делали макет и bga паяли сами ? С бжа опыта нет, страшновато....

[_4afc_]

Т.е. чо то типа SPI ?

Хуже. Синхронный интерфейс.
То что пишет контроллер в SCDI складывается логическим И с внутренним выходом 24624 и подаётся на ногу SCDO. Соответственно если загонять туда 0, то по любому должен выходить 0.
Проблема в том, что туда надо загонять HDLC пакеты на скорости выше 1МГц, со стартом, адресом, данными, CRC и стопом.
Где-то на форуме читал, что при подобном интерфейсе у одной из микрух выход был в другом режиме.
У меня он всегда равен 1.

Вы брали оценочную плату или делали макет и bga паяли сами ? С бжа опыта нет, страшновато....

Разводил сам: 4 слоя, 0.15мм, via0.3, покрытие золото, изготовление - китай.
Сборка макета делалась полностью на стороне.

BGA - ничего страшного. Закройте via маской с двух сторон, сделайте золотые контактные площадки больше отверстий в маске и приготовте 600р за установку.

[Ledol]

1. Речь идет о PEF 24624 SDFE - следующее поколение SHDSL чипсетов от Infineon .
2. Что бы перейти в режим полудуплекса по SCI интерфейсу (в которм как раз идет объединение по "и") нужно передать первый пакет CMD_WR_REG_AUX_SCI_IF_MODE(03H). Который собственно это переключение инициализирует. После этого чип отвечает ACK_WR_REG_AUX_SCI_IF_MODE и переходит в режим полудуплекса, что позволяет отслеживать коллизии. До этого момента никакой взаимосвязи м-у SCDI/SCDO НЕТ!!!

[_4afc_]

1. Речь идет о PEF 24624 SDFE - следующее поколение SHDSL чипсетов от Infineon .
2. Что бы перейти в режим полудуплекса по SCI интерфейсу (в которм как раз идет объединение по "и") нужно передать первый пакет CMD_WR_REG_AUX_SCI_IF_MODE(03H). Который собственно это переключение инициализирует. После этого чип отвечает ACK_WR_REG_AUX_SCI_IF_MODE и переходит в режим полудуплекса, что позволяет отслеживать коллизии. До этого момента никакой взаимосвязи м-у SCDI/SCDO НЕТ!!!

Я так и предпологал. Остаётся лишь сформировать этот пакет и отправить его по SCI интерфейсу, но сдесь у меня три загвоздки:
1. Изначально тактирование идёт по фронту или по срезу?
2. На какой минимальной скорости можно передать первый пакет?
3. Содержимое первого пакета?

Касательно содержимого:
Флаг = 7E
Адрес источника = F1 (HOST)
Адрес приёмника = F9 (AUX)
Регистр A9
Данные 03

CRCpoly 1021

Данные передаём 0 битом вперёд, CRC - 15 битом, после 5 единиц всовываем 0.

Передавал

7E [ 8F 9F 95 C0 87 7F ] 7E - по доке, CRC считаю до переворота данных, данные перевёрнуты
7E [ F1 F9 A9 03 87 7F ] 7E - по доке, CRC считаю до переворота данных, данные не перевёрнуты
7E [ 8F 9F 95 C0 E7 4C] 7E - по доке, CRC считаю после переворота данных, данные перевёрнуты
то же, но CRC инвертировано:
7E [ 8F 9F 95 C0 78 80 ] 7E - по доке, CRC считаю до переворота данных, данные перевёрнуты
7E [ F1 F9 A9 03 78 80 ] 7E - по доке, CRC считаю до переворота данных, данные не перевёрнуты
7E [ 8F 9F 95 C0 18 B3 ] 7E - по доке, CRC считаю после переворота данных, данные перевёрнуты

Передавал с тактированием на фронте, правда частота всего 55кГц.
Числа внутри скобок обрабатывались битстафингом.

Всё безрезультатно.

Не могли бы вы написать точную последовательность бит, или указать где я ошибся?

[Ledol]

1. Речь идет о PEF 24624 SDFE - следующее поколение SHDSL чипсетов от Infineon .
2. Что бы перейти в режим полудуплекса по SCI интерфейсу (в которм как раз идет объединение по "и") нужно передать первый пакет CMD_WR_REG_AUX_SCI_IF_MODE(03H). Который собственно это переключение инициализирует. После этого чип отвечает ACK_WR_REG_AUX_SCI_IF_MODE и переходит в режим полудуплекса, что позволяет отслеживать коллизии. До этого момента никакой взаимосвязи м-у SCDI/SCDO НЕТ!!!

Я так и предпологал. Остаётся лишь сформировать этот пакет и отправить его по SCI интерфейсу, но сдесь у меня три загвоздки:
1. Изначально тактирование идёт по фронту или по срезу?
2. На какой минимальной скорости можно передать первый пакет?
3. Содержимое первого пакета?

Касательно содержимого:
Флаг = 7E
Адрес источника = F1 (HOST)
Адрес приёмника = F9 (AUX)
Регистр A9
Данные 03

CRCpoly 1021

Данные передаём 0 битом вперёд, CRC - 15 битом, после 5 единиц всовываем 0.

Передавал

7E [ 8F 9F 95 C0 87 7F ] 7E - по доке, CRC считаю до переворота данных, данные перевёрнуты
7E [ F1 F9 A9 03 87 7F ] 7E - по доке, CRC считаю до переворота данных, данные не перевёрнуты
7E [ 8F 9F 95 C0 E7 4C] 7E - по доке, CRC считаю после переворота данных, данные перевёрнуты
то же, но CRC инвертировано:
7E [ 8F 9F 95 C0 78 80 ] 7E - по доке, CRC считаю до переворота данных, данные перевёрнуты
7E [ F1 F9 A9 03 78 80 ] 7E - по доке, CRC считаю до переворота данных, данные не перевёрнуты
7E [ 8F 9F 95 C0 18 B3 ] 7E - по доке, CRC считаю после переворота данных, данные перевёрнуты

Передавал с тактированием на фронте, правда частота всего 55кГц.
Числа внутри скобок обрабатывались битстафингом.

Всё безрезультатно.

Не могли бы вы написать точную последовательность бит, или указать где я ошибся?

1. SCI тактируется по фронту. Ваша передача по заднему фронту (SDFE хватает по переднему), ваш прием по переднему фронту SCK (SDFE выдает данные по заднему фронту).
2. Минимальная частота SCI у меня получилась порядка 300 кГц (экспериментально)
3. По CRC: данные не инвертируются, CRC сумма начинается с FFFFh (не с 0000h !!! )
4. Пакет: "F1 F9 A9 03 CRCH CRCL", data LSB first, CRC MSB first (тут у вас все правильно)

[_4afc_]

Спасибо, мне удалось перевести SDFE4(v1.2) в режим полудуплекса.
Основная моя ошибка была в битстафинге (как уже кто-то здесь до меня говорил - ноль надо вставлять после 5 единиц - всегда!).
Передачу и приём надо делать как вы и описали.
А вот контрольная сумма в принципе не важна, чип переходит в полудуплекс ещё не считав второй байт CRC (можно вообще нули передавать).

А вот получить в ответ на CMD_WR_REG_AUX_SCI_IF_MODE(03H) сообщение ACK_WR_REG_AUX_SCI_IF_MODE
мне не удалось. Дело в том что мой SDFE4(v1.2) в режиме 3 выводит на SCDO только то, что приходит на SCDI!
Соответственно ни каких ответов на запись или чтение он в этом режиме не даёт (SCDI=0 и SCDO=0).

В режимах 0 или 1 SCDO=0 (хотя может там открытый коллектор).
В режиме 2 (по умолчанию) я получаю ACK и на чтение и на запись:

HOST: 7E | F1 F9 A9 02 97 5E | 7E
SDFE: 7E | F9 F1 89 FF AA | 7E

HOST: 7E | F1 F9 A8 00 84 2D | 7E
SDFE: 7E | F9 F1 89 02 1D 3B | 7E

Ответ появляется через 3 такта, до и после ответа SCDO=1.
Как видно из ответа SDFE не устраивает моя контрольная сумма, как в прочем и его мне не нравится.

Собственно вопрос - отсутствие ACK в режиме 3 - это особенность v1.2 или мне так повезло?
А то если делать по докам, то ACK должен быть...

[Ledol]

У меня SDFE v1.3. Но в errate и delte про это ничего нет. На режим 3 у меня точно приходит ACK (даже если CRC не правильная). Другие режимы включать не пробовал, сразу заработало. С контрольной суммой вы все правильно понимаете, бит RSTA_CRC д.б. 1 (0xА9 valid byte).
А SCDI у вас точно уводится в 1 после передачи пакета?

[_4afc_]

У меня SDFE v1.3. Но в errate и delte про это ничего нет.

Гдеж вы v1.3 отхватили? Рассыпухой только v1.2 видел. Или у вас 22624?

На режим 3 у меня точно приходит ACK (даже если CRC не правильная). Другие режимы включать не пробовал, сразу заработало. С контрольной суммой вы все правильно понимаете, бит RSTA_CRC д.б. 1 (0xА9 valid byte).

Как вы считаете CRC не правильно считаю я или SDFE?

А SCDI у вас точно уводится в 1 после передачи пакета?

В режиме 3 SCDI=SCDO жёстко. Вне зависимости что и когда передаётся и что приходит после стоп флага. Давал и единицы и нули.

SCDO у меня в режиме 2 до и после флагов равен 1, даже если SCDI=0.
Упакую фирмвару - попробую запуститься на втором режиме.

Я управляю через порты Atmega128 и смотрю изменение бит на ноге - так что всё точно.

Сообщение отредактировал _4afc_ - May 31 2006, 14:03

[Ledol]

- да, у меня PEF22624
- по CRC следующее. Перед тем как засунуть ее подсчет в ПЛИС. Делал ее табличным методом прямо в контроллере (у меня тоже АТMega128). Таблицу взял из примеров JAR(кажется).
ф-я:
unsigned int fast_crc16(unsigned int sum, unsigned char data)
{ sum = pgm_read_word_near(crc16_table + ((sum >> 8) ^ data)) ^ (sum << 8);
return sum;
}
таблица стандартная (первый эл. 0x0000 , последний 0x1ef0)

- SDFE c CRC разумеется не корявит.(сейчас это пишу ч-з канал Ethernet-SDFE <-> SDFE-Ethernet)
- Хуже всего, что как и PEF22622 на линии он работает неодназначно.

[Uree]

...
- Хуже всего, что как и PEF22622 на линии он работает неодназначно.

Немного не в тему, но вопрос есть - что значит неоднозначно? Похоже у нас та же ситуация.
Поясняю: у нас в проекте также стоит этот самый PEF и до боли странно поднимает на линии связь.
Во первых слишком долго (3-15 минут, в идеале до 1 минуты, но это скорее на столе, а не на линии).
Во вторых - непонятно от чего это зависит (loss=33 дБ по его показаниям, изменения мощности сигнала однозначного результата не дают - может поднять при мощности 6.5дБ(мастер) - 9.5дБ(слэйв), а может при 11.5дБ(мастер) - 14.5дБ(слэйв). Это как - от фазы луны зависит что-ли?)
Меняется ли характер работы (и время установления связи) от версии фирмвари?
Хочется понять - только у нас такая проблема, или она вообще присуща этому чипу?

[Ledol]

Ну да, так и есть. Проблема не только с параметрами связи (Line Loss, Signal Quality, SnR). Пусть они будут разные от соединения к соединению. Плохо то, что и факт соединения не гарантирован. На одном и том же участке кабеля стал свидетелем 3-х вариантов развития событий:
- активация с первого раза, качество сигнала порядка 5-и
- активация после 5-и минут, качество сигнала около 0-я
- 1 час, активации линии нет
При всех вариантах начальные условия одинаковые (пары кабеля те же, модемы те же (с теми же настройками), каждый эксперимент начинался со сброса питания на обоих модемах)
Получается, что гарантировать работу не могу. Как следствие заниженные паспортные данные модемов по дальности. С globespan-ообразными модемами конкуренции не выходит.
По поводу firmware. Использую COT15/RT15. Версии 16, 17 считаю не жизнеспособными(по помехозащищиенности). Да и проблему с активацией они не решили.

[grv]

Ну да, так и есть. Проблема не только с параметрами связи (Line Loss, Signal Quality, SnR). Пусть они будут разные от соединения к соединению. Плохо то, что и факт соединения не гарантирован. На одном и том же участке кабеля стал свидетелем 3-х вариантов развития событий:
- активация с первого раза, качество сигнала порядка 5-и
- активация после 5-и минут, качество сигнала около 0-я
- 1 час, активации линии нет
При всех вариантах начальные условия одинаковые (пары кабеля те же, модемы те же (с теми же настройками), каждый эксперимент начинался со сброса питания на обоих модемах)
Получается, что гарантировать работу не могу. Как следствие заниженные паспортные данные модемов по дальности. С globespan-ообразными модемами конкуренции не выходит.
По поводу firmware. Использую COT15/RT15. Версии 16, 17 считаю не жизнеспособными(по помехозащищиенности). Да и проблему с активацией они не решили.

Мы используем версию COT15/RT15. При попытке завести pcm-master на скорости 4096 начинает дрожать с частотой 50-100 герц duti cycle REFCLK и PCLK. Причем скажем передний фронт стоит как вкопанный, а задний пляшет с 0.3 на 0,6. Зачем так было делать и нафиг это кому нужно?
Кто знает как с этим дела в следующих версиях ?.
Какие изменения в вресии 17 относительно 16 ?
И что значит по помехозащищенности ? Они что, линию хуже держат ?

Вообще устал я от Infineona с ихними граблями...
Пологаю с SDFE будут то же.
Жаль что фирма Intel скупившая в свое время Level One свернула это направление.

[Ledol]

Мы используем версию COT15/RT15. При попытке завести pcm-master на скорости 4096 начинает дрожать с частотой 50-100 герц duti cycle REFCLK и PCLK. Причем скажем передний фронт стоит как вкопанный, а задний пляшет с 0.3 на 0,6. Зачем так было делать и нафиг это кому нужно?
Кто знает как с этим дела в следующих версиях ?.
Какие изменения в вресии 17 относительно 16 ?
И что значит по помехозащищенности ? Они что, линию хуже держат ?

Вообще устал я от Infineona с ихними граблями...
Пологаю с SDFE будут то же.
Жаль что фирма Intel скупившая в свое время Level One свернула это направление.
[/quote]

- Ну да, дрожжание есть. Я так мыслю, что это ФАПЧ так захваченную частоту (синхронный режим) или стаффинги (плезиохронный) отрабатывает (смотрите то отн. опоры, не так ли?). Для приема данных с TDM это не критично.
- Версия 17, поначалу радовала устойчивой активацией на 14 км МКС 1.2мм, а кончилось тем, что и на 11 км незаработала (т.е. та же неоднозначность от участка к участку). Причем в сравнении с 15-й версией на одном и том же участке за сутки ошибок вываливается в разы больше (уч-к вдоль ЖД).
- На генераторе шума (Noise ADSL gen. NSA-400) в принципе подтвердилось, что при одном и том же уровне шума на 17-й ошибок больше, хотя порог выключения по большим шумам у 15-й меньше.

к "Вообще устал я от Infineona с ихними граблями..." полностью присоединяюсь.

[grv]

>- Ну да, дрожжание есть. Я так мыслю, что это ФАПЧ так захваченную частоту (синхронный режим) >или стаффинги (плезиохронный) отрабатывает (смотрите то отн. опоры, не так ли?). Для приема >данных с TDM это не критично.

Вопрос какой урод это сделал и зачем. Смотрим кстати не относительно опоры а просто одним лучем.
Такое впечатление что сначала 4096 они вообще не собирались в мастере делать, а когда до них дошло что 2,3мбит не получается втиснуть в 32КИ начали лепить горбатого до стенки.
Кодеки в принципе работают. Меня больше беспокоит на сколько это отразиться скажем в регенератора где будет переприем по TDM, фактически эта билиберда попадет в REFCLK ведомого сократеса со всеми вытекающими.


- Версия 17, поначалу радовала устойчивой активацией на 14 км МКС 1.2мм, а кончилось тем, что и на 11 км незаработала (т.е. та же неоднозначность от участка к участку). Причем в сравнении с 15-й версией на одном и том же участке за сутки ошибок вываливается в разы больше (уч-к вдоль ЖД).
- На генераторе шума (Noise ADSL gen. NSA-400) в принципе подтвердилось, что при одном и том же уровне шума на 17-й ошибок больше, хотя порог выключения по большим шумам у 15-й меньше.

Не думал что версия будет влиять на линейную часть. Нужно будет сравнить 15 и 16 на реальном кабеле. А где 17 взяли ? Не поделитесь для целей экспериментов ?

к "Вообще устал я от Infineona с ихними граблями..." полностью присоединяюсь.
[/quote]

[grv]

В догонку.
Кто нибудь пробовал для увеличения дальности 22622 пускать по двум парам прием-передача (разорвать гибрид и поставить отдельный тр-р на прием)?
В ряде случаев думаю это решение имело бы право на жизнь.