[zxazx 0]

 

Совет дня: не вступайте в схоластические споры о процессах, если не знаете, как вставить компонент.

Удачи. Она вам понадобится.

 

допустим счетчик равен 3 и константа по которой он обнуляется тоже 3

 

далее как вы сами пишите

--1) планируется инкрементировать счётчик

то есть счетчик должен стать из трех четырьмя по выходу из процесса, но пока счетчик 3

--2) сравнивается значение счётчика с константой и по условию планируется обнулить счётчик

три равно трем, то есть счетчик планируется обнуляться, и из 3 должен стать нулем по выходу из процесса.

 

внимание вопрос, чему должен стать равен счетчик по выходу из процесса? Ведь в начале было запланировано что 0, а в конце что 4?

в пользу какого числа должна сделать выбор железяка? Не знаете? Так вот и компилятор ваш не знает, о чем вам и сообщает!

 

эту коллизию вам справедливо и предлагает решить Горби, и он тут как всегда абсолютно прав:)... вы же знаете что хотели, и чему хотели чтобы был равен счетчик

 

 

Я считал, что зесь коллизи нет, железка должна сделать выбор в пользу последнего планирования. Но если общественность считает, что компилятор может не разрулить ситуацию, то спорить не буду, попробую переписать процесс.

 

Ну, лично я предпочитаю руками в потроха не лазить. Разве что очень припечет. А вообще, почему бы и нет? Речь шла о том, чтобы вывести наружу подозрительные клоки на просмотр. А уж как именно - тут хозяин - барин.

 

Ну почему же сразу 'руками'? Этот инструмент (probes) как раз позволяет не вмешиваясь в сушествующую разводку вевести сигналы наружу. А то вдруг после добавления триггера и переразводки баг изчезнет? Где его потом искать? :(

А в общем согласен, универсальных рецептов нет, да и хозяин - барин. Что-то от него вестей нет, может, нашел уже хомут, а мы тут все гадаем?

 

Насчёт бага- так и есть. Он то появляется, то пропадает. Очень интересно как вывести сигналы наружу без перекомпиляции, если можно, то объясните подробнее.

[zxazx 0]

process (clk20)
begin
    if rising_edge(clk20) and (lock1='1') then
        if count_clk_uart(0)='1' then
            count_clk_uart<=(others=>'0');
            if res2='0' then 
                vd3<='1';
            else
                vd3<='0';
            end if;    
            clkFORuart<= not clkFORuart;
        else
            count_clk_uart<='1' & count_clk_uart(count_clk_uart_W downto 1);
        end if;
    end if;
end process;

                
process (clkFORuart) 
begin
    if rising_edge(clkFORuart) then
    if res2='0' then 
        vd1<='1';
    else
        vd1<='0';
    end if;
..................

 

Вывел наружу LOCKED_OUT и RST_IN - вроде DCM работает нормально

res2, vd1 и vd3 тоже внешние

vd3 изменяет полярность при изменении res2, но сигнал на vd1 не изменяется, значит строчка

clkFORuart<= not clkFORuart;

не выполняется!!!!

Причём, при перекомпиляции проекта с незначительными изменениями(добавление входных или выходных портов, изменения в процессах, которые не имеют отношения к приведённым процессам) описанный трабл то появляется, то исчезает

 

Есть такие варнинги

1) Clock buffer is designated to drive clock loads. BUFGMUX

symbol "physical_group_clkFORuart/clkFORuart_BUFG" (output signal=clkFORuart)

has a mix of clock and non-clock loads. The non-clock loads are:

Pin D of clkFORuart

 

2) clkFORuart may have excessive skew because

1 NON-CLK pins failed to route using a CLK template.

 

Мне кажется подозрительным второй варниг

Изменено 20 июня, 2006 пользователем _zx_

[Gorby 6]

process (clk20)
begin
    if rising_edge(clk20) and (lock1='1') then
        if count_clk_uart(0)='1' then
            count_clk_uart<=(others=>'0');
            if res2='0' then 
                vd3<='1';
            else
                vd3<='0';
            end if;    
            clkFORuart<= not clkFORuart;
        else
            count_clk_uart<='1' & count_clk_uart(count_clk_uart_W downto 1);
        end if;
    end if;
end process;

                
process (clkFORuart) 
begin
    if rising_edge(clkFORuart) then
    if res2='0' then 
        vd1<='1';
    else
        vd1<='0';
    end if;
..................

 

Вывел наружу LOCKED_OUT и RST_IN - вроде DCM работает нормально

res2, vd1 и vd3 тоже внешние

vd3 изменяет полярность при изменении res2, но сигнал на vd1 не изменяется, значит строчка

