Может и помог бы чем, да не могу загрузить файл с проектом....

Нет МАХа или какие-то проблемы с моими файлами ?
Я загружаю в МАХе ttf.gdf, делаю его текущим (Control+Shift+J), затем жму Ctrl-L (или Start в окне компилятора), открываю окно симуклятора, тоже жму Start, затем "Open SCF".

Схема у Вас простая, но лучше бы Вы дополнили её описанием входных сигналов и требованиями к выходным:
1. Входные частоты _au и _cp примерно одного диапазона?
2. Всегда ли существуют оба сигнала частоты, один из них?
3. Сигналы управления мультиплексорами поступают синхронное с одной из входных частот?
4. Допустимо ли формировать выходные сигналы с задержкой на такт (два и т.п.) относительно входных частот?

Это он говорит, что Вы взяли все самое худшее от схемотехники на 74 серии.
Что касается глича, так Вы нестробированный перенос задействовали. Через триггер пропустите.
Кстати, у Вас и на макетке на 74 серии на этом переносе (если синхронный счетчик) такие же пички есть.

На "макетке с 74-й серией" была совсем другая схема, я же говорил - я поменял абсолютно всю концепцию.
Через триггер - попробую, но мне все равно непонятно почему эта схема прекрасно работает в симлуяторе на МАХ7000 и не работает на МАХ3000A, МАХ700S ? Некорректности в модуле LPM_COUNTER ?



Да.



Частоты существуют всегда, сигнал управления мультьиплексором - Вы про br1,br0 ? Они вообще статические, т.е. они могут меняться, но с периодом в минуты (входные частоты - десятки МГц).



Допустимо.

А я про синхронность управляющих сигналов (br[x]) относительно частот спросил вот почему - допустим, clk_au только поднялся вверх (пикосекунды какие-то), а clk_cp, например, в это время в нуле, но приходит сигнал переключения и с мультиплексора "слетает" эдакий пичок... Тоже самое про другой мультиплексор, который между одинарной и половинчатой частотами переключает.
Если на это внимания обращать не стоит, то это одно, а если важно, то так нельзя. Да и вообще, надо привыкать, что так нельзя, потому что когда-нибудь такой пичок крепко завесит какой-нибудь автомат или ещё что будет лишний раз что-нибудь делать или не делать, причём, "по настроению" и "в зависимости от фазы луны".
Поищите информацию про перенос сигналов и тактовых импульсов из одного тактового домена в другой и ваш мультиплексор станет немного сложнее, но гораздо корректнее. Тем более, что, как Вы сами говорите, задержка допустима.
P.S. выложите скриншоты ttt и t1, не у всех есть MAX+plusII...

В Квартус есть опция конвертации из МАХ+ в квартус.

В данном случае - безразлично, но я понял о чем Вы говорите.

Сейчас тут вопрос в другом - я ничего не переключаю, сигналы br[x] статические, оба нули.
И проблема (ворниги при симуляции и глитч) возникает не в том мультиплексора, а в 17-м счетчике, при использовании его выхода переноса (на нем глитч повялется, которго нет в MAX7000)
.
Если перенос не использовать - проблемы нет, но почему с переносом проблема есть в MAX3000 и в 7000S, а в MАX7000 нет ни единого ворнинга, ни глитча при симуляциии?



OK.

Потому что у Вас по умолчанию - временное моделирование. Есть определенные правила.
Нельзя комбинаторную логику на с вход триггеров подавать.
Добавите убавите в проекте - появится, скроется. для любого семейства.

Проект не синхронный. Основная проблема - использование выходов cout в качестве клоков для других счетчиков и триггеров. В вашем проекте 1 клок, выбираемый br1 из clock_au, clock_cp, после этого мультиплексора поставьте lcell, получившийся клок используйте для всех остальных элементов. Разрешение счета делайте через enable.

А насчет отсутствия проблемы в MAX7000 - просто повезло.

Т.е. лучше использовать не выход переноса а выход старшего разряда счетчика для подачи на другие счетчики ?
В таком варианте ворнингов действительно нет и при MAX3000А.



Да, все остальное к нему привязано.


Спасибо завтра попробую.

Попутно еще если можно небольшой ликбез:

1) по назначению входов/выходов на пины - их можно как угодно распределять, или есть какие-то ограничения?
2) не очень понял про отдельные пины глобальных "clock, clear, enable" и что-то еще четвертое.
На их выводы можно назначать какие-то входы/выходы?
Или они должны оставаться не занятыми?

Ограничения могут накладываться дизайном схемы и требуемыми временными характеристиками. Рекомендуется вначале спроектировать дизайн и только потом назначать выводы. Особенно, если от ПЛИС требуется максимальное быстродействие.
Можно назначать как угодно, но опять же для обеспечения максимального быстродействия рекомендуется использовать эти пины по прямому назначению, т.е. clock как глобальный тактовый сигнал, clear - как глобальный сброс и т.п. Посмотрите блочную структуру ПЛИС в даташите.

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

Про тайминги уже сказали, но это не во всех проектах требуется. С маленькими CPLD иногда не хватает внутренних интерконнектов для желаемого назначения, хотя LE полно. Бывало такое, что убедившись в том, что проект влезает, заказывали плату, а только потом назначали пины и... тут начиналось...
Я учитываю суммарную токовую нагрузку (управление светодиодами, например), импульсные синхронные нагрузки при одновременном переключении нескольких каскадов. Например, если это параллельная шина, то линии данных стараюсь делать из одного банка напряжений, а линии управления из другого, чтобы при одновременном щёлканье данными шина управления не словила чего-нибудь из-за броска напряжения на индуктивностях внутренних линий нуля и питания.
При трассировке надо учитывать межпроводниковую ёмкость и не располагать сильноточные и/или высокочастотные выходы с высокоомными входами, либо сразу же на плате их растаскивать и не вести в одной шине рядом.

Нет. Используйте cout как вход enable для других счетчиков.
Останется только сделать безглитчевый переключатель клоков.