Cómo elegir un núcleo IP para el diseño de SoC
Los núcleos IP se pueden proporcionar a los clientes de dos formas: núcleo blando y núcleo duro. Ambos métodos permiten a los clientes obtener diseños funcionalmente maduros. Los núcleos blandos también se denominan núcleos sintetizables y los clientes deben sintetizarlos e implementarlos en su SoC. El núcleo duro se ha implementado por completo (se ha completado el diseño del diseño) y se puede utilizar directamente para la fabricación. Técnicamente, un diseño no se realiza hasta que se produce. Pero en este caso, la implementación significa organizar el diseño y pasar directamente a producción). El equipo de SoC sólo necesita colocar el núcleo duro en el chip como si fuera un chip de circuito integrado monolítico. El núcleo blando y el núcleo duro tienen diferentes problemas y beneficios.
La integración de núcleos IP en un chip requiere muchos pasos. La facilidad con la que se puede completar este proceso depende principalmente de los resultados proporcionados. Además, los clientes deben evaluar no sólo el núcleo de IP, sino también el proveedor de IP.
Comparación entre núcleo blando y núcleo duro
1. Rendimiento
Debido a que el núcleo blando no está implementado, es inherentemente más flexible que el núcleo duro en términos de función. e implementación. Por otro lado, los desarrolladores incondicionales pueden dedicar más tiempo a optimizar sus incondicionales porque se utilizan en muchos diseños. Entonces esto hace pensar que el hardcore proporcionará un mayor rendimiento.
De hecho, los núcleos duros de alta gama, totalmente personalizados y diseñados para procesos de última generación, pueden proporcionar un mejor rendimiento que los núcleos blandos. Mediante el uso de pestillos, lógica dinámica, señales de tres estados, memorias personalizadas, etc. , un equipo de diseño totalmente personalizado puede lograr mejores resultados que un diseño integrado completamente estático. Para los SoC que necesitan alcanzar el rendimiento extremo de los procesos y tecnologías de diseño existentes, los núcleos duros totalmente personalizados pueden cumplir mejor con estos requisitos.
Sin embargo, si los objetivos de rendimiento están dentro del rango de los núcleos blandos, entonces las ventajas de los núcleos duros son irrelevantes. Los equipos de diseño de SoC pueden utilizar núcleos blandos para cumplir con los requisitos de rendimiento y aprovechar su flexibilidad inherente. Con el avance de la tecnología, el límite de frecuencia máxima de los núcleos blandos también aumenta constantemente, convirtiéndose en la elección de más diseñadores de SoC. A frecuencias de reloj más bajas, los núcleos duros pueden tener una ventaja en el área del silicio. Pero muchas veces éste no es el caso. Los núcleos duros a menudo simplemente se solidifican mediante ASIC, lo que les impide ofrecer ventajas de velocidad. En otros casos, los núcleos totalmente personalizados no se pueden volver a optimizar con cada generación de tecnología, lo que erosiona las ventajas en frecuencia y tamaño.
2. Independencia tecnológica y portabilidad
Una de las ventajas del soft core es la independencia tecnológica, es decir, Verilog o VHDL no necesitan utilizar una tecnología de proceso específica o una biblioteca de celdas estándar. . Esto significa que el mismo núcleo IP se puede utilizar en múltiples diseños o en la próxima generación de diseños existentes. Algunos proveedores de núcleo blando adoptan un estilo de diseño que hace que sus núcleos no sean técnicamente independientes, pero este enfoque no ofrece ventajas.
Figura 1: Tareas de desarrollo afectadas por los núcleos IP.
El hardcore, por otro lado, está muy centrado en la técnica. De hecho, si la fundición cambia sus parámetros de proceso o bibliotecas, es posible que el núcleo duro no funcione correctamente. Esto crea riesgos porque el proveedor de IP necesita volver a verificar el núcleo duro cuando cambian los parámetros del proceso.
Los núcleos duros se pueden migrar a nuevas tecnologías de proceso, pero volver a optimizar núcleos totalmente personalizados requiere mucho tiempo y es costoso. Para algunos núcleos de microprocesadores avanzados, puede llevar dos años o más. Por lo tanto, los núcleos duros suelen sufrir ajustes ópticos basados en nuevos procesos. Si bien este enfoque es simple y rápido, elimina muchas de las ventajas de una optimización totalmente personalizada de un proceso existente por parte del equipo de diseño.
Y el ajuste de la luz conlleva otro riesgo, porque el ajuste de la luz solo puede garantizar que el nuevo diseño cumpla con las reglas de diseño, pero no puede garantizar la sincronización o el funcionamiento precisos, y es muy difícil verificar el núcleo IP nuevamente después ajuste de luz.
3. Optimización de velocidad/área/potencia
Para la tecnología que se está implementando, los núcleos duros suelen funcionar más rápido que los núcleos blandos comparables.
Pero incluso para esta única tecnología, el núcleo duro está optimizado para un solo conjunto de objetivos. Si el objetivo es reducir el área del chip con un rendimiento razonable, entonces un núcleo duro optimizado para un rendimiento altamente ajustable puede ser demasiado grande para esta aplicación.
Los núcleos blandos se pueden "optimizar para aplicaciones". Es posible que sea necesario ajustar los objetivos de tiempo, área y potencia para adaptarse a un diseño de SoC integrado específico. Por ejemplo, si el SoC utiliza un reloj de 200 MHz, un núcleo IP suave diseñado para funcionar a 250 MHz se puede cambiar con precisión para que funcione a 200 MHz. Esto cumple con las limitaciones de diseño y al mismo tiempo logra un tamaño más pequeño y una menor potencia.
Esta optimización de la aplicación también se aplica a la sincronización de IO de bajo nivel. Las restricciones de IO de los núcleos blandos se pueden ajustar para que coincidan exactamente con el entorno en el que se utiliza el núcleo. Si el núcleo duro tiene señales de salida retrasadas, será difícil para los diseñadores de SoC mejorar la sincronización.
Si los objetivos de velocidad, área y consumo de energía del SoC son consistentes con los del núcleo duro, entonces el núcleo duro será muy competitivo. Pero para la mayoría de los diseñadores, los núcleos blandos tienen ventajas a la hora de optimizarlos para un SoC específico.
4. Personalización
En comparación con los núcleos duros, los núcleos blandos tienen otra ventaja: la personalización del tiempo de compilación. Estas son opciones de diseño previas a la implementación.
El tamaño de la memoria caché es un elemento común definido por el usuario en el momento de la compilación. Los procesadores de núcleo blando se pueden configurar exactamente de acuerdo con el tamaño de caché requerido para una aplicación integrada específica. Hardcore no es personalizable a este respecto.
Otro elemento de personalización utilizado en muchos núcleos blandos es el soporte selectivo o específico de instrucciones para instrucciones especiales. Por ejemplo, algunos SOC pueden requerir soporte de coprocesador externo. Sin embargo, en algunos sistemas que no utilizan estas funciones, se puede eliminar el hardware redundante del núcleo blando para ahorrar área y consumo de energía.
Los núcleos blandos también pueden incluir parámetros de configuración de implementación. Se trata de una personalización especial en tiempo de compilación que puede ayudar a que el núcleo blando coincida mejor con el estilo de diseño utilizado por el equipo de SoC. Por ejemplo, los núcleos de microprocesadores a menudo se implementan utilizando circuitos de reloj controlados, pero este reloj no coincide bien con algunas herramientas de enrutamiento de reloj. Los equipos de SoC pueden facilitar la implementación si el núcleo del procesador puede proporcionar una configuración de tiempo de compilación para el multiplexor (MUX) para que todos los relojes de puerta sean iguales.
5. Facilidad de integración
Es probable que el núcleo blando sea más fácil de integrar en el flujo utilizado por el equipo de diseño de SoC, a menos que el equipo de diseño interno ya haya implementado el núcleo duro. La razón es que el equipo de diseño de SoC agregará módulos RTL alrededor de su núcleo IP aprobado. Estos núcleos se parecen a otros módulos SoC y se pueden implementar como ellos.
Un núcleo duro, por otro lado, se parece más a una RAM de caja negra, especialmente cuando se implementa con tecnología completamente personalizada. Esto significa que los proveedores centrales deberán proporcionar más modelos de caja negra del núcleo para que los diseñadores de SoC puedan diseñar módulos a su alrededor. Esto en sí mismo es más difícil que usar núcleos blandos. Por ejemplo, es posible que un núcleo duro totalmente personalizado no tenga una lista de conexiones a nivel de puerta. Esto se debe a que el diseño se realiza a nivel de transistor, sin el uso de puertas lógicas. Sin embargo, es posible que el equipo de diseño necesite ejecutar una simulación funcional a nivel de puerta con sincronización posterior a la inyección, lo que será muy difícil debido a la falta de una lista de conexiones a nivel de puerta.
Términos adicionales
Un núcleo IP suave competitivo es más que una simple colección de archivos fuente Verilog o VHDL. De la misma manera, un buen núcleo duro es más que simplemente diseñar la base de datos. Los núcleos IP actuales incluyen un conjunto de entregables que permiten a los equipos de diseño de SoC integrar núcleos IP en sus diseños. El objetivo de estos proveedores adicionales es integrar núcleos IP en todos los aspectos del flujo de diseño lo más fácilmente posible.
La Figura 1 muestra las actividades de desarrollo de SoC para diferentes núcleos IP. Esto incluye entregables tanto blandos como duros.
1. Creación de documentos
La documentación clara y concisa es un requisito previo para la mayoría de los productos técnicos. Sin embargo, el número de personas que necesitan consultar los documentos básicos de propiedad intelectual varía mucho, lo que hace que la creación de documentos técnicos básicos de propiedad intelectual sea un gran desafío.
En la Figura 1, cada actividad de desarrollo tiene diferentes requisitos de documentación. Por ejemplo, los desarrolladores de software necesitan conocer la naturaleza programable del hardware, pero es posible que no les importe cómo se implementa.
Por lo tanto, un buen conjunto de documentación puede facilitar que los desarrolladores de software encuentren la información que necesitan sin verse abrumados por mucha información inútil.
Finalmente, si el equipo de SoC desea crear documentación para el SoC que pueda reutilizar parte de la documentación principal de IP, el proveedor de IP debe proporcionar archivos fuente editables y derechos de cita.
2. Comprobador de interfaz
El equipo de SoC debe diseñar una lógica para interactuar con diferentes señales y protocolos centrales IP. Para determinar si su diseño es correcto, los proveedores de IP pueden proporcionar módulos de verificación de interfaz para verificar el funcionamiento correcto de todas las señales y protocolos de la interfaz. Puede ser tan simple como validar una señal estática o tan complejo como verificar el correcto funcionamiento de un protocolo de bus multiciclo.
Estos inspectores simplifican enormemente el trabajo de los equipos de SoC al verificar automáticamente que una interfaz determinada maneja la operación correcta. En caso de procesamiento ilegal, el verificador debe informar los errores para que los diseñadores de SoC puedan identificar fácilmente la lógica defectuosa y solucionarla. Los verificadores de interfaz deben funcionar con precisión dentro del entorno de diseño de SoC. Deberían poder integrarse fácilmente en simulaciones funcionales en lugar de aparecer como hardware real.
3. Tabulador de protocolos
Otro producto que un proveedor de IP puede proporcionar para facilitar la verificación de la interfaz es un tabulador de protocolos. Este es un módulo para monitorear el procesamiento de la interfaz y puede observar varias situaciones especiales. El tabulador de protocolos guarda todos los tipos de procesamiento visibles e informa los "casos extremos" que no se ejecutaron. El proveedor de IP debe proporcionar las tablas angulares necesarias para la verificación completa de la interfaz.
Durante el proceso de desarrollo, el listado de protocolos ayudará al equipo de SoC a decidir qué casos "límites" deben verificarse. Una vez que se completa el desarrollo, también garantiza que se informe al equipo de SoC de que se han realizado todas las verificaciones de casos "límites" necesarias. Debido a que el proveedor de IP tiene el mejor conocimiento de la interfaz central, esta tabla de casos "periféricos" será mejor que cualquier cosa que el equipo de SoC pueda imaginar.
4.RAM Checker
Si el núcleo IP dispone de memoria interna de acceso aleatorio que el equipo SoC debe compilar e integrar, se pueden introducir defectos en el procesamiento. Solucionar problemas de RAM profundamente integrada puede ser muy difícil para los equipos de SoC porque a menudo implica rastrear fallas a través de módulos del kernel. El verificador de RAM puede simplificar enormemente la resolución de problemas causados por los módulos de RAM. (Es una situación muy mala cuando el equipo de SoC tiene que solucionar problemas a través de un núcleo IP. Deben poder confiar en su funcionamiento correcto).
Modelo de simulación rápida
Para SoC. Para los diseñadores, simular un SoC completo con RTL de un núcleo IP grande puede resultar muy lento. Si los proveedores de IP pueden proporcionar modelos funcionales del núcleo rápidos y con ciclos precisos, los clientes se beneficiarán de una simulación más rápida, una depuración más rápida y un uso reducido de licencias de simulación. Incluso los modelos precisos aperiódicos son lo suficientemente buenos para la mayoría de los diseños y depuraciones de SoC. Siempre que se ejecute un modelo preciso del ciclo de ejecución, podrá beneficiarse de modelos funcionales rápidos durante el desarrollo.
6.Soporte de herramientas EDA
Otro indicador de calidad del kernel es el soporte de herramientas EDA. Debido a que diferentes equipos de diseño pueden utilizar diferentes herramientas, los núcleos de alto nivel actuales a menudo proporcionan diversas formas de entregables que admiten varias herramientas EDA.
Por ejemplo, un núcleo IP se diseña utilizando Verilog, pero los clientes que utilizan herramientas y métodos EDA basados en VHDL seguirán necesitando VHDL. Si un kernel solo apunta a Verilog, los equipos de SoC deben soportar un proceso de conversión engorroso y propenso a errores al usar el kernel.
Además, el proveedor de IP debe proporcionar más formatos de los requeridos. Diferentes herramientas EDA pueden tener diferentes métodos de implementación en el formato estándar. En el ejemplo anterior, el proveedor de IP no solo puede proporcionar Verilog RTL a los clientes de Verilog, sino que también puede brindar soporte a los clientes que utilizan emuladores Verilog específicos. De lo contrario, es posible que los clientes tengan que depurar problemas de diseño relacionados con el simulador Verilog ligeramente diferente utilizado por el proveedor de IP.
Este concepto se aplica a casi todos los entregables. Para el núcleo duro, este concepto también se puede aplicar en la fase de implementación. El núcleo duro debe proporcionarse en forma de soporte de herramientas de back-end para el equipo de SoC. Los proveedores de IP deben admitir las herramientas de backend especiales utilizadas por los clientes.
Para el núcleo duro, este concepto también se aplica en la fase de implementación. El núcleo duro debe proporcionarse en una forma que las herramientas de backend del equipo de SoC puedan admitir, y el proveedor de IP debe admitir el uso de herramientas de backend específicas.
7. Ejemplos de scripts de EDA
Para ayudar a desarrollar rápidamente diversas actividades de diseño, los proveedores de IP deben proporcionar scripts de ejemplo para las herramientas EDA compatibles. Esta es otra forma en que los proveedores de IP ayudan a los equipos de SoC a utilizar eficazmente los núcleos de IP para el diseño de sistemas. Los scripts pueden ser tan simples como archivos MAKE que implementan simuladores de funciones de ensamblaje. Estos scripts también pueden ser tan complejos como un conjunto de scripts de diseño automatizados para la regresión funcional. De todos modos, los scripts de muestra siempre son útiles para los diseñadores de SoC.
Para los núcleos blandos, los scripts de síntesis de instancias son casi esenciales. Como mínimo, deberían proporcionar restricciones de alto nivel, rutas de falla y rutas de múltiples ciclos. Si es posible, se deben proporcionar simultáneamente scripts que implementen un enfoque integral de varios estándares de la industria. Por supuesto, cuanto más simples sean estos scripts de ejemplo, más fácil será para los diseñadores de SoC comprenderlos, modificarlos e integrarlos en sus flujos.
8. Verificación del núcleo funcional
Aunque los diseñadores de SoC no modifican el diseño RTL del núcleo IP suave, sí cambian algunas funciones como parte rutinaria del diseño del chip. Los ejemplos incluyen la inserción de enlaces de escaneo, el almacenamiento en caché del reloj y la integración de RAM BIST. El equipo de diseño del SoC necesita verificar que estos cambios no afecten al correcto funcionamiento del núcleo.
Una forma de verificar que un nuevo diseño no ha cambiado funcionalmente con respecto al diseño anterior es utilizar pruebas comparativas y conjuntos de pruebas proporcionados por el proveedor de IP para verificar completamente que el núcleo esté funcionando correctamente. Desafortunadamente, para muchos núcleos, el conjunto de pruebas completo es demasiado grande para proporcionarlo como parte del núcleo IP. Por lo tanto, la mayoría de los proveedores de IP eligen un subconjunto del conjunto completo de verificación que también puede verificar las operaciones. En la mayoría de los casos, este subconjunto es suficiente para encontrar los errores causados por los tipos de cambios de diseño descritos anteriormente.
Sin embargo, las herramientas de verificación formal son una forma más exhaustiva de garantizar el correcto funcionamiento. Estas herramientas pueden verificar con precisión la similitud entre diseños nuevos y antiguos. Admitir herramientas de verificación formales puede evitar que los equipos de SoC ejecuten regresiones a nivel de puerta.
9. Herramientas de desarrollo colaborativo de software
El enfoque estándar para desarrollar software para un nuevo sistema es producir primero una muestra del hardware y luego desarrollar el software para ejecutarlo. Sin embargo, en muchos casos esto prolonga el tiempo de comercialización, por lo que el desarrollo de software suele ir de la mano con el desarrollo de hardware.
El desarrollo de software requiere una simulación del sistema más rápida que el desarrollo de hardware. Por lo tanto, los proveedores de IP deben proporcionar modelos muy rápidos de funcionalidad central de IP. Esto proporciona un rendimiento suficiente para el desarrollo de firmware de bajo nivel.
Para una mayor velocidad de simulación, a veces se utiliza un emulador lógico de hardware, que es un orden de magnitud más rápido que la simulación pura (aunque todavía dos o tres órdenes de magnitud más lento que el hardware real). Estas herramientas son difíciles de usar y requieren una síntesis especial. El soporte de estas tecnologías es un requisito clave para los equipos de diseño de SoC que planean desarrollar hardware y software de forma conjunta.