Сообщения без ответов | Активные темы Текущее время: 28 мар 2024, 15:06



Ответить на тему  [ Сообщений: 305 ]  На страницу Пред.  1 ... 10, 11, 12, 13, 14, 15, 16  След.
 64 квадратных миллиметров счастья 
Автор Сообщение
Сообщение 03 май 2014, 11:29
Профиль
Аватара пользователя

Зарегистрирован:
24 июл 2007, 06:54
Сообщения: 492
Откуда: Embedded
Ну, не знаю...

_________________
Tried so hard and got so far, but in the end, it doesn't even matter...


Сообщение 07 май 2014, 16:32
Профиль

Зарегистрирован:
28 ноя 2012, 17:56
Сообщения: 63
Ковыряю контроль. Найдено 2 счетчика:
1) это обратный счетчик который на вход получает количество пустых значений для RLE и далее считает до нуля, попутно выдавая 3 основных сигнала:
- значение счетчика не равно нулю
- стартовое значение счетчика не равно нулю
- счетчик закончил работу

Этот счетчик напрямую влияет на то что идет в результирующий юнит. Если он работает то результат обнуляется через NANDы и в юнит записывается ноль.

2) это прямой счетчик который работает независимо ни от чего, только от тактового сигнала. Выдает 2 основных сигнала:
- счетчик не равен нулю
- счетчик не переполнился



Кроме этого есть и еще масса контрольных сигналов которые пока предстоит расшифровать.



Вложения:
02_RLE_2014-05-07.jpg
02_RLE_2014-05-07.jpg [ 1.16 МБ | Просмотров: 15263 ]
02_RLE_control.jpg
02_RLE_control.jpg [ 252.98 КБ | Просмотров: 15263 ]
Сообщение 08 май 2014, 00:25
Профиль ICQ WWW
Аватара пользователя

Зарегистрирован:
24 июл 2007, 10:41
Сообщения: 570
Рапорт с моего фронта)

Прочитаны ячейки в области, которую сейчас исследует Акари. Не знаю сколько точно там ячеек в этой "полоске", что-то около 3000. Точный подсчёт будет позднее.
Hires выкладывать не буду, PNG вы сможете скачать с нашего SVN (она весит около 20 Мб).

В планах прочитать все остальные ячейки из куска 00 (верхний левый угол), а также сделать подсчёт количества ячеек и прочей статистики.

Главные результаты - это отличный улов на новые ячейки и М1 для старых. Наша база данных по ячейкам уже содержит почти 100 ячеек и практически для каждой уже найден М1.
http://psxdev.ru/cells

Чего я только там не нашёл, не упомнить всего) Из особенно запоминающегося:

- D-триггеры срабатывающие по переднему фронту. Такие были обнаружены, а это значит что процессор PSX умеет делать 2 действия за такт))

- Заполнитель:
Изображение

- Ячейки-перевертыши: http://psxdev.ru/news/71

Теперь я буду читать ячейки выше этой полоски.


Вложения:
psxcpu_active_00_04_loc.jpg
psxcpu_active_00_04_loc.jpg [ 482.34 КБ | Просмотров: 15246 ]
psxcpu_active_00_04_preview.jpg
psxcpu_active_00_04_preview.jpg [ 154.07 КБ | Просмотров: 15246 ]
Сообщение 09 май 2014, 00:45
Профиль ICQ WWW
Аватара пользователя

Зарегистрирован:
24 июл 2007, 10:41
Сообщения: 570
Попытки автоматической векторизации металла.

Способ 1 :)

Плавающим окном с шагом delta сканируем исходное изображение и сравниваем 2 матрицы, переводя исходные RGB в яркостную компоненту (Y).
Сравнение матриц производится вычислением сумм квадратов разности элементов. Если сумма НЕ превышает некоторого порога, то фрагмент изображения похож на заранее вырезанный паттерн.

Результаты не очень))) Будем искать ещё методы.

http://codepaste.ru/17597/


Вложения:
automate_m2.jpg
automate_m2.jpg [ 123.62 КБ | Просмотров: 15213 ]
Сообщение 12 май 2014, 05:48
Профиль ICQ
Аватара пользователя

Зарегистрирован:
28 дек 2012, 05:58
Сообщения: 19
Откуда: Курган
А в данном примере какая картинка использовалась в качестве паттерна?


Сообщение 21 май 2014, 00:09
Профиль

Зарегистрирован:
28 ноя 2012, 17:56
Сообщения: 63
Закончил реверсить новообнаруженный счетчик для адресации результата рле (zigzag counter). К сожалению результат полученный после этого счетчика не очень похож на настоящий зигзаг. Вот и поди угадай у меня ошибка или просто алгоритм работы хитрее чем кажется.

