и всем тем, кто тут предлагает "делить счетчик пополам и т.д":
кто Вам всем сказал, что разрядности счётчика или компаратора влияют на задержку выхода результата? upcounter представляет из себя конвейерную цепочку триггеров и, соответственно, работает с задержками одного триггера. Только не надо путать счетчик и сумматор. в последнем используются переносы битов, со всеми вытекающими задержками.

Вы бы хоть почитали немного о том, как устроены счётчики и что такое перенос к примеру прежде чем со своими умными замечаниями лезть...
Правильно советуют. Счётчик на 175000000 легко пилится на 2 14-разрядных параллельных счётчика. Второй счётчик получает на свой вход CE перенос от первого счётчика предварительно пропущенный через триггер дабы задержки переноса в первом счётчике не суммировались с задержками второго. Второй счётчик своим переносом (опять же протактированным) кормит всю оставшуюся часть схемы с большим fanout. Если цепь с большим fanout плохо разводится (во что я честно говоря не верю, ибо речь идёт о стратиксах 4 и частотке всего 175 МГц) то этот fanout можно уменьшить несколькими способами.
Синтезатор сам где надо навтыкает дуплицирующих триггеров.Fanout можно поменять глобально (в любом синтезаторе есть такая настройка), а можно и локально - атрибутом на конкретную цепь. Как делать - это ваш выбор. Но ничего сверхужасного, что требовало бы плясок с бубном вокруг глобальных цепей и constrains я тут не вижу. Всё тривиально.

Как минимум синтезаторы, которые последние лет 5-8, на всех современных плис синтезируют счетчики на основе ячеек аппаратных суммторов с быстрым переносом. А вот некоторые разработчики до сих пор мыслят в рамках К155, вместо примитивов целевой ПЛИС %)


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

Только давайте не будем Шерлоками Холмсами.
Любой интересующийся может в любой момент соорудить проект (или взять имеющийся) и попробовать.


Ага .
меня другое в ква удивляет : поставим Max_Fanout в 200, вот если их будет например 205, то он дуплицирует логику, на одну точку повесит 200 точек подключения, а на другую 5. Даже попытку балансировать нагрузку не предпринимает (до 9.1 версии включительно).

да что пробовать, у меня проекты с фанаутом 2000 - 3500 на третьем сыклоне под 200 МГц и нет таких проблем как у вас на стратиксе

ЗЫ. да фанауты меньше, но и сыклон не стратикс

Я не буду всех убеждать в совершенстве своего проекта - он несовершенен, и я это знаю лучше всех .

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

Вам же уже сказали %)
1. Вы не можете гарантировать точные времена задержек, у квартуса тоже нет возможности выровнять их, т.к. он этому не обучен.
2. Назначая мультицикл вы не сможете гарантировать задержку, вы всего лишь облегчаете условия выполнения tsu/th для определенного сигнала. Но это не означает что этот сигнал добежит до ВСЕХ остальных именно через такт. Почему у вас не сработало задание мультицикла для вашего проекта, по "фотографии" вылечить нельзя. Как минимум нужно посмотреть full_path отчет о tsu/th по конкретным путям.
3. Задавать max_net_delay/min_net_delay для асинхронных путей опять же бессмысленно, квартус не умеет выравнивать такие пути и эти параметры задаются скорее для успокоения совести, фиттер на них не смотрит и они даже не входят в комманду проверки валящихся путей (ну до 9.1 точно не входили, врядли что-то изменилось в 11 ой версии).

В таких условиях, в вашем случае лучше всего мультиплицировать регистры и вот тут начинается вопрос : почему у вас ква не хочет этого делать автоматически. Что бы это выяснить по "фотографии" нужны нехилые телепатические способности. Поэтому ИМХО либо ждите телепата, либо перестаньте обижаться и давайте обратную связь.

ЗЫ. если бы не стояла задача обеспечить однозначность прихода импульса на все ваши блоки, то задача решается элементартно. set_false_path + два тригера в каждом модуле, куда приходит сигнал.

ЗЫ.

