Реализация LookUp Table для видеовывода, нечёткое изображеине Опции

[%-)]

при передачи цвета напрямую в порт RGB, затем цап на резисторах - потом на кодер AD724 - на телевизоре изображение чёткое:

Код

if rising_edge(pixel_clock) then
if Blank='1' then
   R<=SRAM_Data(14..10);
   G<=SRAM_Data(9 ...5);
   B<=SRAM_Dta(4..0);
end if;
end if;

при выводе из Look-Up таблицы в порт RGB чёткость изображения понижается - оно как бы размыто - с небольшим трудом читаются символы матрицы 8x8:

Код

if rising_edge(pixel_clock) then
if Blank='1' then
   R<=LookUpRED(conv_integer(SRAM_Data(14..10)));
   G<=LookUpGreen(conv_integer(SRAM_Data(9..5)));
   B<=LookUpBlue(conv_integer(SRAM_Data(4..0)));
end if;
end if;

есть ли способ избавиться от размытости?

Сообщение отредактировал %-) - Dec 14 2009, 06:35

[SM]

хрень какая-то. Констрейны выполняются? Слаков нет? Других причин не вижу.

[%-)]

хрень какая-то. Констрейны выполняются? Слаков нет? Других причин не вижу.

вот слаков навалом к сожалению как только врубаем палитру - их сыпется куча!

подскажите верный способ сделать реализацию ЛУКапа внутри ПЛИС.

внешний рам-дак не предалагать

P.S. на VGA мониторе лукап работает без проблем - а в телевизоре ж@па

Сообщение отредактировал %-) - Dec 14 2009, 06:50

[SM]

вот слаков навалом к сожалению как только врубаем палитру - их сыпется куча!

Конвейеризировать, сделать задержку на 1 пиксел, поставив регистры между памятью и лутами.

Хотя разное поведение на мониторе и на TV - странно это... Сигнал-то один.

[%-)]

Хотя разное поведение на мониторе и на TV - странно это... Сигнал-то один.

развёртка разная - для VGA и NTSC

все счётчики и поля и синхросгналы пересчитываются зависимо от выбранного режима

тактовый генератор - один.

вот исходные данные:

мастерклок 50 мгц

разрешение ВГА 640x480 (из него 320x240)
разрешение NTSC => 320x240

P.S. кстати заметил, что нужно вывод пикселей синхронизировать по фронту, в то время когда остальные счётчики для синхросигналов и бланков должны работать по спаду. Или наоборот.
Потому что выводить точки нужно когда память уже выдаёт на шине - данные (строб OE в SRAM заведён на частоту pixelclock/2=14.5 Мгц)
Иначе - изображение будет дрожжать (особенно при смене видеостраниц)

Сообщение отредактировал %-) - Dec 14 2009, 07:01

[SM]

Короче - пока есть слаки, нет никакого смысла заливать это в железо.

[Builder]

P.S. кстати заметил, что нужно вывод пикселей синхронизировать по фронту, в то время когда остальные счётчики для синхросигналов и бланков должны работать по спаду. Или наоборот.
Потому что выводить точки нужно когда память уже выдаёт на шине - данные (строб OE в SRAM заведён на частоту pixelclock/2=14.5 Мгц)
Иначе - изображение будет дрожжать (особенно при смене видеостраниц)

Учитывая историю вопроса (в других темах) и то что Вы тут написали, проблема во времянке,
и том, что Вы так до конца с ней не разобрались...
Начинайте с проверки и описании времянки. Что-б могли с полной уверенностью знать что все времянки выполняются.
В противном случае будете иметь что имеете - непонятные эффекты и странные зависимости.
А если и получттся что, измените потом проект и появится новая тема, типа "работал прект, добавил модуль - переслал работать,
где искать проблему!".

[SM]

появится новая тема, типа "работал прект, добавил модуль - переслал работать, где искать проблему!".

А еще круче - "при работе за полярным кругом на телевизоре размывается, а на экваторе - с монитором глючит"