00 01 08 10 09 02 03 0a
11 18 20 19 12 0b 04 05
0c 13 1a 21 28 30 29 22
1b 14 0d 06 07 0e 15 1c
23 2a 31 38 39 32 2b 24
1d 16 0f 17 1e 25 2c 33
3a 3b 34 2d 26 1f 27 2e
35 3c 3d 36 2f 37 3e 3f

Хотя учитывая что все было перепроверено на 100 раз - видимо все-таки алгоритм.

Оригинальный зигзаг выглядит так

Код:
zigzag[0..63] =
  0 ,1 ,5 ,6 ,14,15,27,28,
  2 ,4 ,7 ,13,16,26,29,42,
  3 ,8 ,12,17,25,30,41,43,
  9 ,11,18,24,31,40,44,53,
  10,19,23,32,39,45,52,54,
  20,22,33,38,46,51,55,60,
  21,34,37,47,50,56,59,61,
  35,36,48,49,57,58,62,63


Вложения:
02_RLE_zz_counter.jpg
02_RLE_zz_counter.jpg [ 414 КБ | Просмотров: 15106 ]
Сообщение 25 май 2014, 02:53
Профиль

Зарегистрирован:
16 авг 2009, 10:24
Сообщения: 4
Akari писал(а):
Закончил реверсить новообнаруженный счетчик для адресации результата рле (zigzag counter). К сожалению результат полученный после этого счетчика не очень похож на настоящий зигзаг. Вот и поди угадай у меня ошибка или просто алгоритм работы хитрее чем кажется.

Ничего ни разу тут не хитрее. Это совершенно стандартный JPEG Zigzag. Вот примеры:

https://github.com/folecr/jpeg8d/blob/c ... tils.c#L54
https://github.com/Distrotech/libmpeg2/ ... ader.c#L61
https://github.com/xrowgmbh/xrowvideo/b ... Zag.cs#L10

Так что всё в порядке.


Eugene


Сообщение 28 май 2014, 12:53
Профиль ICQ WWW
Аватара пользователя

Зарегистрирован:
24 июл 2007, 10:41
Сообщения: 570
Цитата:
А в данном примере какая картинка использовалась в качестве паттерна?


Вообще пришла идея использовать "колодец", то есть "запускать" точку в картинку и делать рекурсивное заполнение области, ограниченное "тёмными" краями металла. Ну по типу как воду в канаву заливать) Только нам достаточны будут точки экстремума, потому что толщина "канавы" всегда постоянная. Единственное нужно учитывать что "канава" может изгибаться под 90 градусов.


Вложения:
image.jpg
image.jpg [ 188.24 КБ | Просмотров: 15006 ]
pattern.jpg
pattern.jpg [ 8.28 КБ | Просмотров: 15006 ]
Сообщение 28 май 2014, 23:24
Профиль
Аватара пользователя

Зарегистрирован:
24 июл 2007, 06:54
Сообщения: 492
Откуда: Embedded
Это как алгоритм закрашивания области в графических редакторах на Спектруме и Специалисте.

_________________
Tried so hard and got so far, but in the end, it doesn't even matter...


Сообщение 02 июн 2014, 22:59
Профиль

Зарегистрирован:
28 ноя 2012, 17:56
Сообщения: 63
RLE закончен.



Сообщение 07 июн 2014, 11:45
Профиль

Зарегистрирован:
16 авг 2009, 10:24
Сообщения: 4
psxdev.net похоже не проплачен. Доступа нет


Сообщение 07 июн 2014, 16:24
Профиль ICQ WWW
Аватара пользователя

Зарегистрирован:
24 июл 2007, 10:41
Сообщения: 570
Это норма)

PS. Сейчас закину денег)


Сообщение 07 июн 2014, 23:01
Профиль

Зарегистрирован:
16 авг 2009, 10:24
Сообщения: 4
Akari писал(а):
RLE закончен.

И в какую сторону теперь будет копание?

Ещё было бы интересно увидеть финальное положение всех ячеек RLE на чипе.


Сообщение 08 июн 2014, 13:04
Профиль

Зарегистрирован:
28 ноя 2012, 17:56
Сообщения: 63
sev писал(а):
И в какую сторону теперь будет копание?

Ещё было бы интересно увидеть финальное положение всех ячеек RLE на чипе.


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

Цитата:
Error: if quantization factor in DCT == 0 then zagzig order not used. All data stored directly one after another.


