33 мегапикселя на ладони

[Дмитрий Бучинский]

fx2Write_out  должен быть с частотой, в два раза выше чем ADCCLK

ну тут бабушка надвое сказала.
модуль comm_fpga_fx2 Cypress(... специально же для нашей камеры не затачивался. Очевидно автор не расчитывал на то, что там должна быть удвоенная частота. это уже какбэ наша задача - что подадим, то и обработает. если надо, я попробую удвоить ADCCLK  и посмотрим , что получится

Вижу, моя мысль не понята...
Четыре графика, демонстрирующие различные варианты синхронизации источника и приемника сигналов с разными вариантами Data rate, с учетом задержек на распространение сигналов и переключение вентилей. Особо обратите внимание на выделенную мной часть цитаты.

[Дмитрий Бучинский]

Продолжение, наш случай, КМК.

[Дмитрий Бучинский]

Автор проекта связки навряд-ли реализовал DDR. У Вас источник сигналов DDR, поэтому с меандром ADCCLK не работает вообще. А с не-меандром - из за нештатной работы АЦП трансмиттер успевает схватить с шины нечто похожее на полезные данные - но на грани фола.

[Дмитрий Бучинский]

Мне нужно время разобраться с verilog и с проектом трансмиттера, без понимания которых я в дальнейшем буду бесполезен.
Вам пока могу посоветовать: определитесь наверняка - работает ли трансмиттер в DDR или SDR режиме, какой сигнал является входом синхронизации приема данных трансмиттера, и (если не DDR) по положительному или отрицательному фронту трансмиттер захватывает данные.
После этого, приведите циклограмму секвенсора в соответствие с подходящим графиком, из того, что я нарисовал. Не забудьте вернуть меандр ADCCLK.
Если что-то непонятно в моих графиках, или по ходу дела появятся вопросы - пишите сюда или в личку, буду помогать в меру своих сил и знаний.

[andreichk]

какой сигнал является входом синхронизации приема данных трансмиттера, и (если не DDR) по положительному или отрицательному фронту трансмиттер захватывает данные.

вот я красным выделил.

comm_fpga_fx2 Cypress(
   // FX2 interface
   .fx2Clk_in(c48),
   .fx2FifoSel_out(fx2Addr_out[0]),
   .fx2Data_io(fx2Data_io),
   .fx2Read_out(fx2Read),
   .fx2GotData_in(fx2GotData_in),
   .fx2Write_out(fx2Write_out),
   .fx2GotRoom_in(fx2GotRoom_in),
   .fx2PktEnd_out(fx2PktEnd_out),

   // Channel read/write interface
   .chanAddr_out(chanAddr),
   
   .h2fData_out(h2fData[7:0]), //HOST ==> FPGA принятые из консоли данные
   .h2fValid_out(h2fValid),    //
   .h2fReady_in(h2fReady),     //готовность. всегда 1
   
   .f2hData_in(comp_out[7:0] ),//HOST <== FPGA посылка данных в консоль
   .f2hValid_in(comp_valid),   //<==  если есть валидные данные
   .f2hReady_out(f2hReady)     //==>  «1» означает передачу след. байта данных на f2hData_in» по фронту импульса
);
захват по положит. фронту.
вот внутри модуля есть строка    if ( fx2GotRoom_in == 1'b1 && f2hValid_in == 1'b1 )
, которая как раз подтверждает это

[Дмитрий Бучинский]

сделал, подал куда надо и нифига хорошего чунга-чанга !!! получилось!!! только я  REGWR сделал не меандром, а узким импульсом, но с той же частотой что и менандр ацп клока. Но зато и на максимальной тактовой АЦП 8 МГц, нет никаких полос !!! Вечером выложу картинки с симулятора и фотки.

Чтение мануала внесло некоторую ясность. Как гласит фраза со стр.26 pdf документа:

If and only if both the xxxValid and xxxReady signals are asserted when a clock rising
edge arrives, the data is registered by the receiver and the next data byte is made
available by the sender.

"Только если сигналы Valid и Ready активны в момент положительного фронта клока, данные регистрируются приемником, и следующие даные...".
С первыми двумя сигналами все ясно - Ваш код в ПЛИС должен проверить активный уровень сигнала f2hReady, выставить 8бит данные, подтвердить готовность данных высоким уровнем сигнала f2hValid. Причем "валид" должен быть такой длительности (Вы как раз писали, что нужен узкий импульс!), чтобы за время его активного состояния был один положительный фронт сигнала "клок", но не более, чтобы один и тот-же байт не был захвачен в фифо несколько раз.
Что за клок имеется в виду, я пока точно не могу сказать, но с высокой вероятностью имеется в виду клок comm_fpga fx2Clk_in.
Как мне кажется, Вам надо сформировать f2hValid, удовлетворяющий вышеописанным требованиям, и расположенный примерно посередине между фронтами ADCCLK.

[Дмитрий Бучинский]

Хочу добавить - по неактивному уровню на линии f2hReady, работа секвенсора должна блокироваться (КМК, блокировкой опроса сигнала comm_fpga fx2Clk_in), а сигнал f2hValid удерживаться секвенсором в неактивном состоянии.
f2hValid должен располагаться между между фронтами ADCCLK - всего два импульса за один период ADCCLK.

[Дмитрий Бучинский]

Исправил ошибку в предыдущих двух постах.

[andreichk]

с48  - это основной клок == 48 МГц. от него функционирует весь ФПГА. он вводится в каждый модуль всего кода и от него  считываются все остальные переменные , регистры и пр. Напр. в модуле comm_fpga_fx2 Cypress(  , он вводится во вход  отfx2Clk_in

[Дмитрий Бучинский]

Я в мануале не нашел ничего более подходящего, нежели fx2Clk_in. Аргументы "за":
1. Учитывая, что схема сопряжения FPGA и FX2LP синхронная, вполне логично, что это оно.
2.

Since the FX2 Slave FIFO interface clocks data synchronously at the end of every 48MHz clock cycle, the theoretical maximum throughput is 48MB/s.

Макс. скорость передачи данных через кипарис точно совпадает с частотой fx2Clk_in, при условии передачи данных в режиме SDR.

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

[Дмитрий Бучинский]

Думаю, Вам имеет смысл написать бенчмарк*, иммитирующий сигналы, поступающие в ПЛИС из FX2/АЦП и прогнать проект на симуляторе. Иначе процесс отладки превращается в стрельбу в небо наугад - "авось куда-то попаду".

*Или как правильно называется хрень - когда вручную, в файле, описываются внешние сигналы на входах, воздействующие на модель проекта - типа "в момент А подать на вход "In" ПЛИС сигнал лог1, а на входящую шину данных D выставить значение 0хAB". Затем в симуляторе анализируется реакция проекта на эти внешние сигналы и состояние выходящих сигналов.
Я когда-то делал PCI Postcard - без бенчмарка ее можно было проверить только в плане - зависнет с ней компьютер или не зависнет... В бенчмарке были описаны стандартные циклограммы обмена по шине PCI из описания стандарта, а затем, в симуляторе изучалась реакция проекта на разные варианты воздействий и отлавливались баги. Помогло чрезвычайно.

[Дмитрий Бучинский]

Думаю, дело пойдёт быстрее, если вы установите у себя  программу ИЗЕ14.7.  я постараюсь щас выложить для вас весь пакет с инитключём, а вы скачайте и установите у себя. затем скачаете наш проект и вместе будем его модерировать.

Это не оптимально, поскольку мне помимо изучения Verilog'а и раскуривания проекта, придется изучать еще и совершенно незнакомый прикладной софт... Пока я с этим закончу, Вы уже выпустите "FW V2.0" исправленную и улучшенную.
Будет лучше, если я воспользуюсь хорошо известным мне Altera Quartus, в котором я делал все свои проекты; Verilog'овский код я там смогу скомпиллировать, выхлоп симулятора легко экспортируется в виде картинки. Понятно, что вместо Xilinx мне придется "использовать" чип от Alterа, но кроме тонких нюансов с таймингами, это ни на что не повлияет.

[Дмитрий Бучинский]

У вас тут классический случай неправильной, проблемной синхронизации, причем в двойном размере.
Я вырезал из симуляции нужный кусок, увеличил его и выделил проблемные места.
Красными прямоугольниками обозначены моменты, когда на шине данных проходит переходной процесс, связанный со сменой данных источником - ADC.
Из за того, что передний фронт REGWR совпадает по времени с передним (активным) фронтом клока, да еще и с фронтом ADCCLK, возникает неоднозначность - гонка фронтов. Тут возможно множество вариантов поведения схемы, причем все они зависят от температуры, наводок, джиттера и тонкостей компилляции проекта (Вы исправили вообще другой кусок проекта, плейсер переставил элементы в ПЛИС, поменял пути сигналов - и схема перестала работать!)
Подробно расписывать все возможные сорта багов мне не хочется, поэтому я просто приведу картинку "как надо". Импульс WR можно двигать вправо-влево в пределах высокого/низкого уровня ADCCLK, но не "приставлять" его близко к переднему и заднему фронту ADCCLK.
Передний и задний фронты импульса WR должны быть строго по заднему фронту клока, длительность WR - один период клока.
Не забудьте - после правки проекта возможно понадобится поменять местами старший и младший байт получаемых в компьютер(!) данных с АЦП - старший байт пикселя первый, младший второй.

P/S Выложите сюда кусок кода, где формируется REGWR.

[andreichk]

кстати , я привязал проверку f2hReady

//данные и такт с видео АЦП adc2clk
wire expos_clk = (frame && REGWR && f2hReady) || (header && header_clock && f2hReady);
//wire expos_clk = (frame && adc_clock) || (header && header_clock);
wire [7:0]expos_data = (frame && f2hReady) ? adc_data_[7:0] : (header && f2hReady ) ? header_data_[7:0] : 8'd0;//

// коммутатор данных и такта, подаваемых в FPGALINK
//reg1[3] byte=0x08;//управление экспозицией . если бит3==1, то считываем данные



wire    comp_valid = (reg1[3] && f2hReady) ? expos_clk : 1'b0;//
wire [7:0]comp_out = (reg1[3] && f2hReady) ? expos_data[7:0] : 8'b00000000;//

полосы исчезли

[Mixa]

Верилог не самое лучшее средство для разборок, как оно на самом деле работает. Лучше иметь временнЫе диаграммы, в том виде, как они задуманы по проекту, и словесное описание процессов.
Из временных диаграмм по-прежнему загадка, как переносится младший байт АЦП. Строб REGWR сопровождает старший байт, а как младший пишется? Как оно вообще было задумано? Вопрос скорее риторический, потому что таких мелочей куча, и копаться в них не очень продуктивно. Пытаемся разобраться с тем, что получилось, не имея ясного представления о том, как должно быть. Длинный и сложный путь, к тому же оставляющий после себя скрытые косяки: если вдруг что-то заработало, ставим точку и говорим, что так и надо, хотя может быть и не так надо (что скорее и всего).

[andreichk]

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

always @ (negedge clock) // по спаду тактового импульса
begin
     case (buffer) 11,5:  //удвоенная частота  //==> такт записи данных в FX2
                    REGWR <= SSC_ADC;           
           default: REGWR <= 1'b0;   
     endcase           
end

и картинка правильная и байты не сдваиваются и каждый импульс REGWR == одному такту клока и возникает по спаду клока...

[Mixa]

При условии, что REGWR это именно строб байтов (не вникал), то да, именно так и должно быть (по одному стробу на полупериод ADCCLK). Повторюсь, при условии. И если так, то можно сдвинуть чуть правее, ближе к фронтам ADCCLK, где данные гарантированно устоявшиеся. И еще раз повторюсь, в предположении, потому что полной картины не вижу, не вникал.

[andreichk]

При условии, что REGWR это именно строб байтов (не вникал), то да, именно так и должно быть (по одному стробу на полупериод ADCCLK). Повторюсь, при условии. И если так, то можно сдвинуть чуть правее, ближе к фронтам ADCCLK, где данные гарантированно устоявшиеся. И еще раз повторюсь, в предположении, потому что полной картины не вижу, не вникал.

да,это имено он. щас сдвинул на 2 такта вправо, посмотрим , что получится

always @ (negedge clock) // по спаду тактового импульса
begin
     case (buffer) 1,7: //удвоенная частота  //==> такт записи данных в FX2
                    REGWR <= SSC_ADC;           
           default: REGWR <= 1'b0;   
     endcase           
end

сплошной шум. попробую так

always @ (negedge clock) // по спаду тактового импульса
begin
     case (buffer) 0,6: //удвоенная частота  //==> такт записи данных в FX2
                    REGWR <= SSC_ADC;           
           default: REGWR <= 1'b0;   
     endcase           
end
тоже шум, но сквозь него пробивается самый яркий фрагмент картинки.

похоже что  вариант  case (buffer) 11,5:  //удвоенная частота  //==> такт записи данных в FX2
является оптимальным

[Дмитрий Бучинский]

Мне картинки с симулятора xilinx не нравятся, чесговоря.
На альтеровском симуляторе, в репорте видно намного подробнее, фронты сигналов показаны с учетом реального времени распространения сигналов в ПЛИС, видны все неопределенности, шумы переключения шин, даже "иголки" проскакивающие в логике при гонке фронтов. Тут как то гладко все очень, как после blur'а - а так не бывает. Или сама утилита симуляции упрощенная, или в настройках симуляции что-то не включено...
Ниже фрагмент скриншота с альтеровского симулятора. Несмотря на то, что все сигналы синхронизированы с GCLK, видно что фронты несколько поразъезжались из за различной длины путей сигнала в ПЛИС, и разного числа вентилей в каждом пути. Так-же этот симулятор нормально обсчитывает состояние шин, все переходные процессы обсчитаны по времени и видны на диаграмме.

[andreichk]

вобщем я все эти косяки исправил. обновление лежит на гугло-диске. ссылка в начале темы