|
Обращение к SRAM, нет данных на выходе. |
|
|
|
Aug 12 2015, 08:35
|
Частый гость
 
Группа: Участник
Сообщений: 79
Регистрация: 11-06-09
Из: Санкт-Петербург
Пользователь №: 50 207

|
Доброго времени суток Доделываю этот проект: http://electronix.ru/forum/index.php?showt...126809&st=0Суть в следующем, есть частота 40МГц (разрешение 800/600 60Гц), вертикальные и горизонтальные синхроимпульсы от AD9984А. Использую эту частоту для записи в SRAM, т.е. открываю буфер, OE, CE, LB и UB подтянуты к земле. Регистрирую нажатие кнопки, определяющей будет ли производится запись в буфер или чтение. Записываю состояние во время смены кадра, когда Vsync = 0. Далее, если кнопка отпущена, в следующем цикле поднимаю OE в 1, закрываю буфер (режим чтения). В каждом такте меняю адрес. Но по факту данные то ли не пишутся или же не читаются из памяти, экран просто черный. Память 100Мгц (IS61WV51216EDBLL), пробовал меньшее разрешение, все то же самое. p.s. Есть некоторое непонимание по поводу валидности данных на выходе AD9984. Судя по таймингу, валидные данные появляются через 6 циклов после регенерированного HSOUT:
В таком случае непонятно, куда делся передний порог в N пикселей:
Однако это не объясняет проблем с памятью. Пересмотрел тайминги по 10 раз, чувствую, будто на поверхности ответ. Буду рад любому совету. Код на verilog: Код module Capture_Logic ( input wire pclk, input wire rst, input wire hsync, input wire vsync, input wire pb_state, // '1' as long as PB is down output wire [18:0] sram_addr, output wire sram2_nWE, output wire sram2_nOE, output wire buffer2_nOE );
//
localparam TOTAL_PXL_IN_A_ROW = 800;
reg pb_saved; reg [9:0] row_pxl_cntr; reg [18:0] address; reg vback_dis; reg pixel_cntr_en;
wire sram2_rw;
//
assign sram2_rw = pb_saved ? 1 : pclk; assign sram2_nWE = pixel_cntr_en ? sram2_rw : 1; assign sram2_nOE = pb_saved ? 0 : 1; assign buffer2_nOE = pb_saved ? 1 : 0; assign sram_addr = address;
// latch pushbutton state during vertical sync period
always @ (negedge pclk or posedge rst) begin
if (rst) begin pb_saved <= 1; end else if (vsync == 0) begin pb_saved <= !pb_state; end
end
// framebuffer address counter
always @ (negedge pclk or posedge rst) begin if (rst) begin address <= 0; end else begin if (vsync == 0) begin address <= 0; end else if (pixel_cntr_en) begin address <= address + 1; end end end
// enable pixel counter
always @ (negedge pclk or posedge rst) begin if (rst) begin pixel_cntr_en <= 0; end else if (hsync == 0) begin pixel_cntr_en <= 0; end else begin if ((row_pxl_cntr > 3'b110) && (row_pxl_cntr < 10'h320)) begin pixel_cntr_en <= 1; end else begin pixel_cntr_en <= 0; end end
end
// input data delay counter
always @ (negedge pclk or posedge rst) begin if (rst) begin row_pxl_cntr <= 0; end else begin if (hsync == 0) begin row_pxl_cntr <= 0; end else begin if (vback_dis == 0) begin row_pxl_cntr <= row_pxl_cntr + 1; end else begin row_pxl_cntr <= 0; end end end
end // vsync bakc porch data disable check
always @ (negedge pclk or posedge rst) begin if (rst) begin vback_dis <= 1; end else begin if (vsync == 0) begin vback_dis <= 1; end else if (hsync == 0) begin vback_dis <= 0; end end end
endmodule
|
|
|
|
|
Aug 12 2015, 09:17
|
Гуру
     
Группа: Свой
Сообщений: 4 256
Регистрация: 17-02-06
Пользователь №: 14 454

|
Цитата Есть некоторое непонимание по поводу валидности данных на выходе AD9984. Судя по таймингу, валидные данные появляются через 6 циклов после регенерированного HSOUT: Цитата В таком случае непонятно, куда делся передний порог в N пикселей: Валидные данные шире видимых, или вопрос про другое?
|
|
|
|
|
Aug 12 2015, 10:39
|
Частый гость
 
Группа: Участник
Сообщений: 79
Регистрация: 11-06-09
Из: Санкт-Петербург
Пользователь №: 50 207

|
Цитата(Golikov A. @ Aug 12 2015, 12:17)  Валидные данные шире видимых, или вопрос про другое? Я думал, что валидные = видимые. Получается, из валидных данных вычитаются n пикслей под задний и передний порог и остаются видимые? Т.е. следует отсчитать N(порог) + delay валидных пикселей и после начинать вывод видимого кадра, верно?
|
|
|
|
|
Aug 13 2015, 07:13
|
Частый гость
 
Группа: Участник
Сообщений: 84
Регистрация: 22-09-06
Из: NN
Пользователь №: 20 592

|
Цитата есть частота 40МГц Цитата Память 100Мгц Как так? Цитата(Golikov A. @ Aug 12 2015, 14:03)  по описанию у этой микрухи какой-то конвейер на выходе, и его надо очистить прежде чем получите что хотите, это как раз 6 слов данных надо пропустить, а дальше начинается ваша строчка, вроде так, строчка полная с началом и концом. не уверен на счет наличия конвеера (было бы не плохо выдержку из описания привести). Это обычный АЦП. H,V out регенирируются на основании H, V in (в самом простом случае). Начало и длительность H,V out задаются регистрами AD9984.
Сообщение отредактировал KPiter - Aug 13 2015, 07:09
|
|
|
|
|
Aug 16 2015, 14:03
|
Частый гость
 
Группа: Участник
Сообщений: 79
Регистрация: 11-06-09
Из: Санкт-Петербург
Пользователь №: 50 207

|
Цитата(KPiter @ Aug 13 2015, 10:13)  Как так? Время доступа памяти 10нс, частота данных 40МГц (25нс) на таком разрешении. А кто-то может авторитетно заявить =) - нужно ли использовать CE или UB/LB для стробирования данных? Ибо на диаграммах либо то, либо другое используется. А у меня CE, UB и LB подтянуты к нулю.
|
|
|
|
|
Aug 17 2015, 09:29
|

