Нажмите для просмотра прикрепленного файлана рисунке 2 схема управления внешним ЦАП. На рисунке 1 времянка из даташит на АЦП. Как правильно задать констрейны не учитывая внешних задержек (в плате все цепи выравнены).

в *.sdc файле описал клоки.


не могу понять как описывать выходные пины Dout и clkDac? Очевидно нужно описать выходные задержки, но между чем и чем?
мне нужно чтобы передний фронт clkDac был посередине установки данных на Dout. По даташиту, при моих частотах допускается передний фронт clkDac двигать ±2 нс относительно Dout. Как это правильно прописать в констерейнах?
пробовал так


такие констрейны не выполняются. Например по clkAdc такие картинки - рисунок 3. Не понятно по графику.... по идее клок pll|clk_in[0] испустился (Launch Clock), через 5 нс ±2 должен появится клок на выходе плис clkDac (Latch Clock). Но на графике всякие Clok Delay и Data Delay почемуто ДО того, как испустился клок (Launch Clock). Кто-нибудь может пояснить эти диаграммы, плииз.

тактовая на ЦАП неправильно задана.

А где неправильно? Я ваши статьи до дыр зачитал... ни чего не понятно. По вашим картинкам и по вашему тексту вроде всё понятно. У меня совершенно другие картинки в TQ. На моем рисунке начало анализа не понятно от куда. Вышел Lautch Clock из плл (самая верхняя кривая), после этого этот клок должен прийти на вход ОЗУ, очевидно что будет какая-то задержка.... 1...2 нс. Но у меня задержка клока -3.474 нс (Clock Delay). Почему МИНУС 3.47? Далее .... после того, как клок прошел задержку в МИНУС 3.47нс идет задержка 6,243 нс на доставку данных к порту плис (Data Delay).

констрейны create_generated_clock в TQ автоматом создал. Там что-то неправильно?
Что нужно констрейнить и относительно чего? На самом деле мне нужно чтоб на НОЖКЕ плис clkDAC сигнал не убегал относительно данных на НОЖКАХ плис Dout. Как Doun или clkDAC убежит относительно входного клока ПЛИС или выходных регистров PLL - неважно.

Из TQ попытался сделать
set_max_delay -from [get_ports {Dout[*]}] -to [get_ports {clkDac}] 7
так проект вообще не собирается в квартусе.


ps Вопрос по вашей статье.....часть4

Это вы задали допуски для ...... для выхода data[*] модуля dac относительно выхода oclk модуля dac. А как же задержка прохождения от выхода data[*] модуля dac до конкретного пина плис? Или она не констрейница?





Почему в TQ время Clock Delay в Data Required отрицательное?

судя по вашему рисунку, вы тактируете ЦАП от плис. При этом клок, относительно которого должны быть заданы задержки идет от порта плис. У вас же указаны выходные пины PLL.

На остальное чуть позже отвечу и будет неплохо если вы выложите тестовый проектик.

т.е. нужно задать клоки для ЦАП так?



тестовый проектик попробую выдернуть из проекта попозже.

нет, не так. Нужно описать выходной клок с ПЛЛ, порожденный из входного клока. И отдельно клок ЦАП, порожденный из выходного клока ПЛЛ. Не внимательно читали. В приложениях даже ссылки на статьи от альтеры были, с примерами.

с клоком ЦАП вроде прояснилось. Но все равно не получается данные отконстрейнить. в приложении тестовый проектbr (Q11.0 SP1)



с клоком на ЦАП разобрался.... картинки в TQ стали понятные. Толи во всем разобрался, толи формулу под результат подогнал...... Подскажите если сто не так по картинкам...

на первой картинке Launtch Clock - это клок на входе ОЗУ внутри плис. Latch Clock - это клок на выходе из плис который пойдёт на ЦАП. они в противофазе как и нужно. между ними 180°.
Data Arrival складывается из задержки Launtch Clock до входного триггера в озу 0,815 нс и задержки выборки данных из озу 7,564 нс.

