Собрал еще куски 02 и 05:

http://rghost.ru/46911742 экспериментируем дальше. Билд с отключенным автосохранением

mmap destr0x6fcd42c4[/media/1TB/degate_win/degate/lib/./MemoryMap.h:219] unmappi
ng temp file C:\Users\A9F01~1.SHE\AppData\Local\Temp\\temp.b28ccfc6\1_1.dat
[/media/1TB/degate_win/degate/lib/./MemoryMap.h:225] Closing 39 C:\Users\A9F01~1
.SHE\AppData\Local\Temp\\temp.b28ccfc6\1_1.dat
mmap destr0x6fcd42c4[/media/1TB/degate_win/degate/lib/./MemoryMap.h:219] unmappi
ng temp file C:\Users\A9F01~1.SHE\AppData\Local\Temp\\temp.b28ccfc6\0_2.dat
[/media/1TB/degate_win/degate/lib/./MemoryMap.h:225] Closing 41 C:\Users\A9F01~1
.SHE\AppData\Local\Temp\\temp.b28ccfc6\0_2.dat
StoragePolicy_Tile destr
b::remove_d C:\Users\A9F01~1.SHE\AppData\Local\Temp\\temp.4601a530
mmap destr0x6fcd42c4[/media/1TB/degate_win/degate/lib/./MemoryMap.h:219] unmappi
ng temp file C:\Users\A9F01~1.SHE\AppData\Local\Temp\\temp.4601a530\2_2.dat
[/media/1TB/degate_win/degate/lib/./MemoryMap.h:225] Closing 25 C:\Users\A9F01~1
.SHE\AppData\Local\Temp\\temp.4601a530\2_2.dat
[/media/1TB/degate_win/degate/gui/MainWin.cc:865] Algorithm finished.

И... ничего Целый час искал провода.

-- 21 июн 2013, 14:40 --

Вообщем решил попробовать получить netlist хотя бы части блоков.

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

Что-то сомнения у меня появились что тут находится GTE

Дополнительно вывел наружу все контактные площадки, ни одна из них не участвует в моем куске 2-4.

На контакты шины DD приходит аж 6 проводов. 2 из них это RD и WR (пока неизвестно точно какие их двух), еще 2 провода последовательно соединяет DD0 с DD1, DD1 с DD2 и так далее по цепочке, не понятно зачем.
Остальные 2 провода уходят куда-то наружу и я даже называть их никак не стал.

Отдельно стоит отметить разводку контакта /DCAS3

Область где находится искажение (белая волнистая черта) была получена из нормального куска, так что провода там идут хоть и криво, но в итоге выходят наружу правильно.

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

>И... ничего Целый час искал провода.

Ну, это не баг) Виасы он тоже не особо хорошо находит.
Вообще, на гитхабе есть ветка с другим алгоритмом детектирования, можно попробовать ее собрать. Но я все равно сильно сомневаюсь в эффективности

Похоже от дегейта толку мало. Поделка для защиты диплома.
С OSM тоже не гладко, у них нет хранения растра в базе, так что не факт что допиливать его мало придется.

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

Господин Gloval, а можно взглянуть на ваши "не поделки"?
А то от вас слышно только крики "поделка", "криво" и ровно ноль полезных действий.

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

С этим никто не спорит. Но это не единственная фича проги. Виасы он находит. Поиск вайров зависит весьма от настроек поиска.
К тому же degate позволяет подключать внешний алгоритм для поиска.
Вот если бы господин Gloval написал рабочий алгоритм поиска, а потом бы кричал, что Degate поделка, тогда бы я понял.

Ну и, если что, я никоим образом не отношусь к degate и его авторам, я всего-лишь немного поучаствовал в портировании.

-- 22 июн 2013, 17:13 --

Насчет матчинга. Посмотрел в код, а там пути до временной папки захардкожены. Возможно поэтому под виндой ничего и не работает.

Не обязательно делать автомобили, чтобы судить об их качестве.

