Правильное использование locked у PLL Опции

[Jackov]

Приветствую!

Имеется Cyclone4, а в нём имеется PLL.
Как известно PLL на рабочий режим выходит не сразу, сразу после запуска она выдаёт нестабильную частоту.
Тактировать схемы такой нестабильной частотой, понятное дело, нельзя - могут сбойнуть. Для этого в PLL предусмотрен специальный выход "locked". Доподлинно неизвестно синхронизирован ли этот выход с тактовой частотой выдаваемой PLL, или нет. Потому встаёт вопрос: как правильно использовать этот выход.
Я предлагаю такую схему:

На Verilog-е выглядит так:

Код

module M1(
    ....................................
    (*chip_pin = "Y2"*) input inMHz50);


    wire Locked33_6, MHz33_6_;
    PLL1 PLL1(.c0(MHz33_6_), .locked(Locked33_6), .inclk0(inMHz50));
    wire Enable33_6Q;
    DFF Enable33_6(.q(Enable33_6Q), .d(Locked33_6), .clk(MHz33_6_), .clrn(1'd1), .prn(1'd1));
    wire MHz33_6;
    LCELL Cell(.out(MHz33_6), .in(Enable33_6Q & MHz33_6_));

    .......ля-ля-ля тополя.......
endmodule

LCELL нужен только для того чтобы на него сослаться в констрейнах, по другому я не сумел.

Сами констрейны выглядят так:

Код

derive_clock_uncertainty

#тактовая частота с генератора 50МГц
create_clock -period 50MHz -name {inMHz50} [get_ports {inMHz50}]

#тактовая частота с PLL
create_generated_clock -name MHz33_6_  -source [get_ports {inMHz50}] [get_pins {PLL1|altpll_component|auto_generated|pll1|clk[0]}] -divide_by 5 -multiply_by 7 -duty_cycle 70.00
create_generated_clock -name MHz33_6   -source [get_pins {PLL1|altpll_component|auto_generated|pll1|clk[0]}] [get_nets {Cell}] -invert

То что в названии частоты присутствует 33,6 МГц - это пережиток прошлого, сейчас там 70.
В последней строчке я и ссылаюсь на LCELL, "-invert" присутствует из-за того что компилятор по каким-то своим причинам инвертирует сигнал после LCELL.

Вопроса, собственно, два: Правильно ли использовать выход "locked" подобным образом? И если правильно, правильно ли заданы констрейны?

Сообщение отредактировал Jackov - Jan 22 2015, 18:28

[Jackov]

Не совсем, у меня в always-е два сигнала фигурируют, там один. Попробую завтра так сделать, отпишусь что получилось.

Ну да, у Вас асинхронный сброс, не вчитался. Просто сотрите его из олвейза ))) Будет сброс синхронный, а засинтезируется он как клок енэйбл. И наверняка (потом покажете кусок схемы) он ляжет как дополнительный вход LUTа, стоящего перед входом данных триггера. По опыту, не хочет синтезатор подключать сигналы типа CE к соответствующим входам триггера, лучше ему через LUT. Ну на то есть причины конечно (хотя это касается Xilinx, в Альтере может и захочет).

В общем вот. Имеем такой код:

Код

module test(output reg Q, input D, En, input Clk);
    always @(posedge Clk)
    begin
        if(En)
        begin
            Q = D;
        end
    end
endmodule

Синтезатор, вроде, ссинтезировал правильно

А вот как развелось


Такое ощущение, что надо чего-то в настройках повращать.
Запускал в Квартуе 9.1 для Циклона 4.

1) CLB CE.
2) BUFGCE.
3) Gated clock.

Но, в данном, конкретном случае, явно BUFGCE просится, ввиду особенности задачи.

Поясните ньюфагу по хардкору. Если всё правильно понял, то Gated clock - это разрешение клока на триггере, BUFGCE - переключатель клоков с входом разрешения. CLB CE - это что за зверь?

Топикстартеру надо пересмотреть свою позицию:

Разверните мысль, пожалуйста.

Сообщение отредактировал Jackov - Feb 5 2015, 16:51

[des00]

Синтезатор, вроде, ссинтезировал правильно

А вот как развелось


Такое ощущение, что надо чего-то в настройках повращать.
Запускал в Квартуе 9.1 для Циклона 4.

Ничего удивительного. Именно для вашего примера, использование сигнала En, как сигнала разрешения ENA триггера в LE не эффективно. Причины объясняются тут Cyclone IV Device Handbook -> Logic Elements and Logic Array Blocks in Cyclone IV Devices -> Logic Array Blocks.

