serg_k1

Получается следующее. После программирования линки пропадают. Убрал программирование т.е. остались дефолтные настройки плюс там задается AUTO-NEGOTIATION ENABLE через Strap. Все заработало. и линк и связь. правда проверил только на выдачу в компьютер. Все-таки получается , что дело в программировании.

Добрый день. Есть самодельная плата с Artix 7 и DP83867E. По MII задаю и читаю следующие регистры 1. CTRL(h001F) <--- h8000, читаю 0. сброс с регистрами 2. BMCR(h0) <-- h0140 , опрашиваю =h0140. задал 1000BASE 3. PHYCR (h0010) <--- hf068 . dis SGMII опрос= hf068 4. CFG1 (h0009) <--- h1b00 (или h0300), опрос= h1b00 . показать способность. 5. CFG3 (h001E) <--- hcb02 , опрос= hcb02 . 6. BISCR(h0016) <--- h0. но здесь задавал digital loopback - все работает т.е. данные возвращаются. 7. RGMIICTL(h0032) <--- h00d3 , опрос= h00d3 , RGMII ENABLE. 8. RGMIIDCTL 9. CTRL (h001f) <--- h4000 soft restart. далее я читаю BMSR(h0001), PHYSTS(H0011), STS2(h0017) - все нормально. но читаю STS1 (h000A) и получаю h4000. h0 получал при других значениях. еще попробовал analog loopback - все работает т.е. данные возвращаются. и связаться с компьютером не могу. что не так?

это все известно. в каких файлах и что нужно изменить(убрать). но... когда я изменяю руками - это не воспринимается. потому-что синтез уже произведен. и допуска к генерации выходных параметров нет. выдается Generate of output products did not run again as all output products were previously generated and up-to-date. если же запустить customize ip - то все восстанавливается(с не устраивающими параметрами). это к тому, что один раз задать. поэтому я думал путь такой- меняются параметры в xci файле,потом генерация ip. все это tcl командами. к сожалению , это не проходит. сейчас проверил на ip , где можно менять параметры. так что нужен еще какой-то путь. это помогло, просто я в прошлый раз лопухнулся сам. запустил не тот проект. и это ,кстати, убирает частоту из параметров IP. но, все-таки, как менять параметры не ясно. спасибо всем!

ну конечно она задана: - на входе частота(описана - это клок на входе . просто я про это не писал.) и далее из нее получается частота fifo. и она не совпадает с частотой , описанной в ip. все именно так. вопрос как изменить? потому-что не получается изменить это tcl командой. именно для этого параметра. а то , что вы предлагаете - изначально сделано.

Не очень понятно зачем это делать. Ведь и так vivado определил , что частота заведена и не та. нужно дать команду на пересинтез ip с новыми параметрами. но я попробовал. задал create_generated_clock -name fifo_gen_64_160/rd_clk -source [get_pins clk_125_tx/clk_out2] -divide_by 1 [get_pins fifo_gen_64_160/U0/rd_clk] об этом речь? но это ничего не изменило. предупреждение осталось. ну а на счет "забить" , то так и происходит. но количество ip большое. и предупрежэдений много. и по частоте и по "resolve non-primitive black box". и они мешаются под ногами.

это я пробовал. если это " generate output productы" - не влияет.

