[lexx 0]

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

Возможно ли сделать  мультиплексирование (синтезируемое) между двумя masters к одному slave (sram) внутри интерфейса?

Примеров куча, но, как пишут, синтезируемыми являются только функции. 

[des00 25]

ИМХО, можно

[Nick_K 0]

2 hours ago, lexx said:

Примеров куча, но, как пишут, синтезируемыми являются только функции.

Это смотря с какой стороны посмотреть. Обычные if-else работают тоже хорошо, но вот некоторые более сложные выкрутасы могут быть недоступны. И недоступность скорее определяется не стандартом, а поддержкой внутри определённого продукта. Так что или нужно идти в документацию или просто взять попробовать.

з.ы. В интерфейсах простые конструкции синтезируются хорошо с одним НО: Нельзя делать sequential logic. То есть никаких флопов и других клоковых конструкций. Это обусловлено или стандартом или настойчивой рекомендацией, я точно не помню. Но всё что вы хотите пропустить через триггеры, оставьте в Ваших мастер-слейв модулях, а комбинаторику уже пихайте в интерфейс. Ни либо же ставьте полноценный модуль и не морочте голову.

[des00 25]

10 minutes ago, Nick_K said:

з.ы. В интерфейсах простые конструкции синтезируются хорошо с одним НО: Нельзя делать sequential logic. То есть никаких флопов и других клоковых конструкций. Это обусловлено или стандартом или настойчивой рекомендацией, я точно не помню.

ну прям, все реализуется, правда не везде эффективно.

ТС поищите на форуме посты от @druzhin он выкладывал shared bus интерфейс, в котором вся shared bus логика (включая RRA арбитра) была в интерфейсе, плюс еще некоторые интересные плюшки из мира интерфейсов он выкладывал.

ЗЫ. у меня в проектах есть интерфейс - регистровый файл на 10...400 регистров, описанный полностью в интерфейсе, снаружи доступ только по символьному имени, и ква и вивада ест без проблем)

[Nick_K 0]

43 minutes ago, des00 said:

ЗЫ. у меня в проектах есть интерфейс - регистровый файл на 10...400 регистров, описанный полностью в интерфейсе, снаружи доступ только по символьному имени, и ква и вивада ест без проблем)

Ок, значит это я где-то вычитал как настоятельную рекомендацию так не делать и принял её себе за безусловное правило... Бывает и так)

[lexx 0]

55 minutes ago, Nick_K said:

Ок, значит это я где-то вычитал как настоятельную рекомендацию так не делать и принял её себе за безусловное правило... Бывает и так)

Аналогично. У меня слишком большой зоопарк компиляторов, нужно 100% решение. Но с другой стороны - довольно много банков памяти и нужно переделать мультиплексирование между ними.

Изменено 28 сентября, 2020 пользователем lexx

[dxp 34]

5 коп. Логика внутри интерфейса синтезируется и работает. И на Quartus, и на Vivado. Раньше это использовал, но сейчас полностью от этого отказался. Ряд причин.

 

1. Если внутри интерфейса есть логика и интерфейс имеет больше двух портов (модпортов) и/или пробрасывается транзитом через модуль по иерархии, что стопудово получаются тонны предупреждений (на Q что-то типа "interface contains only dangling nets", а на V - "net does not used and will be removed", за точность текста не поручусь, но смысл понятен и примерно одинаков для обоих синтезаторов). По сути там синтезатор сначала создаёт все сигналы (модпорты и внутренние) во всех модулях, в которых так или иначе присутствует экземпляр интерфейса, а потом при оптимизации "видит", что сигналы эти не нужны и материцца на них. Поведение тупое, но повлиять на это нельзя. Хотя логика рожается правильно и всё работает.

 

2. Для параметризации количества портов использовали generate for для модпортов внутри интерфейса. Прекрасно работало. Хотя предупреждения из п.1 пёрли в полный рост. Но на Questa 10.7c это перестало работать - оказывается из языка выпилили возможность описывать модпорты внутри цикла generate. Обосновали это тем, что тут присутствует нарушение логики языка: цикл generate for создаёт ещё один уровень иерархии (ну да, там даже надо блок именовать, чтобы потом можно было ссылаться на сгенерированные модпорты), а это идеологически неверно - модпорт должен быть на том же уровне иерархии, что и основные объекты интерфейса. Вроде там ещё есть какое-то нарушение, но я запомнил только это. В общем, указанная версия квесты забривает.

 

В итоге, пришёл к такому варианту. Да, интерфейсы - очень клёвая штука, и возможность описывать внутри логику - это просто киллерфича, но имеющиеся реализации используемого синтеза таковы, что пользоваться этим без проблем не получается. Итого, делаю так: интерфейсы делаю максимально простыми - точка-точка, т.е. два модпорта, никакой логики внутри, только проброс сигналов. Удобство в том, что просто все сигналы одним пучком. Пробовал вместо интерфейсов использовать структуры - парой: одна на ввод, другая - на вывод, но оказалось очень путано и неудобно - сигналы от разных шины по сути, а с интерфейсом удобно, всё в одном месте. Такой вариант синтезируется без проблем, прост в отладке, нет массы дурацких предупреждений не по делу. И очень важно, что без проблем синтезируются массивы интерфейсов! По крайней мере в V (в Q сейчас не работаю, не знаю, как там в свежих версиях). А это позволяет легко делать параметризованные кроссбары, правда не целиком средствами интерфейсов, а в виде модулей с массивами интерфейсов. Писанины примерно столько же (ведь интерфейс -  это по сути недомодуль с дополнительными фичами), зато никаких проблем ни на симе, ни на синтезе.

[des00 25]

2 minutes ago, dxp said:

5 коп. Логика внутри интерфейса синтезируется и работает. И на Quartus, и на Vivado. Раньше это использовал, но сейчас полностью от этого отказался. Ряд причин.

Блин, точно, это же ваш был код кроссбара на форуме. Извините, запамятовал(