.....
Each LAB consists of the following features:
■ 16 LEs
■ LAB control signals
■ LE carry chains
■ Register chains
■ Local interconnect
......
LAB Control Signals
Each LAB contains dedicated logic for driving control signals to its LEs. The control
signals include:
■ Two clocks
■ Two clock enables
■ Two asynchronous clears
■ One synchronous clear
■ One synchronous load
.......

Логический вывод из этого думаю сможете сделать самостоятельно. Это кстати касается всех современных ПЛИС.

[SM]

Логический вывод из этого думаю сможете сделать самостоятельно. Это кстати касается всех современных ПЛИС.

Вот, кстати, именно в данном случае, в проекте из одного триггера, это логике и не поддается. По разводке оба варианта одинаковы (какая разница, завести enable на LAB CE, или на LUT, все равно куда-то заводить, конкуренции между этими сигналами в данной схеме нет), а вот лишний LUT занят (кол-во LUT - вроде как один из критериев оптимизации).

И, кстати, это далеко не всех ПЛИС и сред касается:

Эскизы прикрепленных изображений

 

[des00]

Вот, кстати, именно в данном случае, в проекте из одного триггера, это логике и не поддается. По разводке оба варианта одинаковы (какая разница, завести enable на LAB CE, или на LUT, все равно куда-то заводить, конкуренции между этими сигналами в данной схеме нет), а вот лишний LUT занят (кол-во LUT - вроде как один из критериев оптимизации).

Немного не корректно. В случае использования clkena для одного LE из LAB, у вас "убивается" весь LAB. Т.е. вы уже не можете использовать триггеры других 15 ти LE. А LUT можете использовать либо для многолютовой комбинаторики либо для нагрузки триггеров из другого LAB. И в общем случае это приведет к перерасходу ресурсов разводки и не возможности register packing. Тоже самое касается сигналов sclr и sload. А то что ква делает так, ну вот такой у него оптимизатор. Даже в проекте из одного триггера на миллионный чип. Кстати LAB в первых сыклонах был 10LE и там чудно делались сложные (с использованием сигналов clear/load/enable) 40 бит аккумуляторы. В старших, пришлось кое где уйти на 32 бита.

И, кстати, это далеко не всех ПЛИС и сред касается:

Как я понимаю это ячейка латекса, подскажите что за чип, посмотрю даташит, вполне возможно что у них в аналоге LAB есть дополнительные ключи на отключение clkena части триггеров от общего управления

UPD. В стратиксе 5 ом, в LAB 10ALM, в каждом 4 ре триггера. И там, цена желания что бы на счетчике был именно clkena (ручная вставка dffeas примитивов) еще выше.

UPD2. Посмотрел на вашу картинку внимательнее. Судя по всему верхняя половина LE не задействована. Вам повезло, "убийство" верхнего триггера вы не заметили. Вот будет у вас более плотный дизайн, тогда думаю обратите на это внимание

[SM]

И в общем случае это приведет к перерасходу ресурсов разводки

А причем тут "общий случай" и какие-то гипотетические триггеры и сигналы, которые могут быть нужны и которых нет? У нас случай вполне себе частный, и конкретный, от автора:

Код

module test(output reg Q, input D, En, input Clk);
    always @(posedge Clk)
    begin
        if(En)
        begin
            Q = D;
        end
    end
endmodule

1) В части разводки конкуренции нет, больше цепей нет в принципе, следовательно, критерий отпадает (умножается на коэфф. конкуренции = 0).
2) В части нужности других CE - тоже нет, тоже критерий отпадает (умножается на коэфф. конкуренции = 0).
3) В части нужности других триггеров в LAB - опять, конкуренции нет, опять, критерий отпадает (умножается на коэфф. конкуренции = 0).
4) А вот LUT - он и ток кушает, и место (area) занимает, так что критерий имеет вес. Вот его и следует соптимизировать, заведя сигнал на CE.

Как я понимаю это ячейка латекса, подскажите что за чип, посмотрю даташит, вполне возможно что у них в аналоге LAB есть дополнительные ключи на отключение clkena части триггеров от общего управления

Нет там таких ключей, CE тоже общий. Любой смотрите на выбор, разводится одинаково (я проверил на XO2, XO3, XP, XP2, ECP2, ECP3). Просто, там, оптимизатор делает свою работу более логично, нежели квартус.

