Попробую немного по-другому.
У вас есть два регистра. То, что хранится в первом, вы как-то обрабатываете и результат защёлкиваете во второй. Но на эту обработку надо больше чем один такт клока. Самое простое решение -- это использование clock enable. В первом регистре данные защёлкиваются по одному cе, во втором -- по другому. Вы формируете эти ce так, что второй ce задержан относительно первого на нужное число тактов. Формируете любым способом: сдвиговым регистром, счётчиком, FSM, главное обеспечить нужное расстояние между ce.

Поскольку один регистр полностью контролируется ce_a, а второй ce_b, то мультицикл описывается как время от ce_a до ce_b. ucf получается таким, как я написал в предыдущем посте.

Вы можете переписать ваш код так?
Если да, то тут вы формируете только cе для temp1, temp2 и temp3, а их самих выносите в отдельный always с примененим этих ce.

Этот пример понятнее. Я сделал так:
В итоге пишет что TS_MX12 и TS_MX23 успешно проходят, а вот TS_clkout_pin по-прежнему не проходит, ругается конкретно на место "temp <= temp - (sum1 * r_sin)".

Так вы можете переделать так, как я писал постом выше?

Могу, постараюсь так сделать, хотя если честно, не очень понимаю, разве то что я сделал - оно не эквивалентно Вашей схеме?

А что мешает реализовать умножение и вычитание через IPcore "Multiplier"? При создании можно выставить задержку получения результата в тактах. По опыту применения такой подход даёт стабильную работу на частотах, когда простое умножение (через символ *) уже не работает

Спасибо, мысль интересная, если там действительно можно выставить задержку. Это ведь автоматически приводит к учету этой задержки в анализаторе таймингов, верно?

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