Dimitrius

Ложная тревога. Оказалось, что отладчик J_link загружает код в MCU через Keil, хотя пишет, что no flash operation selected. Но это тоже плюс, работать можно быстрее.

А мне СЛУЧАЙНО удалось загрузить прошивку МК без инстантинации контроллера флеш. При генерации IP EMPU-M1 оставляем ITCM без инициализации (сколько надо кб). Потом просто программируем в режиме MCU mode L. И всё работает. Получается не документированная фича какая-то. Я искал способ прошивки МК без снижения частоты, которое происходит при введении этого флеш контроллера (у меня 25 Мгц с дебагом). (Способ с merge-bit как для GW2A не работает) Интересно, что область памяти, где флеш (начиная с адреса 0x0), можно затирать через отладчик. Но после выключения питания всё возвращается обратно. То есть каким-то образом режим MCU mode L умеет заводить прошивку МК в ITCM память и сразу прошивать в конфигурационный флеш плис. Только что при этом содержит User Flash пока не могу посмотреть.

Сделайте это на плис, которая под рукой. Что может быть проще?😜 Soft МК туда + необходимая логика. И не нужны никакие прерывания ( считаю они вообще не нужны при наличии ПЛ)

Там не так сделано. Счётчик только один на все сигналы и считает до изменения состояния хотя бы одного из сигналов. В память пишется значение счётчика и состояние всех сигналов. Поэтому избыточностью является только разрядность счётчика.

Я давно уже не пользуюсь встроенными осциллографами именно по причине патологической недоразвитости . Есть гораздо интереснее опенсоурс решение - OpenVerifla. Записывает только количество тактов между изменениями сигналов в память. Таким образом медленно меняющиеся процессы не расходуют память. Несмотря на некоторые неудобства при использовании, альтернатив нет.

Не понял что имеется ввиду по этим...

Зато указан максимальный ток на стр.53 Datasheet - 1,5 мА вверх и 0.5 вниз. Так что думаю не подойдёт. Если частоты до 150-200 МГц, то отражение и звон существенно не влияют на считывание сигналов без терминирования на небольших расстояниях (несколько см). Для более высоких частот есть другие стандарты - SSTL, LVDS и др. Поэтому, если Вы сами ставите 100 Ом по входу для терминирования, то нужно ставить усилитель в Вашем случае и мириться с повышенным потреблением. Но если задача ограничить амплитуду "звона", то перед входом лучше поставить последовательный резистор на 10-20 ом, который его уменьшит за счёт RC фильтра( С- ёмкостью входа). В этом случае не нужно ставить 100 Ом параллельно.

Для каждого пина на выход задаётся ток 4,8,12,16,24 мА в timing constaraints. Нужно знать ёмкость вывода, ёмкость дорожки и ёмкость входа, куда этот вывод идёт. Тогда можно посчитать время нарастания/спада (примерно), то есть t = C/I*dU. Либо в готовом устройстве подобрать с помощью осциллографа.

Да

В общем решил задачу радикальным способом - инверсией клока регистром ODDR и выносом регистров интерфейса на периферию (IO BLOCK). Это на выход. Дальше интереснее, интерфейс двунаправленный. Обратно данные идут по положительному фронту и после IOB этот фронт становится отрицательным. Поэтому добавил дополнительные регистры IOB, которые защёлкиваются по отрицательному фронту и переносят данные на положительный, следующий за ним, фронт. А далее всё считывается по положительному. Но тут важно, чтобы все регистры были на периферии (тогда выравниваются задержки между линиями данных)

Потом, он так лихо добавил целый период к клоку (20нс), и считает, что у него запас остался.

Так вот штука в том, что не удовлетворяется требование, setup на выходе отрицательный.

За счёт размещения/разводки внутри плис. Если это только механизм контроля, то после применения директив должно выйти только сообщение об ошибке, если не получилось сделать так как указано. Однако, так не происходит. После применения директив меняется и сама разводка, так как она опирается на тайминги (в том числе и указанные директивы), что должно привести к изменению задержек setup/hold на выходе. Например на Xilinx без директив интерфейс у меня не работает, с директивами работает. Так что это механизм влияния, а не только контроля. Slack 12.404 Data Arrival Time 4.561 Data Required Time 16.965 From data_2_s0 To data_i Launch Clk clk50:[R] Latch Clk test_clk_gen:[R] Data Arrival Path: AT DELAY TYPE RF FANOUT LOC NODE 0.000 0.000 active clock edge time 0.000 0.000 clk50 0.000 0.000 tCL RR 5 PLL_L[1] PLL_CPU/rpll_inst/CLKOUTD 0.243 0.243 tNET RR 1 R33C34[1][A] data_2_s0/CLK 0.475 0.232 tC2Q RF 2 R33C34[1][A] data_2_s0/Q 1.974 1.499 tNET FF 1 IOR40[A] data_i/I 4.561 2.586 tINS FF 1 IOR40[A] data_i/O Data Required Path: AT DELAY TYPE RF FANOUT LOC NODE 20.000 20.000 active clock edge time 20.000 0.000 test_clk_gen 19.965 -0.035 tUnc data_i 16.965 -3.000 tOut IOR40[A] data_i Это для set_output_delay -min -3.0 (max 3.0)

Смотрел. Написано, что activated. С того, что в расчётах параметров min и max участвуют setup и hold для внешнего интерфейса. То есть эти директивы и нужны, чтобы выдержать setup/hold наружу. У gowin вижу, что фронт данных выходит позже клока (setup не выдержан), также не выдерживается hold. Также я наблюдал эти изменения осциллографом на Xilinx, когда делал этот интерфейс. У Xilinx UG949 стр. 155 есть пример расчёта mix/max параметров.

Переношу проект с Xilinx на GOWIN (GW2A-18). Выяснилось, что директивы set_input_delay / set_output_delay совсем не влияют на результат трассировки плис. Естественно, отдельно проверил с помощью простенького кода и осцилографа, что задержка выходного тактового сигнала относительно данных не меняется при смене значений этой задержи в директивах. Даже не меняется выходной бинарник (fs-файл). Может кто сталкивался, есть ли способ заставить работать это чудо?