здравствуйте, в vivado создал fifo_generator_0. мне нужно работать под 125МГц. я и завел туда 125МГц. При синтезе получаю предупреждение [Timing 38-316] Clock period '10.000' specified during out-of-context synthesis of instance 'fifo_generator_0' at clock pin 'rd_clk' is different from the actual clock period '8.000', this can lead to different synthesis results. не могу изменить параметры IP. раньше я изменял в файле констрейна IP create_clock -period 10 -name wr_clk [get_ports wr_clk] 10 на 8 и при повторном открытии у меня ip пересобирался. и все было нормально. но сейчас vivado 2016.4 так не работает. может я на счет "раньше" что-то путаю. подзабыл. но сейчас хотел сделать как в UG896. tcl команда set_property CONFIG.CORE_CLK.FREQ_HZ 125000000 [get_ips fifo_generator_0] меняет содержимое fifo_generator_0.xci(MASTER и SLAVE - меняется) , а вот на следующие строки( READ_CLK.FREQ_HZ и WRITE_CLK.FREQ_HZ) в этом файле команды set_property CONFIG.READ_CLK.FREQ_HZ 125000000 [get_ips fifo_generator_0] set_property CONFIG.WRITE_CLK.FREQ_HZ 125000000 [get_ips fifo_generator_0] не действуют. т.е. там остается 100000000. при этом ошибки не выдает. ... <spirit:configurableElementValue spirit:referenceId="BUSIFPARAM_VALUE.CORE_CLK.FREQ_HZ">125000000</spirit:configurableElementValue> <spirit:configurableElementValue spirit:referenceId="BUSIFPARAM_VALUE.MASTER_ACLK.FREQ_HZ">100000000</spirit:configurableElementValue> <spirit:configurableElementValue spirit:referenceId="BUSIFPARAM_VALUE.READ_CLK.FREQ_HZ">100000000</spirit:configurableElementValue> <spirit:configurableElementValue spirit:referenceId="BUSIFPARAM_VALUE.SLAVE_ACLK.FREQ_HZ">100000000</spirit:configurableElementValue> <spirit:configurableElementValue spirit:referenceId="BUSIFPARAM_VALUE.WRITE_CLK.FREQ_HZ">100000000</spirit:configurableElementValue> ... может по другому как-то? как можно изменить параметры? 2. еще один вопрос . меня напрягает такие предупреждения [Project 1-486] Could not resolve non-primitive black box cell 'clk_wiz_0' instantiated as 'clk_wiz_125' ["P:/vivado_2016_4/project_5/project_5.srcs/sources_1/new/top.v":39] [Project 1-486] Could not resolve non-primitive black box cell 'fifo_generator_0' instantiated as 'fifo_generator_0' ["P:/vivado_2016_4/project_5/project_5.srcs/sources_1/new/top.v":51] и это есть для нескольких IP. причем пересборка не убирает такое предупреждение. как от этого избавиться?

я так понял, что не получится выполнить тайминги с моими условиями. я на свой вопрос получил на форуме xilinx такой ответ Изменить временные требования я не могу. поэтому приходится что-то делать с граничными значениями. xilinx проводит проверку в slow process corner (высокая температура, низкое напряжение) и fast process corner (низкая температуры, высокое напряжение). Насколько схема будет работоспособна без этих граничных условий. как это можно проверить? Если я задаю config_timing_corners -corner fast -delay_type none то у меня остаются ошибки в slow. и после задания config_timing_corners -corner slow -delay_type none ошибки исчезают. но проводится ли какая-то проверка в этом случае?

нет , там только HR банки. В них только входная задержка.

Распиновка фиксированная. В проекте частота приходит в одном банке и есть 2 выходных канала А и В по (16+1 + clk) LVDS пары. И они выходят в 2-х других банках. Изначально констрейны прописаны были для всего. Это ,наверное, то же , что и подвинуть ближе друг к другу. И везде были одинаковые проблемы такие же. Но даже для каналов А и В цифры в одной разводке отличалиь не более чем на 0.1нс. Это сейчас я рассматриваю 2 сигнала. это я тоже пробовал. Происходит просто смещение величин на 0.3-0.5нс. также как и тогда когда я двигал выходную частоту. следующая таблица это показывает. фаза -это смещение с шагом ~0.208нс . и 1-я без ODDR на выходе и 2-я c ODDR на выходе. я не понял идею. хотя прочитал статью и там все вроде бы понял. Но в любом случае буферы на данные на выходе поставить нельзя. Мало того, что это заимствованный IP xilinx - selectio_wizard и туда трудно чего-то вставить. Вообще-то можно сделать самому подобное. Но там sourse clock записывает данные в OSERDESE2 примитив и далее выход приходит на obufds(в картинке ошибся) и далее выходной порт. картинка

