ADSP BF532 и TMS320C6745, помогите с выбором Опции

[__inline__]

Здравствуйте.

Ищу процессор в QFP корпусе, который будет производительнее, чем ADSP BlackFin BF532.
Цель: запуск обильного кода с 2D графикой (bitblt, colorkey, alfablending) + немножко 3D (поворот, перенос, масштабирование), тригонометрия. + эмуляция процессоров -8 и 16 бит:
Z80, 6502, M68000. + декодирование видео (H264, MJPEG,...) аудио (MP3, FLAC)

Пробовал собирать эмуляторы на BF532, разогнал до 700 МГц. Иногда эмуляция всей системы не достигает 60 FPS из-за отсутствия floating point, медленной производительности.

В качестве кандидата на замену рассматриваю : TMS320C6745 - доступен, корпус QFP, 475 МГц, шина SDRAM 32 бита, есть floating point, VLIW до 6 команд одновременно. Вроде как лучше чем BF532 ? Или даст выигрыш по сравнению с 532-м незначительно?

Сообщение отредактировал __inline__ - Mar 26 2018, 13:53

[_pv]

что-то всё действительно загадочно, есть регистр tcon0_cpu_wr_reg у которого по даташиту 24 разряда и который при записи должен писать целиком в LCD_D[23:0],
а потом взяли и как попало подключили линии данных, не подряд, а старшие шесть разрядов каждого цвета (ну чтобы 24х разрядный цвет преобразовывать в 666, или 565 схемотехнически), а теперь руками каждый пиксель перепаковываем обратно из 16/18 в 24,
а нельзя было просто подключить шину подряд, LCD_D[15:0] или [17:0], и писать данные как есть, раз они уже изначально в таком формате?

[__inline__]

что-то всё действительно загадочно, есть регистр tcon0_cpu_wr_reg у которого по даташиту 24 разряда и который при записи должен писать целиком в LCD_D[23:0],
а потом взяли и как попало подключили линии данных, не подряд, а старшие шесть разрядов каждого цвета (ну чтобы 24х разрядный цвет преобразовывать в 666, или 565 схемотехнически), а теперь руками каждый пиксель перепаковываем обратно из 16/18 в 24,
а нельзя было просто подключить шину подряд, LCD_D[15:0] или [17:0], и писать данные как есть, раз они уже изначально в таком формате?

Я бы отталкивался от того, по каким линиям пойдут биты байта при записи в регистр tcon0_cpu_wr_reg. Проверить в принципе это можно, просто зациклив передачу в этот регистр и путём вызванивания тестером логического уровня на каждом бите. Увы и ах - осциллографа и логического анализатора под рукой нет.

А так да, получается индусский говнокод с нагромождением. Но к сожалению, нормальных SDK под эти чипы нет

Должно хватить вот этого(код я писал):

Код

#define CA 25 /* A1位 A1 bit */

#define TCON 0x01C0C000 /* TCON基地址 TCON Base Address */

#define TCON0_CPU_IF_REG *(volatile u32*)(TCON+0x60)
#define TCON0_CPU_WR_REG *(volatile u32*)(TCON+0x64)

void TCON0_INDEX(u32 index)
{
TCON0_CPU_IF_REG&=~(1UL<<CA); //清除CA位 clear CA bit
TCON0_CPU_WR_REG=index;       //写索引 write index
}

void TCON0_DATA(u32 data)
{
TCON0_CPU_IF_REG|=(1UL<<CA);   //设置CA位 set CA bit
TCON0_CPU_WR_REG=data;         // 写入数据 write data
}

Не забыв отремапить ноги GPIO и включив тактирование нужных узлов периферии.

и отынитить TCON для режима CPU I/F i8080

Ну и второй головняк - тайминги шины. Подозреваю, что на ширину строба записи будет влиять делитель для DCLK, а на длительность цикла - длина VSYNC лили LCDDE

Сообщение отредактировал __inline__ - Mar 30 2018, 08:23