Кто работал с ADV212 Опции

[alexPec]

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

Сигналы подаю по даташиту, дожидаюсь АСК от чипа (он приходит).

Делаю так:

1.Подаю питание (в норме, проверял)
2.Подаю клок 20МГц на МCLK
3.Подаю отрицательный импульс на reset
4.По адресу (прямому) 0xF пишу число 4
5.По адресу (прямому) 0xЕ пишу число 8
6.Читаю адрес 0xE - получаю 0x8B
7.Читаю адрес 0xF - получаю 0xB.

Клок померял прямо на шарике ADV212 - 20МГЦ приходит.
Сигналы RD, WR,CS - думаю тоже нормально доходят, поскольку ACK от чипа приходит и на чтение, и на запись.
Данные и адреса (он идут с ПЛИС) смотрел сигнал-тапом, все в норме.

При чтении регистров (прямых) всех кроме BUSMODE, MMODE, PLL_HI, PLL_LO ACK от чипа не приходит.

Кто что может посоветовать, что еще проверить? Похоже не запускается PLL внутренняя, есть там какие-то хитрости? Хотя написано, что регистры BUSMODE, MMODE, PLL_HI, PLL_LO не требуют клока вообще.
Мысль только менять чип, охота услышать мнение специалиста, работавшего с этим чипом.

[Golikov A.]

10 бит дает 1024 уровня
8 бит дает 256 уровней
чтобы равномерно распределить 1024 уровня на 256 сохранив тот же диапазон, надо на каждую единицу из 256 подать 1024/256=4 единицы, то есть каждое изменение на 1 вызывает изменение на 4. Другими словами ваши уровни надо умножить на 4, то есть сдвинуть на 2 бита.
так что цепляйте их к 11...4, а младшие 4 бита зажимайте в 0.
10 подцепленные к 11..2 - это расширение 10 бит до 12
вы расширите 8 бит до 12.

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

[alexPec]

10 бит дает 1024 уровня
8 бит дает 256 уровней
чтобы равномерно распределить 1024 уровня на 256 сохранив тот же диапазон, надо на каждую единицу из 256 подать 1024/256=4 единицы, то есть каждое изменение на 1 вызывает изменение на 4. Другими словами ваши уровни надо умножить на 4, то есть сдвинуть на 2 бита.
так что цепляйте их к 11...4, а младшие 4 бита зажимайте в 0.
10 подцепленные к 11..2 - это расширение 10 бит до 12
вы расширите 8 бит до 12.

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

Да это понятно, вопрос был в том, с каких ног чип считывает эти 8 бит, ведь у него для пиксел - интерфейса 16 ног. Ну да с этим разобрался.

Другой затык: делаю все по этому алгоритму (картинка). Все проходит нормально - проверяю firmware ID - соответствует. Пытаюсь очистить флаги прерываний - записываю по адресу 6 хост-интерфейса (EIRQFLG) значение 0xFFFF, считываю флаги - как было там значение 15 (0xF) так и остается. Короче, флаги прерываний не сбрасываются. Пытался несколько раз записать 0xffff - результат тот же, флаги остаются в единице.
Думал может действительно в code fifo что-то есть - пытаюсь читать direct регистр по адресу 1 (code fifo) - не получаю ACK.
Параметры пишу следующие (по адресу 0x57f00, установлен автоинкремент на 16 бит):

0x0100 - pal 422, 8bit
0x0303 - 3level transform, unipolar C, unipolar Y
0x0300 - Codeblock 128x32, irreversible 9x7
0x0000 - No skip fields, no attribute data
0x0101 - target rate control,
0x04ac - image size = 66732bytes
0x0041 - LRCP, HVF pins
0x0002 - quantization factor 1x, JP2 format

Все взял из рефренса, дальше че-то тупик.

Эскизы прикрепленных изображений