Ensamblaje de SoC con conocimiento físico

Solíamos sentirnos cómodos con la idea de que los mundos del diseño lógico y la implementación física podían separarse en gran medida. Tira el diseño lógico por la borda y los equipos de síntesis y P&R se encargarían del resto. Esa idea recibió un pequeño golpe cuando nos dimos cuenta de que la síntesis tenía que volverse físicamente consciente. Los proveedores de herramientas de síntesis dieron un paso adelante y ahora pueden optimizar las restricciones del plano de planta. ¿Problema resuelto? No exactamente. Ahora necesitamos un ensamblaje de SoC físicamente consciente, ya que las restricciones físicas se entrometen en el diseño de SoC.

Restricciones de administración de energía

Una razón ampliamente reconocida de este cambio se debe a las islas de potencia y voltaje. Estos deben ser impulsados ​​por buses de alimentación apropiados, conectados a reguladores de voltaje o fuentes de alimentación externas. Esta es una restricción muy física. ¿Así que lo que? Usted decide qué bloques deben ir en qué dominios y pasa esa información al equipo de implementación. Ellos se encargarán del plano de planta y de los autobuses eléctricos. Pero aquí está el problema. Los SoC modernos pueden necesitar cientos de estos dominios, que evolucionan y cambian a medida que evoluciona el diseño y se refina la optimización de energía.

Los buses de energía deben consolidarse entre dominios con requisitos de energía comunes para minimizar la sobrecarga de área y congestión que viene con estos buses y reguladores. Esto también implica que las funciones consolidadas bajo buses comunes deben estar juntas en el plano. Lo que se traduce en la recopilación de funciones dentro de un grupo en un nivel adicional de jerarquía para simplificar la vida del equipo de desarrollo de la UPF, el equipo de verificación y el equipo de implementación. Por otra parte, tal vez alguna subfunción de una IP deba estar en un dominio diferente al resto de la IP, por lo que debe reestructurar esa parte en un grupo diferente. Estos cambios no son decisiones de una sola vez. Las optimizaciones de jerarquía para el poder pueden permanecer algo fluidas hasta que sepa que está alcanzando sus objetivos de poder. A veces bastante tarde en el cronograma de diseño.

Reutilización de subsistemas

A menudo pensamos en la reutilización en términos de IP. Bloques suministrados comercialmente o funciones internas probadas. Sin embargo, la reutilización es igual de importante, quizás más importante, para los subsistemas prediseñados, aunque normalmente no como una reutilización exacta. Algunos cambios que puede necesitar hacer aquí están nuevamente impulsados ​​por las opciones de administración de energía. Tal vez las elecciones de jerarquía que hizo para un diseño anterior no sean del todo correctas para un derivado y deban modificarse. Algunas funciones que estaban en un dominio siempre activo deben pasar a un dominio conmutado, y algunas funciones conmutadas ahora deben estar siempre activas.

A veces, la necesidad de mover funciones en la jerarquía no está motivada por el poder. Piense en un subsistema de memoria, por ejemplo. Diseñado, depurado y probado en el campo en su primer lanzamiento de producto. Quiere usar el mismo subsistema en un producto derivado. Pero de la forma en que esto va al plano de planta, DDR PHY estará orientado hacia el diseño, no hacia el borde del troquel. Una vez más, le gustaría realizar una reestructuración para simplificar el traslado de esto en la implementación.

Asamblea de reestructuración

RTL es muy poderoso, pero un área en la que realmente falla es la flexibilidad en la jerarquía de diseño. Una vez que ha definido una jerarquía, se vuelve muy difícil cambiarla. Para cambios simples, podría considerar la creación de secuencias de comandos, pero ese enfoque se agota rápidamente. Intente mover dos instancias de un bloque a un bloque diferente en el mismo nivel. Deberá unir algunas conexiones con bandas elásticas al bloque original, posiblemente a través de nuevos puertos. O poder sustituir algunos por conexiones directas en el segundo bloque. Luego, deberá eliminar los puertos redundantes en ambos bloques. Etcétera.

La complejidad de mover funciones en una jerarquía se hace evidente rápidamente. Los enfoques basados ​​en guiones son simplemente demasiado difíciles. La sintaxis de SystemVerilog o VHDL agrava aún más el problema. Estas son transformaciones que requieren un conocimiento y validación serios de EDA en múltiples clientes. Aún debe ejecutar la verificación de equivalencia entre las netlists antes y después para verificar dos veces. Pero quiere que eso sea una confirmación, no un paso en un ciclo interminable de correcciones.

El Producto de desarrollo Arteris IP SoC/interfaz hardware-software (HSI) proporciona soporte automatizado para esta reestructuración en el ensamblaje de SoC. Probado en muchos diseños. Haga de estas transformaciones complejas una oportunidad diferenciada para su equipo de producto, no un obstáculo.

Comparte esta publicación a través de: Fuente: https://semiwiki.com/ip/304204-physical-aware-soc-assembly/