Гуру
     
Группа: Свой
Сообщений: 2 076
Регистрация: 10-09-08
Пользователь №: 40 106

|
Цитата(A-10 @ Aug 16 2015, 17:03)  А кто-то может авторитетно заявить =) - нужно ли использовать CE или UB/LB для стробирования данных? Ибо на диаграммах либо то, либо другое используется. А у меня CE, UB и LB подтянуты к нулю. Использую IS61WV102416BLL на 3,3V. Ноги /CE,/OE,/LB,/UB все подключены к GND. Ничего не стробирую, просто выставляю адрес и через 8 нс читаю состояние на ШД. Пишу так как на стр.15 WRITE CYCLE NO. 3(WE Controlled. OE is LOW During Write Cycle) в DS рекомендуют. PS. кстати мс выпуска до 2015 года устойчиво работали даже на 6,25 нс. А теперь только 8 нс.
|
|
|
|
|
Aug 17 2015, 10:19
|
Частый гость
 
Группа: Участник
Сообщений: 79
Регистрация: 11-06-09
Из: Санкт-Петербург
Пользователь №: 50 207

|
Цитата(zombi @ Aug 17 2015, 12:29)  Использую IS61WV102416BLL на 3,3V. Ноги /CE,/OE,/LB,/UB все подключены к GND. Ничего не стробирую, просто выставляю адрес и через 8 нс читаю состояние на ШД. Пишу так как на стр.15 WRITE CYCLE NO. 3(WE Controlled. OE is LOW During Write Cycle) в DS рекомендуют. PS. кстати мс выпуска до 2015 года устойчиво работали даже на 6,25 нс. А теперь только 8 нс. Под стробом я имел ввиду установку WE в 0, а после в 1 в режиме записи. Да, все проверил, именно так и делаю, разве что CE высокое во режиме записи. Но, судя по таймингам, там нет отличий. В моем случае нужно Thzwe+Tsd (11ns) до поднятия WE в 1 (записи). Видимо ошибка где-то еще, потыкаюсь осциллом более тщательно.
|
|
|
|
|
Aug 17 2015, 11:53
|
Частый гость
 