Сам RLE находится тут:



Дальше видимо займусь контролем MDEC IDCT, который не закончил перед RLE. Сейчас известно гораздо больше и разрешить его будет проще. =)


Вложения:
layout_2014-06-08.jpg
layout_2014-06-08.jpg [ 543.79 КБ | Просмотров: 14828 ]
Сообщение 11 июн 2014, 17:18
Профиль

Зарегистрирован:
28 ноя 2012, 17:56
Сообщения: 63
Алгоритм работы RLE более менее разобран. Все декодирование состоит из 4х этапов. После выполнения этапа - данные переходят на следующий этап, а в предыдущий этап загружаются следующие данные.

ЭТАП 0

Такт XX1X_XXX1: Чтение quant.
адрес чтения для UNIT4 берется с ADDRESS_COUNTER_4_Q и выставляется бит A5 (все остальное время адрес чтения берется с ADDRESS_COUNTER_4_D и бит A5 не выставлен).
clk17 - считать quant с UNIT4 (8 бит 0xFF) в стартовые триггеры QUANT_DIVIDER.

Такт X1XX_XXX1: Чтение data.
установить QUANT_DIVIDER на считывание стартовых триггеров (все остальное время работает цикл с главными триггерами).
clk20 - считать quant из стартовых триггеров QUANT_DIVIDER в главные.
clk16 - считать data (младшие 10 бит 0x03FF) в стартовый триггер SUMMATOR1 (он же первый из трех триггеров прямого значения).
если ADDRESS_COUNTER_4_Q равен нулю (ac4_q_n0 == 0, мы декодируем первое число) то:
установить линию чтения Q_SCALE_DIVIDER на входные данные (все остальное время работает цикл с главными триггерами).
clk23:
считать padding_s (проверка на то что data равна 0xFE00) из данных в триггер.
записать qsc_n0_s в триггер (проверка что q_scale != 0).
clk21 - записать значение q_scale (старшие 6 бит 0xFC00) на триггеры q_scale counter для SUMMATOR2.
если ADDRESS_COUNTER_4_Q не равен нулю (ac4_q_n0 != 0, мы декодируем не первое число) то clk19:
считать len (старшие 6 бит 0xFC00) в LEN_COUNTER, если на данный момент значение счетчика 0, иначе уменьшить значение счетчика на единицу.

Такт 1XXX_XXX1: Увеличение адресных счетчиков и первая операция SUMMATOR1.
если значение padding_s равно нулю (первые данные не равны 0xFE00):
установить SUMMATOR1 на использование данных из стартовых триггеров.
clk24:
записать проверку на то что ADDRESS_COUNTER_4_Q не равен нулю в ac4_q_n0_s в триггер 1/2.
записать проверку на то что LEN_COUNTER равен нулю в lc_0_s в триггер 1/3.
вычислить и записать значение nnull_s в триггер 1/3.
увеличить значение ADDRESS_COUNTER_4_Q на 1.
clk15 - считать результат SUMMATOR1 в триггеры результата.
clk20 - сделать тик QUANT_DIVIDER.
если ac4_d_lock не равен 1 и:
если LEN_COUNTER не работает (lc_n0 == 0) или текущее значение data равно 0xFE00) то clk37:
увеличивает ADDRESS_COUNTER_4_D.

ЭТАП 1

Такт XXX0_XX1X: Вторая операция SUMMATOR1.
clk15 - считать результат суммы SUMMATOR1 в триггеры результата.
clk20 - сделать тик QUANT_DIVIDER.

Такт XX1X_XX1X: Третья операция SUMMATOR1.
clk15 - считать результат суммы SUMMATOR1 в триггеры результата.
clk20 - сделать тик QUANT_DIVIDER.
если qsc_n0_s == 0 (q_scale == 0) то clk32 - считать данные во вторые триггеры прямого значения.

Такт X1XX_XX1X: Результат SUMMATOR1.
clk15 - считать результат суммы SUMMATOR1 в триггеры результата.

Такт 1XXX_XX1X: Инициализация SUMMATOR2.
clk22:
записать ac4_q_n0_s в триггер 2/2.
записать lc_0_s в триггер 2/3.
записать nnull_s в триггер 2/3.
записать результат работы SUMMATOR1 на стартовые триггеры SUMMATOR2.

ЭТАП 2

Такт XXX0_X1XX:
для числа SUMMATOR2 используется ac4_q_n0_s.
clk18 - считать результат суммы SUMMATOR2 в триггеры результата.
clk21 - сделать 1 тик Q_SCALE_DIVIDER.
если qsc_n0_s == 0 (q_scale == 0) то clk32 - считать данные в третьи триггеры прямого значения.