clkFORuart<= not clkFORuart;

не выполняется!!!!

Причём, при перекомпиляции проекта с незначительными изменениями(добавление входных или выходных портов, изменения в процессах, которые не имеют отношения к приведённым процессам) описанный трабл то появляется, то исчезает

 

Есть такие варнинги

1) Clock buffer is designated to drive clock loads. BUFGMUX

symbol "physical_group_clkFORuart/clkFORuart_BUFG" (output signal=clkFORuart)

has a mix of clock and non-clock loads. The non-clock loads are:

Pin D of clkFORuart

 

2) clkFORuart may have excessive skew because

1 NON-CLK pins failed to route using a CLK template.

 

Мне кажется подозрительным второй варниг

 

 

Заслуживает занесения в FAQ. Как НЕ надо делать.

Значится, первый варнинг Вам подозрительным не показался? В нем как раз и говорится, что обнаружен генератор клоков. Поэтому для него автоматически поставлен BUFG (что значит использование глобального клока). Но софт и далее в непонятках, так как обнаружил, что Вы подаете этот клок не только на тактовые входы, но еще и на логические.

 

В ФПГА не принято подавать клок на ЛОГИЧЕСКИЕ входы, а только на тактовый вход триггеров. Потому как для клоков используются специальные выделенные ресурсы с минимальными (и практически равными) задержками. Часто в кристалле вообще нет средств подать клок на вход данных (в Спартане 2 точно нельзя, в Спартане 3 - не в курсе). Если все-таки надо, то поступают по-хитрому. Тактируют счетный триггер удвоенной тактовой частотой, а выход используют как клок, но его уже можно подавать на логические входы. Но это будет местный, локальный клок, и его уже нельзя подавать на тактовые входы.

 

А второй варнинг говорит, что оно вообще не развело клок на вход D какого-то триггера, потому как он не соответствует шаблону CLK - ясень пень, что не соответствует!

 

Вы явно перемудрили с вашим счетчиком. Что Вы хотели сделать-то?

[vladz 0]

_zx_,

это не хорошая практика тактировать процесс с выхода триггера. Для FPGA правильнее в первом по листингу процессе сформировать сигнал разрешения, а во втором проверять его. Так вы будете работать только от одного клока, что поможет вам избавиться от многих неприятностей в будущем.

Нo данный конкретный приведенный вами пример должен работать при clk20 равном 20 МГц, т.е. vd1 должен изменяться если

 count_clk_uart<='1' & count_clk_uart(count_clk_uart_W downto 1);

- это действительно счетчик.

У вас в ucf задан период входного клока для DCM? Какова реальная частота сигнала clk20?

Если хитите в FPGA Editor вывести сигнал наружу, то просто открываете *.ncd и идете в меню tools->probes . Думаю, далее разберетесь.

Но если надо чтоб работало всегда и везде, то надо переписать процесс и забыть о подобных проблемах.

[Very_hard 0]

если

CODEcount_clk_uart<='1' & count_clk_uart(count_clk_uart_W downto 1);

- это действительно счетчик.

 

Это очень похоже на сдвиговый регистр... Хотя в принципе по существу проблемы это вроде не важно.

[Golikov 0]

Ну, лично я предпочитаю руками в потроха не лазить. Разве что очень припечет. А вообще, почему бы и нет? Речь шла о том, чтобы вывести наружу подозрительные клоки на просмотр. А уж как именно - тут хозяин - барин.

 

Ну почему же сразу 'руками'? Этот инструмент (probes) как раз позволяет не вмешиваясь в сушествующую разводку вевести сигналы наружу. А то вдруг после добавления триггера и переразводки баг изчезнет? Где его потом искать? :(

А в общем согласен, универсальных рецептов нет, да и хозяин - барин. Что-то от него вестей нет, может, нашел уже хомут, а мы тут все гадаем?

 

 

А если не затруднить чуть поподробнее про пробники.

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

[vladz 0]

А если не затруднить чуть поподробнее про пробники.

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

Думаю никто, кроме Xilinx подробнее не напишет :)

Using Probes

и еще

Implementation Strategies using FPGA Editor

 

Probes

Use the FPGA Editor Probes command to perform real-time debugging when you want to analyze a few signals at a time. Using the Probes command, you can identify and route internal signals to available I/O pins without rerunning the place and route tools. You can then monitor the real-time signal activity using normal lab test equipment, such as logic and state analyzers or oscilloscopes. For details, see Using Probes.

 

К симуляции это не имеет никакого отношения, все работает в железе. Раз уж очень нужно и пробников не xватает или неудобно и есть свободные ресурсы, то можно и ChipScope Core с помощью FPGA Editor прямо в разведенный проект вставить, опять таки без изменения уже существующей логики.

