Это действительно вопрос дизайна, ответ на который зависит от ваших требований. Вот несколько вещей, которые следует учитывать:
Повторное использование
Как и во многих проектах SoC, вы можете захотеть повторно использовать блоки или подсистемы из одного проекта в другой. Рекомендуется группировать модули вместе в зависимости от того, как они могут быть повторно использованы в другом контексте. Таким образом, также можно повторно использовать вспомогательные средства, отличные от проектной RTL (например, тестовые стенды, ограничения синтеза, утверждения и т. д.).
Зависимости
Это соответствует соображениям повторного использования, но подумайте о том, какие зависимости существуют между модулями. В вашем примере будет ли MMU всегда требовать ОЗУ и ПЗУ? Если да, то это аргумент в пользу их создания в mmu. Будет ли mmu работать с другим количеством типов воспоминаний? Если да, то это аргумент в пользу создания экземпляров воспоминаний вне mmu.
Область проверки
В современных проектах SoC проверка требует больше времени и ресурсов, чем сам проект. Поэтому структурируйте иерархию таким образом, чтобы она помогала, а не мешала проверке. Например, если процессор в вашем примере должен быть проверен сам по себе, процессор должен создавать экземпляры всех подкомпонентов, соединять их внутри и представлять только соответствующие порты процессора. Таким образом, среда проверки (также известная как тестовый стенд) не должна дублировать все соединения между процессором, MMU и памятью.
В общем, я думаю, что иерархическая структура (первый из двух ваших примеров) имеет смысл и является наиболее распространенной.
person
dwikle
schedule
18.09.2012