Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: защёлка для сигналов RGB
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
penauch
не получается сделать защёлку для цветов R,G,B

есть синхросигнал
и сигнал поделённый на 4, тоесть счетчик 0,1,2,3,0,1,2,3...

когда сигнал=0 то с шины данных считывается биты в RGB

когда сигнал 1,2,3, то данные с шины не должны поступать, а использоваться защёлкнутые (когда сигнал=0) данные

код типа:

if count(1 downto 0)=0 then
R<=DataBus(3 downto 0);
G<=DataBus(7 downto 4);
B<=DataBus(11 downto 8);
end if;

даёт постоянную коммутацию DataBus на RGB, а надо чтобы оставалось защёлкнуто до тех пор пока снова count станет 0

как это сделать? 1111493779.gif
Костян
нужно делать синхронно , по фронту/срезу clk

Код
process (clock)
begin
   if clock='1' and clock'event then
      if reset='1' then
            R <= (othets => '0');
            G <= (othets => '0');
            B <= (othets => '0');
      elsif count(1 downto 0)=0 then
         R<=DataBus(3 downto 0);
         G<=DataBus(7 downto 4);
         B<=DataBus(11 downto 8);
         else
            R <= R;
            G <= G;
            B <= B;
         end if;
      end if;
   end if;
end process;
penauch
в общем смысл таков. использую Altera-DE на Cyclone-2, память SRAM ISSI 256kx16 10ns - видеобуффер

доступ к памяти такой:

SRAM_CS _|-|_|-|_|-|_|-|_|-|_|-|_|-|_|-|_|-|_|-|_|-| выбор чипа Clk
SRAM_OE _|-----|_|------|_|-----|_|--- строб чтения Clk or c(0)
SRAM_WE----|_|------|_|-----|_|-----|_ строб записи Clk or (not c(0))

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

VHDL:
Код
process(Clk)
begin
if rising_edge(Clk) then
  c<=c+1;
end if;
end process;

Port_CSWE<=Port_CS or Port_WE;

SRAM_CS<=Clk when (Port_CS='0' and Port_WE='0' and Port_A='1') else Clk or c(0);

SRAM_OE<=Clk or c(0);

process(Port_CS,Port_WE,Port_A,CPU_A,Port_D,Clk,c(0),V480(0),Pixel4Clock0,Pixel4Clock1,SRAM_D)
begin
if (Port_CS='0' and Port_WE='0' and Port_A='1') then
  SRAM_A(16 downto 0)<=CPU_A;
  SRAM_D<=Port_D;
  SRAM_WE<=Clk or (not c(0));
else
  if V480(0)='0' then
   SRAM_A(16 downto 0)<=Pixel4Clock0(18 downto 2);
  else
   SRAM_A(16 downto 0)<=Pixel4Clock1(18 downto 2);
  end if;
  SRAM_D<="ZZZZZZZZZZZZZZZZ";
  SRAM_WE<='1';
end if;
end process;

process(Port_A,Port_CSWE,CPU_A)
begin
if Port_A='1' then
  if rising_edge(Port_CSWE) then
   if CPU_A(16 downto 0)<76799 then
    CPU_A<=CPU_A+1;
   else
    CPU_A<="00000000000000000";
   end if;
  end if;
end if;
end process;

process(VBlank,HBlank,c,SRAM_D,SRAM_WE,SRAM_CS,SRAM_OE,c,Clk)
begin
if (SRAM_OE='0' and SRAM_CS='0' and SRAM_WE='1')  then
  if (VBlank='1' and HBlank='1') then
   Video_R<=SRAM_D(14 downto 11);
   Video_G<=SRAM_D( 9 downto  6);
   Video_B<=SRAM_D( 4 downto  1);
  else
   Video_R<="0000";
   Video_G<="0000";
   Video_B<="0000";
  end if;
end if;
end process;


проблема в следующем - когда пишем данные в порт: Port_D[15..0], Port_A=1, Port_CS=0, Port_WE=0, то на экране возникает снег, который исчезает после прекращения записей.

Память пишется нормально и читается тоже - содержимое буфера выводится корректно.

Но портит всё снег smile3046.gif

Помогите плиз советом или методами как не допускать снег ?

пробовал как Костян, написал - снег всёравно есть sad.gif

process(Res,VBlank,HBlank,c,SRAM_D,SRAM_WE,SRAM_CS,SRAM_OE,c,Clk)
begin
if Clk='1' and Clk'event then
if (SRAM_OE='0' and SRAM_CS='0' and SRAM_WE='1') then
if (VBlank='1' and HBlank='1') then
Video_R<=SRAM_D(14 downto 11);
Video_G<=SRAM_D( 9 downto 6);
Video_B<=SRAM_D( 4 downto 1);
else
Video_R<="0000";
Video_G<="0000";
Video_B<="0000";
end if;
else
Video_R <= Video_R;
Video_G <= Video_G;
Video_B <= Video_B;
end if;
end if;
end process;
rv3dll(lex)
для начала зачем писать и читать по одному значению?
penauch
Цитата(rv3dll(lex) @ Oct 28 2009, 17:44) *
для начала зачем писать и читать по одному значению?


