vladz

На всякий случай, вдруг кому пригодится. Последние пару лет Lattice раздает некоторые, в том числе видео и DSP IP suits за $99. В документе по ссылке указано что входит в каждый из наборов: THE LatticeECP3 RE-Surge_f.pdf

Пока что пара очевидных вещей: 1. Из-за того что вы используете оба фронта тактовой частоты !12PLL.c0 и 12PLL.c0, вы поднимаете рабочую частоту проекта в 2 раза до 144МГц. Если логика получилась разбросана по кристаллу, данные могут не успевать за 144МГц тактовой и вызывать ошибки анализатора. Если возможно, то надо стараться использовать в проекте или блоке только один фронт, тода и разводчику PAR станет легче и вам анализировать проблемы станет проще. 2. Нарисуйте на бумаге диаграммы доступа МК к внешней памяти и проставьте длительности всех сигналов в тактах. Посчитайте на каком такте после начала wr и rd вы записываете или выставляете данные наружу. Очень может быть что придется время удержания wr и rd удлинить в программе МК. И еще совет - постарайтесь давать сигналам осмысленные имена, иначе никто не захочет разбраться в этой мешанине символов. Глобальный клок просто не может называться 12PLL.c0, это должен быть просто clk, sys_clk или что-то еще с _clk если не лень набирать длинные имена. Сигнал разрешения обработки не должен именоваться !bscnt.PLDCR[0], измените на что-нибудь с _en/ enable.

Все работает под IE 10 и хромом. И велкам и даунлоад тоже. Пишите в суппорт, помогут ну или подъедут люди в черном если засветились где не надо

Извиняюсь, а вы SLICE и LUT не путаете? Один ROM16X1 = один LUT. В одином SLICE имеется ровно 2 LUT. Посмотрите отчет MAP, там у вас должно быть 3 SLICE и 5 LUT. Внутри .vo видно как раз 3 SLICE, как и должно быть.

MAP тоже умый. Он же вам скорее всего сообщил что он логику выкинул и по отчету видно что Number of logic LUT4s: 0. У меня в Diamond 2.1 помог примитив NOCLIP: ROM16X1 #(.initval("0x0100")) DEDICATED_SLICE0( .AD0(1'b0), .AD1(1'b0), .AD2(1'b0), .AD3(s_tmp[0]), .DO0(s_tmp[1])) /* synthesis NOCLIP="1" */; Инициализацию памяти пришлось изменить потому что симулятор ругался.

Ничего страшного, ну войдет этот регистр в состояние метастабильности на некоторое время. Это совершенно нормальный ожидаемый режим работы для первого регистра в цепочке. Какое такое неверное значение? Состояние регистра может остаться старым, принять новое значение либо быть в процессе перехода. Рано или поздно, но на выходе первого регистра появится стабильный уровень лог.0 или лог.1. При броске мяча в баскетбольное кольцо мяч либо упадет в кольцо (регистр примет новое значение), либо отскочит обратно (регистр сохранит старое значение), но бесконечно находиться на ободе кольца не упав оттуда мяч не сможет. Состояние метастабильности врЕменное, при выходе из него состояние регистра может либо остаться старым, либо принять новое значение. Метастабильное сосотяние может приключиться при защелкивании сколь угодно медленной внешней частоты. Даже если снаружи приходит 1Гц а внутри 100МГц, то синхронизатор все равно нужно ставить. В прошлом сообщении я упомянул про отношение частот в том смысле, что внешняя частота должна быть достаточно медленной чтобы до следующего своего изменения успеть пройти через синхронизатор, иначе не получится выделять нужные фронты.

Чтобы каждый раз не задумываться что же произойдет в этом случае, при условии что период CLK20 хотя бы в несколько раз короче минимальной длительности внешнего сигнала, просто ставят два последовательных регистра и уже после них выделяют нужный фронт. Вот первая попавшаяся ссылка с картинкой: http://infocenter.arm.com/help/index.jsp?t...aqs/ka3834.html Документик от альтеры о сути проблемы: Understanding Metastability in FPGAs Дополнительную информацию ищите по ключевому слову metastability.

А вот здесь: EXTIO<0> | 2.511®| -0.173®|IAL | 0.000| EXTIO<10> | 1.140®| 0.966®|IAL | 0.000| EXTIO<11> | -0.001®| 1.879®|IAL | 0.000| EXTIO<12> | 0.262®| 1.633®|IAL | 0.000| про другую частоту. Вы PAR-у явно не указали какие регистры поместить в IO, вот он их и разбросал куда придется.