[%-)]

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

тут уже другая времянка

А если и получттся что, измените потом проект и появится новая тема, типа "работал прект, добавил модуль - переслал работать,
где искать проблему!".

Да-да! Известное дело. Было такое...
Если вы про это говорите, значит в прошлом у вас такое же было :P

[%-)]

кстати, как правильно(синхронно) вычитывать данные из внешней SRAM на дисплей?

Пока сделано так(для наглядности - код упрощён - нет обнулений по ограничению):

Код

process(Clk) --из 50 МГц получаем 25 мгц для пиксельклока
begin
if rising_edge(Clk) then
  PixelClock<=PixelClock+1;
end if;
end process;

process(PixelClock) --для увеличения адреса SRAM
begin
if rising_edge(PixelClock) then
  Address<=Address+1;
end if;
end process;

SRAM_CE<='0';
SRAM_OE<=PixelClock; --стробируем по пикслеьклоку. Квазисинхронный режим??? Для SRAM
SRAM_A<=Address;

process(PixelClock) --выдаём данные на VGA порт
begin
if rising_edge(PixelClock) then
  if Blank='1' then          -- кадр
   R<=SRAM_D(14 downto 10); -- считываем данные с SRAM
   G<=SRAM_D(9 downto 5);
   B<=SRAM_D(4 downto 0);
  else                            --бланк-интервалы - форсируем цвет в 0
   R<="00000";
   G<="00000";
   B<="00000";
  end if;
end if;
end process;

Blank<=HBlank and VBlank; -- =0 когда обратный ход луча(по строке или кадру), 1 - когда идёт отображение кадра

[Builder]

Да-да! Известное дело. Было такое...
Если вы про это говорите, значит в прошлом у вас такое же было :P

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

кстати, как правильно(синхронно) вычитывать данные из внешней SRAM на дисплей?

А бог его знает как правильно, как кому нравится, главное что-б было корректно и работало.
С ходу, вроде длжно работать, при условии выполнения всех времянок.
Настораживает только:
1) генерация производного клока. Само по себе - ничего плохого. Но при условии что опять-же, описана времянка и нет завязки на другие клоковые домены. Если есть - нада что-б были корректно сделаны связи между доменами. Как-я бросал ссылки на документы.
2) для улучшения времянки, можно поставить тригеры на выходе. Но в принципе - не абязательно, если запас по времянке и так большой. Кстати, как вариант, сделать выход генератора производной частоты как сейчас, а для остальной части кода использовать его не как клок, а как разрешение. Но это желательно, если есть, как я уже написал, завязки на другой код с исходной частотой.

PS. а вообще, я на VHDL не пишу, так, чуть читаю.

[%-)]

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

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

тут и VGA режим нужен и NTSC и каждый из них ещё должен быть в директколоре и в палитровом режиме. Всё зависит от управляющих регистров.

вот и поэтому собираюсь конвееризировать и синхронизировать.

P.S. особенно бесит то , что симулятор насимулил иголки вот в таком на первый взгляд "простом" месте:

Код

HBlank<='1' when (HCounter>=(Sync+BackPorch) and HCounter<(Sync+BackPorch+Visible)) else '0';

а вот при об-клочивании пиксельклоком - горизонтальный синхроимпульс стал выглядеть как надо

логика (особенно программируемая) - это просто КАПЕЦ

[des00]

P.S. особенно бесит то , что симулятор насимулил иголки вот в таком на первый взгляд "простом" месте:

Код

HBlank<='1' when (HCounter>=(Sync+BackPorch) and HCounter<(Sync+BackPorch+Visible)) else '0';

а вот при об-клочивании пиксельклоком - горизонтальный синхроимпульс стал выглядеть как надо

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

логика (особенно программируемая) - это просто КАПЕЦ

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

[Builder]

P.S. особенно бесит то , что симулятор насимулил иголки вот в таком на первый взгляд "простом" месте:

Код