лечится как раз разрешением дуплицирования логики, на автомате и этой функции квартус порой творит чудеса по утаптыванию проектов, как по времянке, так и по уменьшению ресурса(!!!)

Да какая разница какой фанаут? Это ж ПЛИС, а не АСИК. Все нагрузки уже есть и их меньше не станет в зависимости от фанаута. Для задежки важно лишь относительное расположение источника и приемников нэта.

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

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


гм... либо я не те ПЛИС пробую, либо не с тем синтезатором, либо просто отстаю от жизни...
по поводу "ячеек аппаратных сумматоров с быстрым переносом" -- это как? к примеру, у виртексов 4-5-х из основных элементов я знаю только clb-блоки, ram-блоки и блоки dsp48 (я ничего не пропустил?). И я сильно разочаровался бы, если б синтезатор сделал мне данный счётчик на dsp48. У последних имеется уйма куда более полезных применений. Но, к счастью, синтезатор от ise13.1 в 5-м виртексе и с дефолтными настройками выдал мне в качестве результата 28-ми битный upcounter на clb-блоках (проверено в "technology schematic").

В clb блоках как раз есть аппаратные ускорители цепи переноса. ug190.pdf стр. 198. Fast Lookahead Carry Logic

ага, понятно, спасибо.

Давайте я вам покажу -
см на элемент, формирующий сигнал T4 (AND4), и на элемент, формирующий сигнал TC (уже AND5). Сигнал T4 участвует в формировании сигнала TC. То есть, пока T4 не сформируется, TC не начнет формироваться. Дальше - больше. Потребуются AND6, AND7, AND8, AND9... В конце концов перенос съедается совсем. И не cможет сформироваться за период тактовой частоты.
Схемы быстрого переноса не меняют в принципе формирования переноса ничего. Также рано или поздно съедаются. Спасает задержка на такт на триггере. Появляется целый такт времени для формирования переносов.

Проверить зависимость максимальной тактовой частоты от разрядности счетчика элементарно просто.

P.S. Добавлю - задержка на такт не дается "даром". В счетчике теряется одно из состояний, т.е., если бы он был загружаемым, он не смог бы делить на любое допустимое число.

это совсем другая задержка, которая отвечает лишь за то, что счётчик тупо будет или не будет работать на выбранной тактовой частоте. 28 -- сложно судить: много это или мало но, как бы там ни было, это меньше 2^5. и, пусть даже "энды" делались бы на 2-х входовых элементах, то с оптимизацией синтезатора по скорости (как и выставлено по дефолту в ise13.1) имеем в худшем случае последовательный проход сигнала через 5 элементов, согласно рисунку:
.
Но, во-первых, мы уже давно имеем дело с четырех и более -входовых LUT'ами.
И, во-вторых, речь идет совсем о другой задержке: о задержке выдачи результата относительно времени прихода клока. И эта задержка, по-прежнему, остается равной задержке одного триггера.


угу, сейчас попробовал с теми же условиями: оптимизация по объему -- 350 МГц, оптимизация по скорости (дефолтная) -- 550 МГц.

Вы нарисовали сейчас бинарное дерево формирования преноса для n-го бита. Для формирования только одного переноса такая схема пойдёт вполне. Однако в реальной жизни для работы счётчика также необходимо сформировать переносы для ВСЕХ предыдущих n-му разрядов. Поэтому в реальности переносы формируются последовательно дабы не дуплицировать нарисованные вами бинарные деревья для КАЖДОГО разряда. Таким образом, количество "слоёв логики" необходимое для формирования м-разрядного счётчика при r-входовых LUT будет равно (м-1)/(r-1) . Вторая минус единица тут появляется потому, что один вход как раз и занят под переносы со всех младших разрядов. Для первой группы этот вход можно не пользовать (поэтому минус первая единица). Тогда к примеру для 34-разрядного счётчика и 5-входовой LUT необходимо 9 слоёв логики. С использованием цепей быстрого переноса такое реализовать на современных ПЛИСах вполне реально. Без цепей быстрого переноса частотка угробится сразу и очень сильно.