[lhl 0]

Доброго времени суток!

 

Делаю проект в Quartus для EPM3256-10. Синхронная система. Главный клок - 768Fs (33.8688 МГц). Есть четыре сигнала: Wordclock (8Fs), Bitclock (192Fs) и два сигнала данных - DataL и DataR. На первом приложенном изображении соответствуют диаграмме 20 Bit. Потребовалось обеспечить внутри фрейма сдвиг влево/вправо пачки BCLK и регулировку скважности/длительности WCLK. Хорошо, это сделал из основного такта 768Fs. Затем последовала необходимость привязать данные к новым сигналам. После некоторых раздумий, пришел к следующему алгоритму. Для упрощения изложения, исходные сигналы называю WCLK и BCLK, созданные – NWCK и NBCK. Используется 8-и разрядный регистр, входы которого соединены с линией данных, а тактовые входы - с линией BCLK. После отрицательного перепада WCLK, запускается 3-х разрядный счетчик, тактируемый спадом BCLK. Значения счетчика обеспечивают переключение входов разрешения регистра. После того, как в первый разряд регистра произведена запись и счетчик разрешил запись во второй разряд, запускается другой 3-х разрядный счетчик, тактируемый спадом NBCK. Этот счетчик производит мультиплексирование выходов регистра на непосредственно выход данных. Все бы хорошо, алгоритм (теоретически) рабочий, частоты в схеме не очень высокие. Но Quartus этого алгоритма не понимает. Я бы мог закрыть глаза на его предупреждения, но сначала насторожило следующее сообщение:

"Warning: Found 11 node(s) in clock paths which may be acting as ripple and/or gated clocks -- node(s) analyzed as buffer(s) resulting in clock skew"

А в последствие, при симуляции увидел "иголки" - второе изображение в приложении. Посмотрел повнимательнее, "иголки" длиной 0.1 нс и не привязываются ни к одному сигналу. Дело, конечно, поправимое - пересинхронизацией от 768Fs, но мне не нравится такое поведение. Более того, если в проект добавляю дополнительные модули, количество "иголок" увеличивается, а поведение при симуляции вообще не поддается анализу. Алгоритм перестает работать.

Существует ли какой-то нормальный алгоритм перепривязки данных, который компилятор воспринимает рабочим?

[des00 25]

Делаю проект в Quartus для EPM3256-10. Синхронная система. Главный клок - 768Fs (33.8688 МГц). Есть четыре сигнала: Wordclock (8Fs), Bitclock (192Fs) и два сигнала данных - DataL и DataR. На первом приложенном изображении соответствуют диаграмме 20 Bit. Потребовалось обеспечить внутри фрейма сдвиг влево/вправо пачки BCLK и регулировку скважности/длительности WCLK. Хорошо, это сделал из основного такта 768Fs. Затем последовала необходимость привязать данные к новым сигналам.

 

Существует ли какой-то нормальный алгоритм перепривязки данных, который компилятор воспринимает рабочим?

 

Приведите лучше рисунок с вейформами со сдвинутыми BCLK/WCLK и как вы хотите выровнять данные. Не понятно что вы подразумеваете под словами о привязки данных.

[dvladim 0]

"Warning: Found 11 node(s) in clock paths which may be acting as ripple and/or gated clocks -- node(s) analyzed as buffer(s) resulting in clock skew"

Вот это вот говорит о том, что вы сделали сигнал и использовали его как клок. Используйте его как enable, работайте по одному клоку.

[lhl 0]

Простите, я, видимо, плохо объяснил, что мне требуется. Прикрепляю изображение. Исходные сигналы идут фреймами (bcki, wcki, dil, dir), определенными на изображении между маркерами 60.48 us и +2.88 us - как на первом изображении в первом сообщении. На выходе необходимо получить фреймы, соответствующие содержимому между маркерами +302.0 ns и +3.182 us для bcko, wcko, dol, dor. Внутри этого фрейма возможно изменение положения пачки bcko и фронта wcko. Для этого введены группы bcks[] и wcks[]. Во время работы изменение содержимого bcks[] и wcks[] запрещено через фиксирующий регистр.

Для чего мне это нужно, объяснять долго и, думаю, что не интересно никому. К настоящему времени немного разобрался с некоторыми проблемами. Переделал необходимую мне часть проекта из целого листинга в схемно-листинговый вариант. Налицо непонимание между мной и компилятором. Я понимаю, что компилятор не воспринимает "рваный" клок, но он мне таким и нужен. И его необходимо сгенерировать из 768Fs, а затем привязать к нему исходные данные.

Постараюсь сформулировать свои вопросы конкретно:

1) Имеет ли право на жизнь использованный мной алгоритм привязки данных к новому тактовому сигналу? Я его описывал в первом сообщении. На всякий случай, вот ссылка на архив с проектом из Квартуса 9.1: http://narod.ru/disk/15522786000/tim_reg.rar.html Сюда такой большой файл выложить не получается.

2) Откуда могут появляться иголки длительностью 0.1 ns без привязки к какому либо сигналу? Самое интересное, что для серии MAX7000S этих иголок не возникает, а для Stratix иголками усеяны выходные сигналы данных.

3) Как мне объяснить компилятору, что такой-то сигнал должен быть таким - синтезированным и "рваным"? Как ему объяснить, что фиксирующий регистр не требует наносекундных задержек, и для него допустима задержка, например, 1 микросекунда?

 

Заранее благодарен.

 

[EvgenyNik 0]

Иголки генерируются там, где выходные сигналы образованы комбинаторной логикой на лету, а не тактируются уже в установившемся состоянии.

Грубо говоря, некрасиво делать так:

always @ (posedge clk or negedge rst)
    begin
    if (~rst) /*...*/
    else        
        if (load_req)
            begin
            opt_load <= 1; 
            /* ... */
             end
        if (pps & (~pps_lock))
            begin
            pps_lock <= 1; 
            /* ... */
             end
        else    /*...*/
    end
assign start = pps_lock & opt_load & (sum > 32);

Правильнее так:

        if (... & (sum > 32))
            begin
            start <= 1; 
            /* ... */
             end

Хотя, правильность определяется дальнейшим применением этого сигнала.

[lhl 0]

В общем, практически во всем разобрался. Иголки возникают в момент переключения мультиплексора, но почему-то всегда во время переключения с "1" в "1", либо с "0" в "0". Эту проблему снимает синхронный мультиплексор, и это понятно. :) Компилятору оказалось возможным объяснить требования по таймингам для любой внутренней цепи - съел синтезированный "рваный" клок и не подавился. Исправил небольшую досадную ошибку в алгоритме и наступила полная идиллия с полным функционированием, и даже высвобождением (!) макроячеек. Буду развивать идею дальше. :)