HBlank<='1' when (HCounter>=(Sync+BackPorch) and HCounter<(Sync+BackPorch+Visible)) else '0';

а вот при об-клочивании пиксельклоком - горизонтальный синхроимпульс стал выглядеть как надо
логика (особенно программируемая) - это просто КАПЕЦ

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

[VasiaMVR]

кстати, как правильно(синхронно) вычитывать данные из внешней SRAM на дисплей?

Не стоит делить частоту на триггере и затем использовать её в качестве тактовой если потом надо перепривязывать назад к 50. Лучший вариант, когда всё работает от одной тактовой с разрешениями. Есть DLL, PLL и др. блоки предназначенные для этого
я бы сделал так:

Код

process(Clk) --из 50 МГц получаем !!!разрешение!!! 25 мгц для пиксельклока
begin
if rising_edge(Clk) then
  PixelClock_en<=PixelClock_en+1; --зачем +1 ??? можно просто not PixelClock_en
end if;
end process;

process(Clk) --для увеличения адреса SRAM
begin
if rising_edge(Clk) then
  if PixelClock_en='0' then
   Address<=Address+1;
  end if;
end if;
end process;

SRAM_CE<='0';
--SRAM_OE<=PixelClock; --стробируем по пикслеьклоку. Квазисинхронный режим???
-- если нужно постоянно читать, можно вообще SRAM_OE<='0' на время чтения и не дергать лишний раз буфера, кроме этого сокращается время на чтение см ниже.
--SRAM_A<=Address; -- вот это интересней см ниже
-- чтение из SRAM  Есть следующие задержки
--1. от CLK до выходных ножек ПЛИС. Если так вывести, то задержка будет меняться от разводки, можно (вообще-то нужно) задать макс. значение (для Xilinx см OFFSET OUT)
--2. от ADDR SRAM до DATA SRAM см datasheet на SDRAM.
--3. от ножек ПЛИС до регистров. задать макс. значение (для Xilinx см OFFSET IN)
-- Сумма трех задержек меньше периода тактовой, в данном случае 40нс, что много (смотря сколь-ко логики нагородить на данных) и можно не ставить дополнительные регистры в ножках, но все-же лучше так
-- Единственно, если стробировать SRAM_OE для 2. максимальное из (ADDR -> DATA) и  ((ОЕ -> DATA) + 20 нс).

process(Clk)
begin
if rising_edge(Clk) then
  if PixelClock_en='0' then
   SRAM_A<=Address+1;  --не забудь поставить атрибут, что-бы синтез не выкинул одинаковые регистры. Можно без +1, тогда атрибут не нужен, но будет дополнительная задержка на такт.
  end if;
  SRAM_OE<=not PixelClock_en; --не забудь поставить атрибут, что-бы синтез не выкинул одинаковые регистры.
end if;
end process;

--process(PixelClock) --выдаём данные на VGA порт
--begin
-- if rising_edge(PixelClock) then
--  if Blank='1' then          -- кадр
--   R<=SRAM_D(14 downto 10); -- считываем данные с SRAM
--   G<=SRAM_D(9 downto 5);
--   B<=SRAM_D(4 downto 0);
--  else                            --бланк-интервалы - форсируем цвет в 0
--   R<="00000";
--   G<="00000";
--   B<="00000";
--  end if;
-- end if;
--end process;

--Blank<=HBlank and VBlank; -- =0 когда обратный ход луча(по строке или кадру), 1 - когда идёт отображение кадра

-- регистр один на вход и выход, лучше добавить ещё один.

process(Clk) --выдаём данные на VGA порт
begin
if rising_edge(Clk) then
  if PixelClock_en='0' then
   SRAM_D_reg<=SRAM_D;
   if Blank='1' then          -- кадр
    R<=SRAM_D_reg(14 downto 10); -- считываем данные с SRAM
    G<=SRAM_D_reg(9 downto 5);
    B<=SRAM_D_reg(4 downto 0);
   else                            --бланк-интервалы - форсируем цвет в 0
    R<="00000";
    G<="00000";
    B<="00000";
   end if;
   Blank<=HBlank and VBlank; -- задерживаем на такт, другие выходные сигналы тоже задержать.
  end if;