Вы всегда можете посмотреть куда PAR поместил ваш регистр. Толь ко вот забыл как этот viewer называется. Разброс для EXTIO<> такой большой потому что вы записываете данные сразу в несколько регистров с разными клоками. Для ADCI<> разброса нет потому что они скорее всего сидят в IO блоках и тактируются одной частотой. Они и есть одинаковые, только разбросаны как попало по кристаллу. По-хорошему вас должно заботить только где входные/выходные регистры находятся, а максимальную частоту PAR уже сам будет пытаться достичь. Укажите в ucf файле частоту для CLK6I, тогда отчет будет немного по-другому выглядеть.

Нет, это означает что для этой разводки setup time = -2.585, hold time = 6.546. То есть данные должны быть стабильны между -2.585 и 6.546 относительно переднего фронта тактовой на ножке CLK6I. Теперь, можно подсчитать устраивает это вас или нет. Вам известно время распространения от CLK6I до ADCCLK: CLK6I |ADCCLK | 12.299| если время Tco (clock to output) для АЦП равно 6 нс как вы написали ранее и ADCCLK не инвертируется, то примерно через (12.299 + 6)нс данные окажутся на входах ADCI<> и при вашем периоде 50нс остается полно времени до момента -2.585 относительно следуюшего фронта на на ножке CLK6I, которым эти данные будут защелкнуты в регистры. То есть для этой разводки setup time и hold time в порядке. Если где-либо в цепи между ADCI<> и входом памяти, которая тоже должна тактироваться от CLK20N у вас стоит клоковый мультиплексор на CLK20N, то это уже не так. В этом случае задержка по клоку может быть больше задержки между регистрами данных и при отсутстсвии констрейнов схема работать не обязана (хотя и может в зависимости от разводки).

Да, я бы сделал вывод, что проект надо переписать, иначе это будет нескончаемое бодание с времянками. Если бы у вас была одна глобальная частота, и временные ограничения на Tsu/Tco и макс частоту были бы в порядке, то проблема была бы в логике работы и не зависела от разводки и расположения блоков на кристалле. Именно поэтому вам говорили что ручное размещение элементов это тупиковый путь. В случае нескольких частот и тем более мультиплексируемого клока надо с лупой смотреть весь проект и все переходы между тактовыхми сигналами вместо того чтобы сосредоточится на логике работы. Ради интереса посмотрите насколько изменятся значения Setup/Hold если вы сделаете какие-либо изменения в проекте.

Самая большая проблема что у вас в проекте моного тактовых сигналов, поэтому могут быть любые неувязки. Несколько тактовых в проекте изпользовать можно, но вам это явно пока что рано делать. В самом идеальном варианте в проекте должен остаться всего один глобальный тактовый сигнал. Вы сможете переписать проект таким образом, чтобы сигналы IIAL, IWRITE, IWRRD перестали быть тактовыми? То есть выделить нужные фронты из IWRITE и IWRRD и спользуя одну глобальную частоту (например CLK20N) затем уже работать со стробами, а не с самими тактовыми сигналами. Вот только пара вещей, которые режут глаз: 1. Входные регистры на ножках ADCI<> и EXTIO<> тактируются от разных клоков CLK20N и CLK_MR, полученных из CLK6I. Вы же скорее всего потом будете записывать данные в одно место (память или регистр), почему не использовать только CLK20N? 2. Зачем воды EXTIO<> защелкивать еще и от IAL, они же уже есть в регистрах, тактируемых CLK_MR? Без констерйнов PAR сам должен решить какие регистры будет лучше поместить в IO блок, а какие отодвинуть подальше. Из-за этого задержки могут меняться непредсказуемо. Есть подозрение что вы пользуетесь какой-то очень старой версией IDE. Возможно есть смысл установить что-то поновее. Более полный отчет можно получить, изменив настройки анализатора.

Нужен полный репорт. До этого мы тоже может быть дойдем, а если нет, то примите это как условный 0, от которого считаются задержки и фазы всех сигналов, свазанных с этим клоком, включая клоки, сгенерированные DCM.

Через пару месяцев мы таки выудиим из вас всю информацию. То есть у вас осциллограф и логический анализатор? Тогда оставим пока АЦП в покое. И что, даже состояние логических входов временами не отображается? Если не хотите выкладывать куски проекта, выложите хотя бы timing report, раньше это был файл с расширением twr.

Давайте зайдем с другой стороны. Через сколько нс после активного фронта клока данные появляются на выходе АЦП? Есть ли у них свой строб или данные обновляются каждый период?