но когда я ставлю 1 bufg ( 1-й ---> 2-й) , то setup - запас уменьшается 0.867 ->0.656 , а hold запас тоже уменьшается -0.455 -> -0.709 чип xc7a200tfbg676-2, пока ставлю Artix-7 AC701 Evaluation Platform (xc7a200tfbg676-2) DS181 ,стр.14

Спасибо,вроде бы все понятно, кроме того, что оставил. Но ведь нужно попробовать справиться с отрицательным hold. И я решил подвигать частоту, идущую на данные. Частоту Destination Clock я уже двигал- ничего не получилось. Проверил 3 проекта - 1. С одной и той же частотой т.е. исходный 2. проходящей через bufg b 3. проходящей через 2 bufg. Получилось следующее. Начальный одинаковый путь частоты считается по разному. для 1-го одно, для 2-го другое. При этом один путь не удалось получить какие бы изменения я не делал. Значит это не совсем случайно. 1-й и 2-й вроде бы как должно приблизить значения. Для setup есть запас и вроде бы он немного съелся. а для hold минус тоже должен уменьшиться, но он вырос. И только в 3-м проекте уменьшился. Но там уже setup не выполняется. Вот таблица. еще меня смущает разное время у Destination Clock в компонентах ODDR (0.418 0.204 ), OBUFDS (1.484 0.842). Да и у других это просматривается. OBUFDS ( 1.366 0.726).

тут мне непонятно следующее. параметр clock pessimism на самом деле уравнивает время в точке раздвоения. мне непонятны знаки времени до этой точки. при этом если Destination Clock Patch считается по макс. времени , а Source Clock Path по миним. времени , то в этой точке цифры должны быть наоборот т.е. Destination Clock Patch больше и тогда clock pessimism должен бы вычитаться. но счет идет не так. но в любом случае с учетом clock pessimism время уравнено. и это подтверждается тем, что иногда все считается правильно по времени. но все равно со знакамиотрицательными Destination Clock Patch и Source Clock Path до точки раздвоения мне непонятно. здесь тот же проект, но без bufh. и все идеологически правильно с моей точки зрения. только отрицательные времена в начале. но к сожалению hold отрицательный. эти разные подсчеты (подходы, результаты) мне непонятны.

да, такой пораметр clock pessimism считается. и он как раз равен той величине , которая набегает при достижении точки раздвоения . но вот он почему-то усугубляет ситуацию. т.е. эта величина добавляется к Destination Clock Patch и увеличивает Required Time. и соответственно уменьшает hold. общая часть - это одна и та же клоковая дорожка сейчас, как я выяснил ранее, почти все считается правильно. но вот параметр clock pessimism усугубляет ситуацию, а должен улучшать. т.е. приближать две рассчетные величины друг к другу

я с этим и не спорю. но есть вопросы. с setup вопросов нет. там действительно 2 разных фронта ( и об этом говорит добавка 1.250нс при расчете времени пути). и это определяет то, что мы считаем макс. время для данных и мин. время для частоты на протяжении всего пути. с hold же все не так. там один и тот же фронт ( то , что это один фронт - отсутствует добавка 1.250нс в расчетах и показано на нижнем рисунке) формируется на 1-3 частях пути, далее он разделяется и идет на данные по одному пути , а на вых.частоту по другому. так вот, мне кажется , что часть пути 1-3 не внесет изменений в подсчет времени hold при "температурном диапазоне и просадках по питанию" именно потому, что это физически один и тот же фронт. т.е. если что-то не так , то это "не так" одинаково скажется на данных и частоте. А дальше остальной путь, конечно, нужно считать по разному.