end if;
end process;

где-то так.

[%-)]

Не стоит делить частоту на триггере и затем использовать её в качестве тактовой если потом надо перепривязывать назад к 50. Лучший вариант, когда всё работает от одной тактовой с разрешениями. Есть DLL, PLL и др. блоки предназначенные для этого
я бы сделал так:

Спасибо за ваш развёрнутый ответ

А как можно сделать палитру?

Мы должны считать с памяти слово (16 бит). Затем на одном такте его биты 0..7 загнать в индекс массива палитры, на другом такте биты 8..15 в палитру. И так по кругу.

Тоесть в палитровом режиме частота чтения в 2 раза меньше должна быть, но частота вывода останется таже - 12.5 МГц. На первом такте биты 0..7 на втором 8..15

тоесть:

данные на частоте 12.5 / 2 МГц:

Код

SRAM_Address<=ReadAddr+1;

на первом такте 12.5 МГц:

Код

Video_R<=Palette(conv_integer(SRAM_D_Reg(7 downto 0)))(14..10);
Video_G<=Palette(conv_integer(SRAM_D_Reg(7 downto 0)))(9..5);
Video_B<=Palette(conv_integer(SRAM_D_Reg(7 downto 0)))(4..0);

на втором такте 12.5 МГц:

Код

Video_R<=Palette(conv_integer(SRAM_D_Reg(15 downto 8)))(14..10);
Video_G<=Palette(conv_integer(SRAM_D_Reg(15 downto 8)))(9..5);
Video_B<=Palette(conv_integer(SRAM_D_Reg(15 downto 8)))(4..0);

как оптимальнее и правильнее сделать?

[%-)]

ещё вопрос по генерации адреса.
нужно удваивать строки. тогда адреса генерируются так: 0..319, 0..319, 320..639, 320..639, 640.....

делаю пока так:

if rising_edge(Clk) then
if PixelClockEn='0' then
if Blank='1' then
if F(conv_integer(V(0)))=153599 then
F(conv_integer(V(0)))<=(others => '0');
else
F(conv_integer(V(0)))<=F(conv_integer(V(0)))+1;
end if;
end if;
...

тоесть завёл массив из двух счётчиков и инкрементируем их по-очереди (номер 0-1 задается нулевым битом номера строки)

как можно быстрее и проще?

[des00]

А как можно сделать палитру?

какая задача знакомая..... %)

зачем читать палитру с SRAM, которую туда кто то загрузил через FPGA, грузите сразу декодеры палитры и используйте их.

[%-)]

какая задача знакомая..... %)

зачем читать палитру с SRAM, которую туда кто то загрузил через FPGA, грузите сразу декодеры палитры и используйте их.

вы наверное меня не поняли

загружаю палиру через регистры вовнутренние std_logic_vector'а

в SRAM'е палитры нет - просто из SRAM мы вычитываем слово(16 бит) - байты которых - код ццета - индекс массива палитры

памагите сзделать ;-)

гыыы... вот:

Код

