Nick_K

За программным решением Вы не туда пишете. Тут находятся в основном схемотехники и разработчики цифровой аппаратуры. Программисты - это Stuck Overflow и прочие пайтоно-вебчики. По поводу решения Вашего вопроса - погуглите информацию по вопросу защиты от дребезга контактов. По сути это то же самое, только в меньшем масштабе. Из быстрого наткнулся на статью http://www.labbookpages.co.uk/electronics/debounce.html Там на картинках показывают как и зачем, правда привязка к одноразовому действию, но можно применить и к циклическим изменениям (частоты).

Это лично Ваше мнение. Но видимо маркетологи и начальство разбираются больше и их вполне устраивает текущее положение дел. Более того добавлю - сейчас в некотором роде случился дефицит минимальных ПЛИС и я знаю одну контору, которая планирует зайти на рынок конфигурируемой логики с порядка 200-300 лутами на чипе.

Во-первых я не уследил, что разговор идёт именно о каком-то конкретном чипе. Во-вторых клок автоматически не разводится через BUFH. Эти буферы предназначены (в автоматическом плейсинге) только для передачи чувствительных к времянке сигналов в большие фанаут неты/распределённые компоненты и т.п. (например сигнал enable в очень большую RAM будет проходить через такой буфер, так как он усилит сигнал для большого количества bram и непонятно как будет "размазана" память по кристаллу). Сюда же я думаю можно отнести и BUFM. Она явно имеет некое проприетарное значение и просто так в клок не пихается от нечего делать. По поводу влияния буферов на времянку. Если говорить про обычные клоковые буферы BUFG, то наличие оных, наоборот способствует лучшей времянке, так как у клок дерева большой фанаут и нужно накачать до соответствующего напряжения все цепи. Возможно в цепи есть промежуточные клоковые буферы, но видимо к ним нет доступа с юзерспейса. Поэтому вы неправильно поняти эту часть. Проблема начинается, когда в стандартное клоковое дерево начинают вставлять пользовательские элементы, как BUFH или вообще комбинаторику. Первое - временные характеристики этих компонентов уступают значениям стандартного PLL и BUFH, поэтому уже поплывёт времянка (как минимум джиттер, как максимум задержка). Второе - чтобы прокинуть клоки через неклоковые пути, нужно воспользоваться нетами, которые стандартно там не задействованы. У них могут быть и геометрические->электрические характеристики другие. И она запросто будут делать круг-другой, чтобы попасть в нужную матрицу интерконнекта, которая сможет вывести нужные сигналы именно в клоковые пины приёмной части. Я не знаю, смотрели ли Вы, как плейсится на кристалл кастомная частота, но точно могу сказать - там лабиринты ещё те. И первое и второе приводит к потере скорости впринципе. То есть я не говорю, что буферы зло - просто в ПЛИС есть возможности сделать, но так как решение не совсем стандартное, приходится чем-то жертвовать. Если подытожить, да буферы не ухудшают времянку, если это стандартные компоненты или разработка ASIC (там свои нюансы, но всё же), а наоборот способствуют стабильному напряжению и усиливают клок сигнал на большие фанаут цепи. Но если в цепь клока вставлять непреспособленные для этого элементы стандартным поведением, будет ухудшение в связи с различием физических параметров и топологических особенностей.

А окей. Я с Ультраскейлами не работал никогда. Может в больших чипах так и есть. Я говорил из опыта обычных Спартанов/Артиксов/Кинтексов. Может в больших камнях и вправду прикрутили См. выше. В начальных семействах именно так и есть. Если смотреть с точки клоков. Буферов именно для клока не так и много.

Вот вообще нет от слова совсем. В ПЛИСах все клоковые деревья построены по типу H-дерева. Да у них есть возможность обрезать ненужные ветки, но на этом сходство заканчивается. И skew в ПЛИСах одинаковая всегда и везде, потому что одинаковое количество точек разветвления к каждому FF. Для памятей/DSP может как-то хитрее, но думаю тоже самое будет. В АЗИКах же синтез clock-tree это скил на уровне синтеза или place&root. Тут может быть и полезная skew и выборка значений фанаута и инверсные промежутки дерева (когда по falling_edge). Та даже понятие hold violation, которое для FPGA вообще неизвестно, встречается сплошь и рядом... А это эще тот гемор. Относительно отключения частоты на элементы, для ПЛИС не так просто. Если мне не изменяет память, то в FPGA стоит ровно один клок буфер (который, кажется, CBUF у Xilinx) на банк. Он даёт лучшую времянку в пределах ПЛИС. Соответственно если получится запихнуть нужную логику в отдельный банк - тогда проблем не будет. Есть ещё возможность пропустить клок через HBUF (тоже для Xilinx), их больше - порядка 12 на банку, но и времянка страдает у них значительнее.