Data Required: после переднего фронта Latch Clock на выходе Pll через 2,287 нс на пыходе ПЛИС появится клок - это время задержки распространения клока. Т.е. реально в через 2,287 нс на ЦАП придет клок. Но нужно ещё 2 нс на tsu. поэтому данные должны быть готовы не позднее чем за 2 нс до клока на ЦАП. А в реале данные появятся на 2,869 нс позже требуемого.
Наверно нужно задержать клок ЦАП примерно на 3 нс и должно все заработать. между Launtch Clock и Latch Clock 180°. 3 нс на 100 МГц - это примерно 108°. Делаю между Launtch Clock и Latch Clock 290°. Пересобираю проект и вуаля.... вторая картинка: данные на пинах плис появились на 0,186 нс раньше требуемого.

я правильно расшифровал графики и исправил ошибки? как то всё слишком просто получилось.

бинго !!! %) я же говорил что ничего сложного, но требуется понимание физики процесса %)

ЗЫ. а в вашем случае лучше фазу вообще не крутить, если по холду проходите конечно

ага, спасибо за подсказки. В тестовом проекте не стал фазу вообще крутить. сделал 0°. и tsu/th сделал 4 нс. проект пустой все собралось прекрасно.

Стал в рабочем проекте реализовывать полученный опыт )) Если фазу не крутить, и tsu/th = 3 нс, то setup не проходит. т.е. получается Data Arrival порядка 9 нс. допустим фаза сдвинута на 359°. Т.е. клок на цапе будет задержан практически на 9.999 нс. и чуть чуть не проходит. не успевают данные к расчетному Data Required. Задержать бы клок ещё на пару нс и былобы всё прекрасно. Ставлю в PLL задержку на клок в 11 нс, при том что период равен 10. Тут уже TQ не понимает меня. Он считает что клок на цапе задержен не на 11, а на 1 нс. и соответственно все расчеты делает неверно. см рисунок. Как в таких случаях указать TQ, что Latch Clock задержен от Lautch Clok на время, больше периода, т.е. на 11 нс?

1. триггеры в выходные порты ЦАПА поставьте. Уж какой то большой у вас DataArrival
2. Мультициклы. Подробнее посмотрите сайт журнала КиТ. Там в архивах за прошлый год открыли мои статьи. В них более полно расписано задание констрейнов В/В и в частности есть ваш конкретный случай %)

наверно это будет самое правильное. раньше стояли триггеры, но убрал, чему-то они сильно мешали. Возможно верну.
Спасибо, нашел ваши статьи. Выучил ещё один урок )).

Если можно, ещё вопрос..... На самом деле для работы цап нужен clk и wr. По даташиту они практически совпадают. Я сейчас отконстреинил данные относительно клока на цап. wr на цап - это соседний порт на плис соединённый внутри плис. см рис. Нужно описывать констрейны для wr? Если нужно, то как? Первые мысли - это создать ещё один клок от выхода плл до порта вр, так же как клок для цап, и прописать задержки для данных относительно нового клока wr.

я бы сделал так, описал wr как generated_clock с того же порта PLL что и clkDac. И задал бы те же констрейны относительно него. Только не забудьте добавить ключ -add в задержки, что бы анализ не выкинул часть заданных задержек.

я уже так и сделал, тока без адд )))
Спасибо за подсказку

А как констрейнить такие схемы? Сигнал прерывания в модуле MyMod порождается клоком 100 МГц, а процессор считывает порт клоком 50 МГц от др источника. TQ на такие схемы ругается. В предыдущих схемах сделал на логике так, что чтение порта блокирует изменение int, что-то типа аппаратного мютикса. Но в текущей схеме такой возможности нет.

Входные клоки идут с одного клокдистребьютера, очевидно что входные клоки можно описать относительно друг друга, или принять что фаза каждого 4-го клока совпадает. Cигнал int надо описать, .... но как? set_input_delay или set_output_delay? Какие max и min?

недавно пробегали статьи по CDC (Clock Domain Crossing) поройте что к чему. А описывается просто : если клоки асинхронные, то через эксклюзивные группы, если синхронные то через мультициклы или ложные пути.

2 des00
где то в доках встречал что false_path и эксклюзивные группы - это одно и то же.

это вопрос или утверждение ? эксклюзивная группа эквивалента set_false_path между клоками входящими в группу

Это был скорее вопрос потому как я не помню где именно я это прочитал

в хенбуке на TQ скорее всего

чем дальше в лес, тем больше дров. как написать блок, который бы работал от 2-х асинхронных клоков?


