Перейти к содержанию
    

alexkarnaukhov

Участник
  • Постов

    16
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о alexkarnaukhov

  • Звание
    Участник
    Участник
  1. Ну вообще Ньютон как раз может и быть интересен. По крайней мере в алгоритме быстрого вычисления обратного корня именно он и используется. Кстати интересно, есть ли готовые корки, реализующие быстрый инверсный корень?
  2. Да, есть такое. Адекватно аппроксимировать 1/х и возле нуля и на хвосте невозможно... Хотя, как в той же статье, можно попытаться разбить область определения на несколько сегментов и в каждом сегменте использовать свои коэффициенты для полинома... Считать полиномы посложнее будет - надо концы сегментов согласовывать, т.е. решать задачу с закрепленными концами, но все-таки мне кажется такой поход интересным...
  3. С нормировкой кадра такое прокатит, а вот когда множитель для каждого пикселя меняется (а такое тоже надо) - уже нет
  4. Частота - 50МГц, 14бит, плис - 7я серия xilinx. На данный момент для деления использую корку DividerGenerator в режиме Radix-2. Хавает более 2000 FF... pipeline нужен обязательно, а вот latency роли не играет, хоть 1000 тактов пойдет. Ваш алгоритм, насколько я понимаю, несколько тактов на деление требует? Я боюсь, что если его конвейеризировать, то слайсов будет прилично занимать... И все-таки в аппроксимации меня привлекает то, что результат-то можно получать гораздо большей разрядности, чем наихудшую точность (ну как в АЦП - есть разрядность, а есть нелинейность и в плохом АЦП может быть 16 эффективных разрядов, но линейными могут быть только 14). Т.е. можно получить монотонную 16-битную функцию на выходе, у которой только первые 11 бит будут всегда точно соответствовать 1/х, что вполне может сгодиться. Делением в столбик такого не получишь...
  5. У меня стоит задача нормировки потока чисел (поток пикселей изображения) на некоторое переменное значение (например разницу максимальной и минимальной яркости изображения). Соответственно без деления не обойтись. Те алгоритмы, которые используются чаще всего, делятся на два типа: либо тупо LUT с забитой таблицей 1/х, либо итеративные алгоритмы, имитирующие деление в столбик, с различной степенью оптимизации. Еще можно складывать делитель, пока результат не превзойдет делимое и посчитать количество таких операций, но это совсем плохой алгоритм. Почему никто не использует тупо полиномиальную аппроксимацию 1/х? Вот здесь всего навсего полином 3-й степени, 100 слайсов на 3-ем Спартане и при этом точность 11 бит. Мне так кажется, что я здесь что-то не понимаю, это же так просто, почему так не делают? Еще и конкретно для моей задачи - даже при точности 11 бит, я мог бы получить приемлемый результат, забив на линейность нормировки. Спасибо.
  6. Да, будет так называемый эффект "tearing". Так что сейчас я просто синхронизирую само чтение из сенсора, благо все-таки удалось от него этого добиться.
  7. zxcv спасибо вам конечно за ответ, ваш вариант я реализовал почти сразу, но нас он не очень-то устраивает - во-первых задержка между считыванием кадра с сенсора и его выводом на bt656 будет медленно плавать от 0 до 40мс, а хотелось бы обеспечить минимальную задержку. во-вторых нам по некоторым соображениям, связанным с дальнейшей обработкой видеосигнала будет не очень удобно работать с потоком, в котором интервал между обновлением картинки меняется от 2 до 3 или от 3 до 4. Ну и в конце концов просто обидно, что из-за незначительного расхождения во фреймрейте приходится что-то городить. Кстати с синхронизацией сенсора по внешнему импульсу тоже не все гладко оказалось, глючит иногда, но это все решаемо...
  8. В общем при выбрасывании/добавлении тактов в bt656 потоке не годится - картинка начинает слегка помаргивать. На разных мониторах немного по-разному, но в любом случае как решение не пойдет. Хотя свою проблему я надеюсь что решил - вроде как все-таки можно запускать сенсор по внешнему синхроимпульсу...
  9. Сенсор по выдает данные пачками по паралельной шине, тактируются они по своему клоку ~10Мгц, т.е не кратному 27Мгц. Да и вообще с сенсора идет кадр гораздо меньшего разрешения, чем pal. Так что клок сенсора мне не поможет. Да и вообще там еще фреймбуфер стоит, так что не важно каким именно образом данные с сенсора читаются. Главное тут что фреймбуфер обновляется с частотой почти точно в три раза меньшей PAL. Т.е. около 120мс.
  10. Спасибо за ответ, но это в моем случае не подходит-у сенсора свой внутренний клок, причем наружу не выводится - наружу идет только одиночный импульс при старте каждого кадра. На другой частоте - все равно придется каким-то образом подстраиваться под эти внешние синхроимпульсы, потому что эта частота точно не известна, известно, что она отличается примерно на 0.0001% от 27МГц в меньшую сторону. Там около десятка тактов за 6 полукадров набегает. Хотелось тупо blanking период в самом конце кадра укорачивать, но вот непонятно будут ли хавать приемники такой поток с укороченной длиной последней строки...
  11. Привет всем! Проблема такая: на плис заводится видеосигнал с частотой кадров в 3 раза меньше стандарта PAL (25/3=8.3 Гц) и кладется в фреймбуфер. Далее из фреймбуфера полукадрами это изображение выводится наружу по протоколу bt656. проблема в том, что клок, по которому работает сенсор не синхронен с клоком bt656, т.е. картинка с сенсора может приходить с чуть меньшей частотой, или слегка большей. Есть ли возможность в bt656 каким-то образом увеличивать или уменьшать blanking - интервал, чтобы вывод видео наружу шел синхронно с поступающими кадрами? Или может можно слегка отклоняться от 27МГц? Ни в стандарте bt656, ни на популярной страничке http://www.spacewire.co.uk/video_standard.html, ни на этом форуме ничего похожего не находил.... Спасибо.
  12. Я конечно дико извиняюсь за реанимацию 2х годичной темы... Но все-таки уж очень хочется поюзать HLS/SysGen. Если у кого есть, можете скинуть мне на почту alexkarnaukhov @ mail . ru Буду очень признателен!
  13. ну да, можно всегда по данным задержку увеличить, это не проблема конечно... Т.е. все эти ифы исполняются как бы одновременно? И если вдруг сработает больше одного, то в регистры SELECTED_MODE и STATE запись будет идти синхронно? И что в итоге окажется в этих регистрах?
  14. 2likeasm: в железе работает... 2serjj: frame_start с клоком синхронен (в модуле симуляции его фронт точно совпадает с фронтом клока), хотя когда сделал по вашему, то заработало в Post-Synthesis Functional! Правда задержка выросла аж на 2 клока... а вот добавление else к первым 3-м ифам ситуации не меняет... 2Torpeda: Да я пока пытаюсь во всем разобраться, чтоб ожидания совпадали с реальностью, так сказать. А то потом глюки повылазят, задолбаюсь отлаживать. А режимы эти значат вроде как простую вещь: Behavioral - симуляция на уровне RTL, Post-Synthesis - симуляция на уровне синтезированного проекта, Post-Implementation - симуляция на уровне реализации с учетом особенностей железа. Ну и timing - значит учет задержек распространения сигнала в логике (а в Post-Implementation еще и с учетом задержек в роутинге) По крайней мере я так понимаю. Но что именно в данной ситуации приводит к разным результатам...
  15. Привет всем, Я новичок в HDL, до этого были только обычные языки типа c/c++... Задача такая: на вход подается 3 сигнала нажатия кнопки, клок, ресет и сигнал старта видеокадра (длительностью несколько клоков с периодом "очень много клоков") По фронту с одной из кнопок необходимо начать считать кадры до 4-х и выдавать номер кадра наружу. В момент прихода 5-го кадра нужно сбросить счетчик. В момент прихода первого кадра с момента нажатия необходимо выдать наружу номер нажатой кнопки и держать его, пока не начнется 5-й кадр. Еще необходимо сформировать дополнительный сигнал старта кадра, который будет выдаваться только пока идет счет кадров. В итоге получился такой код: module switch_ctrl( input ffc, //кнопка 1 input cold, //кнопка 2 input hot, //кнопка 3 input frame_start, //старт кадра output reg [3:0]switch_enable, //какая кнопка была нажата: 0х01(никакая) 0х02 (ffc) 0х04(cold) 0x08 (hot) output reg [3:0]frame_number, //номер кадра output reg frame_start_out, //доп сигнал старта кадра input clk, input resetn ); localparam FRAME_AVG = 3; //количество кадров для счета reg [7:0] frm_cntr; //внутренний счетчик кадров localparam M_NORMAL = 4'b0001, //идентификаторы кнопки M_FFC = 4'b0010, M_COLD = 4'b0100, M_HOT = 4'b1000; reg[3:0] SELECTED_MODE; // регистр индентификатора кнопки reg[4:0] STATE; // регистр состояния localparam S_IDLE = 0, //идентификаторы состояния S_EN_CNTR = 1, S_COUNTING = 2, S_CNTR_DONE = 3; wire frame_start_pulse; one_pulse frame_start_i(.clk(clk), .resetn(resetn), .thing(frame_start), .pulsy(frame_start_pulse)); always @(posedge clk or negedge resetn) begin if( resetn == 1'b0) //resetting begin SELECTED_MODE <= M_NORMAL; STATE <= S_IDLE; frm_cntr <= FRAME_AVG; switch_enable <= M_NORMAL; frame_start_STATE <= 0; frame_number <= 0; frame_start_out <= 0; end else begin case(STATE) S_IDLE: //ожидание нажатия кнопки begin if(ffc) begin SELECTED_MODE <= M_FFC; STATE <= S_EN_CNTR; end if(cold) begin SELECTED_MODE <= M_COLD; STATE <= S_EN_CNTR; end if(hot) begin SELECTED_MODE <= M_HOT; STATE <= S_EN_CNTR; end end S_EN_CNTR: //кнопка была нажата, ожидаем фронта сигнала старта кадра begin if(frame_start_pulse) begin STATE <= S_COUNTING; switch_enable <= SELECTED_MODE; frame_start_out <=1; end end S_COUNTING: //считаем кадры begin if(frame_start_pulse) begin if(frm_cntr) begin frm_cntr <= frm_cntr - 1; frame_number <= frame_number + 1; frame_start_out <= 1; end else begin //если счетчик кадров дошел до нуля, то возвращаемся в ожидание STATE <= S_IDLE; frm_cntr <= FRAME_AVG; switch_enable <= M_NORMAL; SELECTED_MODE <= M_NORMAL; frame_number <= 0; end end else begin frame_start_out <= 0; end end endcase end end endmodule module one_pulse(input clk, input resetn, input thing, output pulsy); //детектор фронта сигнала старта кадра reg thing_dly; assign pulsy = thing & ~thing_dly; always @(posedge clk or negedge resetn) begin if(!resetn) thing_dly <= 1'b0; else thing_dly <= thing; end endmodule Я работаю в Vivado и тут есть 5 типов симуляции: Behavioral, Post-Synthesis Functional, Post-Synthesis Timing, Post-Implementation Functional и Post-Implementation Timing. В бехэворе все норм: А вот в Post-Synthesis Functional вообще все глухо: В Post-Synthesis Timing снова все хорошо (если не считать на один клок увеличившейся задержки, но это не критично) И в Post-Implementation Timing тоже неплохо, если не считать скачков (glitches?) на выходах... В Post-Implementation Functional снова все глухо на выходах... Что не так с моим кодом и как его переделать так, чтобы в любой симуляции он работал правильно? И что это за выбросы на выходах в Implementation? это артефакт симуляции, или надо ставить дополнительные регистры на выходы? (хотя вроде они там и так стоят...) Спасибо.
×
×
  • Создать...