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

    

serg_k1

Участник
  • Публикаций

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

  • Посещение

Репутация

0 Обычный

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

  • Звание
    Частый гость
  1. Цитата(Alex11 @ Nov 27 2017, 15:17) Я конкретно с этой физикой не работал, но судя по регистрам, она не договаривается с компом. Посмотрите осциллографом, что на линиях творится. Там еще link-импульсы или уже нормальный сигнал? Дальше варианты - кварц с большим отклонением по частоте или питание плохое. Еще может быть проблема в перепутанных проводах. Получается следующее. После программирования линки пропадают. Убрал программирование т.е. остались дефолтные настройки плюс там задается AUTO-NEGOTIATION ENABLE через Strap. Все заработало. и линк и связь. правда проверил только на выдачу в компьютер. Все-таки получается , что дело в программировании.
  2. Добрый день. Есть самодельная плата с 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 - все работает т.е. данные возвращаются. и связаться с компьютером не могу. что не так? Цитата8.6.11 Status Register 1 (STS1) Table 20. Status Register 1 (STS1) Address 0x000A BIT BIT NAME DEFAULT DESCRIPTION 15 MASTER / SLAVE CONFIGURATION FAULT 0, RO, LH, COR Master / Slave Manual Configuration Fault Detected: 1 = Manual Master/Slave Configuration fault detected. 0 = No Manual Master/Slave Configuration fault detected. 14 MASTER / SLAVE CONFIGURATION RESOLUTION 0, RO Master / Slave Configuration Results: 1 = Configuration resolved to MASTER. 0 = Configuration resolved to SLAVE. 13 LOCAL RECEIVER STATUS 0, RO Local Receiver Status: 1 = Local receiver is OK. 0 = Local receiver is not OK. 12 REMOTE RECEIVER STATUS 0, RO Remote Receiver Status: 1 = Remote receiver is OK. 0 = Remote receiver is not OK. 11 1000BASE-T FULL DUPLEX 0, RO Link Partner 1000BASE-T Full Duplex Capable: 1 = Link Partner capable of 1000Base-T Full Duplex. 0 = Link partner not capable of 1000Base-T Full Duplex. 10 1000BASE-T HALF DUPLEX 0, RO Link Partner 1000BASE-T Half Duplex Capable: 1 = Link Partner capable of 1000Base-T Half Duplex. 0 = Link partner not capable of 1000Base-T Half Duplex. 9:8 RESERVED 00, RO RESERVED by IEEE: Writes ignored, read as 0. 7:0 IDLE ERROR COUNTER 0000 0000, RO, COR 1000BASE-T Idle Error Counter
  3. Цитата(Dr.Alex @ Jun 30 2017, 15:38) Оперный коразь.... Я же сразу сказал: один раз задайте, и именно входной клок. А если будет опять ругаться, значит у вас по-прежнему где-то задано второй раз, и неправильно, неужели не понятно? Ищите до посинения, где оно задано второй раз, и уберите. это все известно. в каких файлах и что нужно изменить(убрать). но... когда я изменяю руками - это не воспринимается. потому-что синтез уже произведен. и допуска к генерации выходных параметров нет. выдается Код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 , где можно менять параметры. так что нужен еще какой-то путь. Цитата(doom13 @ Jun 29 2017, 15:25) Может быть проблема в out-of-context synthesis? Всегда использую опцию Global. это помогло, просто я в прошлый раз лопухнулся сам. запустил не тот проект. и это ,кстати, убирает частоту из параметров IP. но, все-таки, как менять параметры не ясно. спасибо всем!
  4. Цитата(Dr.Alex @ Jun 30 2017, 14:35) Или всё-таки из-за того, что она задана в двух разных местах по-разному? Нет конечно. Для начала никаких дженерейтед клоков, а только клок на входе. ну конечно она задана: - на входе частота(описана - это клок на входе . просто я про это не писал.) и далее из нее получается частота fifo. и она не совпадает с частотой , описанной в ip. все именно так. вопрос как изменить? потому-что не получается изменить это tcl командой. именно для этого параметра. а то , что вы предлагаете - изначально сделано.
  5. Цитата(Dr.Alex @ Jun 29 2017, 17:05) Не нужно в корках никаких частот задавать. А задайте её один раз в sdc (xdc) файле. Не очень понятно зачем это делать. Ведь и так 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". и они мешаются под ногами.
  6. Цитата(doom13 @ Jun 29 2017, 15:25) Может быть проблема в out-of-context synthesis? Всегда использую опцию Global. это я пробовал. если это " generate output productы" - не влияет.
  7. здравствуйте, в 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. причем пересборка не убирает такое предупреждение. как от этого избавиться?
  8. Цитата(bogaev_roman @ Nov 30 2016, 13:57) у vivado есть две временные модели - fast|slow, и в зависимости от технологического разброса/температуры и напряжения пути будут иметь разную задержку - для сетапа и холда рассчитываются они по разному. Таким образом производитель гарантирует работоспособность всех чипов в заданном температурном диапазоне и просадках по питанию. я так понял, что не получится выполнить тайминги с моими условиями. я на свой вопрос получил на форуме xilinx такой ответ ЦитатаFrom your constraints you are asking the tools to provide an edge aligned DDR interface with no more than -100ps to +300ps of skew. The tools are telling you (clearly and categorically) that it can't be done. Without the ODDR, the tools are telling you that the total violation (setup slack + hold slack) is consistently around 980ps, meaning that it cannot give you a skew of less than 980ps plus the 400 you are asking for (around 1300ps of skew). With the ODDR, the total violation is decreased - its around 450ps plus the 400 you are asking for, so 850ps. So, no matter what, this will fail. From these numbers alone it is clear that there is no phase that can meet both the setup max and min skew. Furthermore, you are adjusting the skew in increments of 30 degrees - so 1/12 of your clock period. At 400MHz, this is therefore increments of 208ps - again, this is confirmed by your results (the difference in timing between, say, 90deg and 120dec is moving 208ps of slack from setup to hold). You also get into some launch/capture edge changes as you move from 0degrees to 30degrees (which can be fixed, but is not the root of your problem). If you want to minimize skew, forget about trying to use different clocks on different phases of the MMCM - clock both the forwarded clock and forwarded data on the same clock using the same BUFG. This will minimize the skew (but likely still won't meet your requirements). Using different outputs of the MMCM add skew (about 200ps total) and using different BUFGs adds a fair bit of additional skew (as compared to using a single BUFG). You might get (slightly) better results using a BUFH instead of a BUFG if your MMCM and all your outputs are in the same bank. There might even be a way to use a BUFIO, which could be slightly better yet. But, again, its not likely that any of these are going to meet your tight requirement. That being said, Vivado is fairly pessimistic in these situations. The way it handles "on chip variation" is chip wide; the difference in timing between the longest and shortest paths it uses for timing (which is really what is creating all this skew) is the same ratio, regardless of whether the two structures are right beside each other or on opposite corners of the chip. So, if your forwarded clock and data are all in the same bank (ideally with the clock in the middle of the cluster of data), then the skew is going to be better (maybe even a fair bit better) than what the tools predict. Unfortunately, no one can really tell you "how much better". So, if you really need the tightest possible skew, then just put everything in the same bank and use the same clock to clock both the forwarded clock (using the ODDR) and the output data (using an ODDR or OSERDES) - nothing you can do in the FPGA is better than that. If that isn't good enough, then (basically) you are out of luck... Изменить временные требования я не могу. поэтому приходится что-то делать с граничными значениями. xilinx проводит проверку в slow process corner (высокая температура, низкое напряжение) и fast process corner (низкая температуры, высокое напряжение). Насколько схема будет работоспособна без этих граничных условий. как это можно проверить? Если я задаю Кодconfig_timing_corners -corner fast -delay_type none то у меня остаются ошибки в slow. и после задания Кодconfig_timing_corners -corner slow -delay_type none ошибки исчезают. но проводится ли какая-то проверка в этом случае?
  9. Цитата(bogaev_roman @ Dec 3 2016, 13:12) В этих выходных буферах есть программируемая задержка (у артикса в некотрых банках есть такая возможность)? нет , там только HR банки. В них только входная задержка.
  10. Цитата(bogaev_roman @ Dec 2 2016, 12:16) Кстати, распиновка у Вас фиксированная? Смотрю путь тактовой частоты - начало в координате x0y1 (это для клок контрола), а конец x0_y174, для данных x0_y192. Попробуйте вообще отвязать от пинов или подвинуть их ближе друг к другу и к переходу на клоковое дерево. Распиновка фиксированная. В проекте частота приходит в одном банке и есть 2 выходных канала А и В по (16+1 + clk) LVDS пары. И они выходят в 2-х других банках. Изначально констрейны прописаны были для всего. Это ,наверное, то же , что и подвинуть ближе друг к другу. И везде были одинаковые проблемы такие же. Но даже для каналов А и В цифры в одной разводке отличалиь не более чем на 0.1нс. Это сейчас я рассматриваю 2 сигнала. Цитата(bogaev_roman @ Dec 2 2016, 12:16) Можно еще попробовать частоту пускать на прямую - без перехода на клоковый буфер. это я тоже пробовал. Происходит просто смещение величин на 0.3-0.5нс. также как и тогда когда я двигал выходную частоту. следующая таблица это показывает. фаза -это смещение с шагом ~0.208нс . и 1-я без ODDR на выходе и 2-я c ODDR на выходе. Цитата(Shivers @ Dec 2 2016, 13:55) Лучше буферы в данные добавлять. я не понял идею. хотя прочитал статью и там все вроде бы понял. Но в любом случае буферы на данные на выходе поставить нельзя. Мало того, что это заимствованный IP xilinx - selectio_wizard и туда трудно чего-то вставить. Вообще-то можно сделать самому подобное. Но там sourse clock записывает данные в OSERDESE2 примитив и далее выход приходит на obufds(в картинке ошибся) и далее выходной порт. картинка
  11. Цитата(bogaev_roman @ Dec 2 2016, 12:16) setup и hold взаимосвязаны, если у Вас будет увеличиваться запас по setup, то будет уменьшаться запас по hold - это нормально. Теперь вопрос - что на максимальное быстродействие для DDR написано в даташите для конкретного чипа? но когда я ставлю 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
  12. Цитата(Shivers @ Dec 1 2016, 14:17) В Вашем случае clock pessimism получился отрицательным, почему - не знаю, надо у фиттера спросить. Спасибо,вроде бы все понятно, кроме того, что оставил. Но ведь нужно попробовать справиться с отрицательным 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).
  13. тут мне непонятно следующее. параметр clock pessimism на самом деле уравнивает время в точке раздвоения. мне непонятны знаки времени до этой точки. при этом если Destination Clock Patch считается по макс. времени , а Source Clock Path по миним. времени , то в этой точке цифры должны быть наоборот т.е. Destination Clock Patch больше и тогда clock pessimism должен бы вычитаться. но счет идет не так. но в любом случае с учетом clock pessimism время уравнено. и это подтверждается тем, что иногда все считается правильно по времени. но все равно со знакамиотрицательными Destination Clock Patch и Source Clock Path до точки раздвоения мне непонятно. здесь тот же проект, но без bufh. и все идеологически правильно с моей точки зрения. только отрицательные времена в начале. но к сожалению hold отрицательный. эти разные подсчеты (подходы, результаты) мне непонятны.
  14. Цитата(des333 @ Nov 30 2016, 17:47) У Altera в TimeQuest есть вот такой параметр Посмотрите что-то похожее у Xilinx. Может быть, что этот параметр у Вас выключен. да, такой пораметр clock pessimism считается. и он как раз равен той величине , которая набегает при достижении точки раздвоения . но вот он почему-то усугубляет ситуацию. т.е. эта величина добавляется к Destination Clock Patch и увеличивает Required Time. и соответственно уменьшает hold. Цитата(bogaev_roman @ Nov 30 2016, 18:00) - тактируемая частота обычно в кристалле идет по клоковой дорожке, задержки на которой отличаются от обычной дорожки, по которой идут данные, соответственно утверждение о том что при повышении температуры задержка на пути данных и пути частоты увеличатся на одинаковую величину ошибочно, общая часть - это одна и та же клоковая дорожка Цитата(bogaev_roman @ Nov 30 2016, 18:00) Вы бы привели полностью пути по расчету сетапа и холда для конкретного пути и сказали, какое место с Вашей точки зрения не корректно рассчитывается. А так на самом деле уточню пару моментов: сейчас, как я выяснил ранее, почти все считается правильно. но вот параметр clock pessimism усугубляет ситуацию, а должен улучшать. т.е. приближать две рассчетные величины друг к другу
  15. Цитата(bogaev_roman @ Nov 30 2016, 13:57) ... в зависимости от технологического разброса/температуры и напряжения пути будут иметь разную задержку - для сетапа и холда рассчитываются они по разному. Таким образом производитель гарантирует работоспособность всех чипов в заданном температурном диапазоне и просадках по питанию. ... т.к. допустим при минус 40 градусах время распространения сигнала будет существенно отличаться от него же при плюс 100. я с этим и не спорю. но есть вопросы. с setup вопросов нет. там действительно 2 разных фронта ( и об этом говорит добавка 1.250нс при расчете времени пути). и это определяет то, что мы считаем макс. время для данных и мин. время для частоты на протяжении всего пути. с hold же все не так. там один и тот же фронт ( то , что это один фронт - отсутствует добавка 1.250нс в расчетах и показано на нижнем рисунке) формируется на 1-3 частях пути, далее он разделяется и идет на данные по одному пути , а на вых.частоту по другому. так вот, мне кажется , что часть пути 1-3 не внесет изменений в подсчет времени hold при "температурном диапазоне и просадках по питанию" именно потому, что это физически один и тот же фронт. т.е. если что-то не так , то это "не так" одинаково скажется на данных и частоте. А дальше остальной путь, конечно, нужно считать по разному.