Группа: Участник
Сообщений: 79
Регистрация: 11-06-09
Из: Санкт-Петербург
Пользователь №: 50 207

|
Цитата(zombi @ Aug 17 2015, 13:33)  /CE (Chip Enable) должен быть низким во всех режимах. Да, речь шла об OE )) CE подтянут(ы) к 0.
Цитата(zombi @ Aug 17 2015, 13:33)  Может Вы /OE (Output Enable) поднимаете во время записи, а не /CE?  То есть наоборот, вы хотели сказать )) Но я понял
|
|
|
|
|
Aug 27 2015, 18:11
|
Частый гость
 
Группа: Участник
Сообщений: 79
Регистрация: 11-06-09
Из: Санкт-Петербург
Пользователь №: 50 207

|
В итоге, проблема оказалась из серии "сам дурак" - Vsync регенерированный оказался active High, вместо low, как у Hsync. Вроде в начале самом проверял, оба сигнала были low. Дальше начались некоторые непонятности - напомню, использую режим 800x600 @ 60 / @ 75 Штатная частота при 60 кадрах 40МГц. Параметры такие: hsync передний бордюр - 40 (пкс) задний бордюр - 88 (пкс) vsync передний бордюр - 1 (линия) задний бордюр - 23 (линии) Соот-но у меня активный сигнал (записи и чтения) включался по следующим условиям: (счетчик линий > 23) AND (счетчик линий < 623) AND (счетчик пикселей > 46) AND (счетчик пикселей < 846) +6 - это задержка конвейера. В итоге, правая часть экрана - обрезана, черная. Примерно 50 пикселей. Изображение раз в несколько секунд обновляется с артефактами (что-то проскакивает) и есть вертикальные серые полосы на общем фоне. Пробовал сначала немного смещать активную зону вправо, но это приводило, напротив, к совсем убитой картинке. При смещении влево, наоборот, картинка оставась такой же (что вроде не логично). Методом тыка подобрал такие параметры: (счетчик линий > 23) AND (счетчик линий < 623) AND (счетчик пикселей > 150) AND (счетчик пикселей < 1056) Может кто-то объяснить, почему это работает при таких параметрах? Дрожание исчезло, картинка не обрезана, но все равно не очень качественная:
Видно не очень, но на ней есть желтые полосы и в демке с двигающимся объектом фон неравномерный, как будто размазан кистью. Причем картинка, в режиме вывода (когда кнопка зажата и данные просто вываливаются насквозь) четче и без желтизны:
Я грешу на несколько вариантов: а) частоты WE и PCLK не в фазе, так как первый проходит с задержкой
б) R2R ОУ имеет нелинейность, у меня к тому же на этом канале резисторы натыканы с большим допуском, т.к. выбрал неправильные номиналы изначально и впаял что есть. в) PCLK брошен не на global clock вход CPLD. изначально завел туда только основую частоту (которую использую для I2C и периферии). Не знаю, насколько это влияет. p.s. Снимал осциллогамму вывода данных с VGA напрямую, выводил просто белый квадрат. Строб WE идет не там, но я это исправил. Непонятно, почему во время переднего бордюра выводятся какие-то данные.
|
|
|
|
|
Aug 28 2015, 03:46
|
Участник

Группа: Участник
Сообщений: 63
Регистрация: 14-12-11
Пользователь №: 68 851

|
А что служит сигналом к сбросу счетчика?
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|