PS
А когда количество enable-ов от одного сигнала возрастает, так, тем более, есть прямой смысл их объединять в кучу и заводить на CE, и не только на LAB/SLICE CE, но и в более глобальные ресурсы разводки.

[des00]

А причем тут "общий случай"? У нас случай вполне себе частный, и конкретный, от автора:

Код

module test(output reg Q, input D, En, input Clk);
    always @(posedge Clk)
    begin
        if(En)
        begin
            Q = D;
        end
    end
endmodule

1) В части разводки конкуренции нет, больше цепей нет в принципе, следовательно, критерий отпадает (умножается на коэфф. конкуренции = 0).
2) В части нужности других CE - тоже нет, тоже критерий отпадает (умножается на коэфф. конкуренции = 0).
3) В части нужности других триггеров в LAB - опять, конкуренции нет, опять, критерий отпадает (умножается на коэфф. конкуренции = 0).
4) А вот LUT - он и ток кушает, и место (area) занимает, так что критерий имеет вес. Вот его и следует соптимизировать, заведя сигнал на CE.


Нет там таких ключей, CE тоже общий. Любой смотрите на выбор, разводится одинаково (я проверил на XO2, XO3, XP, XP2, ECP2, ECP3). Просто, там, оптимизатор делает свою работу более логично, нежели квартус.

Это все софистика при решении задачи о сферическом коне в вакууме. Вы гуру вам виднее и опыта у вас больше.

Мои результаты по утаптыванию проектов в чипы от альтер приводил на форуме кучу раз. 99.5-99.8 % занятого дспешным кодом третьего сыклона, хлопающего на частоте 192МГц (у него триггерная 250). Всё после изучения даташитов и логических выводов о работе квартуса.

[SM]

Это все софистика при решении задачи о сферическом коне в вакууме.

А Вы вернитесь в мир реальный, к реальному элементарному исходнику из одного триггера, о котором речь в теме идет, и который неоптимально укладывается квартусом. А не о забитии 99% кристалла.

PS
Может, если ему дать больше приоритета на Area, и заведет? Я сейчас посмотрел, в моей среде по умолчанию стоит и Area, и Timing driven.

UPD:
Убрал "Area", ничего не поменялось...

[Krys]

А Вы вернитесь в мир реальный, к реальному элементарному исходнику из одного триггера, о котором речь в теме идет, и который неоптимально укладывается квартусом. А не о забитии 99% кристалла

Про сферического коня - это правильно. Пример тривиальный. Зачем ругать синтезатор из-за ошибки на тривиальных примерах? Да, формально это ошибка, но ругать надо, когда будет неоптимально синтезить нормальные проекты.
Предлагаю засинтезить проект по защёлкиванию шины данных (размером с количество "теряемых" триггеров) по клоку, стробируемому по CE. В этом случае хотя бы синтезатору будет видно, что совершенно все триггеры имеют CE, и ничего не потеряется, если подать CE прямо на соответствующий выделенный аппаратный вход триггера.
Можно ещё дополнительно усложнить задачу, подобрав на входе триггера такую комбинационную функцию, которая бы занимала все входы LUT'а. В этом случае добавление к этой функции ещё одного сигнала приводит к необходимости ещё одного лута, а это уж точно неоптимально (просто в тривиальном примере от добавления сигнала CE к LUT'у ничего страшного не происходит, т.к. ещё есть свободные входы).

Не грешит, а показывает взвешенный подход, где один триггер, там одно, где кристалл под завязку - там другое.

Да я пробовал и на неплотных проектах. Да вообще где ни пробовал - там это везде наблюдалось. Из чего я сделал для себя эмпирический вывод, что с этим надо смириться, CE он добавляет не на аппаратный выделенный вход триггера, а замешивает в LUT.

Простоту алгоритма коррекции таймингов между разными клок-доменами

А если домен один - то нет преимуществ?

[SM]

А если домен один - то нет преимуществ?

Ну это, смотря как этот enable делать. Я имел в виду нечто вроде DCS/BUFGCE/Gated_clock - таким образом, каждый enable создает свой домен, экономя потребление (отключается целый сегмент дерева тактовых сигналов). Но затраты на разводку увеличиваются - так как начинаются проблемы с коррекцией HOLD-ов на междоменных переходах. А подача на CE с точки зрения затратности ресурсов на разводку идентична мультиплексору данных.

Зачем ругать синтезатор из-за ошибки на тривиальных примерах?

Из соображений логики. Раз на тривиальном сделал неоптимально, значит и на нетривиальном где-то лажанется по этой же причине....