не понял вопрос.

чиатаем и пишем по разным адресам.

когда происходите фронт Port_WE, адрес по записи CPU_A инкрементируется
а когда наступают фазы отображения - адрес меняется на Pixel4Clock0 или Pixel4Clock1 (режим удвоения строк)
Костян
Цитата(penauch @ Oct 28 2009, 11:47) *
не понял вопрос.

чиатаем и пишем по разным адресам.


пишите в SRAM в момент времени когда (VBlank='1' and HBlank='1') = false
eliza
Попробуйте подхватывать считанные данные по положительному фронту OE, т.е.
Код
process(Res,VBlank,HBlank,c,SRAM_D,SRAM_WE,SRAM_CS,SRAM_OE,c,Clk)
begin
if (SRAM_CS='0' and SRAM_WE='1') then
  if (rising_edge(SRAM_OE)) then
    if (VBlank='1' and HBlank='1') then
    .......
penauch
Цитата(eliza @ Oct 29 2009, 03:01) *
Попробуйте подхватывать считанные данные по положительному фронту OE, т.е.
Код
process(Res,VBlank,HBlank,c,SRAM_D,SRAM_WE,SRAM_CS,SRAM_OE,c,Clk)
begin
if (SRAM_CS='0' and SRAM_WE='1') then
  if (rising_edge(SRAM_OE)) then
    if (VBlank='1' and HBlank='1') then
    .......


Сделал - данные не пишутся в SRAM sad.gif

Возможно из-за коротких стробов чтения(OE), выбора кристалла(CS)

Также подхватывал по фронту OE - R,G,B

Цитата(Костян @ Oct 28 2009, 18:44) *
пишите в SRAM в момент времени когда (VBlank='1' and HBlank='1') = false


вот этого больше всего боялся услышать rolleyes.gif

действительно, когда запись происходит в моменты VBLank=0 ИЛИ HBlank=0 то снега нет, что логично.
Но вот времени переслать весь кадр целиком - не хватает.

А пересылать кадр построчно во время HBlank= 0 (каждую строку) - недопустимо в проекте ... unsure.gif


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

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

Или все дело в двухпортовом ОЗУ?
Shtirlits
Предположу, что у вас синтезируется ерунда несинхронная. В симуляторе не видно, а на практике гонки.
Сколько у вас разных сигналов стоит в скобках if rising_edge() ?
Я бы сделал полностью синхронную схему, тактируемую одним фронтом одного клока, а если не получится, то тогда концепцию подозревал. И обязательно посмотрел бы во что синтезируется.
penauch
Цитата(Shtirlits @ Oct 29 2009, 03:52) *
Предположу, что у вас синтезируется ерунда несинхронная. В симуляторе не видно, а на практике гонки.
Сколько у вас разных сигналов стоит в скобках if rising_edge() ?
Я бы сделал полностью синхронную схему, тактируемую одним фронтом одного клока, а если не получится, то тогда концепцию подозревал. И обязательно посмотрел бы во что синтезируется.


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

можете написать свой вариант фрагментов по которым было бы видно что и как?

и ещё - частота Clk = 50 МГц, ширина строба 10нс - притык для SRAM, может из-за этого?

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

одним словом, когда мы пишем - в память пишется, а луч находится в другом месте и вместо цвета в данном месте чертит на доли секунды то что пишим в ячейку! потому что снег появляется не случайно - он выстроен в косые линии идущие вертикально.

как можно заткнуть RGB чтоб они не обновлялись в момент записи?

SRAM_D обьявлен как inout - предполагаю что он засоряется в момент записи, а в RGB передается тот самый SRAM_D

как можно разрулить?
Shtirlits
Считаю, что полезно будет написать модель памяти с assert-ами, сделать наконец-то Testbench и загнать все это в симулятор и там все будет видно.
eliza
Я не работаю с VHDL, поэтому хотела передать идею - данные, считанные с памяти, по положительному фронту OE писать в выходной регистр. Снег появляется, скорее всего, из-за того, что у Вас данные пропускаются на выход во время всего OE=0, а после подачи OE на SDRAM валидные данные на ее выходе появляются не сразу.
А длительность OE на минимуме, если 10нс есть, едва ли влиять может. Длительность CS, времена установления, удержания - выдерживаются?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.