Такт XX1X_X1XX:
что-то 1 делает с суммой для SUMMATOR2.
для числа SUMMATOR2 используется ac4_q_n0_s.
clk18 - считать результат суммы SUMMATOR2 в триггеры результата.
clk21 - сделать 1 тик Q_SCALE_DIVIDER.

Такт X1XX_X1XX:
что-то 2 делает с суммой для SUMMATOR2.
для числа SUMMATOR2 используется ac4_q_n0_s.
clk18 - считать результат суммы SUMMATOR2 в триггеры результата.
clk21 - сделать 1 тик Q_SCALE_DIVIDER.

Такт 1XXX_X1XX:
clk27:
записать lc_0_s в триггер 3/3.
записать nnull_s в триггер 3/3.
clk18 - считать результат суммы SUMMATOR2 в триггеры результата.
clk21 - сделать 1 тик Q_SCALE_DIVIDER

ЭТАП 3

Такт XXX0_1XXX:
clk36 - записать результат на финальные триггеры:
если ndirect_s == 0 то результат берется с прямых данных (если lc_0_s == 0 то результат прямых данных обнуляется)
если ndirect_s != 0 то результат берется с SUMMATOR2 (через финальные округления))
если ac5_d_nfull == 0 то в триггер -709- сохраним 1 (на следующий такт) это сбросит LEN_COUNTER и переключит выходной триггер данных A5 для unit5 на 1.

Такт XX1X_1XXX:
устанавливает IE1 или IE2 у UNIT05 для того чтобы записать результат с финальных триггеров.

Такт 1XXX_1XXX:
clk35 - увеличить значение ADDRESS_COUNTER_5_D на 1.
сделать тик ADDRESS_COUNTER_5_Z в зависимости от внутренних условий самого каунтера (clk33 и/или clk34).


Сообщение 02 авг 2014, 11:01
Профиль

Зарегистрирован:
28 ноя 2012, 17:56
Сообщения: 63
Продолжаю работать над схемой управления RLE. Сейчас настал черег глобального управления, которое выбирает запустить или сбросить все RLE декодирование, какой блок считывать и декодить или отправлять кусок данных на IDCT.



Все эта схема расположена чуть правее верхней части схемы в 4 части на чипе и сейчас расползается еще выше и правее, залезая в 7 часть нулевой четверти чипа.





Паралельно я пытаюсь заставить работать схему с логисиме. Исправлена еще одна ошибка и наконец-то первая схема умножения заработала. Большое спасибо LostTemplar который нашел что умножение делается по модифицированному алгоритму Бута.

Я приведу здесь его пост который вкратце описывает работу RLE (на англиском)

LostTemplar писал(а):
Anyway, I think that I now understand most of the RLE circuit, so let me report my findings, maybe it can be of help to everyone as well. I will refer to this version of Akari's RLE circuit schematic that I structured into its components. Of course, my descriptions are tentative and may contain errors, so feel free to correct me!

The counters are mostly self-explanatory, so I will omit them here. At the bottom, we have the control circuit that outputs the clocks for most other components. It basically contains a finite state machine that implements a two-level pipeline: one that enters a new stage every 4 cycles (right shift register), and one that changes every cycle (left shift register), but repeats every 4 cycles. This is done so that the components can be orchestrated in a pipelined fashion, where each component can start in an arbitrary cycle and be pipelined either every 4 or every cycle. For example, the multipliers are clocked every master clock cycle but output the result only every four cycles to the next pipeline stage. This is because the multipliers need four adds to get the result, so every cycle an add must be executed, and every 4 cycles the product is ready. Whether the state machine enters the next state is controlled mostly by the counter flags (full, zero, etc.), but also by some other flags (e.g. data == 0xfe00).

In the center of the schematic we have the quantization table multiplier that multiplies the data with the elements of the quantization table/matrix. I am fairly sure that this is a variant of the Booth multiplication algorithm where instead of bit slices of length 2, we look at bit slices of length 3. This particular multiplier works according to this algorithm. I can elaborate if desired. (By the way, I noticed that the multiplier of the IDCT is exactly the same algorithm, just a different, more parallelized, hardware implementation). At the end, before the result is written to the next stage, the result is clamped to 15 bits (the multiplier itself calculates the the full 19=11+8 bits of the result).