Советую посмотреть еще вот эту вещь, на счет возможностей перепиливания под задачи чип реверсинга.
http://www.openmicroscopy.org/site

Ну так захардкодь их на %TEMP%

Попытки присобачить к нашему делу OpenLayers :

http://psxdev.ru/files/tilemaps/psxcpu_part24/

А можно равки заполучить? Чтоб вручную сшить их.
Так как автоматика сшивает безобразно, виасы со вторым слоем не совместятся!

Спасибо за равки.
Посмотрел как они совмещаются. Авто сшившика не получается нормально из-за геометрических искажений, которые приемлимы для панорам, но для карты чипа это не годится.
Совмещение в фотошопе показало, что разбежка между краем и центром около 20-25 пикселей, центр меньше. Значит - подушка. Надо подбирать коэффициент коррекции, чтоб практически 1:1 сходились снимки.

бочку мы тоже учитываем в Hugin при сшивании картинок.
А вообще сшиванием считай только Акари занимается, я сшил только кусок 2-4 и то получилось криво )

Разумеется эти вещи учитываются, НО никакая из программ сшивки не имеет понятия, какие линии должны быть параллельны, а какие перпендикулярны. Они их просто выпрямить стараются, ну а получившиеся погрешности - накапливаются на полной картине. Сшивщики созданы для фото панорам, там такое не заметно.

В хьюджине есть указание вертикальных и горизонтальных линий. Я только не заморачивался с их проставлением. Вообще там можно идеально склеить, но надо очень долго заморачиватся.
http://hugin.sourceforge.net/tutorials/ ... e/en.shtml



Проименовал все блоки которые не относятся к рандомной логике центральной части процессора. Проименованы они по порядку в зависимости от того в каком квадрате они встречаются.



Всего на чипе 5 разных разновидностей таких блоков.

Рассмотрим блоки типа 4, которые достаточно легко идентифицируются на чипе. Это блоки имеющие такую структуру:



К этим блокам относятся unit-10, unit-26 и unit-30 и они являются по всей видимости SRAM.

Unit-30 имеет высоту по вертикали 32x8 и 128 столбцов по горизонтали, что дает нам 4096 ячеек и позволяет идентифицировать блок как кеш данных.

Unit-26 имеет высоту по вертикали 32x8 и 32 столбца по горизонтали, что дает нам 1024 ячейки и позволяет идентифицировать блок как кеш инструкций.

Оставшийся блок Unit-10 имеет высоту по вертикали 24х8 и 32 столбца по горизонтали. Это дает нам 768 байт памяти. Я не знаю для чего может использоватся этот блок. Может для регистров, может в качестве буфера... Есть идеи у кого-нибуть?

Только наоборот : кеш инструкций 4 Кб, кеш данных 1 Кб (который на самом деле всегда залочен и называется ScratchPad).
Кстати справа от кеша данных находится какая-то плотная область логики, очень похожая на RAS/CAS.

Там ещё должно быть 256+1 байт для GTE таблицы, используемой для деления по алгоритму UNRT (хотя не уверен что это RAM)

MDEC использует 64+64 байта для таблиц квантизации и 128 байт (64 полуслов) для scale table.

Должен быть ещё кольцевой буфер для SIO.

Также не уверен, но должно быть где-то хранилище для DMA-буферов.

Теперь понятно, почему так криво сшивалась панорама. Наконец найден софт, который оказался способен распознать и поправить дисторсию. И дисторсия, как оказалось, вообще не свойственная для фотобъективов (на которую рассчитан хьюджин). После коррекции картинки сходятся пиксель в пиксель.
Но не все так гладко, результат прога почему-то сохраняет в 16 битный серый тифф.

Софт опенсорсный, написан на Яве.
http://fiji.sc/Fiji

Кто-нибуть может разобраться и пофиксить проблему с сохранением результатов?

При создании Image указать Type = RGB

Не помогает.
plugins->transform->distortion correction

Он сохранает результат почему-то только серым.