process(Clk)
begin
if rising_edge(Clk) then
  if PixelClockEn='0' then
   if Blank='1' then
    --Direct Color 16bpp R:G:B = 1:5:5:5
    if R_M(0)='0' then
     if R_P='0' then
      RGB<=VRAM0_D(14 downto 0);
     else
      RGB<=VRAM1_D(14 downto 0);
     end if;
    --Palette Color 8bpp
    else
     if R_P='0' then
      if R_M(1)='0' then                                --VGA
       if F(conv_integer(V(0)))(2)='0' then
        RGB<=R_RGB(conv_integer(VRAM0_D( 7 downto 0)));
       else
        RGB<=R_RGB(conv_integer(VRAM0_D(15 downto 8)));
       end if;
      else                                              --NTSC
       if F(0)(2)='0' then
        RGB<=R_RGB(conv_integer(VRAM0_D( 7 downto 0)));
       else
        RGB<=R_RGB(conv_integer(VRAM0_D(15 downto 8)));
       end if;
      end if;
     else
      if R_M(1)='0' then                                --VGA
       if F(conv_integer(V(0)))(2)='0' then
        RGB<=R_RGB(conv_integer(VRAM1_D( 7 downto 0)));
       else
        RGB<=R_RGB(conv_integer(VRAM1_D(15 downto 8)));
       end if;
      else                                              --NTSC
       if F(0)(2)='0' then
        RGB<=R_RGB(conv_integer(VRAM1_D( 7 downto 0)));
       else
        RGB<=R_RGB(conv_integer(VRAM1_D(15 downto 8)));
       end if;
      end if;
     end if;
    end if;
   end if;
  end if;
end if;
end process;

process(Clk)
begin
if rising_edge(Clk) then
  if PixelClockEn='0' then
   RGB_Reg<=RGB;
   if Blank='1' then
    Video_R<=RGB_Reg(14 downto 10);
    Video_G<=RGB_Reg( 9 downto  5);
    Video_B<=RGB_Reg( 4 downto  0);
   else
    Video_R<=(others => '0');
    Video_G<=(others => '0');
    Video_B<=(others => '0');
   end if;
  end if;
end if;
end process;

[%-)]

люди!
памагите!

сроки поджимают, а мы(контора) до конца не сделали!

палитру подскажите как делать плиз...

--------------
пока такая идея: потактово - вычисление адреса, вычитывание байта, считывание палитры, выод на экран

[torik]

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

[%-)]

палитра не считается по формуле.

всего 256 цветов - они хранятся в видеопамяти по 1 байту на 1 точку

этот байт - и есть номер(смещение) массива палитры. (массив хранит R,G,B в 15 битах)

описание массива палитры:

Код

type R_RGB_Type is array(255 downto 0) of std_logic_vector(14 downto 0);
signal R_RGB:R_RGB_Type;

запись в регистры палитры:

Код

*(short*)(BaseAddr+RegOffs)=0x7000|Color;
*(short*)(BaseAddr+RegOffs)=0x8000|(R<<10)|(G<<5)|B;

Код

process(ClkPLL)
begin
if rising_edge(ClkPLL) then
...
   when "0111"=>                                        
      R_C:=D1(7 downto 0);

   when "1000"=>      
      if D1(15)='1' then
       R_RGB(conv_integer(R_C))<=D1(14 downto 0);
      end if;
...

При синтезе массив палитры преобразуется в двухпортовую синхронную память, тактируемую ClkPLL (200МГц)

Вывод видеоданных на VGA происходит на другом клоке - Clk=50 МГц

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

Сообщение отредактировал %-) - Dec 17 2009, 02:12

[des00]

При синтезе массив палитры преобразуется в двухпортовую синхронную память, тактируемую ClkPLL (200МГц)
Возможно , нечёткое изображение (когда используется палитра) из-за разных тактовых клоков

в чем проблема заменить двухпортовую синхронную одноклоковую на двухпортовую синхронную двухкловую? в N-ый раз повторяю читайте хендбуки с www.altera.com, там все написано. Ответ на большинство ваших вопросов ищется в хендбуке за 10-15 минут + немного логики здравого смысла, но вы по прежнему прете в слепую на баррикады уповая на помощь форума, неправильно это.

[%-)]

в чем проблема заменить двухпортовую синхронную одноклоковую на двухпортовую синхронную двухкловую? в N-ый раз повторяю читайте хендбуки с www.altera.com, там все написано. Ответ на большинство ваших вопросов ищется в хендбуке за 10-15 минут + немного логики здравого смысла, но вы по прежнему прете в слепую на баррикады уповая на помощь форума, неправильно это.

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

