Алгоритм привязки данных, Не хочет работать Опции

[LHL]

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

Делаю проект в 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, но мне не нравится такое поведение. Более того, если в проект добавляю дополнительные модули, количество "иголок" увеличивается, а поведение при симуляции вообще не поддается анализу. Алгоритм перестает работать.
Существует ли какой-то нормальный алгоритм перепривязки данных, который компилятор воспринимает рабочим?

[LHL]

Простите, я, видимо, плохо объяснил, что мне требуется. Прикрепляю изображение. Исходные сигналы идут фреймами (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 микросекунда?

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