Вопрос немного заглох, но решение не самое лучшее, так как я надеялся всё-же ограничить область размещения, а не "словить" удачное размещение на переборе Сидов и потом просто заморозить... И да в Лайте не работает, а в Про нет нужного камня (получилось запустить на более старой версии, но там тоже с камнем вопросы небольшие). За наводку в любом случае спасибо, но по-видимому без переделки RTL не обойтись - Ква упорно не хочет паковать неординарное описание сумматоров в DSP, что очень раздувает комбинационную часть. Не знаю, но есть предположение по каждому компоненту_его_параметры. В Genus вообще раздутие модулей происходит индивидуально для каждого, даже при условии одинаковых параметров - мол так можно оптимизировать каждый по-разному.

Недавно поднимал тему - обьявление сигналов как (* keep = 1 *) или /* synthesis keep */ должны предотвратить оптимизацию (второй вариант у меня почему-то не работал). Но повторюсь - это очень плохое решение и может вызвать неординарное раздутие проекта, потому что протрейсить 32 net'а ещё та задачка.

Для начала: Вы смотрите пост-элаборейт схематик. А тут может быть нарисовано всё что угодно и как угодно, лишь бы красиво и понятно. Чтобы понимать реальность, нужно смотреть пост-синтез схематик. Там скорее всего нет такой чёткой иерархии, но там будет видно куда именно цепляется сигналтап. Возможно во время оптимизации и горячо любимого Альтерой флаттеринга, меняется расстановка или реордерится какая-то логика. В результате будут разные значения. Второй момент: а действительно вот так жизненно необходимо передавать именно число частоты? Нельзя ли как-то закодировать значения передаваемых частот (2'b00 = 200МГц, 2'b01 = 100МГц и т.д.), а на приёмной стороне уже сделать необходимую подстановку констант. Я очень сомневаюсь, что это число у Вас сильно варьируется, а вот гонять по кристаллу на 99% пустую 32-х битную шину - это глупо как минимум. По этой же причине, возможно, инструмент оказался хитрее и сам оптимизировал-закодировал передаваемые значения (код 00...0h приравнивается к 200kk).

Наличие дефолтного состояния подсказало синтезатору. Не забывайте, что синтезатор не Ква/Хилых и целевай борда не плис. В прототипе на Альтере всё было ок, кстати.

А сори, опечатка. Там нормально всё было кроме одного состояния кейса. Это я когда писал под вечер уже невнимательный стал)

Именно такие. Там весь прикол ,что в одном из стейтов внутри if-а не был задействован объявленный сигнал. Вот и генерился латч. Где-то так: always @(clk) begin net1 <= '0; net2 <= '0; if (reset) begin net1 <= '0; net2 <= '0; end else begin case (net3) 2'b00: begin net1 <= '0; net2 <= '0; end 2'b01: begin net1 <= 2'b01; net2 <= 2'b10; end 2'b10: begin net1 <= 2'b10; end default: begin net1 <= 2'b00; net2 <= 2'b01; end end end Или без дефолта, я уже точно не помню.

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

За такое я бы уже пальцы в дверь зажимал. Вы вообще понимаете, что такое ресет и почему нельзя логику пихать в состояние ресета? Второй момент, если хочется что-то этакое замутить - вынесите в функцию. И читать проще и потом редактировать. И вложенные и циклы под generate, можно всё что угодно, только правильно. И как я сказал ранее - вынесите в функцию. Вы будете удивлены, но функции для HDL и функции в Си имеют намного больше общего, чем различий (за исключением статик-автоматик). На последок, что такое "Хочу задавать полином шеснадцетеричным числом"? Это типа я программист и мне впадло разбираться? Ну или код для оных. Если очень хочется оставить совместимость, можно накрутить через макросы. Непонятно что за зверёк получится, но вполне вероятно даже будет работать.

А можно поподробнее? А то я тут колупаюсь с прототипом в котором есть очень большие АЛУшки без пайплайнов (но частота работы не высокая). И вот планируется переход на Хилых, только как-бы не сделать только хуже.

Основной вопрос отпал, прагма (* keep = 1 *) перед портами в объявлении интерфейса сработала (при том, что /* synthesis keep */ до этого не работала). Вопрос с фиксированием модулей в регионе на флорплане остаётся открытым.