во-вторых: что-то мы сомневаемся, что алтера изобилует экзамплами вга-контроллеров , особенно с применением колор-меппера

в-третьих: почти весь OpenSource в 90% представляет собой г@вно, которое не работает либо работает не так

в-четвртых: кроме нас думается никто в точности не знает что надо получить ;-)

[torik]

во-вторых: что-то мы сомневаемся, что алтера изобилует экзамплами вга-контроллеров , особенно с применением колор-меппера

Да, вещь действительно уникальнейшая, потому примеров нет ниииигде.

в-четвртых: кроме нас думается никто в точности не знает что надо получить ;-)

Да на самом деле, господин des00 вам правду сказал насчет памяти. Сгенерируйте тогда это ОЗУ (и нафига двухпортовое?) в мегавизарде, да вставьте как модуль.

[des00]

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

"не зная броду, не суйся в воду" (с) Народная мудрость. Дальнейший разговор с вами, при такой вашей позиции, считаю бессмысленным и буду ставить в игнор. Желаю удачи %)

[%-)]

"не зная броду, не суйся в воду" (с) Народная мудрость. Дальнейший разговор с вами, при такой вашей позиции, считаю бессмысленным и буду ставить в игнор. Желаю удачи %)

напоминает разговор слепого с глухим. чесслово...

ожидаю здравых ыслей по палитре - а мне подсовывают формулы??? в недоумении...

тогда нах форум этот нужен вообще, если ответы можно в другом месте искать?

толку ~0

Да на самом деле, господин des00 вам правду сказал насчет памяти. Сгенерируйте тогда это ОЗУ (и нафига двухпортовое?) в мегавизарде, да вставьте как модуль.

неправда.

двухпортовое озу просто необходимо - нужно одновременно и оперативно писать и вычитывать.

[torik]

неправда.

двухпортовое озу просто необходимо - нужно одновременно и оперативно писать и вычитывать.

Хорошо, пусть так. Тогда хоть объясните что вы собрались записывать в память с палитрой? Я думал, что палитра - это массив констант, однопортовое ПЗУ. Адрес = номер цвета, а выход = нужное значение. Не вижу принципиальных проблем. Чего так настойчиво отказываться от предложенного выше. Через мегавизард хоть одно хоть двухпортовую память можно сделать...

[Builder]

напоминает разговор слепого с глухим. чесслово...

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

ожидаю здравых ыслей по палитре - а мне подсовывают формулы??? в недоумении...

Да Вы сами не знаете что Вам нужно. Если-бы знали - не говорили-бы так. Зачем было ввязываться в проект, с такими знаниями.

тогда нах форум этот нужен вообще, если ответы можно в другом месте искать?
толку ~0

Форум для того, что-бы обсуждать проблемы, делится опытом и знаниями. А не для того, что-бы вместе Вам писать проект.
Вам надавали информации, по которой без напряга Ваш проект делается за время, меньшее чем Вы обсуждаете его тут, на форуме.
Но это конечно если знать что и как делать.

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

Синтезатор делает не больше чем Вы ему сказали, так что не расслабляйтесь.

Хорошо, пусть так. Тогда хоть объясните что вы собрались записывать в память с палитрой? Я думал, что палитра - это массив констант, однопортовое ПЗУ. Адрес = номер цвета, а выход = нужное значение. Не вижу принципиальных проблем. Чего так настойчиво отказываться от предложенного выше. Через мегавизард хоть одно хоть двухпортовую память можно сделать...

Как я понял, ему нужно то что Вы написали, но не ПЗУ, а ОЗУ, коды палитры могут в процессе работы перегружатся, они не константны.

[Maverick]

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

во-вторых: что-то мы сомневаемся, что алтера изобилует экзамплами вга-контроллеров , особенно с применением колор-меппера

синтезатор синтезирует то, что ВЫ ему дали на съедение...
Мегавизар - генерирует в соответствии с Вашими параметрами(всякие галочки, ввод/выбор различных цифр), которые Вы установили. Ему все равно, что Вы там поставили...(единственно за чем Мегавизард следит так это чтобы не было перебора с ресурсами ПЛИС)

