Jump to content

    

des00

Модераторы
  • Content Count

    8657
  • Joined

Community Reputation

0 Обычный

4 Followers

About des00

  • Rank
    Вечный ламер
  • Birthday 01/14/1980

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

35314 profile views
  1. да просто в вивадо карты новых устройств храняться, в натурном формате, типа большого case, вот отсюда и размеры)))))
  2. я не про хуки, я про возможность изменить значение параметра в RTL коде средствами вивадо. в квартусе это делается через set_parameter
  3. в квартусе можно назначить парметр в топе снаружи. Потом скриптом его назначить добавить в *.qsf set_global_assignment -name PRE_FLOW_SCRIPT_FILE "quartus_sh:get_time.tcl" get_time.tcl project_open -revision <project_name> <project_name> set t [clock seconds] set_parameter -name pCOMPILATION_TIME $t export_assignments ну и в коде просто используете pCOMPILATION_TIME в вивадо по идее должно быть что-то аналогичное
  4. там в опциях есть какая то быстрая сборка, ее пробовали ?
  5. Ндя, в песочнице кубики перекладывать неа, я как на хилых сел, так и потерялся) микрочип начал печь или это чьето наследие?
  6. В свое время, нужно мне было забить артикс 200ку (кто знает, он внутри устроен как буква Н) на 98% по логике, 100% дсп и 50% памяти, на частотах 100/200МГц. Сколько не крутил эти регионы, ничего не помогало. Результат был от немогу развести, до задержек раза в 3-4 больше чем сборка в лоб)
  7. Ну я про это и говорил сразу +-1 слово выходного интерейса, девиация задержки. Вот и наблюдает ТС эту девиацию, затем умножает на ширину слова и получает те самые свои "коллосальные" задержки. но вот дальше продолжаем вашу же мысль, эта неопределенность даст вам комбинации сдвига фазы восстановленных клоков низкой частоты -1/0, 0/0, 0/-1. Что при оценке, относительно одной опорной частоты может дать вам +-1 слово интерфейса. Все зависит от фазировки этой опорной частоты относительно восстановленных клоков. Один попал до фронта, второй после фронта. Об этом я сразу и написал. А если вы один из восстановленных клоков используете в качестве измерительного, то там тем более будет девиация +-1 символ который у вас N бит. Но итоговая то будет недетерменированная. Понятно, у нас с вами разные подходы к термину "детерминированная задержка", точнее разные системы интерпретации этой задержки.
  8. вот тут у меня диссонанс. Вы же сами пишете про разную фазу восстановленной низкой частоты, но при этом пишете про детерминированную задержку. Я же верно прочитал: у вас фаза восстановленной частоты плавает от 0 до 360 градусов, но при этом задержка фиксированна? Тогда относительно чего и в чем вы ее измеряете? Измерение проводится в тактах восстановленной частоты? Мысленный экспиремент: если взять не плавающую опорную, синхронную по частоте относительно восстановленной. Затактировать ей логику плис, что принимает данные с GTX. Вывести эту опорную частоту синхронно с восстановленной, при сдвиге ее фазы в 0, тогда при сдвиге фазы в 360 градусов, данные, относительно опорной частоты лягут на +1 такт, т.е. появится задержка, зависящая от фазы восстановленного RX клока на низкой частоте и временных параметров триггеров при перекладке из сдвигового регистра GTX в регистр логики.
  9. ЕМНП там пропускается одна фаза счета: не добавляется следующий бит в сдвиговый регистр и нет инкрементирования счетчика выходного слова. Может мы про разные GTX/GTH говорим или я готовить не умею, но на 7-Series у меня разбегались потоки. даже те которые шли с одной плисы, с двух GTX на два GTX другой плисы. В итоге я поставил небольшое FIFO + метки времени и все выравнивалось автоматически. ЗЫ. Еще вспомнил проект на Ария 5. Делал заворот на двух плисах, хотел задержку оптического кабеля измерить, в символах. В GTX все по минимуму, все синхронно, ничего лишнего на завороте. В итоге +-1 символ относительно среднего, от включения к включению. Даже если просто оптику перетыкать, не выключая плис.
  10. да, но вы же работаете снаружи корки не с битовым потоком, а со словным. И интерфейс у вас на широком слове. И вот эта разбержка на бит может перейти в разбежку на символ. Т.к. сам символ у вас соберется позже/раньше. Попробую на пальцах. Есть битовый поток, положим слово у нас 6 бит. Слово мы кладем с нулевого бита на стороне передатчика. Отравили Т Е В И Р П. В каналы пришло х х Т Е В И Р П х х х - положим удачно попали что буква Т - пришлась на нулевой бит сдвигового регистра, х х х Т Е В И Р П х х х х - а вот здесь вам нужно додвинуть поток бит влево на 1 битовый интервал. ЕМНП штатно для этого нужно будет сделать 5 сдвигов вправо. И в итоге слово соберет свои 6 бит на один выходной символ позже. Ну оке, решили выровнять регистром на широком слове, поставили, но при другом включении порядок прихода бит может поменяться). ЕМНП это влияние CDR + эквалайзера. И в итоге снова мимо. Если бы работали на уровне битов, проблем было бы меньше, но не тянет плиса.
  11. да легко. он выравнивается в разные стороны. один в минус символ, второй в плюс символ. ЕМНП там выравнивание идет за счет отбрасывания бита bitslib. два потока могут встать как -1/0 так и 0/-1 (где 0 это точная фаза бита потока), это следствие работы CDR, если выравнивать их дропами, то они как раз и разбегаются на символ. ЕМНП там же две CDRки сделанные по приницпу DLL, поэтому, не смотря на то что частота будет одинаковая фаза семплирования может будет разная.
  12. если уникальный 146% и будет уникальный до окончания чтения памяти, то, как написал @RobFPGA AND-OR мультиплексор, Если не уникальный то либо простой приоритетный арбитраж, как предложил @Flip-fl0p или RRA арбитр. Вот псевдокод ядра RRA typedef logic [pN-1 : 0] request_t; typedef logic [pN_LOG2-1 : 0] winner_t; logic request ; winner_t last_winner ; winner_t winner ; assign request = (ireq != 0); assign winner = get_winner(ireq, last_winner); always_ff @(posedge iclk) begin if (request) begin last_winner <= winner; grant <= '0; grant[winner] <= request; end end function automatic winner_t get_winner (input request_t request, input winner_t last_winner); get_winner = last_winner; // for (int i = 0; i < pN; i++) begin get_winner = get_winner + 1'b1; if (get_winner == pN) begin get_winner = 0; end if (request [get_winner]) begin return get_winner; end end endfunction ну а дальше уже, зная того кто победил, интегрируете это в ваш FSM по чтению
  13. и все равно ИМХО разбежитесь на выраванивании в десериализаторе. там +-1 бит, потом будет словный выравниватель и пошло поехало. Причем недетерминированно. Когда мне нужно было синхронизировать 12 каналов, я ставил метку времени и внешней логикой привязывал каналы к восстановленной метке.
  14. синус не совсем хорошо для тестирования фильтров. Если можно записать ваш сигнал, то захватить его в файл и потом, в офлайне, попробовать разные фильтр в любом ПО, которым владете. В том же питоне например, с либами а-ля матлаб. Данный скил в любом случае пригодиться)