[%-) 0]

при передачи цвета напрямую в порт 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;

 

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

Изменено 14 декабря, 2009 пользователем %-)

[SM 0]

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

[%-) 0]

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

 

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

 

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

 

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

 

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

Изменено 14 декабря, 2009 пользователем %-)

[SM 0]

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

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

 

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

[%-) 0]

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

 

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

 

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

 

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

 

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

 

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

 

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

разрешение NTSC => 320x240

 

P.S. кстати заметил, что нужно вывод пикселей синхронизировать по фронту, в то время когда остальные счётчики для синхросигналов и бланков должны работать по спаду. Или наоборот.

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

Иначе - изображение будет дрожжать (особенно при смене видеостраниц)

Изменено 14 декабря, 2009 пользователем %-)

[SM 0]

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

[Builder 1]

P.S. кстати заметил, что нужно вывод пикселей синхронизировать по фронту, в то время когда остальные счётчики для синхросигналов и бланков должны работать по спаду. Или наоборот.

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

Иначе - изображение будет дрожжать (особенно при смене видеостраниц)

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

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

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

В противном случае будете иметь что имеете - непонятные эффекты и странные зависимости.

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

где искать проблему!".

[SM 0]

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

 

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

[%-) 0]

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

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

 

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

 

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

где искать проблему!".

 

Да-да! Известное дело. Было такое... :)

Если вы про это говорите, значит в прошлом у вас такое же было :P

[%-) 0]

кстати, как правильно(синхронно) вычитывать данные из внешней 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 1]

Да-да! Известное дело. Было такое... :)

Если вы про это говорите, значит в прошлом у вас такое же было :P

Не помню, может и было.

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

 

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

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

С ходу, вроде длжно работать, при условии выполнения всех времянок.

Настораживает только:

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

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

 

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

[%-) 0]

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

[des00 25]

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

 

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

 

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

 

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

 

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

 

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

[Builder 1]

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

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

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

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

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

Будете постоянно не понимать что происходит.

Я только не понял, если нет опыта или наставника под боком, зачем брались за такой сложный для Вас проект?

[VasiaMVR 0]

кстати, как правильно(синхронно) вычитывать данные из внешней 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;

 

где-то так.