напоминает разговор слепого с глухим. чесслово...

ожидаю здравых мыслей по палитре - а мне подсовывают формулы??? в недоумении...

тогда нах форум этот нужен вообще, если ответы можно в другом месте искать?

Значит Вы некорректно задаете вопрос или не полностью делитесь проблемой

!!!почитай Вам будет интересно!!!

ЗЫ прежде чем говорить что либо, подумай говорят помогает.

[Builder]

!!!почитай Вам будет интересно!!!

Я уже давал эту ссылку...

[%-)]

!!!почитай Вам будет интересно!!!

засуньте себе в одно место

в N-ый раз повторяю читайте хендбуки с www.altera.com, там все написано. Ответ на большинство ваших вопросов ищется в хендбуке за 10-15 минут + немного логики здравого смысла

номер хендбука от Алтеры пожалуйста...
где написано как сделать перегружаемую палитру на 256 цветов

отсутствие ссылки - факт подтверждения вашего мнимого профессионализма.

P.S. говорить и посылать мы все можем.

[torik]

Многие ли захотят Вам помогать
Да и нечем, похоже, помочь...

[DmitryR]

двухпортовое озу просто необходимо - нужно одновременно и оперативно писать и вычитывать.

В надежде закончить этот холивар я вам скажу: когда вы одновременно пишете значение палитры и читаете его же, вы в зависимости от настроек памяти можете получить три разных вида значений, в том числе и неопределенное (что IMHO по умолчанию или даже без вариантов у Альтеры). Двухпортовая память может применяться, когда запись и чтение разделены по адресам. Так как чтение палитры использует случайные адреса - реализовать это, на мой взгляд можно только сделам палитру двустраничной, в неактивную страницу пишите - из активной читаете, потом меняете местами. Или все-таки писать палитру во время бланкинга - тогда хватит одной страницы.

[%-)]

когда вы одновременно пишете значение палитры и читаете его же, вы в зависимости от настроек памяти можете получить три разных вида значений, в том числе и неопределенное (что IMHO по умолчанию или даже без вариантов у Альтеры). Двухпортовая память может применяться, когда запись и чтение разделены по адресам. Так как чтение палитры использует случайные адреса - реализовать это, на мой взгляд можно только сделам палитру двустраничной, в неактивную страницу пишите - из активной читаете, потом меняете местами. Или все-таки писать палитру во время бланкинга - тогда хватит одной страницы.

лажу несёте, сударь, однако

эксперименты с палитрой показали, что если индекс палитры - всегда определённые биты (например биты 0 - 7 памяти), то палитра успешно отображается и на VGA и на ТВ:
здесь адрес меняется по фронту clk:

Код

if rising_edge(clk) then
   R<rgb(conv_integer(sram(7..0)))(14..10);
   G<rgb(conv_integer(sram(7..0)))(9..5);
   B<rgb(conv_integer(sram(7..0)))(4..0);
end if;

если же на первом такте вычитывать биты 0-7 памяти, а на втором такте - биты 8-15 (ещё раз: биты 0-7 - это одна точка, биты 8-15 - вторая точка), то размытость на ТВ ожидаема. На VGA всё ОК
здесь адрес меняется по фронту clk/2:

Код

if rising_edge(clk) then
if shift='0' then
   R<rgb(conv_integer(sram(7..0)))(14..10);
   G<rgb(conv_integer(sram(7..0)))(9..5);
   B<rgb(conv_integer(sram(7..0)))(4..0);
else
   R<rgb(conv_integer(sram(15..8)))(14..10);
   G<rgb(conv_integer(sram(15..8)))(9..5);
   B<rgb(conv_integer(sram(15..8)))(4..0);
end if;
shift<=not shift;
end if;

Сообщение отредактировал %-) - Dec 19 2009, 06:02