клоки асинхронные. если оставить код так, как он есть, то есть вероятность, что чтение данных из data произойдет в тот момент, когда они там меняются. Как от 2-х клоков "правильно" блоки писать, чтоб не было метастабильности?

http://electronix.ru/forum/index.php?showtopic=97626
недавно тема была

А если делать ход конём? процессор со своим контроллером ддр работает от одного клока, а остальная логика от др. Стык нужно делать во внешней логике к которой обращаяется проц на чтение/запись. А если ядро процессора, всю периферию процессора и внешнюю логику в плис запитать от одного клока, а контроллер ддр2 запистать от др. клока. стык клоков будет между ядром ниоса и контроллером ддр. Quartus в такой схеме автоматом разрулит стык клоковых доменов?

Добрый день.
Чтобы не плодить темы, пишу сюда.
Задача простая, но вот не знаю каким констрейном ее решать.
Нужно вывести из циклона клок и его же, но инвертированным:

Mem_ClkP <= Clk;
Mem_ClkN <= not Clk;

Так вот как описать, что до внешней памяти они должны добежать не сильно разбежавшись от изначальной фазы в 180 градусов?
Для конкретики : Сlk = 200 MHz, допустимая разбежка 0.5 ns.
Есть задумка рассматривать первого как generated_clock, а второго как данные, чтобы потом задать setup и hold для обоих фронтов, но не уверен я в своих силах. К тому же сомневаюсь, что это верный путь.

Спасибо.

нет желания для этих целей использовать PLL или DCM ?

Понимаете, тут вопрос не столько в том, как выкинуть эти сигналы наружу, сколько в том, чтобы получше разобраться с констрейнами. Это для примера у меня циклон. А был бы acex, например, то никаких pll не было бы возможности заюзать.

Хочу немного подтянуть знания в области обконстрейнивания проекта.

Помогите, пожалуйста, обконстрейнить следующую схему (см. аттач):
Нажмите для просмотра прикрепленного файла
DataOut - 10 наносекундный положительный импульс, WE - отрицательный, шириной 7.5 ns.

Внешний девайс латчит сигнал с ноги ПЛИС DataOut по фронту сигнала с ноги WE (как обычная SRAM).
Параметры внешнего устройства: tsu = 4.9 ns, th = 0.1 ns.

В проекте я на Pll сделал сдвинутую тактовую серию. WE делаю как "nand2" тригеров, один из которых латчит разрешающий сигнал основным клоком, а второй - сдвинутым.

Пока что мой sdc выглядит так:

create_clock -name {ClkIn} -period 10.000 -waveform { 0.000 5.00 } [get_ports {ClkIn}]
derive_pll_clocks

create_generated_clock -name ClkWE -source [get_nets {inst|altpll_component|_clk0}] -duty_cycle 75 -offset 2
set_output_delay -clock [get_clocks {ClkWE}] -max 4.9 [get_ports {DataOut}]
set_output_delay -clock [get_clocks {ClkWE}] -min -0.1 [get_ports {DataOut}]

Но это не то, что я хотел бы получить. Не знаю, как timeQuest-у сказать, что WE генерится из двух клоков и что его скважность определяется их сдвигом, задаваемым в настройках Pll. Тоже и про его сдвиг относительно основного. Просто если сейчас я делаю Report Timing, то он рисует latch и launch клоки так, как я прописал в create_generated_clock, а не как на самом деле.

Спасибо.

Может надо создать виртуальный клок, а DataOut и WE рассматривать как данные, задавая set_output_delay для обоих относительно виртуального...

Попробовал с виртуальным клоком.
Создал его, потом для DataOut задал set_output_delay. Тут все понятно.
С сигналом WE тупик. Я то ему задал set_output_delay относительно виртуального клока, но TimеQuest рассчитывает слаки для этого сигнала дважды: первый раз исходя из того, что WE дрыгается по фронту первого выхода pll, а второй раз - по фронту второго выхода pll.
В принципе, это почти то, что мне и надо - для нарастающего фронта WE я бы задал константы, соответствующие tsu и hd относительно виртуального, а для спадающего подобрал бы, чтобы выдерживалась допустимая ширина WE.
Но вот как можно задать два набора set_output_delay для WE относительно виртуального клока, чтобы каждый из наборов учитывал только один из выходов Pll?