[Golikov 0]

А если не затруднить чуть поподробнее про пробники.

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

Думаю никто, кроме Xilinx подробнее не напишет :)

Using Probes

и еще

Implementation Strategies using FPGA Editor

 

Probes

Use the FPGA Editor Probes command to perform real-time debugging when you want to analyze a few signals at a time. Using the Probes command, you can identify and route internal signals to available I/O pins without rerunning the place and route tools. You can then monitor the real-time signal activity using normal lab test equipment, such as logic and state analyzers or oscilloscopes. For details, see Using Probes.

 

К симуляции это не имеет никакого отношения, все работает в железе. Раз уж очень нужно и пробников не xватает или неудобно и есть свободные ресурсы, то можно и ChipScope Core с помощью FPGA Editor прямо в разведенный проект вставить, опять таки без изменения уже существующей логики.

 

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

[Gorby 6]

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

 

Все когда-то начинали. Не лезьте сразу в дебри - рискуете остаться там надолго. Сделайте что-то простое, но стабильно работающее. Прогоните его в пост-лейаут симуляции (это тоже большой кусок знаний для вас). Помотрите на дизайн изнутри.

 

Насчет баланса однозначного ответа нет. Надеюсь, Вы уже знаете, что скорость дизайна определяется как скоростью срабатывания аппаратных средств (LUT, триггер, схема переноса), так и задержками на проводниках, их соединяющих. Причем триггеры всегда работают быстро, а например логика - далеко не всегда, зависит от количества входов (больше входов - больше уровней логики, ибо нет элементов 32_И-НЕ, их строят из 4-х входовых). Также существенный вклад в задержки вносят соединительные линии. Вы как ни-будь посмотрите отчет о статических таймингах, особенно если где-то чего по времянке не влезло. Там очень подробно показывают, что, где и как.

 

В некоторых синтезаторах есть галочки - оптимизировать по скорости или по размеру логики. Не верьте. Просто попробуйте то и то и выберите более вам подходящее. Не раз сталкивался, что дизайн, синтезированный с оптимизацией по скорости, работает медленнее, чем он же, но по размеру. Что весьма логично - меньше размер - меньшие задержки на соединениях. Хотя бывает по-разному.

 

Наличие длинных цепочек (и как следствие, низкая скорость) - целиком на вашей совести как разработчика. Если вы закрутили процесс, в котором за один такт делаете н-дцать операций с одним и тем же счетчиком, то чему вы удивляетесь? Пишите простые процессы. Они и работать будут быстро.

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

 

У меня например в Спартане-3 28-битный синхронный загружаемый счетчик работает на частоте более 125 МГц и еще запас есть. А у вас несколько бит и вы жалуетесь на низкое быстродействие.

 

И еще. Не надо добиваться максимального быстродействия от схемы. Если сильно задрать требуемую частоту, разводчик иногда начинает выдавать чудеса глупости. Установите в констрейнах частоту, на 10-20 процентов превышающую максимальную рабочую частоту вашего изделия.

 

Удачи.

[Golikov 0]

Да я собственно то изучаю все это по ходу проектирования. Вот сейчас на столе лежит модуль ПЛЛ сделанный на спартане 3Е + ДСП. Разбираюсь во всем по ходу дела, и поставленные задачи решаю вполне.

Меня вот что беспокоит, написал я чтобы клок период был 10 нСек, синтезатор шуршал шуршал, написал не получается, ну и отчет что там в длинной цепочке 325 элементов натыкано. Но когда я описывал эту логику я имел ввиду все гораздо проще, я даже представить немогу откуда столько элементов, когда там просто все можно было на 3 регистрах сделать...

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

 

 

хотя это конечно может я хочу от спартана больше чем он может. У меня фазовый дискриминатор на 109-121 МГц работает, остальные части схемы 150-200 МГц. Медленно это когда частота дискриминатора упала до 98 МГц, мне она нужна выше 100, чтобы на 4 клока приходился период АЦП, а лучше чтобы частота была 200 МГц а то я 65 МГц АЦП на полную не использую, и почему то мне кажется что это возможно если бы синтезатор иначе синтезировал схему...

 

Но это так познавательный вопрос был на самом деле, я потихоньку всем этим овладею, просто не могу полностью плисами сейчас заниматься, приходиться целиком проект вести, а там еще ДСП есть. Но думаю у меня не плохо получается для 4 месячного знакомства с плисами%).... Думаю меня сейчас интересует как управлять процессом синтеза в общем, какие инструменты есть для указания критических путей и прочее...