Next is the quantization scale multiplier. It's again the same algorithm, but implemented a bit differently. Because every element of our block needs to be multiplied by QS, the shift register that selects the next 3-bit-slice is cyclic and repeats every 4 cycles. What I tagged as "constant factor" is actually the factor 8 that is used with the very first element (it's probably 8 in order to compensate for the division by 8 in the following steps). The result of the multiplication drops bits 0 and 1, which is equivalent to a right shift by 2, or an integer division by 4 (the last perceived division by 2 probably stems from the very last step, but I'm not too sure; additional input would from others would be appreciated).

Finally, the result is clamped to 12 bits, and then, as Akari mentioned, rounded to the next even number closer to zero (except -1, which stays the same). I do not know why this is done; does -1 have a special meaning? I am not too knowledgeable about JPEG compression. But I guess this is where the last perceived division by 2 comes from; it's not actually a division (that's why I wrote "perceived"), but the precision is effectively reduced by one bit.

So overall the steps should be:
1. res = clamp_to_15_bits(val * qt[k])
2. res = clamp_to_12_bits((res * qs) >> 2)
3. res = res == -1 ? -1 : round_to_even_number_closer_to_zero(res)


Вложения:
02_RLE_control_2014-08-02.jpg
02_RLE_control_2014-08-02.jpg [ 515.81 КБ | Просмотров: 14498 ]
part04_2014-08-02.jpg
part04_2014-08-02.jpg [ 476.21 КБ | Просмотров: 14498 ]
Сообщение 02 авг 2014, 11:49
Профиль ICQ WWW
Аватара пользователя

Зарегистрирован:
24 июл 2007, 10:41
Сообщения: 570
На улице стало холодать, короткое русское лето движется к зиме. Мозги немного остыли и стали думать.

После непродолжительного совещания мне было поручено разобраться куда приходят входы и откуда выходят выходы у шины DD.

Шина DD - это 32-разрядная шина данных, которая соединяет центральный процессор с оперативной памятью (DRAM).

Как и все контакты шины данных - контакты шины DD двунаправленные. Внутренне каждый контакт разводится на два провода: входной (DD/CPU) и выходной (CPU/DD). Про устройство контактной площадки (там используется кастомная CMOS-логика) можно почитать тут : http://wiki.psxdev.ru/index.php/CPU_PADS_BUSES#DD

Далее. Я проследил куда идут все провода и получилась такая картина:

Изображение

Выходы на шину DD идут с обычных защёлок: http://psxdev.ru/cells/63

Входные пути идут на более хитрую схему, которая как я подозреваю работает следующим образом:

Изображение

То есть если управляющая линия каскада активна, то входные данные загружаются на входной DFF, а линия DD "обрывается" с помощью tri-state, чтобы данные не уходили на другие схемы.

Каких-то чётких границ у схем нет, более того часть выходной схемы вылазиет вообще за пределы куска 00 (в кусок 02).


Сообщение 03 авг 2014, 12:46
Профиль ICQ WWW
Аватара пользователя

Зарегистрирован:
24 июл 2007, 10:41
Сообщения: 570
Найдена 8-MUX:

Изображение

http://psxdev.ru/cells/99


Сообщение 29 авг 2014, 17:10
Профиль

Зарегистрирован:
28 ноя 2012, 17:56
Сообщения: 63
Небольшой прогресс по трассировке YUV to RGB преобразованию.

Результат IDCT преобразования (8бит) с юнита 20 расширяется до 10 бит путем дублирования бита 4 и 6. После чего умножается на хз пока что )



Вложения:
part09_2014-08-29.jpg
part09_2014-08-29.jpg [ 671.66 КБ | Просмотров: 14229 ]
04_YUV_2014-08-29.jpg
04_YUV_2014-08-29.jpg [ 157.53 КБ | Просмотров: 14229 ]
Сообщение 21 сен 2014, 22:19
Профиль

Зарегистрирован:
28 ноя 2012, 17:56
Сообщения: 63
Небольшой прогресс по трассировке YUV to RGB преобразованию.

Почти все ячейки теперь перебрались в 05 кусок. Внизу было первое умножение и контроль.



Вложения:
part09_2014-09-22.jpg
part09_2014-09-22.jpg [ 604.97 КБ | Просмотров: 14061 ]
04_YUV_2014-09-22.jpg
04_YUV_2014-09-22.jpg [ 423.3 КБ | Просмотров: 14061 ]
Показать сообщения за:  Поле сортировки  
Ответить на тему   [ Сообщений: 305 ]  На страницу Пред.  1 ... 10, 11, 12, 13, 14, 15, 16  След.

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 7


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by STSoftware for PTF (mod by Zeru-j).
Русская поддержка phpBB