Logic Synthesis SOC Prototyping, RTL Design Using VHDL - 2020 - Taraate - SP

Machine Translated by Google
Taraate Vaibbhav
lógica
Síntesis y
SOC
Prototipos
Diseño RTL usando VHDL
Síntesis lógica y creación de prototipos SOC
Taraate Vaibbhav
Síntesis Lógica y SOC
Prototipos
Diseño RTL usando VHDL
123
Vaibbhav Taraate 1
rupia ST
(Entrenamiento de semiconductores @ Rs. 1)
Pune, Maharastra, India
ISBN 9789811513138 ISBN 9789811513145 (libro electrónico)
https://doi.org/10.1007/9789811513145
© Springer Nature Singapore Pte Ltd. 2020 Este
trabajo está sujeto a derechos de autor. Todos los derechos están reservados por el Editor, ya sea total o
parcialmente el material, específicamente los derechos de traducción, reimpresión, reutilización de ilustraciones,
recitación, radiodifusión, reproducción en microfilmes o de cualquier otra forma física, y transmisión o almacenamiento
de información. y recuperación, adaptación electrónica, software de computadora, o por metodología similar o
diferente ahora conocida o desarrollada en el futuro.
El uso de nombres descriptivos generales, nombres registrados, marcas registradas, marcas de servicio, etc. en
esta publicación no implica, incluso en ausencia de una declaración específica, que dichos nombres estén exentos
de las leyes y reglamentos de protección pertinentes y, por lo tanto, libres para uso general.
El editor, los autores y los editores pueden asumir con seguridad que los consejos y la información de este libro se
consideran verdaderos y precisos en la fecha de publicación. Ni el editor ni los autores o los editores dan garantía,
expresa o implícita, con respecto al material contenido en este documento o por cualquier error u omisión que
pueda haberse cometido. El editor se mantiene neutral con respecto a los reclamos jurisdiccionales en mapas
publicados y afiliaciones institucionales.
Este pie de imprenta de Springer es publicado por la empresa registrada Springer Nature Singapore Pte Ltd.
La dirección de la empresa registrada es: 152 Beach Road, #2101/04 Gateway East, Singapur 189721, Singapur
Prefacio
Durante esta década, ha surgido con fuerza la necesidad de dispositivos inteligentes para el
procesamiento de datos, aplicaciones multimedia y aplicaciones inalámbricas. Debido a la
demanda de los consumidores, las principales casas de diseño están experimentando un ciclo
de diseño más corto. El verdadero desafío para las casas de diseño es lanzar los productos con
nuevas características en un lapso de tiempo más corto.
Si vemos el procesamiento de datos móviles, la IA y el aprendizaje automático, entonces
todos los días hay inventos innovadores. Para satisfacer la demanda de los consumidores, las
casas de fabricación líderes están tratando de trabajar en la automatización con las empresas EDA.
La era del SOC de alta densidad, donde la inteligencia artificial puede integrarse en los
productos y debe tener una arquitectura de baja potencia y alta velocidad, se puede realizar
utilizando los FPGA de alta densidad. Los FPGA se perfilan como los mejores candidatos para
realizar los SOC de alta densidad. Son rentables y, debido a las características programables,
se utilizan para la creación rápida de prototipos de ideas. Es como el concepto de realización de
chips utilizando los complejos FPGA.
Las empresas líderes en FPGA como Xilinx e Intel FPGA tienen potentes FPGA. La
arquitectura de los FPGA de alta densidad se encuentra en nodos de tecnología más baja de 28
nanómetros o menos. La arquitectura FPGA es compatible con el diseño de baja potencia y alta
velocidad debido a la disponibilidad de interfaces de alta velocidad, DDR en chip, USB, núcleos
de procesador y estructura de alta densidad para desarrollar la lógica personalizada.
El libro es el resultado de mi investigación en el área del diseño de SOC utilizando FPGA
Xilinx de alta densidad como Spartan3A (700K Gates), Artix7, Zynq, Pynq y muchos otros. El
libro tiene 13 capítulos y analiza la síntesis de ASIC, las restricciones de diseño, los comandos
del compilador de diseño (DC) y su uso durante la optimización. El libro también analiza las
técnicas de mejora del rendimiento para los diseños ASIC y FPGA. El libro también es útil para
comprender la síntesis de ASIC y FPGA y la creación de prototipos de SOC utilizando FPGA.
Capítulo 1 Introducción: este capítulo describe el diseño, los desafíos y el flujo de diseño de
ASIC. En este capítulo también se analizan diferentes tipos de ASIC y la arquitectura y
microarquitectura para el ASIC. Este capítulo incluso analiza los diferentes HDL, HVL y HCL.
v
usted Prefacio
Capítulo 2 Diseño de ASIC y creación de prototipos de SOC: este capítulo describe los conceptos
básicos de diseño de SOC, los componentes de SOC, el flujo de diseño de SOC y los desafíos durante
el diseño de SOC. Este capítulo incluso analiza la necesidad de creación de prototipos ASIC y el papel
de FPGA durante la creación de prototipos. Este capítulo también analiza los comandos importantes
del compilador de diseño (DC) que se utilizan durante la síntesis ASIC.
Capítulo 3 Diseño usando VHDL y pautas: este capítulo cubre las pautas de diseño de RTL usando
VHDL y escenarios de diseño importantes. Este capítulo también cubre los aspectos importantes de la
necesidad de sincronizadores, relojes controlados, habilitaciones de relojes y otros escenarios
importantes.
Capítulo 4 Escenarios de diseño VHDL y síntesis: este capítulo cubre los escenarios de diseño
RTL usando VHDL. Este capítulo es útil para comprender la síntesis del diseño RTL. En este capítulo
se explican las construcciones sintetizables importantes, su uso y los resultados de la síntesis.
Capítulo 5 Estrategias de diseño y verificación: este capítulo analiza las estrategias de diseño y
verificación para los diseños complejos. El diseño de la arquitectura, los desafíos y cuál debería ser la
estrategia durante el diseño y la verificación de RTL se analizan en este capítulo. El codificador H.264,
el diseño de la arquitectura del procesador y la estrategia para el diseño y la verificación eficientes de
RTL se elaboran con algunos escenarios importantes.
Capítulo 6 Diseño de VHDL y ajustes de RTL: este capítulo cubre la síntesis de Moore, Mealy
FSM, FSM y la mejora del rendimiento mediante ajustes de RTL. Los esquemas de arbitraje de bus y
el diseño de arquitectura y RTL para las aplicaciones de video y DSP se analizan en este capítulo.
Este capítulo incluso analiza las estrategias de diseño y la mejora del rendimiento durante la etapa
RTL. Las estrategias para el reloj y la red de reinicio también se describen en este capítulo.
Capítulo 7 Síntesis de ASIC y restricciones de diseño: este capítulo trata sobre la síntesis de ASIC
mediante Synopsys Design Compiler (DC) y el uso de los comandos de DC durante la síntesis. Este
capítulo cubre el área, el tiempo, las limitaciones y las estrategias durante la síntesis de ASIC. En este
capítulo se describen los comandos de CC utilizados con frecuencia durante la síntesis y el cierre de
temporización.
Capítulo 8 Optimización del diseño: este capítulo describe la optimización del diseño utilizando DC.
En este capítulo se analiza cómo optimizar el diseño para el nivel de bloque y chip para las restricciones
dadas con algunos ejemplos. Este capítulo es útil para comprender la optimización del diseño para
lograr el objetivo requerido.
Capítulo 9 Escenarios de optimización del diseño: este capítulo cubre los escenarios importantes
que pueden surgir durante la síntesis lógica ASIC y la optimización del diseño. El papel de DC y la
optimización para el área, la velocidad se analiza en este capítulo utilizando los comandos de DC
relevantes.
Capítulo 10 FPGA para la creación de prototipos de SOC: este capítulo analiza la arquitectura de
FPGA de alta densidad y la creación de prototipos mediante FPGA. Este capítulo es útil para
comprender los escenarios y desafíos durante el diseño de FPGA y la síntesis de FPGA para las
restricciones a nivel de chip.
Capítulo 11 Creación de prototipos con FPGA únicos y múltiples: este capítulo cubre la creación
de prototipos con FPGA únicos y múltiples, las pautas utilizadas durante la creación de prototipos, la
partición del diseño y los aspectos de síntesis, y los diferentes datos de IO.
Prefacio viii
esquemas de transferencia Incluso este capítulo es útil para comprender los ajustes de RTL durante
la fase de prototipo del SOC. En este capítulo se analiza cómo lograr el prototipo de FPGA eficiente.
Capítulo 12 Síntesis e implementación del diseño de SOC: este capítulo cubre las estrategias
de diseño, síntesis e implementación de SOC para lograr mejores resultados durante la fase de
creación de prototipos de SOC. Este capítulo cubre la síntesis de FPGA, el diseño de memoria para
FPGA, la arquitectura y los ajustes, y las conversiones requeridas durante la fase de creación de
prototipos. En este capítulo se analiza la implementación del diseño con Xilinx Vivado. Incluso el
capítulo es útil para comprender la partición del diseño.
Capítulo 13 Escenarios de prueba y depuración del SOC: este capítulo cubre las estrategias
importantes durante la prueba del SOC. En este capítulo se analizan los escenarios importantes, la
depuración y la planificación de pruebas para el prototipo que utiliza FPGA únicos y múltiples, y las
estrategias. Las diferentes metodologías de depuración y prueba y las herramientas de prueba y
depuración utilizadas durante esta fase también se tratan en este capítulo.
Como se indicó, el libro consta del diseño de la arquitectura para el ASIC/SOC y los escenarios
prácticos encontrados durante el ciclo de diseño e implementación del SOC.
El libro cubre la arquitectura FPGA de los dispositivos Xilinx y la preparación de la placa. El libro es
útil para los ingenieros de pregrado y posgrado, diseñadores de SOC, diseñadores de RTL,
diseñadores de sistemas e ingenieros de prototipos de SOC como libro de referencia.
Taraate Vaibbhav
Emprendedor y Mentor
1 rupia ST
Puno, India
Expresiones de gratitud
El libro es resultado de mi trabajo en el área de diseños de FPGA, ASIC y SOC. El libro es
posible gracias a la ayuda de muchas personas. Estoy agradecido con los ingenieros de
diseño con quienes compartí mis pensamientos en varias corporaciones multinacionales.
Estoy agradecido con todos esos empresarios, ingenieros de diseño/verificación y gerentes
con quienes trabajé en el pasado durante casi 18 años.
Estoy agradecido con el personal de Springer Nature, especialmente con Swati Meherishi,
Parimel, Rini Christy y Ashok Kumar por su gran apoyo.
Estoy agradecido con mi esposa Somi y mi querido amigo Kaju por su gran apoyo y
buenos deseos durante este período. Agradecido con mi hijo Siddhesh y mi hija Kajal por sus
maravillosas ideas al crear el esquema de este libro.
Agradecido con mis alumnos Nikhil, Akshat, Vishwanath por asistir a mis sesiones sobre
VHDL y FPGA. Han contribuido indirectamente en este libro expresando sus ideas
innovadoras para implementar las IP y los productos.
¡Un agradecimiento especial de antemano a todos los lectores e ingenieros por comprar,
leer y disfrutar de este libro!
ix
Contenido
1 Introducción ..................................................
1.1 Diseño ASIC ..............................................
1 1 1.1.1 Tipos
4 1.2 D esafíos
de ASIC [d3] .........................
e diseño ............................... 5 1.3 Flujo
de diseño A SIC ... ..........................
Lenguajes de descripción de 6h 1ardware .......................
.4 ¿Necesidad de HDL? 11 111
1.5
.6
Construcción de hardware y diseño IP .............. .. .. 12 1.7 Desafíos y
áreas de diseño de ASIC/SOC .................. 13 1.8 Puntos importantes para
....................................
concluir el capítulo ............. .. 14 _
2 Diseño de ASIC y creación de prototipos de SOC ......... 15 2.1 Diseño de
SOC .................. .......... 15 2.2 Flujo de diseño del SOC .......................... .... .....
17 2.2.1 Especificaciones de diseño y arquitectura del sistema ..... 18 2.2.2
Diseño de RTL y verificación
verificación funcional ...........
de tiempo ..... ......... 19 2.2.3
20 Diseño Síntesis
físico y y
verificación ............... 20 Prototipo y prueba ............. .... ........ 20
2.2.4
2.2.5
2.3 Prototipos y desafíos del SOC ........................... 20 2.4 Prototipos del
ASIC .................... ...... 22 2.5 Comandos importantes del compilador de
diseño (capítulo ...... ..........
DC) ...... 25 2.6 Puntos 25 Rieferencias ............................................. .......
mportantes para concluir el
28
3 Diseño utilizando VHDL y directrices .......................... 29 3.1 Directrices de
diseño RTL ............... . ............. 29 3.2 Escenarios prácticos de diseño de
RTL ...................... 30 3.2.1 Lista de sensibilidad incompleta . ..................
30 3.2.2 Caso versus sientoncessi no .................... 32 _
xi
xi Contenido
3.3 Agrupación de los términos .......................... 34 3.4 Buses triestado y
lógica ......... ... ..........
Sincronizador 3 d6
e 3
n.5 Compartir recursos .......................... ... ...
ivel ................................
40 3.7 Relojes 37 3.6
sincronizados .... ... ............................. 42
reloj .............. ... ................... 43 3.8
3.9 Habilitación
Puntos del para concluir
importantes
el capítulo ................ 44 Referencia .. ... .......................................... 45
4 Síntesis y escenarios de diseño de VHDL ................. 47 Convertidores de código
4.1 y dominio de reloj múltiple ...... 47 4.1 .1 Código binario a código Gray
Convertidor ................ 47 4.1.2
binario .................. 48 C4onvertidor
.2 Síntesis dpe
código
ara Gray a
arquitectura
múltiple .. ................... 49 4.3 Definición y síntesis de
señales ........................... ....
51 45.4
síntesis .......................... 2 A
4signación
.5 Bloques dd
e variables
e
procesos y múltiples y
síntesis ..... 5 3
4 .6 S íntesis p ara I fthenelse a nidado ...........................
Construcción y síntesis de casos ....... ...... ............ 57 Lógica de 55 4.7
prioridad u sando c onstrucciones s intetizables ............ 5 8
4 .8 S íntesis
lógica de paridad ........ ...... ........... 60 4.10 Diseño y síntesis basados d e la
en pestillos ..................
6 1 4 .11 R egistros y
s íntesis P IPO .......... ...................
63 4.12 Síntesis e inferencia lógica del registro de desplazamiento ........
64 4.13 Puntos
Lógica yimportantes
síntesis de pdara
etección
concluir de eflancos.. ...................
capítulo ................ 666
l 5 4.14 Yo
Referencia ........................... ...................
67
4.9
5 Estrategias de diseño y verificación ................................ 69 Estrategias de
diseño para diseños complejos ........... ... .... 69 71 Estudio de
5.1 5.2 Estrategias de diseño RTL para SOC ........................... 5.3 5.4
caso de arquitectura de procesador [1] .................. 73 Arquitectura
de procesador y microarquitectura ......... ... 75 5.4.1
Microarquitectura
diseño de del
alto
procesador ..................
nivel de RTL [1 ] ......... .. .....
77 5.5 S8íntesis
4 5.5.1 y
Diseño a nivel de bloque ........................... 84 5.5.2 Diseño a nivel
superior ... .. ..................
85
SOC .................. Estrategias
85 para la Verificación
Puntos importantes para concluir del el
capítulo ................
87 8 7 R eferencia ........................... .. ...................
5.6
5.7
Contenido XIII
6 Diseño de VHDL y ajustes de RTL ........................... 89 Estrategias de
6.1 restablecimiento .............. ........... 90 6.1.1 Restablecimiento
asíncrono .......................
90 6.1.2
síncrono ....................... 9R1
establecimiento
estado ............... ..... ...............
Máquinas de 92 6.2.1
Máquina dMealy ................................
e Moore ........................ ...
993
2 66.3
.2 D
.2 Máquina
Moore ...... ...... ...........
iseño RTL
94 d6e
.4
la
DM iseño
áquina
6.2 RTL de Mealy Machine ....................... 96
de FSM ... ................... 6.5
99 Síntesis
6.6 y optimización
Transferencia de datos
y diseño del árbitro .................. ....
99 6.6 .1 Arbitraje
bus ............................ de
100 6.7 Diseños
basados en DSP y estrategias
recomendados
RTL ....... .......
de R1TL .........................
04 6.8 Ajustes 106
6.9 Puntos importantes para concluir el capítulo ..... ...........
Referencia .............................. ....... ........
106
107
7 Síntesis de ASIC y restricciones de diseño .................. 109 Diseño de particiones
7.1 para diseños complejos .................. 109 111
7.2 Síntesis ASIC ............................................. 7.3
Síntesis usando Design Compiler (DC) .................. 113 7.4 Comandos
DC usados durante la síntesis .................. 114 7.4. 1 Comandos DC para leer
el diseño ........ 116 7.4.2 Comandos DC para comprobar el diseño ........
116 7.4.3 Comandos DC para Definir sesgo ........... 117 7.4.4 Comandos
de CC para especificar el retardo de entrada y salida ............... . ...............
118
7.4.5 Comandos DC para especificar el retardo mínimo (Min) y máximo
(Max) ................ . 118 7.4.6 Comando utilizado para realizar
la síntesis ........... 119 7.4.7 Comando DC para guardar el
diseño ............... 120 7.5 Restricciones de optimización del
diseño y script básico .......... 120 7.6 Latencia de red de
reloj .................................. 122 7.7 Reloj generado .......................................
123 7.8 reloj .......................... .........
Muxing de reloj y rutas falsas ...... .................. 123 7.9
1A24
124 7.10 Rutas multiciclo ctivación del
7.11 Puntos
importantes para concluir el capítulo ................ 125
Referencia ........... . . ............................. 126
....................................
8 Optimización del diseño .......................................... 127
8.1 Restricciones de diseño y síntesis de ASIC .................. 127
8.1.1 Síntesis y restricciones a nivel de bloque ........... 129 Síntesis
8.1.2 y restricciones a nivel de chip ........... 131
xiv Contenido
8.2 Restricciones de reglas de diseño (DRC) ....................... 133 8.2.1
max_fanout .................. ............... 133 8.2.2 max_transition ................................
133 8.2 .3 m ax_capacitance ................................
optimización .................. ........... 134 Restricciones de
135 8.3.1
establecer_no_usar ........................... 136 8.3.2 set_dont_touch ..........................
136 8.3.3 set_prefer ................ . ...............
137 8.3.4 Comando para
8.3 el Aplanamiento del Diseño ............. 137 8.3.5 Comandos Utilizados para la
Estructuración .... . ..........
138 8.3.6
138 8.4 Optimización de FCSM ........... . .....................
omandos Agrupar y Desagrupar ..................
139 8.5 Puntos
importantes para concluir el capítulo .................. 140 140
Referencia .. . .............................................
9 Escenarios de Optimización de Diseño ............................... 141
9.1 ¿Dónde está el problema en la optimización? ................... 9.2 9.3 141
Estrategias de optimización de diseño para el SOC ............... 143 Estrategias
de compilación ........................... ... 144 9.3.1 Compilaciones de arriba hacia
abajo .................. 144
9.3.2 Compilación de abajo hacia arriba .................. 144
9.4 Estrategias para la Optimización de Área .......................... 145 9.4.1 No Usar
Lógica Combinacional como Bloque Individual ..... ...... .................................
146 9.4.2 No
Uso utilice
del Glue
atributo Logic entre dos módulos ....
set_max_area .. ............... 147
147 9.4.3
9.4.4
Área
de informe ....................... ...... 148 Estrategias para la optimización del tiempo
y la
mejora del rendimiento ........................... 148 9.5.1 Compilación de diseño con
'map_effort_high' ....... 149 9.5.2 Uso del comando group_path ..................
9.5 149 9.5.3 Análisis de tiempo de configuración y comprobación .. . ............ 152
9.5.4 Análisis y comprobación del tiempo de retención ......... 153 9.5.5
Caracterización de submódulos ....... ............
registros ......................... 155 9.5.7 1R
55 9.5.6
utas Equilibrio de
multiciclo . ..........................
156 9.6 Puntos importantes para concluir el capítulo ................. 157
Referencias ............................................. 158
10 FPGA para la creación de prototipos de SOC ................. 159 10.1 FPGA de la serie Xilinx
7 ........... ..................... 159 10.1.1 Arquitectura CLB de la serie Xilinx 7 ................. 161
10.1.2 Xilinx 7 RAM de bloque de la serie ........... 163 10.1.3 DSP de la serie
Xilinx 7 .................. ... 166
Contenido XV
10.1.4 Reloj de la serie Xilinx 7 ........................ 169 10.1.5 E/S de la
serie XILINX 7 .............. .......... 170 10.1.6 Transceptores de la serie
Xilinx 7 .................. 170 10.1.7 IP integradas ...... ......................... 172
10.1.8 Monitor integrado ................ . ......... 173 10.2 Flujo de síntesis
e implementación [2] ..................
lógica 1u73
10.2.1
sando ¿Cómo se m
CLB? ............ apea
174 la
10.2.2
¿Cómo se asignan los bloques DSP? .......... 175 10.2.3 ¿Cómo se mapean
los bloques de memoria dentro de FPGA?... 175 10.3 Las técnicas
para una mejor optimización ........... ... 176 10.3.1 Multiplicadores y
uso compartido de recursos ......... 176 10.3.2 Duplicación de lógica
para la lógica de decodificación más grande .. 177 10.4 Estrategias para la
creación de prototipos de SOC .... .......... 179 10.5 Puntos importantes
para concluir el capítulo ................ 180
Referencias ..... .......................................... 181
11 Creación de prototipos con FPGA únicas y múltiples .................. 183 11.1
Elección de la FPGA de destino ............... ..... 183 11.2 Creación de prototipos
de SOC con un solo FPGA ..... 185 11.3 ¿Cómo reducir el riesgo durante la
creación de prototipos? .......... 186 11.4 Creación de prototipos usando
múltiples FPGA .................. 187 11.5 Interconexiones diferidas .......... ...........
189 11.6 Temporización de retardo a bordo
Estrategias y[ 1] ...................... . ....
190 11.7
Directrices para el Prototipado
Eficiente ....... 193 11.7.1 Directrices Generales y Planificación de Proyectos
[1]....... 193 11.7.2 Planificación de OI y Estrategias para Minimizar Pin
Recuento [1] ............................. 194 11.8 Planificación y restricciones
de IO [1] ....... . ............... 196 11.9 Puntos importantes para concluir
el capítulo .................. 198
Referencias ........ . .................................... 199
12 Síntesis e implementación del diseño SOC .................. 201 12.1 Particiones y
objetivos del diseño .......................... .. .. 202 12.2 Desafíos en el diseño de
particiones .................... 203 12.3 Cómo superar los desafíos de particiones
[1] ......... 205 12.3 .1 Nivel de arquitectura ....................... 205 12.3.2 Síntesis
a nivel de Netlist [1] ...... ... ......... 206 12.4 Necesidad de las
herramientas EDA para el diseño de particiones [1] ...... 209 12.4.1
Partición manual ............ ... .......... 209 12.4.2 Particionamiento
automático ......... 210 211
12.5 Síntesis para el mejor resultado del prototipo [1] ............
12.5.1 Síntesis rápida para la estimación inicial de ...... 211
recursos 12.5.2 Síntesis incremental ....................... 212
xvi Contenido
12.6 Restricciones y síntesis para diseños de FPGA [1]........... 212 12.7
Síntesis de almohadilla de E/S para FPGA ........... .... 217 12.8 ¿Qué
cuidados debo tener durante la síntesis y la creación de
prototipos? .......................... 217 12.8.1 Evitar el uso de pestillos
217 12.8.2 Evitar rutas combinadas .......................
más largas 217 12.8.3 Evite
los
bucles combinados .................. 219 12.8.4 U.............
tilice
envolturas .................. ........ 219 12.8.5 Modelado de
memoria ......................... 220 12.8.6 Uso de generadores
centrales .. .................... 220 12.8.7 Verificación
formal .......................... 220 12.8.8 Bloques que no se mapean en
el FPGA .................. 220 12.8.9 Mejor diseño de arquitectura ...........
221 12.8. 10 Usar la lógica del reloj en el NIVEL
SUPERIOR ............... 221 12.8.11 Enfoque de abajo hacia
arriba ............... .... .. 221 12.9 Puntos importantes para concluir el
capítulo .................
221
Referencia ................................................ 222
13 Escenarios de prueba y depuración del SOC ........................... 223 13.1 Diseño y
consideraciones del SOC ........... ............ 223 13.2 Desafíos de creación de
prototipos y cómo superarlos? ...... 225 13.3 Arquitectura de FPGA múltiple factores
y
limitantes ........ 226 13.4 Presentación de la placa y qué probar? 227 13.5 Plan de
depuración y lista de verificación ................. 227 .....................
13.5.1 Pruebas básicas para el
FPGA ........ ............ 229 13.5.2 Pruebas de placa adicional ........................... 229
13.5.3 Pruebas los buses del analizador lógico externo .......... 229 13.5.4
Conectividad de FPGA múltiple y p rueba
para darticionamiento
el p e E/S ...... 229 1d3.5.5
Prueba
e FPGA
múltiple ...... .. .. 229 13.6 Cuáles son los diferentes problemas en las
placas FPGA ........... 230 13.7 Pruebas para la interfaz FPGA
múltiple ........... 230 13.8 Lógica de depuración y uso de analizadores
lógicos ............... 233 13.8.1 Sondeo mediante pines de E/S ............... ...
Uso del Test 233 13.8.2
MUX ............................... 234 13.8.3 Uso del Analizador
(para
Lógico:
Detectar
Escenario
los Datos
Práctico
paquete está dañado) ........... 234 13.8.4 Osciloscopio para depurar el
diseño ............... 235 13.8.5 Depuración 13.9
cV
on
erificación
núcleos ILA ... ... ............
y depuración a n2ivel 36
del sistema ......... 238 13.9.1 Coverificación de hardware/software .. ... ... ......
238 13.9.2 Transactores y modelado a nivel de transacción ...... 239
Contenido xviii
13.10 SOC Prototyping Future ................................ 239 13.11 Puntos importantes
para concluir el capítulo .......... ...... 240 Referencias .......................................... ... ...
240
Apéndice: Familia de la serie Xilinx 7 ............................... 241
Índice ............................................... .... .245 _
Sobre el Autor
Vaibbhav Taraate es empresario y mentor en "1 Rupee ST". Él tiene un BE
(Electrónica) de la Universidad de Shivaji, Kolhapur, en 1995 y obtuvo una medalla de oro
por ocupar el primer lugar en todas las ramas de la ingeniería. Ha completado su M.Tech.
(Aerospace Control and Guidance) en 1999 de IIT Bombay. Tiene más de 18 años de
experiencia en diseño semipersonalizado de ASIC y FPGA, principalmente utilizando
lenguajes HDL como Verilog y VHDL. Ha trabajado con pocas corporaciones multinacionales
como consultor, ingeniero de diseño senior y gerente técnico. Sus áreas de especialización
incluyen diseño RTL con VHDL, diseño RTL con Verilog, diseño complejo basado en FPGA,
diseño de bajo consumo, síntesis/optimización, análisis de tiempo estático, diseño de
sistemas con microprocesadores, diseños VLSI de alta velocidad y diseño de arquitectura
de SOC complejos. .
xix
Capítulo 1
Introducción
“La complejidad del diseño ASIC ha crecido exponencialmente en
los últimos 50 años”.
Resumen Durante esta década, la complejidad del diseño de ASIC se ha incrementado
sustancialmente. La necesidad de ASIC en las aplicaciones inalámbricas, automotrices,
médicas y otras aplicaciones de alto procesamiento ha crecido. El objetivo de este capítulo es
tener una discusión sobre los ASIC y los desafíos en los diseños de ASIC. El capítulo incluso
analiza el flujo de diseño ASIC, la evolución del nodo de proceso y los conceptos básicos de la
arquitectura SOC. El capítulo es útil para comprender los procesos involucrados en el diseño
de SOC.
Palabras clave ASIC ∙ SOC ∙ ASSP ∙ Celda estándar ∙ Matriz de puertas ∙ ASIC estructurado ∙
Síntesis ∙ IP ∙ Micro ∙ Multitarea ∙ Tasa de reloj ∙ Tasa de datos ∙ Ancho de banda
El diseño ASIC para la funcionalidad compleja que utiliza la lógica de mil millones de puertas
es la necesidad de esta década. Las áreas de aplicación pueden ser la comunicación
inalámbrica, la computación de alta velocidad o el procesamiento de video. En todas estas
áreas necesitamos tener los chips ASIC de alta velocidad. El prototipo que utiliza FPGA para
dicho ASIC o SOC es clave para medir el rendimiento y reducir el respin del diseño del ASIC.
En este contexto, el capítulo trata sobre el flujo de diseño ASIC, la creación de prototipos ASIC y los desafíos.
1.1 Diseño ASIC
La complejidad del circuito integrado específico de la aplicación (ASIC) ha crecido
exponencialmente en las últimas dos décadas. La mayoría de las empresas de diseño han
comenzado a trabajar en los nodos de tecnología de 10 nanómetros y 7 nanómetros. De
acuerdo con la ley de Moore, la cantidad de transistores en los circuitos integrados densos se
duplicará en aproximadamente 18 a 24 meses. La ley de Moore tiene limitaciones debido a la contracción y la
© Springer Nature Singapore Pte Ltd. 2020 V. 1
Taraate, síntesis lógica y creación de prototipos SOC,
https://doi.org/10.1007/9789811513145_1
2 1. Introducción
complejidad funcional del diseño. La mayoría de las empresas de diseño se enfrentan a desafíos
reales debido a la reducción del área, los requisitos de baja potencia y el requisito de alta
velocidad.
Los ASIC están diseñados para algunas aplicaciones específicas y, la mayoría de las veces,
observamos la aplicación de dichos diseños en automóviles, comunicaciones, procesamiento de
datos de alta velocidad e incluso en aplicaciones de defensa.
El circuito integrado de aplicación específica (ASIC) está diseñado para el propósito o la
aplicación específicos. Los chips ASIC están diseñados utilizando un flujo de diseño totalmente
personalizado o semipersonalizado. El diseño completamente personalizado comienza desde
cero, y las celdas requeridas se diseñan y caracterizan para el nodo de proceso específico. En el
caso de un diseño ASIC semipersonalizado, se utilizan las celdas y bibliotecas estándar
previamente validadas y las celdas adicionales requeridas se diseñan y caracterizan según los
requisitos para el nodo de proceso deseado. La funcionalidad adicional requerida puede ser el
diseño de celdas estándar, IP y otra lógica personalizada. El flujo de diseño ASIC se clasifica
como flujo de diseño frontal que es diseño lógico y síntesis y backend que es flujo de diseño
físico.
El ciclo general de diseño de ASIC comienza con la encuesta de mercado y la captura de
requisitos, y el flujo de diseño de frontend incluye pasos importantes como: entrada de diseño
utilizando lenguajes de descripción de hardware, verificación funcional de ASIC, síntesis y análisis
de tiempo previo al diseño.
El flujo de diseño de backend involucra los hitos importantes: plano de planta, plan de
energía, síntesis de árbol de reloj, ubicación y enrutamiento del diseño y, finalmente, el análisis
de tiempo posterior al diseño y la prueba del chip.
Debido a las especificaciones de diseño complejas, es un requisito que el arquitecto del chip
y los miembros del equipo de diseño comprendan las especificaciones funcionales al más alto
nivel para desarrollar las estrategias de partición de hardware y software.
El ASIC puede ser un diseño de procesadores, decodificadores de video y chips para
algoritmos de comunicación digital complejos; En todos estos diseños, la comprensión de la
especificación funcional y la evolución de la arquitectura eficiente y la documentación de la
microarquitectura juegan un papel importante y crucial.
La compleja arquitectura SOC puede evolucionar mediante la comprensión de las
especificaciones funcionales, el nivel de bloque y la funcionalidad de nivel superior, los requisitos
de tiempo, área y velocidad. El equipo de expertos de primer nivel participa en la definición de la
arquitectura para el diseño. Durante el ciclo de diseño, la arquitectura eficiente y el documento
de microarquitectura desempeñarán un papel importante.
¿Qué describe el documento de arquitectura y microarquitectura?
El documento de arquitectura y microarquitectura debe describir lo siguiente:
1. Detalles de nivel superior de los bloques
funcionales 2. Detalles e interfaces a nivel de
bloque 3. Requisitos de temporización 4.
Requisitos de memoria 5. Detalles de partición
de hardware y software 6. Requisitos de área,
velocidad y potencia 7. Especificaciones eléctricas y
mecánicas
1.1 Diseño ASIC 3
8. Requisitos de IP 9.
Información sobre las placas prototipo.
Durante la presente década, el flujo de diseño del SOC se ha vuelto muy complejo e involucra
a muchos equipos para completar hitos como; diseño de procesador/IP, diseño de arquitectura y
microarquitectura, diseño y verificación de RTL, síntesis y cierre de temporización, implementación
y pruebas a nivel de sistema.
Los principales desafíos en este tipo de diseño se enumeran a continuación y, principalmente,
están
(1) Diseño de arquitectura y partición del sistema para la funcionalidad compleja (2)
Administración de energía para cumplir con las restricciones de energía requeridas (3)
Selección de IP y su tiempo (4) Verificación completa del chip (5) Planificación de prueba
requerida y herramientas EDA (6) Metodología de verificación de pruebas y diseño de placa
(7) Efecto submicrónico profundo e integración (8) Tiempo de comercialización (9) Procesos
avanzados y modelos de simulación.
El SOC que se puede utilizar en la comunicación móvil se muestra en la Fig. 1.1.
Tiene los procesadores de video y audio, almacenamiento interno, procesador de propósito general
Procesador Audio
Memoria
LA
Procesador
Datos de audio
arroyos
Procesador Memoria Video

Yo Controladores
Procesador
Fecha del vídeo
arroyos
Red AUTOBÚS Extensión BIST
Interfaces interfaz lógica
Fig. 1.1 SOC para aplicaciones multimedia
4 1. Introducción
I, II, memoria interna y controladores de memoria. Incluso ese tipo de chip tiene lógica BIST con
otras interfaces de red. Los flujos de datos de video y audio están disponibles como interfaces
separadas.
Debido al requisito del procesamiento de datos de alta densidad, este tipo de ASIC debe
tener paralelismo. Esto se puede lograr mediante el uso de la arquitectura de múltiples
procesadores.
1.1.1 Tipos de ASIC [3]
Como se indicó anteriormente, el chip diseñado para el propósito o la aplicación específicos se
denomina Circuito integrado específico de la aplicación (ASIC). Principalmente, el ASIC puede
estar compuesto por múltiples procesadores, memorias y otros bloques funcionales con módulos
de interfaz de alta velocidad. El chip puede tener bloques analógicos o digitales. Por ejemplo,
considere el diseño del sistema de comunicación digital que consta de transmisores o receptores.
Este tipo de chips debe tener la lógica del transmisor y el receptor y debe operar con los datos
digitales. El chip puede tener uno o más de un procesador para realizar el procesamiento paralelo
de los datos y debe cumplir con los criterios de rendimiento requeridos.
Un circuito integrado (IC) se compone de obleas de silicio y cada oblea puede tener miles de
troqueles. La mayoría de las veces, a menudo nos encontramos con el término Producto estándar
específico de la aplicación (ASSP), y están disponibles en el mercado citando números de pieza,
por ejemplo, chips de procesador, decodificadores de video, chips de procesamiento de audio y
DSP.
Los ASIC se clasifican principalmente en las siguientes categorías y se nombran como:
• ASIC totalmente
personalizado • ASIC
semipersonalizado • ASIC de matriz de puertas
ASIC completamente personalizado: el diseño que se ha hecho desde cero se denomina ASIC
completamente personalizado. El flujo de diseño de dicho diseño incluye el diseño y la validación
de las celdas o puertas requeridas. Las celdas predefinidas no se utilizan en este tipo de ASIC.
Considere el escenario de diseño donde las especificaciones de diseño se entregan al equipo de
diseño con el requisito de velocidad, potencia y área. Si la celda existente no cumple con los
criterios de rendimiento requeridos, la opción es diseñar las celdas requeridas para el nodo de
proceso de destino. El ciclo de diseño en este tipo de ASIC es más largo debido al diseño de
celdas estándar, macros y validación de las mismas.
ASIC semipersonalizado: en este tipo de diseño, se utilizan las celdas estándar existentes de
puertas lógicas (AND, OR, NOT y EXOR), MUX, flipflop y latch. En esto, el equipo de diseño
utiliza la biblioteca de celdas estándar, donde las celdas ya están diseñadas y probadas
previamente. Esto implica un menor tiempo de comercialización, menores inversiones e incluso
un bajo riesgo en comparación con el diseño totalmente personalizado. Considere el escenario
donde la celda estándar y las macros están prediseñadas y validadas para el nodo de proceso de 10 nanómetros
Ahora se dan las especificaciones al equipo de diseño para diseñar el controlador de memoria.
1.1 Diseño ASIC 5
utilizando un nodo de proceso de 10 nanómetros. En este tipo de escenario, el equipo de diseño utiliza las bibliotecas
de celdas estándar prediseñadas y probadas previamente. Esto reduce el tiempo del ciclo de diseño y el riesgo durante
el ciclo de diseño. Las bibliotecas de celdas estándar se diseñan utilizando solo el flujo de diseño completamente
personalizado y las celdas estándar se pueden optimizar individualmente.
ASIC de matriz de puerta : los ASIC de matriz de puerta se clasifican además como
• Arreglos de puertas canalizados
• Arreglos de puertas sin canales •
Arreglos de puertas estructurados
En el ASIC de matriz de puertas, el diseño involucra la matriz base y la celda base. La matriz base es el patrón
requerido predefinido de los transistores en la matriz de compuertas. La celda base se describe ampliamente como el
elemento más pequeño en la matriz base. En este tipo de ASIC, el diseño de la celda es el mismo para todas las
celdas, pero las interconexiones entre las celdas y el interior de la celda se personalizan.
1.2 Desafíos de diseño
Hay muchos desafíos en los diseños complejos de SOC, y la mayoría de los informes de ITRS describen los siguientes
aspectos destacados importantes relacionados con el diseño físico de ASIC/SOC:
1. Interconexiones y ruido en frecuencias más altas: los verdaderos desafíos en alta
frecuencia son
la. Inmunidad al ruido y margen de ruido ii. Integridad
de la señal y problemas de convergencia de datos iii. No linealidad
en las variaciones de retardo iv. Acoplamiento cruzado de los
dispositivos.
2. Restricciones de energía: Debido a la escala no ideal de la tensión parásita y de suministro o de umbral, realmente
afecta las restricciones de energía para el diseño.
3. Rendimiento y limitación de la interconexión: uno de los principales desafíos es cómo escalar el rendimiento de la
interconexión para tener la integridad y la convergencia de los datos.
4. Reloj del sistema y sincronización: el requisito real para cualquier diseño de ASIC o SOC es tener un sesgo de reloj
uniforme. En tal escenario, la distribución uniforme del reloj con la sincronización requerida es el verdadero
desafío.
International Technology Roadmap for Semiconductors (ITRS) presta mucha más atención al diseño del sistema a
nivel de chip y las estrategias de diseño. ITRS evalúa las tendencias de diseño, las tecnologías de diseño y el desarrollo
futuro para hacer que los diseños SOC sean más sólidos. ITRS produce la hoja de ruta con nuevas adiciones que se
pueden aplicar incluso a los diseños SOC de mil millones de puertas. El objetivo principal de ITRS es producir una hoja
de ruta para el diseño de circuitos integrados.
Los puntos clave en la mayoría de las hojas de ruta de ITRS son el costo del diseño, el tiempo del ciclo de
fabricación y la tecnología de diseño objetivo. Para los clientes de semiconductores, el mayor desafío es el costo de
NRE, que es de millones de dólares. Pocos
6 1. Introducción
de las hojas de ruta de ITRS producidas en la última década se centran en la reducción del costo del
diseño. El mensaje principal de tales hojas de ruta es que el costo de NRE para la máscara y las
pruebas ha llegado a unos pocos cientos de millones de dólares durante esta década y si debido a
cambios en las especificaciones del diseño o debido a deficiencias importantes en el diseño, si el
diseño vuelve a girar, entonces dichos costos se multiplicarán. . Debido a la tecnología de proceso de
contracción, el ciclo de vida del producto de diseño se ha acortado y debido a eso, el tiempo de
comercialización es un tema muy crítico para las empresas de diseño y fabricación de semiconductores.
Si consideramos el diseño ASIC, entonces el ciclo de diseño o verificación es de unos pocos meses
y el tiempo de fabricación de unas pocas semanas. Hay incertidumbres en el diseño y la verificación,
pero poca incertidumbre en la fabricación del chip. En tales circunstancias, las inversiones en
tecnología de proceso han dominado las inversiones en tecnología de diseño. Pero el punto importante
es que el costo de diseño de los ASIC/SOC energéticamente eficientes durante el año 2016 fue de
casi unos pocos millones de dólares frente a las inversiones de cientos de millones de dólares en la
última década.
Aún así, si consideramos las aplicaciones ASIC, necesitan comunicación de software y hardware;
por lo tanto, durante esta década, los sistemas suelen ser del tipo integrado. Casi alrededor del 7080%
del costo se invierte para desarrollar software para tales sistemas. Durante esta década, el costo de la
prueba ASIC ha crecido significativamente y para cualquier diseño complejo, el costo de la verificación
es mucho mayor en comparación con el costo del diseño.
La evaluación del ITRS y la hoja de ruta se clasifican en dos verticales principales.
Una es la complejidad del silicio, que está relacionada con el diseño físico del chip, y la otra es la
complejidad del sistema, que está relacionada con los escenarios de diseño del sistema y la
funcionalidad compleja.
Las empresas de diseño y fabricación deben pensar en todos estos desafíos durante el diseño de
chips ASIC de bajo costo y bajo consumo. Durante esta década, estamos siendo testigos de la
limitación real en la reducción y duplicación de los transistores en circuitos integrados densos y tiene
un impacto significativo en la hoja de ruta general para la disponibilidad de nuevos procesadores.
Además de estos desafíos de diseño físico, el diseñador del sistema debe pensar en el costo de la
verificación y las pruebas, el largo ciclo de verificación, la reutilización de bloques para los diseños
jerárquicos, los codiseños de hardware y software y, por último, pero no menos importante, el diseño. /
tamaño del equipo de verificación y ubicaciones geográficas.
1.3 Flujo de diseño ASIC
Para diseñar los ASIC, la idea del producto o estudio de mercado es un hito importante. Los datos
disponibles durante la encuesta de mercado se pueden utilizar para finalizar las especificaciones
funcionales y juegan un papel importante. Durante la encuesta de mercado, el equipo puede extraer lo
siguiente:
1. Tipos de productos similares disponibles en el mercado
2. Características de los productos 3. Especificaciones
eléctricas y ensamblaje mecánico
1.3 Flujo de diseño ASIC 7
4. Rango de precios de los productos
5. ¿El producto tiene características actualizables?
Las especificaciones funcionales son útiles para el equipo de diseño de ASIC ya que da
información sobre las características generales y las amplias áreas de aplicación (Fig. 1.2).
1. Especificaciones de diseño: Las especificaciones ASIC incluyen especificaciones y características
funcionales, eléctricas y mecánicas de los bloques lógicos y funcionales. Por ejemplo, el SOC
móvil debe tener el procesador, la memoria
Fig. 1.2 Algunos pasos
importantes en el diseño de ASIC
Encuestas de mercado
Extracción de especificaciones
Diseño Arquitectura y
Microarquitectura
Diseño RTL y
Verificación
Síntesis lógica y
Extensión DFT
Diseño previo de STA
diseño físico
CHIP
8 1. Introducción
controladores, interfaces externas, cámaras de alta resolución, pantallas de alta resolución,
etc. Para todos los componentes requeridos, es esencial comprender la velocidad, la latencia,
el rendimiento, la velocidad de datos y el ancho de banda.
2. Diseño de arquitectura: mediante el uso de la especificación de diseño, se puede crear el
documento de arquitectura y microarquitectura. El diseño ASIC se divide en pequeños
bloques y el diseño a nivel de bloque con los detalles de la interfaz se puede documentar en
el nivel superior. Por ejemplo, si ASIC usa el procesador como uno de los bloques funcionales,
durante el hito del diseño de la arquitectura, el equipo de arquitectos debe considerar los
requisitos de velocidad, las interfaces externas, la canalización y el rendimiento de E/S.
Mediante el uso de estos detalles, la arquitectura y la microarquitectura del ASIC pueden
evolucionar. Si bien es un proceso iterativo que requiere mucho tiempo, es uno de los
principales hitos, ya que este documento se utiliza en todo el ciclo de diseño de ASIC.
3. Diseño y síntesis lógicos: el diseño lógico ASIC implica la partición del diseño, el diseño RTL,
la verificación RTL, la síntesis, la inserción de pruebas y el análisis de tiempo previo al
diseño. Durante la STA previa al diseño, el objetivo es corregir las violaciones del tiempo de
configuración para los diversos bloques funcionales. La Figura 1.3 brinda información sobre
el diseño lógico ASIC a un nivel superior.
Fig. 1.3 Pasos importantes en
el diseño lógico ASIC
Diseño RTL
Verificación RTL
Síntesis lógica
Inserción de prueba
Diseño previo de STA
1.3 Flujo de diseño ASIC 9
1. Estudio de mercado para extraer el requisito de especificación para el ASIC o SOC. La especificación
puede ser funcional, eléctrica y mecánica para la velocidad y potencia requerida.
2. Diseño de arquitectura: Comprensión de especificaciones y arquitectura y microarquitectura para el diseño
ASIC o SOC. La representación a nivel de bloque para el diseño con otros detalles de interfaz y tiempo.
3. Diseño usando HDL: Diseño RTL usando HDL (VHDL, Verilog o usando SystemVerilog).
4. Verificación RTL: Simulación dinámica exhaustiva del diseño, para verificar la
funcionalidad del diseño.
5. Inserción de prueba, inserción BIST de memoria DFT, para diseños que contienen memoria
elementos.
6. Configuración del entorno: Esto incluye la biblioteca de tecnología que se utilizará, junto con otros atributos
del entorno.
7. Restricciones y síntesis del diseño: Restricción y síntesis del diseño con inserción de escaneo (y JTAG
opcional) utilizando Design Compiler.
8. STA a nivel de bloque : uso del análisis de tiempo estático incorporado de Design Compiler
motor.
9. Verificación formal: comparación RTL contra la netlist sintetizada, usando
Formalidades.
10. Diseño previo de STA: STA de diseño de chip completo usando PrimeTime.
4. Flujo de diseño físico: el flujo de diseño físico utiliza la lista de conexiones a nivel de puerta que
es el resultado de la síntesis lógica, y se muestra en la Fig. 1.4.
Los pasos importantes se documentan a continuación:
1. Anotación de reenvío: anotación de reenvío de restricciones de tiempo en el diseño
herramientas.
2. Floorplanning: Floorplanning inicial con ubicación de celdas controlada por tiempo, inserción de árbol de reloj y
enrutamiento global.
3. CTS: Transferencia del árbol del reloj al diseño original (netlist) que reside en Diseño
compilador.
4. IPO: Optimización in situ (IPO) del diseño en Design Compiler.
5. Verificación formal: Verificación entre la lista de conexiones sintetizada y la lista de conexiones insertada en el
árbol del reloj, utilizando Formalidad.
6. Extracción de retrasos de tiempo: Extracción de retrasos de tiempo estimados del diseño
después del paso de enrutamiento global.
7. Anotación posterior: anotación posterior de los datos de tiempo estimados del global
diseño enrutado, a PrimeTime.
8. STA: análisis de tiempo estático en PrimeTime, utilizando los retrasos estimados extraídos
después de realizar la ruta global.
9. Enrutamiento detallado: enrutamiento detallado del diseño. Extracción de tiempos reales
retrasos del diseño enrutado detallado.
10. Anotación posterior de datos de tiempo: anotación posterior de los datos de tiempo reales extraídos
a horario de máxima audiencia.
10 1. Introducción
Fig. 1.4 Pasos importantes
en el flujo de diseño físico
Diseño
fraccionamiento
planificación de suelos
Planificación energética
extensión CTS
Ubicaciones
y enrutamiento
Diseños de publicaciones
ES
Grabar
11. STA posterior al diseño: análisis de tiempo estático posterior al diseño mediante PrimeTime.
12. Simulación posterior al diseño: simulación funcional a nivel de puerta del diseño con sincronización
posterior al diseño (si es necesario).
13. Tape out: Tape out después de la verificación de LVS y DRC.
1.4 Necesidad de HDL? 11
Tabla 1.1 Aspectos destacados importantes del lenguaje de
Parámetros programación C/C++ y HDL (C o C+ extensión HDL
+)
Instrucciones o construcciones El lenguaje se adapta mejor a la ejecución Admite construcciones secuenciales
secuencial debido a las construcciones y concurrentes
Estilo de descripción El objetivo principal codificar la La descripción es Registro

funcionalidad del diseño. El programador Nivel de transferencia (RTL) y el
utiliza el pensamiento analítico y lógico objetivo principal es inferir la
para desarrollar el modelo de estructura de nivel de puerta requerida
comportamiento.
Recursos y uso La intención principal del El diseñador debe considerar los

programador es desarrollar el recursos necesarios, el paralelismo y
algoritmo, y el programador nunca la concurrencia.
considera los requisitos de área, Incluso los diseñadores deben usar
velocidad y potencia. las restricciones de área, potencia
y velocidad para lograr el mejor
resultados
Solicitud Debe usarse como lenguaje de Debe usarse para describir el

programación para describir la hardware, ya que tiene construcciones
funcionalidad. En otras palabras, es una sintetizables. Debido al uso de
mezcla de ensamblador y lenguaje de construcciones no sintetizables, esto
alto nivel. también se puede usar para verificar la
funcionalidad del diseño.
Construcciones de tiempo No admite la noción de tiempo. Apoya los constructos de tiempo y la
noción de tiempo.
Construcciones de flujo Debido a la ejecución secuencial, HDL admite el flujo de datos y

soporta el flujo de datos. control
1.4 Necesidad de HDL?
Antes de la evolución de los lenguajes de descripción de hardware (HDL), los diseñadores tenían
dificultades para describir el diseño utilizando la captura esquemática. El C y C++ son lenguajes de alto
nivel y se utilizan para desarrollar el modelo funcional para el diseño.
Mientras que los HDL se utilizan para describir el hardware. La Tabla 1.1 ofrece una descripción general
de C, C++ y HDL.
De la Tabla 1.1, está claro que, dado que C y C++ no son compatibles con la concurrencia, las
construcciones de tiempo y el flujo de control. Por lo tanto, necesitamos usar el HDL para describir el hardware.
1.5 Lenguajes de descripción de hardware
Para describir el hardware, los lenguajes de descripción populares utilizados en la industria son VHDL,
Verilog y System Verilog. La Tabla 1.2 da la información sobre la evolución de HDL con su estándar.
12 1. Introducción
Tabla 1.2 Evolución de HDL y sus estándares
extensión HDL
Descripción Solicitud Estándar
Extensión AHD
Lenguaje de Código abierto y utilizado 1980
descripción de hardware analógicopara la verificación analógica
VerilogAMS Verilog para señales Estándar abierto y utilizado Derivado de IEEE

analógicas y mixtas para la combinación de 1364
simulación digital y analógica
VHDLAMS VHDL para señales analógicas y mixtas Lenguaje estándar para la IEEE 1076.12007

simulación de señal mixta
analógica y digital
extensión VHDL
Circuitos integrados Utilizado para el diseño y IEEE 10762008
HDL de muy alta velocidad verificación de lógica digital.
(VHSICHDL)
Verilog Lenguaje de descripción de Utilizado para el diseño y IEEE 13642005
hardware ampliamente utilizado verificación de lógica digital.
ABEL Lenguaje de expresiones Utilizado para el No lo es
booleanas avanzado Diseño basado en PLD
Sistema C El lenguaje de Utiliza las clases de C++ IEEE 16662011

abstracción de alto nivel para el modelado de nivel
para los diseños de de transacción y de
hardware. comportamiento de nivel
superior (TLM) para describir
el hardware a nivel de
sistema.
Sistema Verilog Superconjunto de Verilog Se utiliza para abordar IEEE 18002017

el diseño y la verificación a
nivel del sistema.
1.6 Construcción de hardware y diseño IP
Chisel es un lenguaje de construcción de hardware (HCL) desarrollado por UC Berkeley. El objetivo
principal de este lenguaje es diseñar hardware utilizando generadores parametrizados.
Algunos de los puntos destacados importantes del lenguaje son
1. Es un lenguaje de construcción de hardware de código abierto.
2. Tiene construcción y cableado algebraicos e integrado en la programación de Scala
idioma.
3. Lo más destacado es que tiene conexiones masivas con los tipos de datos abstractos
e interfaces.
4. Se utiliza para las construcciones jerárquicas, orientadas a objetos y funcionales.
5. Admite la estratificación de los idiomas específicos del dominio.
6. Está altamente parametrizado usando metaprogramación en Scala.
7. Admite diseños de punto flotante y dominio de múltiples relojes.
1.6 Construcción de hardware y diseño IP 13
8. Lo más destacado es que genera el Verilog que puede ser utilizado por el
Herramientas líderes en FPGA y ASIC.
Debido a las potentes funciones, el lenguaje se puede utilizar como lenguaje de construcción de
hardware, y podemos ver la creciente demanda de dicho lenguaje debido a la reducción del tiempo de
comercialización. La discusión sobre el cincel está fuera del alcance de este libro.
1.7 Desafíos y áreas de diseño de ASIC/SOC
El diseño ASIC y SOC del siglo XXI debe tener procesadores paralelos, ya que la ley de Moore ha
alcanzado sus limitaciones en la velocidad de los ASIC y la disipación de energía. Si percibimos el futuro
del diseño, siempre habrá desafíos en los diseños ASIC y SOC debido a las demandas de los
consumidores. Hoy en día, todo ser humano está interesado en tener teléfonos inteligentes, dispositivos
de control inteligente y los dispositivos. La diversión será durante la próxima década, cuando el
paralelismo masivo en el diseño de los ASIC y SOC intentará cambiar los procesos y algoritmos de
diseño.
Hay muchos desafíos que deben abordarse; pocos de ellos me los he imaginado, y están documentados
a continuación:
1. Los ASIC se pueden diseñar para ancho de banda alto y comunicaciones confiables para
cumplir con los requisitos de los clientes finales.
2. Las empresas similares a Google pueden usar los ASIC en los sistemas de computación cuántica
para el reconocimiento de voz.
3. El área de inteligencia artificial enfrentará los desafíos debido a la reducción del nodo de proceso y
estos pueden superarse mediante el uso de motores de procesamiento paralelo y paralelismo.
4. El campo del diagnóstico médico consumirá una gran cantidad de ASIC y se desarrollarán nuevos
SOC con los procesadores paralelos.
5. El área de síntesis de texto a voz evolucionará utilizando el procesador paralelo basado
SOC.
6. La automatización en los controles del vehículo para brindar controles más fáciles de usar al usuario
final evolucionará y se puede lograr mediante los diseños SOC.
7. Con una potencia informática y de procesamiento mejorada, los SOC incluso se pueden usar para
controlar los robots en las áreas peligrosas con más precisión y exactitud.
8. Los sensores, cámaras y escáneres inteligentes para identificar los artículos peligrosos sin la
intervención de seres humanos pueden evolucionar mediante el uso de diseños multiSOC.
9. Las automatizaciones en los hospitales para monitorear la salud del paciente a larga distancia es
una de las áreas que puede evolucionar utilizando los multiprocesadores y SOCs.
10. Como se requiere menos área, alta velocidad y menos potencia en todos los tipos de ASIC y SOC,
podemos presenciar el cambio de tecnología y la evolución de los algoritmos para respaldar el
paralelismo masivo durante esta década.
14 1. Introducción
1.8 Puntos importantes para concluir el Capítulo
Como se discutió anteriormente, los siguientes son algunos puntos importantes para concluir el capítulo.
1. Los ASIC están diseñados para aplicaciones específicas y pueden tener
bloques digitales.
2. Los ASIC se pueden clasificar como totalmente personalizados, semipersonalizados y programables
ASIC.
3. Para diseños ASIC de mayor densidad, la partición del diseño juega un papel importante para
definir los límites de la interfaz.
4. Los HDL populares son VHDL, Verilog, System Verilog y chisel es Hardware
Lenguaje de construcción (HCL).
5. La arquitectura y microarquitectura para ASIC se utiliza como documento de referencia durante todo el ciclo de
diseño de ASIC.
6. Durante el STA previo al diseño, el objetivo es corregir todas las violaciones del tiempo de configuración.
7. Durante el STA posterior al diseño, todas las violaciones de tiempo (configuración, violaciones de tiempo de espera)
debe ser arreglado
8. Se puede usar FPGA para crear un prototipo del diseño. Si el diseño tiene características complejas y tiene
densidades más grandes, entonces se pueden usar múltiples plataformas FPGA.
En el próximo capítulo, discutiremos sobre los conceptos básicos del diseño ASIC y el prototipo SOC y los
desafíos importantes. El cap. 2 también es útil para comprender el flujo de diseño, el diseño, la verificación
y el prototipo de SOC para los diseños de SOC.
Capitulo 2
Diseño ASIC y Prototipado SOC
“El ciclo general de diseño y verificación de ASIC consume el 80 %
de los esfuerzos”.
Resumen El capítulo analiza los conceptos de diseño de ASIC, los conceptos básicos de creación de
prototipos de SOC y los desafíos en los diseños de ASIC/SOC. El capítulo incluso analiza comandos
importantes del compilador de diseño (DC) que se utilizan durante la fase de síntesis y optimización del
diseño. El capítulo es útil para comprender los conceptos básicos de la creación de prototipos de SOC
y los desafíos importantes durante la fase de prototipo utilizando FPGA de alta densidad.
Palabras clave FPGA ASIC SOC Prototipo Compilador de diseño Componentes SOC
Arquitectura Microarquitectura Diseño RTL Prueba _ _ _ _
Con referencia a los bloques SOC de uso frecuente, en este capítulo se analizan el flujo de diseño SOC
y los desafíos del prototipo.
2.1 Diseño del SOC
En el siglo actual, la complejidad del diseño ha crecido debido a la necesidad de productos y
características inteligentes. El área ASIC/SOC ha surgido en las aplicaciones de automoción, consumo,
medicina, comunicaciones inalámbricas y multimedia. Para diseñar este tipo de lógica de alta densidad,
el SOC debe constar de múltiples procesadores, interfaces de bus de alta velocidad, controladores de
memoria y otras interfaces. Considere el SOC que se muestra en la Fig. 2.1. Da información sobre los
bloques de uso frecuente. En el diseño de tales SOC, se deben considerar los siguientes puntos.
1. ¿Cuál es la velocidad total del SOC?
2. ¿La arquitectura tiene un motor de procesamiento paralelo?
3. ¿Hay suficiente memoria interna?
4. ¿Cuáles son los requisitos generales de energía?
https://doi.org/10.1007/9789811513145_2
dieciséis
2 Diseño ASIC y creación de prototipos SOC
5. ¿Qué es el nodo de proceso/tecnología y cuál debería ser la plataforma prototipo?
6. ¿Cuáles son los requisitos de PI?
7. ¿Qué componentes analógicos, digitales/IP y herramientas EDA se requieren?
8. ¿Cuánto tiempo se requiere para obtener el diseño, la verificación y el prototipo del chip completo?
Con referencia a la arquitectura SOC que se muestra en la Fig. 2.1, los siguientes son algunos
aspectos destacados importantes y deben tenerse en cuenta durante la fase de diseño y verificación
del SOC.
1. Arquitectura de múltiples procesadores: la necesidad es tener un procesamiento paralelo de los datos
y, en ese contexto, el SOC debe tener múltiples procesadores. El paralelismo puede mejorar la
velocidad del diseño general. Como se muestra, el SOC usa un procesador para realizar el cálculo
de propósito general y el procesador de video para realizar el procesamiento de datos de video de
flujo alto. Al diseñar este tipo de SOC, el equipo de arquitectos debe cuidar la velocidad de los
buses, el ancho de banda del sistema en general, la velocidad de datos, la latencia y el rendimiento.
Se pueden incorporar funciones de canalización adicionales para mejorar la arquitectura general
del SOC.
USB
RAM
interfaces y
Controladores
Memoria
Bluetooth
Procesador Controladores
ROM
Temporizador
y contadores
SDRAM
Video Arbitraje de autobuses interfaz
Procesador y control
anuncio
externo
Alto
CAD
Memoria Velocidad
extensión DMA
interfaz Controladores
Autobús
interfaz
extensión PL
Osciladores
Figura 2.1 Arquitectura SOC
2.1 Diseño del SOC 17
2. Memoria y controlador de memoria: ¿Cuál es el requisito de memoria para este tipo de diseño?
El almacenamiento interno y las interfaces de memoria externa deben tener la menor latencia
durante las operaciones de lectura y escritura. Dependiendo de los requisitos de velocidad de
datos, se pueden diseñar los controladores de memoria. El controlador DDR o SDRAM o flash
NAND se pueden diseñar o se pueden usar sus IP para lograr el mejor prototipo.
3. Interfaces seriales: ¿Cuáles son las interfaces seriales requeridas y cuál debería ser su velocidad?
La mayoría de las veces, necesitamos tener I2C, SPI, UART para la comunicación en serie.
4. Interfaces de alta velocidad: si el SOC tiene USB y Bluetooth, entonces qué debería ser estándar
y cuáles son los desafíos durante la integración es otro punto importante a discutir mientras se
desarrolla la arquitectura.
5. Controlador DMA: Para el acceso directo a memoria sin involucrar al procesador, ¿cuál debería
ser la estrategia de diseño? ¿Qué tipo de interfaces de bus se requieren y cuál es la velocidad
de transferencia de datos? ¡Eso debe pensarse durante la fase de evolución de la arquitectura!
6. Bloques analógicos: para las interfaces analógicas, el SOC debe tener los ADC y DAC. El
arquitecto debe considerar la tasa de muestreo de ADC, el tiempo de conversión, la resolución
de DAC y la linealidad.
7. Recursos de reloj: los osciladores y PLL incorporados se pueden usar para generar los relojes
con el sesgo de reloj uniforme y se pueden usar como fuente de reloj para los componentes de
diseño SOC de dominio de reloj múltiple.
Además de lo anterior, las características eléctricas y la velocidad, la potencia y el área deben
considerarse durante la fase de diseño de la arquitectura SOC. La extracción de las restricciones de
nivel de bloque y de nivel superior para la biblioteca de tecnología requerida debe realizarse durante
la evolución de la arquitectura de SOC.
Las siguientes secciones se utilizan para obtener más información sobre el flujo de diseño del
SOC y los hitos importantes.
2.2 Flujo de diseño del SOC
Con la evolución de la tecnología de diseño VLSI, los diseños ASIC o SOC se vuelven cada vez
más complejos y el diseño basado en SOC es factible en un ciclo de diseño más corto. La demanda
de los clientes de entregar el producto en el tiempo de ciclo de diseño más corto es posible mediante
el uso de un flujo de diseño eficiente. El diseño debe evolucionar desde la etapa de especificación
hasta el diseño final. El uso de herramientas EDA con las características adecuadas ha hecho
posible tener diseños libres de errores con una funcionalidad comprobada. El flujo de diseño se
muestra en la Fig. 2.2 y consta de los siguientes hitos importantes.
18 2 Diseño ASIC y creación de prototipos SOC
Fig. 2.2 Flujo de diseño del SOC
Encuestas de mercado
SOC Especificaciones y
Diseño arquitectónico
Diseño y Verificación RTL
Síntesis y Cronometraje
Verificación
Diseño Físico y
Verificación
Prototipos y pruebas
2.2.1 Especificaciones de diseño y arquitectura del sistema
La extracción de las especificaciones funcionales del diseño para ASIC o ASSP es una fase
importante, y durante esta fase, se debe realizar una investigación de mercado exhaustiva
para congelar las especificaciones funcionales del diseño. Considere el SOC móvil; luego,
algunas especificaciones funcionales importantes pueden ser, velocidad del procesador,
especificación funcional del procesador, memoria interna, pantalla y su resolución, cámara y
resolución de la cámara, interfaces de comunicación externa, etc. Más que eso, es fundamental
tener información sobre el montaje mecánico y otras características eléctricas del dispositivo.
Pueden ser requisitos de suministro de energía y circuito de carga de la batería y características
de seguridad. Las especificaciones se utilizan para esbozar el plano de planta de nivel superior
del chip que podemos llamar arquitectura de SOC móvil. Incluso los parámetros importantes
son las restricciones ambientales y las restricciones de diseño. Las limitaciones clave del
diseño son el área, la velocidad y la potencia.
Esbozar la arquitectura de cualquier SOC de mil millones de puertas es una de las tareas
difíciles, ya que implica la imaginación real y la comprensión de la interdependencia entre
2.2 Flujo de diseño del SOC 19
el hardware y el software. Para evitar los gastos generales en un solo procesador, es posible que el
diseño deba tener más procesadores para realizar la multitarea. El documento de arquitectura
siempre se desarrolla a partir de las especificaciones de diseño y es una representación a nivel de
bloque del diseño general. El equipo de profesionales experimentados puede crear este tipo de
documento, y esto puede usarse como referencia para esbozar la microarquitectura del diseño.
El documento de microarquitectura es la abstracción de nivel inferior de los documentos de
arquitectura y brinda información sobre la funcionalidad de cada bloque con su interfaz e información
de tiempo. En un nivel superior, podemos considerar este documento como una representación a
nivel de subbloque para el diseño a nivel de bloque. Incluso este documento debe brindar información
sobre las IP en el diseño, su sincronización y los detalles de la interfaz.
El diseño de arquitectura para SOC y la evolución de la microarquitectura para SOC es
discutido en el próximo capítulo subsiguiente.
2.2.2 Diseño RTL y verificación funcional
Para los diseños complejos de SOC, el equipo de diseño utiliza el documento de microarquitectura
como referencia. El diseño del SOC de mil millones de puertas se divide en varios bloques y el
equipo de cientos de ingenieros trabaja para implementar el diseño y realizar la verificación. El
equipo de diseño de RTL utiliza las pautas de diseño y codificación recomendadas durante la fase
de diseño de RTL. Un diseño RTL eficiente siempre juega un papel importante durante el ciclo de
implementación. Durante la fase de diseño de RTL, los miembros del grupo describen la funcionalidad
a nivel de bloque y de nivel superior mediante construcciones eficientes de Verilog, SystemVerilog
o VHDL.
Después de completar una fase de diseño RTL eficiente para las especificaciones de diseño
dadas, la funcionalidad del diseño se verifica mediante el uso de un simulador estándar de la industria.
La simulación previa a la síntesis se realiza sin demoras y, durante esta, el enfoque es verificar la
funcionalidad del diseño. Pero la práctica común en la industria es verificar la funcionalidad
escribiendo los bancos de prueba. El banco de pruebas fuerza el estímulo de las señales al diseño
y monitorea la salida del diseño. En el escenario actual, la automatización en el flujo de verificación
y las nuevas metodologías de verificación han evolucionado y se utilizan para verificar la
funcionalidad del diseño complejo en un período de tiempo más corto utilizando los recursos
adecuados. El papel del ingeniero de verificación es probar los desajustes funcionales entre el
resultado esperado y el resultado real. Si se encuentra una discrepancia funcional durante la
verificación, debe rectificarse antes de pasar al paso de síntesis.
La verificación funcional es un proceso iterativo a menos y hasta que el diseño cumpla con la
funcionalidad requerida. Para la verificación de funciones complejas SOC o ASIC; ¡Se debe
considerar la automatización con múltiples bancos de pruebas y la planificación de la verificación
para lograr los objetivos de cobertura deseados!
2.2.3 Verificación de síntesis y temporización
Cuando se cumplen los requisitos funcionales del diseño, el siguiente paso es realizar el bloque y la síntesis de
nivel superior. La herramienta de síntesis utiliza el diseño RTL, las restricciones de diseño y las bibliotecas como
entradas y genera la lista de conexiones a nivel de puerta como salida. La síntesis es un proceso iterativo hasta
que se cumplen las restricciones de diseño. Las principales restricciones de diseño son el área, la velocidad y la
potencia. Si no se cumplen las restricciones de diseño, la herramienta de síntesis realiza más optimización en el
diseño RTL. Después de la optimización, si se ha observado que no se cumplen las restricciones, se vuelve
obligatorio modificar el código RTL o ajustar la microarquitectura. La herramienta de síntesis genera los informes
de área, velocidad y potencia y la lista de conexiones a nivel de puerta como salida.
La verificación de tiempo debe llevarse a cabo para la lista de conexiones a nivel de puerta, y esta fase es útil
para encontrar las discrepancias de simulación previas y posteriores a la síntesis.
El análisis de tiempo previo al diseño también es una fase importante para corregir las violaciones de
configuración en el diseño. Las infracciones de retención se pueden corregir durante una etapa posterior del ciclo
de diseño durante el análisis de tiempo posterior al diseño.
2.2.4 Diseño físico y verificación
Implica la planificación del diseño, la planificación de energía, el lugar y la ruta, la síntesis del árbol de reloj, la
verificación posterior al diseño, el análisis de tiempo estático y la generación de GDSII para un diseño ASIC.
2.2.5 Prototipo y Prueba
Durante esta fase, el prototipo de diseño que utiliza FPGA se puede validar y probar para comprender si las
características de diseño están cubiertas o no. Esta fase es un hito que requiere mucho tiempo, y antes de la
fabricación del chip, se deben realizar pruebas exhaustivas para verificar la funcionalidad y el resultado deseado.
2.3 Prototipos y desafíos del SOC
En la década actual, Xilinx, IntelFPGA y otros proveedores tienen una poderosa arquitectura FPGA y los FPGA se
utilizan para la emulación y creación de prototipos. Las siguientes son algunas razones para el uso de FPGA
modernos de alta densidad para la creación de prototipos.
1. El FPGA con arquitectura de alta velocidad puede tener una ejecución inigualable
rendimiento durante la emulación y la creación de prototipos.
2.3 Prototipos y desafíos del SOC 21
2. Las placas FPGA se pueden usar como emuladores, por lo que las soluciones son rentables. Si
consideramos el ASIC, entonces la prueba comercial es muy costosa en comparación con FPGA.
3. Descubrir los objetivos deseados y requeridos mediante la simulación puede funcionar para los diseños
de conteo de puertas pequeñas, pero para los diseños complejos, la verificación robusta mediante
el software de la aplicación puede ser la mejor opción.
4. La fase de emulación y creación de prototipos reduce el riesgo de los ASIC en general
el tiempo de respuesta es más corto.
Aún en el entorno práctico, puede haber múltiples desafíos en la emulación y creación de prototipos
utilizando FPGA de alta densidad. Algunos de los desafíos clave se enumeran en la siguiente sección
1. Arquitectura FPGA múltiple: la mayoría de los SOC de alta densidad deben crearse prototipos
utilizando FPGA múltiples. La arquitectura de la FPGA es específica del proveedor e incluso el
soporte de la herramienta EDA es específico del proveedor y es posible que no siempre sea efectivo.
La calidad real de la partición del diseño en varias FPGA determina el rendimiento de la emulación.
Otro punto importante es la rentabilidad y la necesidad de mano de obra durante la creación de
prototipos. El trabajo real debe estar en el área de partición de diseño eficiente para un mejor
rendimiento utilizando las interfaces FPGA disponibles.
2. Diseño RTL para ASIC versus FPGA: El codificado RTL para ASIC no
mapa fácilmente en el FPGA objetivo. Las razones principales son
a. A menudo hay diferencia entre las frecuencias de operación de la FPGA y
ASIC.
b. La arquitectura de sincronización y la lógica de inicialización son el verdadero cuello de
botella. C. Las interfaces IO y la tecnología de memoria para ASIC y FPGA pueden tener una
arquitectura diferente. Considere el flash que se usa en el diseño ASIC, pero FPGA usa DRAM.
d. Los modelos de bus son diferentes para ASIC y FPGA. Si comparamos ASIC con FPGA, entonces
podemos decir que no hay lógica de tres estados dentro de FPGA. Y. Para el ASIC, necesitamos
características como depuración, controlabilidad y observabilidad, y faltan en el flujo de FPGA.
Entonces, durante la fase de diseño de RTL, siempre es una mejor práctica describir el RTL
diseño para ASIC y FPGA.
3. Coverificación y uso de IPs: El mayor desafío es la disponibilidad de las IPs en forma adecuada. La
mayoría de las veces, las direcciones IP no están disponibles en el formato RTL adecuado. Incluso
para lograr la velocidad deseada, es requisito que las interfaces FPGA para los simuladores o
modelos C/C++ sean fáciles de diseñar y la disponibilidad de tales interfaces con un alto ancho de
banda es un cuello de botella real. Incluso es necesario comprender las interfaces personalizadas y
otras comunicaciones.
modelos para las IP de terceros.
4. Cuellos de botella de E/S: la velocidad de emulación está limitada debido a las E/S disponibles y las
interfaces de la FPGA. El cuello de botella real debido a la velocidad de E/S es durante la recopilación
de grandes trozos de datos mientras se realiza la simulación funcional. Incluso al aplicar los
estímulos, es esencial considerar la velocidad de las IO y las interfaces.
5. Particionamiento: si los SOC se particionan de la mejor manera, entonces también la comunicación
entre el hardware y el software mediante interfaces IO es el verdadero desafío. La generación de
flujo de bits durante la programación de múltiples entornos FPGA es una tarea que requiere
mucho tiempo y la recompilación puede llevar horas.
6. Emulación en circuito: la emulación en circuito o en el entorno es uno de los desafíos
longitudes Debido a la participación de otro sistema en el entorno, lograr el rendimiento en tiempo
real es el cuello de botella si la velocidad emulada es menor que la velocidad operativa objetivo.
Considere el escenario práctico real en el que Ethernet necesita funcionar a una velocidad de
100 Mbps y luego, mientras crea prototipos, si la Ethernet de 100 Mbps tiene una velocidad de
reloj de 1/10 de la velocidad del reloj, entonces se puede lograr la velocidad deseada en el
sistema práctico.
7. Red de reloj y reinicio: otro desafío es el reloj y la red de reinicio, ya que son diferentes en el
sistema real y en el sistema emulado.
2.4 Prototipos ASIC
FPGA es el mejor candidato para la creación de prototipos ASIC o SOC. ASIC es un circuito integrado
de aplicación específica, FPGA es una matriz de puertas programables en campo y SOC es System
On Chip. Durante esta década, la densidad del SOC es muy superior en comparación con los chips
ASIC. Si consideramos esta década, los FPGA de alta densidad de Xilinx e Intel están disponibles
con las características requeridas. Las características principales pueden ser controladores de
memoria dedicados, núcleos de procesador de alta velocidad, interfaces de bus de alta velocidad, etc.
El objetivo principal del equipo de prototipos es validar el firmware, el software y el hardware del SOC
utilizando FPGA de alta densidad. La creación de prototipos ASIC es útil para reducir el tiempo de
entrega, el presupuesto y los objetivos del mercado. Para los diseños de SOC de alta densidad, la
prueba de concepto en menos tiempo y costo puede enfocarse mediante el uso de FPGA.
A medida que el nodo del proceso se redujo a 14 nanómetros, la complejidad del diseño, el riesgo
de diseño y el tiempo de desarrollo aumentaron. El principal desafío para cada organización es
desarrollar productos de menor costo con más funcionalidad en un área pequeña de silicio. En tal
escenario, los diseñadores se enfrentan a los desafíos de desarrollo y verificación. En tales
circunstancias, los FPGA de gama alta se pueden utilizar para crear un prototipo de la funcionalidad
ASIC y reduce el riesgo general. El diseño funcionalmente verificado y completamente probado en
FPGA de gama alta se puede volver a sintetizar para el ASIC de celda estándar utilizando el mismo
RTL, restricciones y scripts. Hay muchas herramientas EDA disponibles para portar un prototipo de
FPGA en ASIC estructurados. Esto realmente reduce el riesgo general en el diseño de ASIC y ahorra
dinero y tiempo de comercialización del producto.
Las siguientes son ventajas clave de la creación de prototipos ASIC utilizando FPGA
2.4 Prototipos ASIC 23
1. Inversiones: El nodo del proceso de contracción y las geometrías de los chips implican la inversión de
millones de dólares en la etapa inicial de diseño. Usando FPGA, el riesgo de inversión se reduce.
2. Riesgos: Debido a las condiciones descontroladas del mercado, existe riesgo en el diseño y desarrollo
de productos. El prototipo de FPGA reduce el riesgo, ya que las especificaciones del producto y el
diseño se pueden validar según los requisitos o cambios funcionales.
3. Facilidad de prueba: la creación de prototipos de FPGA es eficiente ya que los errores que no se
detectaron en la simulación se pueden abordar y cubrir durante la creación de prototipos.
4. Prueba y verificación del sistema: Verificación del sistema completo utilizando el prototipo FPGA
puede detectar los errores funcionales en el ciclo de diseño inicial.
5. Costo de fabricación: la creación de prototipos de FPGA ahorra millones de dólares en costos de
herramientas EDA e incluso ahorra millones de dólares en esfuerzos de ingeniería antes de la cinta
ASIC.
6. Tiempo de comercialización: como el diseño que usa FPGA se puede migrar usando las cadenas de
herramientas EDA a los ASIC, ahorra tiempo para comercializar el producto con la funcionalidad
prevista.
7. Validación e integración de IP: se pueden integrar varias IP y se puede verificar y probar la funcionalidad
del diseño, lo que puede acelerar el ciclo de diseño.
8. Partición del diseño: en la mayoría de los casos, la partición del hardware y el software se visualiza en
un nivel de abstracción más alto. El codiseño de software de hardware se puede evaluar a nivel de
hardware y es un hito más importante en el ciclo de diseño general. Entonces, la creación de prototipos
ASIC puede ser útil para ajustar la arquitectura. Si hay una sobrecarga de diseño adicional en el
hardware, entonces la arquitectura de diseño se puede cambiar insertando algunos bloques en el
software y viceversa.
Esto proporcionará una arquitectura y un diseño SOC más eficientes.
La Tabla 2.1 brinda información sobre las ventajas y desventajas de FPGA y ASIC.
Siempre hay confusión entre el prototipo y la migración. La creación de prototipos de ASIC es
básicamente el diseño o la validación de la idea para verificar la funcionalidad temprana y la viabilidad de
la idea o el diseño del producto. La migración del diseño de ASIC a FPGA involucra el flujo desde el diseño
RTL hasta la implementación y puede ser útil en la actualización del diseño con características adicionales.
Los siguientes son los puntos importantes que deben tenerse en cuenta durante la migración de diseño
y creación de prototipos ASIC utilizando FPGA de gama alta.
1. Tableros de prototipos: use el tablero de prototipos universal, ya que ahorra el tiempo de casi cuatro
meses a doce meses para el diseño y desarrollo de tableros de prototipos de alta velocidad.
2. Selección de FPGA: elija el dispositivo FPGA según la funcionalidad y el número de puertas. No es
posible colocar todo el ASIC en un solo tejido FPGA incluso si usamos las familias de gama alta de
FPGA Altera o Xilinx. Entonces, la solución práctica es el uso de múltiples FPGA. Pero el problema
real es la partición del diseño y la intercomunicación entre múltiples FPGA. Si el diseño está bien
definido y particionado correctamente, entonces la partición manual en múltiples FPGA puede dar
resultados eficientes. Si el diseño es grande y tiene una funcionalidad compleja, entonces el
Tabla 2.1 Comparación de implementación FPGA vs ASIC
FPGA Copia impresa Célula estándar ASIC estructurada

ASIC
Herramientas Hasta unos Un par de Un par de Un millón de dólares

NRE, máscara y EDA pocos miles cientos de cientos de miles dependiendo de la
US$, por lo que miles de US$ para US$ para funcionalidad del
el costo total es conversión de interconexión/máscaras diseño. Entonces el
bajo FPGA y máscaras. metálicas, por lo que el costo es alto
Así que el costo costo total es moderado
total es moderado.
Precio unitario Alto Mediobajo Mediobajo Bajo
Tiempo para volumen Inmediato Casi alrededor de Casi alrededor de Casi alrededor de

810 semanas. la 810 semanas. El 18 semanas +
adicional adicional tiempo de conversión
tiempo de conversión tiempo de conversión de otro
puede requerir para puede requerir para 18 semanas

otros estructurados otros estructurados
productos ASIC productos ASIC
Recursos de Mínimo Mínimo de Nominal pero para Alto, ya que la mayor

ingeniería y desarrolladores, los otros productos parte del trabajo
constante pero otros productos ASIC estructurados requiere el desarrollo
estructurados pueden puede requerir el desde cero y requiere
requerir ingeniería compromiso adicional un buen soporte del
adicional del equipo de backend
recursos recursos
FPGA Mismo dispositivo Para ASIC Depende del tipo de Mismo RTL pero
correlación estructurado en papel: IP utilizada y la bibliotecas,

prototipo casi idénticos, los funcionalidad. procesos, análogos
mismos elementos y paquetes
lógicos, procesos, Mismo RTL pero potencialmente
componentes bibliotecas, diferentes
analógicos y paquetes procesos, análogos y
paquetes potencialmente
diferentes
El uso de la partición automática puede desempeñar un papel importante y puede crear el
prototipo eficiente.
3. Recursos ASIC versus FPGA: Como la biblioteca de diseño para ASIC y FPGA es totalmente
diferente, el desafío clave es mapear las primitivas. Por lo tanto, es esencial mapear las primitivas
instanciadas directamente durante la síntesis o durante el nivel de implementación posterior a la
síntesis, todas las primitivas de la biblioteca ASIC deben reasignarse para obtener el prototipo
de FPGA.
4. E/S requeridas: el FPGA de gama alta puede tener entre 1000 y 1500 pines, y si se usa un solo
FPGA para el prototipo, entonces no hay ningún problema. Pero si los pines IO requieren más
pines que los disponibles en un FPGA, entonces el verdadero problema se debe a las interfaces
y la conectividad de FPGA. El problema se puede resolver utilizando la partición con el
2.4 Prototipos ASIC 25
señal y multiplexación IO. Esto asegurará la partición de diseño eficiente y el prototipo de diseño
eficiente.
5. Diseños de dominio de reloj único versus múltiple: la implementación del prototipo de diseño de
dominio de reloj único es fácil usando FPGA. Pero si el diseño tiene más de un reloj que es múltiples
dominios de reloj, entonces es bastante desafiante usar la activación del reloj y otras técnicas de
generación de relojes durante el prototipo. Entonces, la migración del diseño ASIC a FPGA necesita
más esfuerzos y soluciones sofisticadas. Una de las soluciones eficientes es convertir los diseños
en unidades de diseño más pequeñas sincronizadas por la fuente de reloj global.
6. Requisitos y modelos de memoria: los modelos de memoria utilizados en la FPGA son diferentes en
comparación con ASIC. Por lo tanto, es esencial utilizar la estrategia adecuada durante el mapeo
de memoria. La mayoría de las veces, los modelos de memoria sintetizada requeridos no están
disponibles. Bajo tal escenario, la mejor solución posible es usar la placa de prototipos con el
dispositivo de memoria específico requerido.
7. Prueba funcional y depuración: la prueba funcional completa y la depuración son uno de los principales
desafíos en la creación de prototipos ASIC. Durante esta fase, es esencial utilizar la plataforma de
depuración que puede brindar visibilidad de los resultados, como la velocidad y los resultados de
las pruebas funcionales.
La creación de prototipos ASIC se logra mediante el uso de herramientas líderes estándar de la
industria como Design Compiler FPGA. La herramienta EDA está disponible para la creación de
prototipos ASIC utilizando FPGA de gama alta. El compilador de diseño es líder en la industria en el uso
de herramientas EDA para obtener el mejor resultado de síntesis óptimo y el mejor momento para la
síntesis de FPGA. El flujo básico para la creación de prototipos ASIC se muestra en la Fig. 2.3, y en los
capítulos siguientes, discutiremos los pasos clave de la creación de prototipos ASIC y cómo podemos
lograr el prototipo ASIC eficiente.
2.5 Comandos importantes del compilador de diseño (DC)
Algunos de los comandos DC importantes se utilizan durante la compilación y optimización y se
documentan en esta sección (Tabla 2.2).
1. El prototipo ASIC y SOC se puede lograr mediante el uso de FPGA de alta densidad. En la década
actual, los FPGAs son ampliamente utilizados para la creación de prototipos y la emulación.
2. El objetivo principal de la creación de prototipos de FPGA es tener una respuesta rápida de las ideas
con un costo menor.
Fig. 2.3 Flujo del prototipo ASIC
3. Los FPGA de gama alta de Xilinx, IntelFPGA consisten en núcleos de procesador, controladores
de memoria y otras interfaces de alta velocidad y se pueden utilizar para el prototipo SOC.
4. Las especificaciones de diseño y la arquitectura de SOC juegan un papel importante durante el
diseño y creación de prototipos de ASIC, SOC.
5. La arquitectura SOC debe admitir interfaces de alta velocidad, multiprocesamiento y
IOs con alto ancho de banda.
6. El equipo de prototipos SOC puede usar las IP probadas funcionales y de tiempo durante
Diseño y prototipo del SOC.
Tabla
2.2
Comandos
importantes
del
compilador
de
diseño
[1]
establecer_no_tocar establecer_reloj_latencia
establecer_reloj_transición establecer_reloj_incertidumbre set_multicycle_path–
mantener
<período>
desde
[get_cells]–
hasta
[get_cells[ set_multicycle_path–
configure
<período>
desde
[get_cells]–
a
[get_cells[ set_false_path–
from
[get_ports
<
lista
de
puertos>]–
to
get_ports
<lista
de
puertos>] write–
format
<tipo_formato>
salida
<nombre_archivo> compile–
map_effort
<map_effort_level> set_input_delay–
clock
<nombres_reloj>
<retraso_entrada>
<puerto_entrada>
set_output_delay–
clock
<nombres_reloj>
<retraso_salida>
<puerto_salida> set_clock_skew–
rise_delay
<rising_clock_skew>
<nombre_del_reloj> create_clock–
name
<nombre_del_reloj>
period
<eriod_del_reloj>
<nombres_del_reloj> cheque_diseño elaborar–
formato
<lista
de
nombres
de
módulos> analyse–
format
<tipo_de_formato>
<lista
de
nombres
archivos> formato
de
lectura
<tipo_de_formato>
<nombre
de
archivo> dominio
el
Analice
diseño
en
busca
de
errores
sintaxis
y
traducción
antes
de
construir
el
Definir
el
sesgo
de
reloj
estimado Definir
el
sesgo
de
reloj
para
el
diseño. lógica
genérica Leer
el
diseño Descripción
Para
definir
la
fuente
estimada
y
la
latencia
de
red Para
definir
el
sesgo
de
red
estimado Para
empujar
la
retención
para
el
diseño
que
tiene
una
ruta
de
varios
ciclos Para
impulsar
la
configuración
para
el
diseño
que
tiene
una
ruta
de
varios
ciclos Para
establecer
la
ruta
falsa Para
guardar
la
salida
generada
por
la
herramienta
de
síntesis Para
compilar
con
el
nivel
de
esfuerzo
mapa
bajo,
medio
o
alto Para
configurar
el
retraso
del
puerto
de
salida Para
configurar
el
retraso
del
puerto
de
entrada Crear
el
reloj
para
el
diseño. Para
comprobar
los
problemas
de
diseño
como
cortos,
abierto,
conexión
múltiple,
instanciaciones
sin
conexiones
Se
utiliza
para
evitar
la
optimización
de
las
puertas
mapeadas. Se
utiliza
para
elaborar
el
diseño.
27 2.6 Puntos importantes para concluir el Capítulo
7. La lista de conexiones ASIC y FPGA difieren en muchos aspectos, y durante el prototipo SOC,
es esencial tener un equivalente FPGA de memorias, relojes controlados y otra lógica
personalizada.
Este capítulo nos ha brindado una comprensión de los conceptos básicos de la arquitectura
SOC, el flujo de diseño SOC y los desafíos durante el prototipo. El próximo capítulo se
centrará en el diseño RTL utilizando VHDL y las pautas de diseño RTL utilizadas con frecuencia.
Referencia
1. www.synopsys.com.
Capítulo 3
Diseño usando VHDL y pautas
“Para un diseño eficiente, los miembros del equipo de diseño deben seguir
las pautas de diseño”.
Resumen El enfoque principal de este capítulo es discutir las pautas de diseño importantes que deben
seguirse durante el ciclo de diseño de RTL. Cada organización tiene sus propios estándares y pautas y
debe usarse durante el ciclo de diseño para obtener un resultado de diseño eficiente. En tal escenario,
el capítulo describe lo que se debe y lo que no se debe hacer durante el diseño de RTL, las
construcciones de diseño importantes de VHDL y la lógica inferida usando el esquema de RTL.
Palabras clave RTL VHDL If then else Caso Anidado if then else Proceso
Lista de sensibilidad Sensibilidad vacía Agrupación Lógica paralela Lógica de prioridad
Múltiples diseños de dominio de reloj ∙ Sincronizador de nivel ∙ Uso compartido de recursos ∙
Activación de reloj ∙ Habilitación de reloj ∙ Síntesis
3.1 Pautas de diseño de RTL
Las siguientes son las pautas utilizadas durante el ciclo de diseño de RTL
1. Evite los bucles combinacionales en el diseño.
2. Para evitar los desajustes de simulación y síntesis, use la lista completa de entradas requeridas,
variables temporales y señales mientras usa el bloque de proceso. ¡En palabras simples, use la
lista completa de sensibilidad mientras usa los bloques de procedimiento!
3. Elimine los pestillos no intencionales potenciales usando 'cuando otros' en la construcción del caso
o usando todas las condiciones del caso en las construcciones del caso.
4. Trate de cubrir todas las demás condiciones, ya que la falta de otra puede inferir los pestillos en el
diseño.
5. Si la intención es diseñar la lógica de prioridad, utilice el ifthenelse anidado
construir.
6. Para inferir la lógica paralela, use la construcción de caso.
https://doi.org/10.1007/9789811513145_3
30 3 Diseño usando VHDL y pautas
7. Para evitar fallas en el diseño, use las FSM de codificación onehot.
8. No implemente el FSM con la combinación de pestillos y registros.
9. Inicialice los estados de FSM no utilizados usando reset o usando when others.
10. Use el bloque de proceso separado para el siguiente estado, registro de estado y lógica de salida.
11. Para las máquinas Moore, use el proceso (estado_actual) para el bloque lógico de salida, y para
la máquina harinosa, use el proceso (estado_actual, entradas) para la lógica de salida.
12. No haga las asignaciones a la misma variable o salida en los múltiples bloques de proceso.
13. Use el bloque de proceso separado para cada módulo funcional activado en los diferentes relojes.
14. Cree el diseño separado para el nivel multiflop o el sincronizador de pulsos y ejecútelos mientras
pasa los datos entre dos dominios de reloj.
15. Intente que el proveedor de diseño de RTL sea independiente utilizando la inferencia.
3.2 Escenarios prácticos de diseño RTL
La siguiente sección analiza los escenarios de diseño de RTL importantes y los ajustes de RTL para
mejorar el rendimiento del diseño. Algunas de las técnicas como la agrupación y el intercambio de
recursos se analizan en este capítulo. Para obtener más detalles sobre la mejora del rendimiento en
RTL y la etapa de síntesis, consulte los siguientes capítulos.
3.2.1 Lista de sensibilidad incompleta
La lista de sensibilidad incompleta infiere los pestillos no intencionales. La herramienta de síntesis
ignora la lista de sensibilidad e infiere la lógica combinacional como puerta XOR para los Ejemplos 1,
2, 3.
Ejemplo 1: descripción de VHDL utilizando la lista de sensibilidad completa
biblioteca
utilizar ieee; ieee.std_logic_1164.todos;
utilizar ieee.std_logic_arith.todos;
utilizar ieee.std_logic_unsigned.all;
entidad comb_logic es
b_in ( a_in, puerto : en std_logic ;
tu_fuera : fuera std_logic);
fin
peine_logico; arquitectura arch_comb_logic de comb_logic es
3.2 Escenarios prácticos de diseño RTL 31
comenzar
proceso sensible a las entradas a_in y b_in
proceso empieza
(a_in, by_in)
_sale
el
finaliza el proceso; final
< = a_in xor
arch_comb_logic; compartimiento;
Considere el Ejemplo 2; en este, una de las entradas requeridas 'b_in' falta en la lista de
sensibilidad y, en tales circunstancias, habrá una falta de coincidencia entre la simulación previa y
posterior a la síntesis.
Ejemplo 2: descripción de VHDL con la lista de sensibilidad incompleta
comienza la arquitectura arch_comb_logic
de comb_logic
proceso sensible a las entradas a_in y b_in
proceso comienza
( a_in )
y_out finaliza
< = a_en b_en; xor
proceso;
final arch_comb_logic;
Si la lista de sensibilidad está vacía, entonces el bloque de proceso se bloquea durante la
simulación y es como un bucle infinito. La herramienta de síntesis infiere la puerta lógica
combinacional XOR.
Ejemplo 3: descripción de VHDL con la lista de sensibilidad vacía
comienza la arquitectura arch_comb_logic
de comb_logic
proceso sin ninguna lista de sensibilidad
proceso
comienza
y_out < = a_en xor compartimiento;
finaliza proceso;
final
arch_comb_logic;
3.2.2 Caso frente a sientoncessi no
Las construcciones secuenciales importantes son 'case' y 'ifthenelse' y se utilizan para inferir la
lógica paralela y el diseño de prioridad, respectivamente. Estas construcciones se utilizan en el
proceso de bloque de procedimiento. La mayoría de las veces, la lógica de ruta de datos que es
lógica combinacional en la ruta de registro a registro decide sobre la sincronización del diseño general.
Dependiendo del escenario, el diseñador puede usar la construcción 'caso' o la construcción 'si
entoncesotro' para inferir la lógica prevista requerida.
Considere el código VHDL de 4: 1 MUX (Ejemplo 4) usando la construcción 'case', la
construcción case se usa dentro del proceso y, como todas las entradas tienen la misma prioridad,
infiere la lógica paralela.
Ejemplo 4: Descripción de VHDL usando 'Caso final de caso'
Código VHDL para biblioteca
MUX 4:1 ieee.std_logic_1164.todos;
ieee;
utilizar entidad mux_4to1 es puerto
( d_in sel_in
: en std_logic_vector (3 hasta 0); en
: std_logic_vector (1
std_logic); fin m a 0); q_out fuera
ux_4to1;
:
Descripción de la funcionalidad usando el caso
arquitectura arch_mux_4to1 de mux_4to1 es
comenzar
proceso sensible a la entrada de datos y selección de
cuando “01” entrada
qdel
_out
proceso
>(q_out
d_in,
< d_in(2);
(sel_in)
ds_in(0);
el_in)
cuando
ecds
aso
_en(1);
cuando
“d10”
e inicio
q"_out
00"
> < d_in(3); cuando otros q_out > <
=> <=
= =
= =
= =
fin del ;
caso del
fin ;
proceso
fin
arch_mux_4to1;
El resultado de la síntesis se muestra en la Fig. 3.1 y, como se muestra, infiere MUX 4:1 con
4 líneas de entrada y una sola línea de salida. Las entradas seleccionadas se utilizan para
controlar el flujo de datos desde una de las entradas a la salida del multiplexor. Multiplexor es
lógica universal y se llama tantos a un interruptor. ¡Los multiplexores se utilizan ampliamente en
los esquemas de multiplexación IO!
El MUX 4:1 que utiliza el ifthenelse anidado se describe en el ejemplo 5. Debido a la
el uso de la declaración secuencial ifthenelse infiere la lógica de prioridad.
Se muestra el resultado de la síntesis (Fig. 3.2) y la entrada d_in(0) tiene la prioridad más
alta, y d_in(3) tiene la prioridad más baja. La lógica de prioridad de 4:1 MUX tiene
3.2 Escenarios prácticos de diseño RTL 33
lógica para realizar la decodificación. Como se muestra, la lógica de decodificación controla la transferencia
de datos desde la cadena en cascada del multiplexor 2:1 (Fig. 3.2).
Ejemplo 5: Descripción de VHDL usando Ifthenelse anidado
Código VHDL para la biblioteca MUX
de prioridad
ieee.std_logic_1164.todos;
4:1 ieee;
utilizar entidad mux_4to_priority es ( en
std_logic_vector
downto : (e3
n
0s);
td_logic_vector
puerto 0);
d_in
sel_in
(1
downto: sfinal
td_logic);
mux_4to1_priority;
q_out out :
Descripción funcional usando ifthenelse anidado
arquitectura arch_mux_4to1_priority de mux_4to1_priority es comenzar
Procesar sensible a los datos y seleccionar la entrada
inicio del proceso
( d_in, sel_in)
si (sel_in="00") entonces
< = elsif
q_out d_in(0);
(sel_in="01") luego
d_in(1); elsif q_out
< = q_out
(sel_in="10") luego
d_in(2);
<=
más
q_out < = d_en(3);
termina s; i
fin del proceso ;
fin arch_mux_4to1_priority;
Fig. 3.1 Resultado de la síntesis de 4:1 MUX usando el caso [1]
3.3 Agrupación de los términos
Para mejorar el rendimiento del diseño, se puede utilizar la agrupación de términos. Esto
se puede lograr usando paréntesis. Considere el ejemplo 6 que se muestra a continuación.
En este ejemplo, el resultado de (a_in + b_in − c_ind_in) se asigna a y_out. Sin la
agrupación, la herramienta de síntesis da como resultado la red en cascada de los
elementos lógicos aritméticos.
Ejemplo 6: Descripción de VHDL sin agrupar los términos
biblioteca
entidad sin_agrupación es
puerto (a_in, b_in, c_in, d_in : en std_logic_vector (1 a 0);
tu_fuera : fuera std_logic_vector (1 a 0));
terminar sin_agrupar;
arquitectura arch_sin_agrupar de sin_agrupar es
comenzar
Asignación sin utilizar la agrupación de términos
tu_fuera < = a_en + b_en c_en d_en;

end arch_sin_agrupar;
Fig. 3.2 Resultado de la síntesis de 4:1 MUX utilizando ifthenelse anidado
3.3 Agrupación de los términos 35
Fig. 3.3 Resultado de la síntesis de la descripción VHDL sin agrupación de términos [1]
El resultado de la síntesis se muestra en la Fig. 3.3 y, como se muestra, la lógica tiene
tres elementos combinados nacionales y están conectados en cascada. En palabras simples,
es lógica combinacional y el retraso general es n*tpd. Donde n = número de elementos
combinacionales y tpd = retardo de propagación del elemento.
La descripción de RTL en el ejemplo 6 se puede modificar mediante el uso de paréntesis.
El código modificado se muestra en el Ejemplo 7 y usa la expresión como y_out = (a_in +
b_in) − (c_in + d_in).
Ejemplo 7: Descripción de VHDL utilizando la agrupación de los términos
biblioteca
entidad con_agrupación es
puerto ( a_in, b_in, c_in, d_in : en std_logic_vector (1 a 0);
tu_fuera : fuera std_logic_vector (1 a 0));
terminar con_agrupación;
arquitectura arch_with_grouping de with_grouping es
comenzar
Asignación utilizando la agrupación de términos
tu_fuera < = (a_en +

−
compartimiento) (c_en + estruendo) ;
fin arch_with_grouping;
El resultado de la síntesis se muestra en la Fig. 3.4 e infiere la lógica paralela en el lado
de entrada debido al uso de paréntesis. Debido al uso del paréntesis, deduce dos sumadores
y un restador durante la síntesis. La operación de resta se puede implementar usando la
suma en complemento a 2. Si el retraso de cada elemento es de 1 ns, entonces el retraso de
propagación general es de 2 ns. Esta técnica se utiliza para mejorar el rendimiento del diseño.
Fig. 3.4 Resultado de la síntesis para el código VHDL utilizando la agrupación de los términos
3.4 Buses Tristate y Lógica
El triestado tiene tres valores lógico '0', lógico '1' y alta impedancia 'z'. Los buses tristate
se utilizan para comunicarse con los otros módulos de diseño. Más información sobre los
buses y las interfaces se discute en los capítulos siguientes. El Ejemplo 8 describe la
lógica de tres estados. Se recomienda utilizar la lógica de tres estados en la parte superior
del diseño para evitar la contención del bus. En lugar de usar la lógica de tres estados, es
mejor idea usar la lógica basada en MUX con la habilitación.
Ejemplo 8: Descripción de VHDL para Tristate Logic
biblioteca
ieee;
utilizar ieee.std_logic_1164.todos;
entidad tri_estado es
( puerto a_in, enable_in en std_logic : ;
y_fuera : std_logic);
final tri_estado;
Descripción de la lógica del bus Tristate usando ifthenelse
arquitectura arch_tri_state de tri_state es
comenzar
Proceso para definir la salida como alta impedancia para enable_in='0'
(a_in, enable_in) proceso
comenzar
si (habilitar_in='1') entonces
tu_fuera < = entrar;

3.4 Buses Tristate y Lógica 37
más
tu_fuera <='Z';
terminara
si;
proceso finalizado;
final arch_tri_state;
La Figura 3.5 muestra el resultado de la síntesis para la lógica de tres estados y la lógica se puede
usar para pasar los datos cuando 'enable_in' es igual a '1' lógico. Para la entrada de habilitación de
lógica '0', la salida de la lógica de tres estados es de alta impedancia que es un contacto libre de potencial.
3.5 Compartir recursos
En la mayoría de los escenarios prácticos de diseño, los recursos comunes se pueden compartir
utilizando los conceptos fundamentales del diseño lógico. Por ejemplo, si se usan sumadores y consumen
más área, entonces el área se puede reducir compartiendo el sumador común como recurso. Esta
técnica juega un papel importante en la reducción del área y, por lo tanto, optimiza el diseño para los
conteos de puertas requeridos. En lugar de usar una mayor cantidad de sumadores, es una mejor
práctica usar una mayor cantidad de multiplexores en el diseño.
Considere el código VHDL descrito en el Ejemplo 9 para la Tabla de verdad 3.1: Tabla de verdad para
las operaciones aritméticas. Como se describe en el código VHDL, la salida debe asignarse según la
condición de la entrada seleccionada. Para 'sel_in = 1', la salida 'y_out' se asigna a 'a_in + b_in', y para
'sel_in = 0', se asigna una salida 'y_out' a 'c_in + d_in'.
Fig. 3.5 Resultado de la síntesis
para la lógica triestado [1]
Tabla 3.1 Tabla de verdad para las
sel_in tu_fuera
operaciones aritméticas
0 c_en + d_en
1 a_en + b_en
Ejemplo 9: Descripción de VHDL para realizar sumas sin recursos
Intercambio
biblioteca
ieee; ieee.std_logic_1164.todos;
utilizar
ieee.std_logic_arith.all;
ieee.std_logic_unsigned.all;
utilizar utilice
la entidad resource_sharing es
(a_in,b_in,c_in,d_in:
en std_logic en
std_logic_vector
(de
std_logic_vector
1 a 0)); y_out:
(o
de
ut
1e nd
a 0r);
esource_sharing;
puerto sel_in:
;
Descripción funcional sin empujar los recursos comunes
comienza la arquitectura arch_without_sharing de resource_sharing
Proceso sensible a todas las entradas y señales de control
del proceso(a_in, b_in, c_in, d_in, sel_in) inicio
si (sel_in='1') entonces
<=
y_out a_in + compartimiento;
más
tu_fuera < = c_en + estruendo;
terminara
si ;
proceso
finalizado;
end
arch_sin_compartir;
El resultado de la síntesis de la lógica aritmética sin utilizar el concepto de recursos
compartidos se muestra en la Fig. 3.6. Como se muestra en la figura 3.6, la lógica infiere
dos sumadores y un solo multiplexor. Los sumadores se utilizan en la ruta de datos para
realizar la suma. La salida del multiplexor está controlada por la entrada 'sel_in'; y para
la entrada 'sel_in' como lógica '1', genera una salida que es la suma de 'a_in', 'b_in'. Para
la condición lógica '0' de 'sel_in', genera una salida como suma de 'c_in', 'd_in'.
Fig. 3.6 Resultado de la síntesis para la descripción de VHDL sin compartir recursos comunes [1]
3.5 Compartir recursos 39
Tabla 3.2 Tabla de verdad para
sel_in sig_1 Sr_2 tu_fuera
las operaciones aritméticas para
compartir recursos 0 c_en estruendo c_en + d_en
1 a_en compartimiento a_en + b_en
La lógica generada tiene un problema, ya que ambos sumadores están realizando
operaciones al mismo tiempo; tan innecesario que es desperdicio de energía y aún más área.
Los datos después de realizar las adiciones esperan en las líneas de entrada de los
multiplexores y, según el estado de la línea seleccionada, se asigna la salida. Entonces, este
tipo de técnica es menos eficiente y tiene más número de puertas y más disipación de energía.
Para superar esta limitación, se utiliza el uso compartido de recursos donde el recurso común
se comparte empujando el sumador hacia los multiplexores. Entonces, al compartir recursos,
se usan más multiplexores y menos sumadores.
Como se discutió anteriormente, el sumador de recursos comunes se puede compartir
empujando la cadena de multiplexores en la entrada y usando el sumador en la salida. La
Tabla 3.2: Tabla de verdad para las operaciones aritméticas para compartir recursos; da
información sobre la estrategia utilizada para compartir los recursos comunes.
Al modificar el código, se puede lograr el intercambio de recursos. El código RTL modificado
se describe en el Ejemplo 10 y usa las señales temporales como 'sig_1' y 'sig_2'. Para el
estado lógico '0' en la línea de selección 'sel_in', 'sig_1' contiene la entrada 'c_in' y 'sig_2'
contiene el valor de entrada 'd_in'. Para el estado lógico '1' en la línea de selección 'sel_in',
'sig_1' contiene la entrada 'a_in' y 'sig_2' contiene el valor de entrada 'b_in'.
Ejemplo 10: Descripción de VHDL para insertar recursos comunes en la salida [1]
biblioteca ieee;
puerto std_logic_vector
(de 1e n
a 0);
sel_in: en std_logic y_out: fuera de
std_logic_vector (de 1 a 0;)); fin de compartir_recursos;
La descripción funcional usando compartir recursos comunes
la arquitectura arch_with_sharing de resource_sharing es la señal
: std_logic_vector
sig_1, sig_2 (de 1 a 0); comenzar
El proceso para asignar las señales intermedias a las entradas requeridas
P1: (a_in, b_in, c_in, d_in, sel_in) proceso
Fig. 3.7 Resultado de la síntesis para la descripción de VHDL utilizando el concepto de uso compartido de recursos [1]
empezar
si (sel_in='1') entonces
<=
sig_1 sig_2 a_en;
<= compartimiento;
más
sig_1 < = c_en;
sig_2< = estruendo;
terminara
si ;
El proceso para obtener la salida del sumador de recursos comunes
P2: ( sig_1,
comienza
sig_2)
y_out
proceso
final proceso
final arch_with_sharing;
< = sig_1 + sig_2;
;
El resultado de la síntesis del Ejemplo 10 se muestra en la Fig. 3.7. Como se muestra en la
figura, la lógica se realiza utilizando el sumador único y dos multiplexores. Como un sumador
consume menos área, el diseño es eficiente y tiene menos número de puertas y menos energía.
En este diseño, solo se realiza una operación a la vez.
3.6 Sincronizador de nivel
Los diseños complejos de ASIC o el diseño que utiliza FPGA pueden tener dominios de reloj
únicos o múltiples. Un diseño de dominio de reloj único no tiene el problema de la integridad
de datos o la convergencia de datos. Pero si el diseño tiene múltiples relojes, entonces el
verdadero problema es cuando los datos pasan de un dominio de reloj a otro dominio de reloj.
Para evitar problemas de metaestabilidad e integridad de datos, los datos de un solo bit o control
3.6 Sincronizador de nivel 41
las señales se pueden pasar del dominio de reloj I al dominio de reloj II usando los sincronizadores
de nivel de dos etapas o multietapa.
El ejemplo 11 describe el escenario de diseño de múltiples dominios de reloj. Pero en la
práctica, puede haber un diseño separado para el dominio de reloj I y el dominio de reloj II. Cree
una instancia del bloque sincronizador mientras pasa datos del dominio de reloj uno al dominio
de reloj dos.
Ejemplo 11: Descripción de VHDL para el sincronizador de nivel
biblioteca
utilizar
la entidad clock_domain_crossing es
arch_mult_clock
(a_in
std_logic);
b_in cdlk_1,
e
y_out end port : en std_logic
, clock_domain_crossing;
c,lock_domain_crossing
arquitectura
clk_2 ;
: afuera es
sig_domain_1 sig_domain_2
señal
std_logic begin
, : ;
El proceso sensible al dominio del reloj I
P1: proceso (clk_1)
empezar si rise_edge (clk_1) luego
< =y b_in; terminara
sig_domain_1 a_in
si; proceso finalizado;
El proceso sensible al dominio del reloj II
P2: proceso (clk_2)
empezar si rise_edge (clk_2) luego
<=
sig_domain_2 sig_domain_1;
<
termina s=i; sig_dominio_2;
y_out
fin
arch_mult_clock;
El resultado de la síntesis se muestra en la Fig. 3.8 y como se muestra al pasar los datos del
dominio de reloj I al dominio de reloj II; Se utiliza un sincronizador de dos niveles. Este tipo de
sincronizador también se denomina sincronizador multiflop. La salida del sincronizador de dos
niveles es un estado legal válido aunque el primer flipflop en el segundo dominio de reloj entra
en el estado metaestable.
3.7 Relojes cerrados
El reloj es una red hambrienta en el diseño. Debido al cambio de reloj, el diseño tiene una disipación de
energía más dinámica. La disipación de energía se puede reducir utilizando las celdas de sincronización
del reloj. El diseño que utiliza el concepto de sincronización de reloj se describe en el Ejemplo 12.
El resultado de la síntesis se muestra en la Fig. 3.9.
Ejemplo 12: Descripción de VHDL para reloj cerrado
biblioteca
ieee;
la entidad gated_clock es
(data_in, clk,
fin gated_clock; en el puerto std_logic std_logic); y_out: ;
clock_en:
load_en,
afuera
arquitectura arch_gated_clock de gated_clock
es la señal
clock_gate: std_logic begin clock_gate;
< = (clk y clock_en);
El proceso es sensible a la carga y la entrada de la puerta del reloj
proceso (load_en, clock_gate) comienza
if (clock_gate='1' y clock_gate'event) entonces if
(load_en='1') then y_out data_in; terminara si;
<=
terminara
si; proceso
finalizado;
final arch_gated_clock;
Como se muestra en el resultado de la síntesis, la entrada de reloj del registro se controla mediante
el uso de 'clock_gate'. Donde la señal 'clock_gate' se genera mediante el uso de la lógica AND.
Pero este tipo de estrategia de activación es propensa a fallas. Para evitar fallas, es
Fig. 3.8 Resultado de la síntesis para la descripción de VHDL usando múltiples relojes [1]
3.7 Relojes cerrados 43
Fig. 3.9 Resultado de la síntesis para la descripción de VHDL usando sincronización de reloj [1]
Se recomienda utilizar las celdas de sincronización del reloj. Para inferir la sincronización del reloj,
use las directivas de la herramienta EDA específicas del proveedor. La activación del reloj ASIC
puede no ser equivalente funcional a las estrategias de activación del reloj FPGA. En este tipo de
escenarios, es obligatorio ajustar el RTL o usar la conversión de activación del reloj mientras se
realiza el diseño con FPGA. Las conversiones y los ajustes de activación del reloj se analizan con
más detalle en los próximos capítulos.
3.8 Activaciones de reloj
El diseño secuencial puede tener una señal de habilitación adicional. Dependiendo del estado de la
señal de habilitación, los datos de entrada se pueden transferir a la salida. El ejemplo 13 describe el
VHDL RTL que tiene la entrada de habilitación y el resultado de la síntesis se muestra en la figura 3.10.
Ejemplo 13: Descripción de VHDL usando Clock Enable
biblioteca
ieee;
la entidad clock_enable es
(data_in, clk,
clock_enable; clock_en:
load_en, ;
en el puerto std_logic std_logic); y_out: end
afuera
arquitectura arch_clock_enable de clock_enable es la señal
: std_logic;
clock_enable begin clock_enable
< = cargar_en y reloj_en;
El proceso sensible al reloj, habilitación y entrada de datos
(clk, data_in, clock_enable) proceso
Fig. 3.10 Resultado de la síntesis para la descripción VHDL usando la habilitación del reloj
comenzar
if (clk='1' y clk'event) luego if
(clock_enable='1')
y_out data_in; luego
<=
si ;
terminara
si ;
terminara
proceso
finalizado; fin
arch_clock_enable;
Como se muestra en el resultado de la síntesis, la lógica de habilitación del reloj se genera y se utiliza
en la ruta de habilitación del flipflop.
Más pautas relacionadas con los escenarios prácticos durante la fase de creación de prototipos de SOC
y su interpretación será discutida en algunos de los próximos capítulos.
1 Cada organización tiene sus propias pautas y convenciones de nomenclatura.
2 Durante el ciclo de diseño de RTL, use las convenciones de nomenclatura y las pautas de diseño.
3 Para evitar el desajuste de la simulación y la síntesis, utilice la lista de sensibilidad completa.
4 No use 'Buffer' ya que durante la síntesis crea el problema. Utilice 'inout' con la señal intermedia adecuada para el
bucle de retorno de las señales.
5 Use la construcción 'case' para la lógica paralela y use la construcción 'ifthenelse' para la lógica de prioridad.
6 Para un mejor diseño de sincronización y restricción, use la entrada registrada y
producción.
7 No utilice la lógica de pegado entre diferentes módulos, sino que combine la lógica de pegado en el diseño requerido.
8Utilice la canalización para mejorar el rendimiento del diseño.
9 Use más cantidad de multiplexores en comparación con el sumador. Adder consume más área en comparación
con los multiplexores.
10 Use la lógica de tres estados en el nivel superior o modele el comportamiento de tres estados usando la lógica de
multiplexación adecuada con entrada de habilitación.
3.9 Puntos importantes para concluir el Capítulo 45
11 Utilice la agrupación de los términos entre paréntesis para reducir la propagación general
demora.
12 Describa todas las condiciones en la construcción 'caso' y cubra todas las demás condiciones mientras usa la
construcción 'ifthenelse' para evitar la inferencia de pestillos no intencionales.
13 Los pestillos se infieren en el diseño si la condición 'otra' no está cubierta. Incluso si no se cubren todas las
condiciones en la construcción del 'caso', se deducen pestillos no intencionales.
14 Use el sincronizador de dos niveles o multinivel para pasar los datos de uno de los dominios de reloj a otro dominio
de reloj.
15 Utilice la técnica de duplicación lógica para mejorar el rendimiento general del diseño.
Según el escenario, la duplicación lógica puede aumentar el número de puertas o puede reducirlo.
16 Tener rutas de datos y control limpias en el diseño. Trate de adelantar la señal de llegada tardía en comparación
con las señales de llegada temprana. Esto tendrá una mejor sincronización y se puede usar para eliminar las
violaciones del tiempo de configuración.
17 Utilice un reloj controlado para la disipación de baja potencia. Use una puerta de reloj dedicada
célula.
Este capítulo nos ha dado una buena comprensión sobre las pautas de diseño y el uso de las construcciones
VHDL importantes. El siguiente capítulo describe el diseño RTL usando VHDL para diseños de uso frecuente.
Incluso el capítulo trata sobre las construcciones VHDL importantes y su uso durante el diseño para una
síntesis lógica eficiente.
Referencia
1. www.xilinx.com.
Capítulo 4
Escenarios de diseño VHDL y síntesis
“siempre es mejor elegir las construcciones eficientes que pueden
dar lugar a la lógica óptima deseada”.
Resumen El capítulo describe los pocos escenarios de diseño RTL importantes que pueden surgir
durante la fase de diseño. La mayoría de las veces, para obtener el resultado deseado de la síntesis,
debemos ser cuidadosos al elegir las construcciones requeridas. El objetivo del diseñador RTL es
percibir el resultado del diseño en el nivel más bajo de abstracción. Las restricciones de área,
velocidad y potencia se utilizan durante la etapa de síntesis. En tal contexto, el capítulo analiza
algunos escenarios de diseño importantes.
Palabras clave RTL VHDL If then else Caso Proceso Síntesis ASIC Síntesis FPGA Multiplicadores
Canalización Diseños de dominio de reloj múltiple Contadores grises Contadores binarios Utilización
de recursos Uso compartido de recursos Compuerta de reloj Equilibrio de registros Duplicación
lógica
4.1 Convertidores de código y dominio de reloj múltiple
4.1.1 Convertidor de código binario a Gray
En dos de los números binarios sucesivos, pueden cambiar múltiples bits, pero en los dos números
grises sucesivos, solo cambia un bit. Por lo tanto, durante el diseño de múltiples diseños de dominio
de reloj, la mayor parte del tiempo, usamos los punteros y contadores grises. Imagine un escenario
en el que los datos deben pasar del dominio del reloj I al dominio del reloj II, en este tipo de diseños
se pueden usar los punteros grises. El diseño utiliza convertidores de código binario a gris y
convertidores de código gris a binario.
El código VHDL del ejemplo 1 es una descripción del código binario a gris de 4 bits
convertidor.
© Springer Nature Singapore Pte Ltd. 2020 47
V. Taraate, síntesis lógica y creación de prototipos
SOC, https://doi.org/10.1007/9789811513145_4
48 4 escenarios de diseño VHDL y síntesis
Fig. 4.1 Convertidor de código binario a código Gray de cuatro bits [1]
Ejemplo 1: Descripción de VHDL para convertidor de código binario a Gray
biblioteca
IEEE; IEEE.STD_LOGIC_1164.TODO;
utilizar
definición de puerto para el convertidor de código binario a gris
entidad binarytogray es
Puerto (binary_data : en std_logic_vector(3 hasta 0); 0) );
: std_logic_vector(3 downto end
gray_data out
binarytogray;
definición de funcionalidad para el convertidor de código binario a gris
Comienza la arquitectura de comportamiento de
binarytogray
datos_grises(3)<=
atos_grises(2)< xor datos_binarios(2);
= ddatos_binarios(3)
datos_binarios(3);
= datos_binarios(2) xor datos_binarios(1);
= datos_binarios(1) xor datos_binarios(0);
datos_grises(1)<datos_grises(0)<
fin conductual;
El resultado de la síntesis del convertidor de código binario a gris de 4 bits se muestra en la Fig.
4.1. Como se muestra, utiliza datos binarios como entrada y genera los datos grises como salida.
Para un mejor resultado de la síntesis, el diseñador de RTL puede implementar los convertidores de
código como un diseño separado y puede instanciarlo cuando sea necesario.
4.1.2 Convertidor de código Gray a binario
La aplicación principal del convertidor de código binario a gris es recuperar los datos binarios. El
convertidor de código binario a código gris de 4 bits que utiliza construcciones VHDL se describe en
el ejemplo 2.
4.1 Convertidores de código y dominio de reloj múltiple 49
Fig. 4.2 Convertidor de código binario a gris de cuatro bits [1]
Ejemplo 2: Descripción de VHDL para el convertidor de código binario a gris
biblioteca
utilizar
descripción del pin para el convertidor de código binario a gris
entidad gris a binaria es
Puerto ( gray_data : en std_logic_vector ( 3 hasta 0); fuera
binary_data : std_logic_vector ( 3 hasta 0));
end graytobinary;
descripción funcional del convertidor de código binario a gris de cuatro bits
arquitectura arch_graytobinary de graytobinary es
señal tmp_binary_data : 3 hasta (0); std_logic_vector

comienza
tmp_binary_data(3) <=
< = gray_data(3) xor datos_grises(2);
datos_grises(3); tmp_binary_data(2)
tmp_datos_binarios(1) < = tmp_binary_data(2) xor datos_grises(1);
tmp_datos_binarios(0) < = tmp_binary_data(1) xor datos_grises(0);
datos_binarios< = tmp_binary_data;
final arch_graytobinary;
El resultado de la síntesis del convertidor de gris a binario de 4 bits se muestra en la Fig. 4.2.
4.2 Síntesis para Múltiples Arquitecturas
La descripción de VHDL debe tener una sola entidad, pero puede admitir arquitectura única o
múltiple. La arquitectura se utiliza para describir la funcionalidad del diseño y varias arquitecturas se
ejecutarán en paralelo. Si la construcción de configuración no se usa en el diseño de RTL, la última
arquitectura descrita en la descripción de VHDL
estar acoplado con la entidad. La herramienta de síntesis inferirá la lógica dependiendo de
la funcionalidad descrita en la última arquitectura.
Durante la etapa de diseño RTL, la mayor parte del tiempo, necesitamos explorar
diferentes posibilidades para describir la funcionalidad del diseño. Por ejemplo, el uso de 'if
thenelse' y 'caseend case' para la misma funcionalidad de diseño. En tales circunstancias,
en lugar de tener dos diseños RTL diferentes, es mejor que podamos tener varias arquitecturas.
Según el requisito, se puede elegir una de las arquitecturas utilizando la construcción de
'configuración'.
Ejemplo 3: Descripción de VHDL usando múltiples arquitecturas
múltiples definiciones de arquitectura
y biblioteca de
configuración
utilizar
utilizar
utilizar
para el diseño
ieee.std_logic_arith.todos; Descripción de la entidad Describe los puertos de entrada y salida dependientes.
ing cariño la especificación de diseño
entidad multiple_architecture es
port ( s_in
in :sstd_logic);
std_logic
std_logic
in td_logic
yb_out
_in iaon
terminar _in
ut ;
:
multiple_architecture; ;
: ;
:
Definición de arquitectura que es una descripción funcional para el diseño.
arquitectura arch_design_1 de multiple_architecture es
comenzar y_out a_in b_in s_in; xor xor final arch_design_1;
<=
Definición de arquitectura para el diseño
arquitectura arch_design de multiple_architecture es comenzar
y_out a_in y b_in y s_in; < fin arch_design;
=
Para seleccionar la funcionalidad requerida, la la configuración con
estructura se describe a continuación
la configuración conf_arch1 de multiple_architecture es
Para arch_design_1
fin Para;
final conf_arch1;
Como se describe en el Ejemplo 3, se elige 'arch_design_1' para inferir la lógica XOR. Si
no se utiliza la configuración , la última arquitectura se combinará con la entidad para inferir
la lógica. El resultado de la síntesis se muestra en la Fig. 4.3.
4.3 Definición y síntesis de señales 51
Fig. 4.3 Lógica inferida para el
diseño de múltiples arquitecturas
[1]
4.3 Definición y síntesis de señales
Las señales son hilos intermedios utilizados para la conexión de las diferentes instancias.
La Tabla 4.1 ofrece algunos puntos destacados importantes para las asignaciones de señales.
La descripción de VHDL que usa las asignaciones de señales se muestra en el Ejemplo 4.
Como se ha descrito, la 'señal_1, señal_2' se utilizan para establecer las conexiones intermedias entre
puertas lógicas o celdas. La 'señal_2' se actualiza al final del proceso para inferir la lógica (Fig. 4.4).
Ejemplo 4: Descripción de VHDL usando asignaciones de señales
biblioteca de asignaciones
de señales ieee;
entidad señal_asignación es puerto
(a_in, b_in, c_in, d_in, e_in : en std_logic ;
Tabla 4.1 Puntos importantes
Las señales son globales para la arquitectura.
relacionados con las asignaciones de señales
Las señales se actualizan cuando la ejecución del proceso se suspende, es
decir, al final del proceso.
En la asignación de la señal, se puede especificar el retardo
A la misma señal dentro del proceso, si se utilizan múltiples asignaciones,
entonces la última asignación es efectiva
Fig. 4.4 Lógica inferida usando las asignaciones de señales [1]
y1_out , y2_out fuera : std_logic);

end signal_assignment;
arquitectura arch_signal de signal_assignment es
señal señal_1, señal_2 : std_logic ;
comienzan
< = (c_in,
señal_1 b_in; a_ensxoreñal_1,
señal_2)
comienza
proceso; y2_out (pe_in
no roceso
y1_salida
señal_2
end
finaliza
arch_signal;
< = no señal_2;
< = señal_1 xor c_en;
<= xor d_en);
4.4 Asignación de variables y síntesis
Las variables son locales para el proceso y, cuando se usan, se actualizan instantáneamente.
Durante el diseño RTL, es esencial elegir entre señales y variables. La Tabla 4.2 brinda información
sobre aspectos destacados importantes con respecto a las asignaciones de variables.
La descripción de VHDL usando la asignación de variables se muestra en el Ejemplo 5.
Ejemplo 5: Descripción de VHDL usando asignaciones de variables
asignaciones de variables
biblioteca
entidad variable_assignment es
( puerto a_in, b_in, c_in, d_in, e_in a std_logic :
y1_fuera fuera ;
std_logic);
, y2_fuera:
fin variable_asignación;
arquitectura arch_variable de variable_assignment es
Cuadro 4.2 Puntos importantes
Las variables son locales al proceso.
relacionados con la asignación de
variables Las variables se actualizan instantáneamente y el evento no está
programado
Las asignaciones de variables no se pueden retrasar
Muchas asignaciones a la misma variable son efectivas
4.4 Asignación de variables y síntesis 53
Fig. 4.5 Lógica inferida para las asignaciones de variables [1]
comenzar
variable de
( a_in,
proceso
b_in,
variable_1 ,
c_in, d_in,
variable_2,
e_in)
variable_3, variable_4: std_logic ;
comenzar
variable_1 a_in = b_in; : c_in; :
variable_2 xor
variable_1
xor
= variable_3
y1_out no variable_2; (variable_2
(variable_2 no :
variable_4
y2_out no :
< =< terminar proceso
variable_4;
= xor e_en);
);
= d_in xor
=
;
end arch_variable;
El resultado de la síntesis se muestra en la Fig. 4.5. Y como se muestra, como las variables se
actualizan instantáneamente, la lógica inferida es diferente en comparación con las asignaciones de señales.
4.5 Síntesis y bloques de procesos múltiples
Durante la fase de diseño de RTL, la mayor parte del tiempo necesitamos pensar en la concurrencia en
el diseño. Bajo tales circunstancias, podemos tener múltiples procesos. Como diseñador, podemos
pensar en; ¿Qué sucede exactamente cuando se utilizan múltiples bloques de proceso dentro de la
arquitectura?
Se ejecutarán múltiples procesos en paralelo para inferir la lógica. Considere la descripción de
VHDL en el Ejemplo 6. Como se describe, dos bloques de proceso diferentes P1, P2 se ejecutan en
paralelo e infieren la lógica que tiene dos rutas de datos y control separadas.
Siempre se recomienda tener la descripción del proceso múltiple para una mejor legibilidad y una
mejor sincronización. La lógica inferida puede tener una sincronización limpia y un mejor paralelismo
debido al enfoque de diseño modular.
Considere la síntesis RTL para la máquina de estados finitos (FSM), si la FSM está codificada
usando un bloque de proceso único, entonces la lógica inferida no tiene la sincronización limpia. Por lo
tanto, se recomienda tener el diseño RTL para los controladores FSM que utilizan varios bloques de
proceso. Se recomienda utilizar el bloque de proceso separado para el
'lógica de estado siguiente', 'Registro de estado' y para la 'lógica de salida'. Para una discusión
detallada sobre la síntesis FSM, consulte el Cap. 6.
Ejemplo 6: Descripción de VHDL usando múltiples bloques de proceso [1]
Lógica combinacional usando múltiples procesos.
biblioteca
utilizar
utilice
ieee.std_logic_arith.all; utilizar
entidad multi_proceso es
( enable_in_0
std_logic
enable_in_1 : epn
en std_logic ;
uerto
: en
a_in en std_logic bstd_logic
_in ;
: std_logic
c_in en std_logic ed_in
_in fe_in
n
: ; ;
:
: ; ;
: en std_logic ;
: en fuera
std_logic
de ;
y_out : std_logic
fuera de ;
y1_out: std_logic);
terminar multi_proceso;
definición funcional usando múltiples procesos.
arquitectura arch_multi_process de multi_process es
comenzar
P1: ( enable_in_0, a_in, b_in, c_in, d_in) proceso
comenzar
si (habilitar_en_0 = '1') entonces
tu_fuera < = b_en a_en; xor
más
tu_fuera < = estruendo xor c_en;
terminara
si ;
proceso finalizado ;
P2: (habilitar_en_1,
a_en, b_en, e_en, f_en) proceso
4.5 Síntesis y bloques de procesos múltiples 55
Fig. 4.6 Lógica inferida debido a la síntesis de procesos múltiples [1]
comenzar
si (habilitar_en_1 = '1') entonces
y1_fuera < = e_in f_in; xor
más
y1_fuera < = b_en a_en; xor
terminara
si ;
terminar arch_multi_process;
El resultado de la síntesis para la arquitectura de procesos múltiples se muestra en la Fig. 4.6.
Como se muestra, la lógica inferida usó datos separados y elementos de ruta de control debido al
uso de múltiples procesos.
4.6 Síntesis para Ifthenelse anidado
Una de las poderosas construcciones VHDL es 'ifthenelse'. Usando esta construcción, el diseñador
puede implementar la lógica del multiplexor. Incluso dependiendo del requisito, el diseñador puede
usar esto dentro de 'clk='1' y clk'event' para inferir la lógica secuencial. El punto importante para
pensar es que, ¿puedo inferir el diseño de prioridad usando la construcción 'ifthenelse'? La
respuesta es sí, siempre que la descripción utilice la construcción 'ifthenelse' anidada.
La construcción 'ifthenelse' anidada infiere la lógica de prioridad. La descripción de VHDL
para el multiplexor 4:1 se muestra en el Ejemplo 7.
Ejemplo 7: Descripción de VHDL usando Ifthenelse anidado
biblioteca
entidad nested_if_mux es
( puerto sel_in a :std_logic_vector ( hasta 0); 1
datos
entrada
en de
:
std_logic_vector (3 hasta 0); std_logic); afuera
y_out :
end nested_if_mux;
arquitectura arch_mux_nested_if de nested_if_mux es
comenzar
proceso (sel_in, data_in)
comenzar
si ( sel_in = "00") entonces
tu_fuera < = fecha_en(0);
elseif ( sel_in = "01") entonces
elseif ( sel_in = "10") entonces
más
tu_fuera < = fecha_en (3);
termina si ;
final arch_mux_nested_if;
Cada 'ifthenelse' infiere el multiplexor 2:1. La lógica inferida se muestra en la Fig. 4.7. Como
se muestra en la figura 4.7, la lógica inferida tiene etapas en cascada de multiplexores 2:1 con
lógica de decodificación adicional. La principal desventaja de este tipo de descripción es la lógica
adicional en la ruta de control para controlar el flujo de datos.
Debido a las etapas en cascada, el retardo de propagación global es la suma del retardo de
etapa individual. Este tipo de descripción RTL es adecuada cuando el diseño necesita asignaciones
de prioridad. Considere codificadores de prioridad, controladores de interrupción de prioridad.
4.7 Construcción y síntesis de casos 57
Fig. 4.7 Lógica inferida para el ifthenelse anidado [1]
4.7 Construcción y síntesis de casos
Como se discutió anteriormente en el Cap. 3, el 'caso' y 'ifthenelse' son poderosas
construcciones VHDL secuenciales y deben usarse dentro del proceso para describir la
funcionalidad del diseño. La herramienta de síntesis inferirá la lógica diferente para la
descripción usando el 'caso' y 'ifthenelse'.
La construcción 'caso' se describe con las condiciones de selección y, según la condición
de selección requerida, la entrada requerida se asigna a la salida. La construcción 'caso'
infiere la lógica paralela ya que todas las entradas tienen la misma prioridad. Entonces,
durante la fase de diseño de RTL, para inferir la lógica paralela, use la construcción 'caseend case'.
Es obligatorio cubrir todas las condiciones al usar la construcción 'caso'. Si una de las
condiciones no está cubierta, entonces se infieren pestillos no intencionales innecesarios.
Si no se requieren todas las condiciones para cubrir el interior de la 'caja', use 'cuando otros'
para evitar pestillos involuntarios. El ejemplo 8 describe el uso de la construcción 'caso' para
realizar la funcionalidad del multiplexor.
Ejemplo 8: Descripción de VHDL utilizando Case Construct
biblioteca
entidad es case_mux
( puerto sel_in : en std_logic_vector ( 1 hasta 0); data_in

:
en std_logic_vector
(3 a 0); std_logic);
tu_fuera fuera :
fin
case_mux; arquitectura arch_mux_case de es case_mux
comenzar
proceso (sel_in, data_in)
comenzar
Fig. 4.8 Lógica inferida para la descripción del caso [1]
caso (sel_in) es
cuando "00" = > tu_fuera < = fecha_en(0);
cuando “01” = > tu_fuera < = fecha_en(1);
cuando "10" = > tu_fuera < = fecha_en(2);
cuando otros = > tu_fuera < = fecha_en(3);
caso final ;
final arch_mux_case;
La síntesis de la descripción de VHDL usando 'caso' infiere la lógica paralela sin ninguna
estructura de decodificación adicional. Según el estado de las entradas seleccionadas, una de
las entradas se asigna a la salida para obtener la funcionalidad de cambio de muchos a uno.
El retraso de este tipo de lógica se debe al retraso de la etapa única (Fig. 4.8).
4.8 Lógica de prioridad usando construcciones sintetizables
Si la mayoría de las señales sensibles al nivel llegan a la vez y es necesario detectarlas y
procesarlas según la prioridad, se pueden utilizar los codificadores de prioridad. Considere un
escenario práctico en el que la lógica del procesador tiene interrupciones sensibles de cuatro
niveles y la prioridad debe programarse para ellas, luego la lógica puede diseñarse utilizando
la construcción anidada ifelse de VHDL.
Considere la Tabla 4.3, en la que la entrada INT3 tiene la prioridad más alta y INT0 tiene la
prioridad más baja. Las salidas del codificador son y1_out y y0_out.
Como se muestra en la Tabla 4.3, la entrada sensible al nivel INT3 tiene la prioridad más
alta e INT0 tiene la prioridad más baja. Si se observan cuidadosamente las entradas de la tabla
anterior, podemos ver la salida '00' para dos secuencias de entrada '0001', '0000'. Si la salida
del codificador se da como entrada a otro bloque funcional, entonces es muy difícil
4.8 Lógica de prioridad usando construcciones sintetizables 59
Tabla 4.3 Tabla de verdad de codificadores de prioridad 4:2
INT3 INT2 INT1 INT0 tu_fuera(1) tu_fuera(0)
1 X X X 1 1
0 1 X X 1 0
0 0 1 X 0 1
0 0 0 1 0 0
0 0 0 0 0 0
diferenciar si una salida de la etapa del codificador es '00' debido a la entrada '0001' o debido
a la secuencia de entrada '0000' Para diferenciar esto, use flag_out como salida del codificador.
Si todas las entradas del codificador tienen un valor lógico cero, fuerce flag_out a 1 lógico; de
lo contrario, flag_out debería ser 0 lógico.
El código VHDL se muestra en el ejemplo 9 y el resultado de su síntesis se muestra en la
figura 4.9.
Ejemplo 9: código VHDL para codificador de prioridad 4:2
biblioteca
la entidad Priority_encoder es
puerto ( INT estd_logic
n std_logic_vector
y_out out (s 3
td_logic_vector
hasta 0); : flag_out
( 1 hasta
out
: de prioridad; ;
0)); codificador
:
fin
arquitectura arch_priority_encoder de es priority_encoder comenzar
proceso (INT)
comenzar
si(INT(3)='1') entonces
tu_fuera < = “11” ;

bandera_fuera< = '0';
Fig. 4.9 Resultado de la síntesis del codificador de prioridad 4:2 [1]
de lo contrario si (INT (2) = '1') entonces
tu_fuera < = “10” ;

si no( INT(1)='1') entonces
tu_fuera < = "01" ;

de lo contrario si (INT (0) = '1' ) entonces
tu_fuera < = "00";

otra
cosa < = "00";
< = '1';
y_out flag_out
terminar
si; proceso
finalizado ;
terminar arch_priority_encoder;
4.9 Síntesis de la Lógica de Paridad
En la mayoría de las aplicaciones de diseño, necesitamos calcular la paridad. En el entorno de
procesamiento, la mayor parte del tiempo necesitamos calcular la paridad y la mayoría de los procesadores
utilizan la lógica de paridad para actualizar los indicadores de paridad. Por ejemplo, el cálculo de paridad
par e impar utilizando el flujo de datos de entrada para asignar una salida de paridad válida.
Dependiendo del requerimiento, podemos asignar '1' o '0' para paridad par e impar.
VHDL tiene una construcción poderosa como bucle y se puede usar para diseñar la lógica de paridad.
La descripción de VHDL que usa 'forloop' para generar la paridad se muestra en el Ejemplo 10.
Ejemplo 10: Descripción de VHDL para generador de paridad
biblioteca
ieee;
entidad parity_generator es
puerto ( fecha en : en std_logic_vector (3 hasta 0); y_out

: afuera
std_logic);
fin parity_generator;
arquitectura arch_parity_generator de parity_generator es
4.9 Síntesis de la Lógica de Paridad 61
Fig. 4.10 Lógica inferida para el generador de paridad [1]
comenzar
proceso (data_in) variable temp_q_out : std_logic ;
comenzar
temp_q_salida: = '0';
para contar en 0 a 3 bucles
temp_q_salida: = temp_q_out xor fecha_en (recuento);
bucles finales ;
tu_fuera < = temp_q_salida;
final arch_parity_generator;
La lógica inferida para el Ejemplo 10 tiene elementos en cascada y por eso puede tener más
retardo. El resultado de la síntesis se muestra en la Fig. 4.10.
4.10 Diseño y síntesis basados en pestillos
Los pestillos son transparentes durante el nivel activo y, por lo tanto, resultan en la menor disipación
de energía. Pero el diseñador debe tener en cuenta la duración del tiempo de activación de la ventana
activa y el préstamo de tiempo.
Al eliminar la cláusula 'else' mientras se usa la construcción 'ifthenelse', se pueden inferir los
pestillos intencionales. El diseño basado en pestillos puede tener ciertas ventajas y desventajas y se
discutirá posteriormente durante la síntesis.
La descripción de VHDL para inferir un latch de 4 bits se muestra en el Ejemplo 11. El diseño
utiliza el borrado asíncrono y la entrada de datos de 4 bits se bloquea usando la habilitación alta activa
para obtener la salida de 4 bits.
Ejemplo 11: Descripción de VHDL para el pestillo de 4 bits
Latch sensible al nivel de cuatro bits usando 'ifthenelse'
biblioteca
use ieee.std_logic_unsigned.all;
utilice ieee.std_logic_arith.all;
utilizar
entidad latch_4bit es
( puerto enable_in, reset_in en s:td_logic data_in ;
: std_logic_vector
en std_logic_vector
hasta (3
a 0); (3
0));
tu_fuera fuera :
fin
latch_4bit; arquitectura arch_latch_4bit de latch_4bit es
comenzar
proceso ( enable_in, reset_in, data_in)
comenzar
si (restablecer_en = '1') entonces
tu_fuera < = "0000";
elsif (habilitar_en = '1') entonces
< = fecha en;
terminas
; si
final arch_latch_4bit;
El resultado de la síntesis es la inferencia de la lógica sensible al nivel de 4 bits con el
reinicio asincrónico y la habilitación activa de enganche alto. Se muestra en la Fig. 4.11.
Fig. 4.11 Lógica inferida para el latch de 4 bits [1]
4.11 Registros PIPO y Síntesis 63
4.11 Registros PIPO y Síntesis
Para el almacenamiento interno de datos, podemos usar la matriz de registros. La matriz de registros
puede tener múltiples registros para almacenar los datos temporalmente durante el procesamiento.
Por ejemplo, considere el procesador de 16 bits, que tiene una matriz interna de 8 registros, cada uno
con un tamaño de 16 bits.
La descripción VHDL para el registro de 4 bits se muestra en el Ejemplo 12. En el flanco
ascendente (transición de bajo a alto) del reloj, la entrada de datos se asigna a la salida (Fig. 4.12).
Ejemplo 12: Descripción VHDL para el registro de 4 bits
biblioteca
ieee;
entidad register_4bit es
(clk,
en setd_logic_vector
data_in n std_logic_vector
std_logic port
(3
reset:
a( 3
0); 0)); ;
af uera
:
y_out :
final registro_4bit;
arquitectura arch_register_4bit de register_4bit es
comenzar
proceso (clk, restablecer)
comenzar
si (restablecer
= '1') entonces
tu_fuera < = "0000";
elsif (clk='1' y clk'event) entonces
Fig. 4.12 Lógica inferida para el registro de 4 bits [1]
< = fecha en;
terminas
; si
final arch_register_4bit;
4.12 Síntesis e Inferencia Lógica del Registro de Desplazamiento
El VHDL RTL del registro de desplazamiento de entrada y salida en serie se muestra en el Ejemplo 13. El
resultado de la síntesis es un registro de desplazamiento de salida en serie de entrada en serie que tiene un
flanco ascendente del reloj y un restablecimiento asíncrono bajo activo (Fig. 4.13).
Ejemplo 13: Código VHDL de registro de desplazamiento de salida serie de entrada serie
Código VHDL para la biblioteca de registro de desplazamiento de salida
en serie d
shift_register
e entrada en
ess
erie
puerto
ieee;
( d_in
ieee.std_logic_1164.todos;
in std_logic clk in std_logic :
entidad
in
utilizar std_logic q_out out std_logic); final turno_registro;
: ;
;
restablecer_n : ;
:
arquitectura arch_shift_register de shift_register es la señal
:
q1_out,q2_out std_logic begin ;
proceso (clk,reset_n)
empezar si (restablecer_n='0') entonces
q1_fuera < = '0';
q2_fuera < = '0';
q_fuera < = '0';
Fig. 4.13 Lógica de registro SISO [1]
4.12 Síntesis e Inferencia Lógica del Registro de Desplazamiento sesenta y cinco
elsif (clk='1' clk'event) y luego
=
<1_salida
estruendo; q
q2_salida <=q1_salida;
=
q_salida q<2_salida;
terminara
si ;
fin del proceso ;
fin arch_shift_register;
4.13 Lógica y síntesis de detección de bordes
La mayoría de las veces, necesitamos tener la lógica para detectar el borde positivo o
el borde negativo. La lógica síncrona que opera en el borde del reloj y se describe en
el Ejemplo 14 (Fig. 4.14).
Ejemplo 14: código VHDL para el detector de bordes
biblioteca
entidad edge_detector es
(d_in : en std_logic ;
puerto
reset_n : en en
std_logic ;
std_logic
clk : fuera de std_logic);
;
q_fuera :
final edge_detector;
arquitectura arch_edge_detector de edge_detector es
comenzar
Fig. 4.14 Resultado de la síntesis del detector de bordes [1]
proceso (clk, reset_n)
comenzar
si (restablecer_n = '0') entonces
tmp_q_out < = '0';
elsif (clk='1' y clk'event)
entonces
tmp_q_out <= estruendo;
terminara
si ;
q_fuera < = tmp_q_out xor estruendo;
final arch_edge_detector;
Los siguientes son puntos importantes para concluir el capítulo:
1. Use el bloque de procedimiento separado que es el bloque de proceso para el diseño combinacional y
secuencial.
2. Una lista de sensibilidad incompleta puede crear un desajuste en la simulación y la síntesis, por lo tanto,
utilice las entradas requeridas, las señales en la lista de sensibilidad.
3. La falta de la lista de sensibilidad dará como resultado un bucle infinito durante la simulación.
4. Design Compiler (DC) ignora la lista de sensibilidad durante la síntesis.
5. Las señales se actualizan al final del proceso y las variables se actualizan inmediatamente, así que tenga
una estrategia mientras usa la señal y la variable.
6. Múltiples bloques de proceso en el diseño pueden inferir la lógica paralela, es decir, lógica con
dos caminos separados.
7. Múltiples arquitecturas son posibles en VHDL. Durante la síntesis, el DC acopla la última arquitectura
compilada para inferir la lógica.
8. Si se usa 'configuración', una de las arquitecturas especificadas se puede acoplar con una entidad para
inferir la lógica deseada.
9. Para el diseño de prioridad, utilice la construcción 'ifthenelse' anidada.
10. Para el diseño paralelo, use la construcción 'caseend case'.
11. No mezcle los pestillos y las chanclas en el mismo diseño.
12. Cubra todas las condiciones de 'caso' requeridas mientras usa la construcción 'caso de fin de caso'
para evitar la lógica con pestillos involuntarios.
13. La cláusula 'else' faltante generará lógica con pestillos no intencionales. Para evitar la lógica con pestillos
involuntarios, especifique todas las cláusulas 'else'.
14. Durante la transferencia de datos entre múltiples diseños de dominio de reloj, utilice el gris
punteros
15. Los convertidores de código binario a gris y gris a binario son necesarios al implementar
el diseño FIFO.
16. El número de asignaciones dentro de 'clk='1' y clk'event' inferirá esos muchos
flipflops durante la síntesis.
Este capítulo nos ha permitido comprender las construcciones VHDL importantes y
sus aplicaciones durante la etapa de diseño de RTL. El próximo capítulo subsiguiente
analiza el diseño y la verificación de RTL para algunos diseños complejos y los
desafíos durante la fase de diseño de RTL. Incluso el siguiente capítulo es útil para
comprender los conceptos básicos de la síntesis lógica.
Referencia
1. www.xilinx.com.
Capítulo 5
Estrategias de Diseño y Verificación
“El diseño y la verificación eficientes de RTL con objetivos de cobertura
pueden ahorrar mucho tiempo durante la fase de implementación del diseño”.
Resumen El capítulo trata sobre los complejos escenarios de diseño y verificación de RTL. El
capítulo incluso describe el estudio de caso de la arquitectura del procesador y analiza el
proceso de pensamiento mientras se desarrolla la arquitectura y la microarquitectura utilizando
las especificaciones funcionales de SOC. El capítulo es útil para comprender las estrategias y
los procesos durante el diseño de la arquitectura, el diseño RTL y la verificación. La planificación
de verificación y la arquitectura de verificación básica para los diseños y estrategias complejos
también se analizan en este capítulo.
Palabras clave Arquitectura RTL Cobertura de verificación Cobertura de palanca
Cobertura funcional Cobertura de código Plan de verificación Caso de prueba Casos de esquina
Latencia Codificador H.264 Canalización Velocidad Rendimiento Procesador Microarquitectura
Velocidad de datos Entrada de video _ _ _ _ _ ∙ Datos comprimidos
5.1 Estrategias de diseño para diseños complejos
Considere la implementación de un diseño complejo usando VHDL. Necesitamos usar las
construcciones sintetizables para inferir la lógica requerida. El diseño debe estar bien
particionado, y la arquitectura y la microarquitectura de este tipo de diseño deben tener
información sobre las interfaces, la velocidad, el rendimiento y las IP requeridas.
Por ejemplo, considere el diseño y la implementación del codificador H.264 para admitir el
tamaño HD y otros marcos. ¿Qué información necesitamos?
1. Documento de arquitectura y microarquitectura que es el resultado de la
especificaciones de diseño funcional.
2. Partición de los bloques funcionales de diseño como
a. Predicción intraframe
Taraate, síntesis lógica y creación de prototipos SOC, https://
doi.org/10.1007/9789811513145_5
70 5 Estrategias de Diseño y Verificación
b. Predicción entre cuadros c.
Bloques de transformación y cuantificación d.
Codificación de entropía e. Búferes de
fotogramas.
3. Para cada bloque funcional, debemos conocer la información de la interfaz con
sincronización.
4. La información sobre la memoria interna o el almacenamiento requerido y las estrategias de partición
a través de los límites secuenciales deben considerarse durante la fase de diseño.
5. La información sobre la canalización del diseño, el rendimiento y el ancho de banda debe usarse
durante el diseño y mientras se modifica el RTL o durante la síntesis.
6. Cuál debería ser la tecnología para ASIC y cuál debería ser el FPGA objetivo que debería ser
conocido por el equipo de diseño.
Para los diseños SOC complejos según los requisitos, el equipo de diseño de RTL puede codificar
el RTL para cada bloque funcional. El miembro del equipo debe utilizar el enfoque de diseño modular
para tener un RTL eficiente.
La verificación funcional se puede realizar después de la fase de diseño RTL. Pero para los diseños
complejos, la verificación funcional y la fase de diseño RTL pueden comenzar simultáneamente. Casi
alrededor del 70% del ciclo de diseño, el tiempo y los esfuerzos se dedican a la fase de verificación.
El diseño RTL en el nivel superior se puede visualizar como la integración del número de bloques
funcionales. Como se muestra en la Fig. 5.1, el diseño tiene diferentes bloques funcionales y está
dividido en límites secuenciales para mejorar la velocidad y la sincronización.
El módulo superior RTL del codificador H.264 utiliza la instanciación de todos los bloques funcionales.
Para cada bloque RTL, se deben especificar las restricciones de nivel de bloque y, finalmente, para el
diseño de nivel superior, se deben especificar las restricciones.
Fig. 5.1 Arquitectura del codificador H.264
5.1 Estrategias de diseño para diseños complejos 71
Ahora, para este tipo de diseño, ¿cuál debería ser el proceso de pensamiento del equipo de arquitectura?
1. ¿Qué tipo de fotogramas de video debe admitir el codificador?
2. ¿Cuántos fotogramas por segundo debe admitir el diseño y comprimir?
3. ¿Cuáles deberían ser los requisitos de almacenamiento para el tamaño de imagen HD de 1920×?
1080P?
4. ¿Qué tipo de gestión de búfer se requiere para almacenar fotogramas de vídeo de entrada? Lo es
¿Estructura de pingpong o amortiguadores circulares?
5. ¿Cuál debe ser la velocidad del codificador H.264, para que pueda procesar el
número requerido de fotogramas por segundo?
6. Mejor comprensión del rendimiento, ancho de banda, latencia para elegir y definir
las interfaces
7. ¿Cuáles deberían ser los requisitos de almacenamiento interno para los cuadros de video de referencia?
Por ejemplo, el requisito de diseño es tener de 3 a 5 cuadros de referencia para una mejor compresión
y, para lograrlo, el diseño debe tener una cantidad de búferes para contener los píxeles requeridos.
8. ¿Cuál debería ser la estructura de la trama para el paquete de entrada y cuál debería ser la
formato para el video comprimido en la salida?
9. ¿Existen IP disponibles en el mercado que sean funcionales y de tiempo comprobado? Por ejemplo,
estimación de movimiento, núcleos IP de codificación de entropía.
10. ¿Cómo probar el diseño usando FPGA? Qué tipos de FPGA son adecuados y
¿Cuál debería ser la densidad lógica de tales FPGA?
11. ¿Cuál debería ser el gasto total en herramientas EDA, recursos para tales tipos de diseño, verificación
y prueba?
5.2 Estrategias de diseño RTL para SOC
Para los diseños SOC complejos, la fase de diseño RTL puede consumir casi alrededor del 10 al 15 % del
tiempo de diseño. El diseño se puede dividir según la funcionalidad y, mediante el método divide y vencerás,
se puede codificar RTL. El punto importante a tener en cuenta es sobre la disponibilidad comprobada de IP
funcional y temporal de plugandplay y ¿pueden usarse durante el diseño del SOC? Para tal tipo de diseño,
el RTL puede ser una integración general de las IP probadas funcionales, la lógica de unión y la lógica de
prueba y depuración. El equipo de diseño de RTL debe tener cuidado de utilizar las siguientes pautas
importantes durante esta fase:
1. Trate de tener una mejor comprensión de la arquitectura y la microarquitectura de
el diseño.
2. Intente usar las IP existentes y otra lógica personalizada asociada si el diseño es
dirigidos a la misma tecnología de proceso.
3. Trate de tener claridad sobre las dependencias funcionales para el diseño y la
interfaces externas requeridas para la comunicación.
4. Use las pautas de diseño de RTL durante la fase de diseño de RTL.
5. Trate de tener un enfoque modular al implementar el RTL para cada uno de los bloques funcionales.
6. Realice la verificación básica para verificar la corrección funcional de cada
subbloque para detectar los primeros errores en el diseño.
7. En el diseño de nivel superior, use la lógica de prueba, depuración y prueba.
Considere el SOC de alta densidad que se muestra en la Fig. 5.2, ahora cuál debe ser el proceso de
pensamiento mientras se desarrolla el RTL. ¡Los siguientes pueden ser algunos aspectos destacados importantes!
1. Intente tener la definición de diseño de nivel superior e identifique las direcciones IP disponibles. Por
ejemplo, para el SOC que se muestra en la Fig. 5.2, las IP están disponibles para los bloques
analógicos, el procesador, el procesador de video, el controlador DMA y el controlador de memoria y
luego intente tener un equipo separado para la validación de IP y el diseño RTL.
2. Intentar tener una mejor gestión de configuración, prueba y depuración al más alto nivel.
3. Trate de identificar la partición de diseño para múltiples dominios de reloj y energía
antes de la fase de diseño RTL.
USB
RAM
interfaces y
Controladores
Memoria
Procesador Controladores
Bluetooth
ROM
Temporizador
y contadores
SDRAM
Video Arbitraje de autobuses interfaz
Procesador Y control
anuncio
externo Alto CAD
Memoria Velocidad extensión DMA
Controladores
interfaz Autobús
interfaz extensión PL
Osciladores
Fig. 5.2 Diseño SOC complejo
5.2 Estrategias de diseño RTL para SOC 73
4. Con referencia a la arquitectura y la microarquitectura del SOC, intente encontrar los recursos necesarios
para completar el diseño RTL y también para verificar la integración de IP disponible en el nivel
superior.
5. Asignar las responsabilidades primarias y secundarias a esos recursos y tener
el plan del proyecto en su lugar.
6. Utilice el enfoque modular para los bloques funcionales restantes. Por ejemplo, considere la interfaz de
memoria externa, la interfaz de memoria de alta velocidad, entonces la máxima prioridad es tener la
definición de las interfaces de entrada y salida a nivel de bloque. Esto dará una mayor claridad al
integrar los bloques funcionales durante la integración del diseño de nivel superior.
7. Use la partición de diseño durante la fase de diseño de RTL y codifique el RTL usando el
construcciones sintetizables.
8. Tener una mayor claridad sobre el rendimiento requerido, la velocidad, el paralelismo, la prioridad
lógica al codificar RTL.
9. Para cada bloque, trate de averiguar los casos de prueba básicos para verificar la corrección funcional
del diseño. Aunque este es el trabajo del ingeniero de verificación, es obligatorio tener RTL sin
errores funcionales.
10. Es muy necesario contar con una mejor coordinación de la validación de IP y el equipo de diseño de
RTL durante esta fase. Será fácil para el equipo de integración integrar los bloques funcionales para
tener un diseño de primer nivel.
5.3 Estudio de caso de la arquitectura del procesador [1]
Consideremos el núcleo del procesador configurable de 16 o 32 bits. La arquitectura eficiente y el diseño
RTL para cualquier aplicación SOC no solo es útil para mejorar la confiabilidad del procesador, sino que
también mejora el rendimiento general en términos de área, velocidad y potencia. El objetivo principal en
este tipo de diseños es lograr un mayor rendimiento a velocidades de reloj más bajas. Como se discutió
anteriormente, usaremos el VHDL para codificar el RTL. El diseño del procesador debe tener la función de
programabilidad y es mejor tener menos instrucciones. El mayor riesgo en este tipo de diseños puede
deberse a los cambios en las especificaciones, la adición de la calidad de la función y los requisitos
cambiantes del mercado. En tales circunstancias, la arquitectura debe diseñarse para hacer frente a todos
estos tipos de cambios.
Pensemos qué debería tener el núcleo del procesador.
1. Arquitectura flexible: la arquitectura debe ser lo suficientemente flexible para adaptarse a los cambios
durante el ciclo de diseño. Para tener un mejor rendimiento, si deseo diseñar la arquitectura, entonces
para las instrucciones de carga o almacenamiento solo se puede usar la referencia de memoria
externa. Para todos los demás tipos de instrucciones, se debe utilizar la lógica incorporada para reducir
los retrasos y mejorar la velocidad del procesador.
Los gastos generales de comunicación externa deben ser lo menos posible. Esto mejora la eficiencia
general del procesador.
2. Funciones de canalización: para mejorar el rendimiento del diseño, el núcleo del procesador
debe tener la lógica de control canalizada. Dependiendo de los requisitos, el diseño debe
utilizar la tubería de varias etapas. Se debe prestar especial atención para agregar las etapas
controladas canalizadas en el diseño. Si consideramos los procesadores Intel, los procesadores
ARM, entonces las arquitecturas tienen la canalización de varias etapas para las colas internas
de datos e instrucciones.
3. Almacenamiento interno: la arquitectura del núcleo del procesador debe tener suficiente
almacenamiento interno. La mayoría de las veces diseñamos la arquitectura que tiene más
registros de propósito general. Estos registros de propósito general se pueden usar durante la
ejecución de las instrucciones de carga y almacenamiento. Este tipo de registros internos
puede ser útil para contener la información del operando requerida durante la ejecución de la
instrucción.
4. Conjunto de instrucciones simple: para mejorar el rendimiento y el rendimiento del núcleo, las
instrucciones deben ser de un solo ciclo y eso se puede lograr mediante la canalización. Una
mejor implementación de RTL para las instrucciones utilizadas para la transferencia de datos,
operaciones aritméticológicas, ramificación puede resultar en un mejor rendimiento.
5. Definiciones de operandos: el diseño debe tener los operandos para el origen y los destinos, y
este tipo de mecanismo mejora las rutas de control y su tiempo.
6. Interfaces externas: el núcleo del procesador debe tener interfaces de puerto directo, interfaces
de registro e interfaces que utilicen FIFO para transferir la mayor cantidad de datos. Incluso
las interfaces de bus de alta velocidad y las interfaces de red pueden ser útiles para los
algoritmos complejos y la transferencia de datos.
7. Registros de puertos para la transferencia de datos: el rendimiento de cualquier procesador
depende del ancho de banda de E/S y de las interfaces utilizadas en la transferencia de datos.
Si algún diseño necesita varios núcleos de procesador, entonces, para transferir los datos de
uno de los núcleos del procesador a otro, podemos pensar en usar conexiones de puerto directas.
La figura 5.3 muestra el mecanismo que utiliza los registros de entrada y salida.
La conexión de puerto directo para transferir los datos del procesador #1 al procesador #2 se
muestra en la Fig. 5.3. Como se muestra cuando el procesador #1 completa la ejecución de la
instrucción, el resultado se almacena en el registro del puerto de salida.
Fig. 5.3 Conexiones de puerto directo
5.3 Estudio de caso de la arquitectura del procesador 75
El contenido del registro del puerto de salida puede transferirse al procesador #2 y almacenarse en el registro
de entrada del procesador #2. Para realizar la transferencia de datos inicialmente, el procesador n.° 1 ejecuta la
instrucción de almacenamiento y, posteriormente, cuando el procesador n.° 2 requiere los datos, el procesador n.°
2 puede iniciar la transacción de carga de datos. Este tipo de mecanismo necesita señales de control adicionales
para lectura y escritura.
Incluso se requiere la puesta en cola de los datos mientras se transfieren datos entre los procesadores. En
comparación con las interfaces de puerto directo, se pueden utilizar los buses de datos de alta velocidad.
5.4 Arquitectura del procesador y microarquitectura
La arquitectura es la representación a nivel de bloque de las especificaciones de diseño. La arquitectura se
desarrolla a partir de la especificación funcional del diseño. Considere diseñar la arquitectura del procesador de 16
bits. ¿Qué tenemos que pensar?
1. Aplicación: El entorno en el que trabaja el procesador. Dependiendo de eso decide por la funcionalidad. Incluso
la investigación de mercado para recopilar la funcionalidad del procesador y su mejora puede jugar un papel
importante.
2. Operaciones: ¿Cuáles son las operaciones que debe soportar el procesador?
a. Aritmética B.
lógico c.
Transferencia de datos
d. ramificación y.
control de E/S
3. Tamaño de la transferencia de datos: Tamaño del bus de
datos 4. Memoria máxima direccionable: ¿Cuál debe ser la memoria máxima direccionable del procesador?
Dependiendo de eso, extraiga el recuento del bus de direcciones.
5. Multiplexación del bus de direcciones y datos: Disposición de los buses multiplexados para reducir el número de
pines del procesador.
6. Parámetros de rendimiento:
a. Velocidad
b. Poder c.
Tamaño del
troquel d. Latencia para la transferencia de
datos e. Cuotas de fecha
F. Rendimiento g.
Etapas canalizadas.
7. Almacenamiento interno: El almacenamiento requerido
a. Registros internos para almacenamiento temporal b.
Memoria interna RAM, ROM, buffers FIFO.
Fig. 5.4 Arquitectura del procesador a nivel básico
8.Interfaces IO :
a. Puertos de E/S de propósito
general b. Interfaces seriales c.
Interfaces de red d. Interfaces de
bus de alta velocidad.
Mediante el uso de todos estos parámetros, la funcionalidad a nivel de bloque para el
procesador básico se puede documentar y mostrar en la figura 5.4. Es la arquitectura básica que
es la fase inicial para poner en marcha el diseño. En las implementaciones prácticas de SOC, el
equipo de diseño de arquitectura debe tener una buena cantidad de experiencia e imaginación.
El equipo de expertos puede crear las arquitecturas para el procesador canalizado y es un
proceso iterativo.
El documento de arquitectura debe consistir en la información sobre
1. La funcionalidad de cada bloque para realizar las operaciones .
a. ALU: ALU de 16 bits para realizar las operaciones aritméticológicas i. El
tipo de instrucción: aritmética, lógica, transferencia de datos
2. La información sobre el almacenamiento interno
a. Matriz de registros
b. memoria interna
3. La información de alto nivel sobre el flujo de datos
5.4 Arquitectura del procesador y microarquitectura 77
a. Obtener la instrucción: Se utiliza la lógica de la interfaz de bus. b.
Decodificar la instrucción: Se utiliza la lógica de decodificación. C. Ejecutar
la instrucción: ALU y otra lógica asociada según el
tipo de instrucción. d.
Guarda el resultado.
la. En el registro/memoria interna ii. Memoria
externa.
4. Información sobre la inicialización/configuración y registros y lógica de prueba: Lógica de prueba y depuración para
la inicialización y configuración 5. Información de alto nivel sobre las interfaces externas (serie y paralelo):
a. Interfaces seriales b.
Interfaz IO de propósito general.
6. Interrupciones: ejecución de tareas inmediatas de alta prioridad
a. Número de interrupciones (si hay más de una) y salidas de reconocimiento de interrupción
Si alguna
7. Información sobre la red de reinicio del reloj 8. Información
sobre las restricciones 9. Conectividad del mundo externo (para
las interfaces externas de alta velocidad, si las hay)
10. Información sobre las fuentes de alimentación y dominios de tensión.
Recuento de
pines: para obtener una mayor visibilidad de los pines externos, el documento de arquitectura puede tener los
detalles del ancho de cada pin.
1. Por ejemplo, la memoria externa conectada al procesador es de 1 MB y el tamaño del bus de direcciones debe ser
de 20 bits.
2. El tamaño del bus de datos es de 16 bits. El tamaño de cada registro es de 16 bits. Tamaño de los punteros de
memoria 20 bits.
3. La minimización del conteo de pines: use la dirección multiplexada, el bus de datos es como se muestra
en la figura 5.5.
La Tabla 5.1 brinda información sobre la descripción de los pines y las señales de interfaz requeridas. Consulte
la Fig. 5.4 para ver la arquitectura de nivel superior.
Además de esto, el procesador debe tener las conexiones de la fuente de alimentación. Para esta discusión, se
descarta.
5.4.1 Microarquitectura del procesador
La microarquitectura del procesador es la representación a nivel de subbloque de los bloques funcionales individuales.
La microarquitectura debe brindar información sobre los requisitos lógicos de alto nivel para los bloques funcionales
individuales y su temporización.
Fig. 5.5 Buses multiplexados
Cuadro 5.1 Conectividad del mundo exterior
External_interface Pin_count Descripción
Bus de datos dieciséis Bus bidireccional para transferir los datos
dirección_bus 20 Para la IO o dirección de memoria
control_datos 1 Para demultiplexar las líneas de datos de dirección
R/Wb 1 Para leer y escribir. Para la operación de lectura, el estado de esta línea
es '1' lógico y para la operación de escritura, el estado de esta línea es '0'
lógico.
M/IOB 1 El pin de salida y el estado lógico '1' indican la operación de la memoria
y la lógica '0' en esta línea indica la operación IO
entrada_de_cristal 2 Pasadores de conexión de cristal y utilizados por el oscilador incorporado
Serial_in 1 Para conectar dispositivos de entrada serie
Salida_serie 1 Para conectar un dispositivo de salida serie
EN T 1 Nivel de interrupción sensible al procesador
EN T 1 Confirmación de interrupción del procesador
Restablecer_no 1 Entrada de restablecimiento bajo activo
y detalles de la interfaz. La siguiente sección elabora esto con muchos más detalles.
Para los bloques funcionales de alta densidad, puede ser una tarea difícil, pero la evolución de
la microarquitectura es útil durante la fase de diseño, verificación e implementación de RTL. En
esta sección se describe la microarquitectura de algunos de los bloques funcionales importantes.
5.4.1.1 ALU
Realiza las operaciones aritméticas y lógicas y ALU se opera en los dos operandos. ¿Qué
debemos pensar al desarrollar la microarquitectura para la ALU?
1. Tamaño del operando.
2. ¿Permite la ejecución segmentada de las instrucciones? Si no es así, ¿entonces es posible la
ejecución de ciclo único para qué tipo de instrucciones?
3. ¿Cuántas instrucciones lógicas e instrucciones aritméticas admite?
4. ¿Qué tipo de información de estado/inicialización se requiere para realizar la
operaciones?
5. Si debe generar información sobre el estado de la operación, por ejemplo
la paridad, el desbordamiento del acarreo, el resultado cero, etc.?
Mediante el uso de este proceso de pensamiento, se puede desarrollar la microarquitectura de este bloque.
Como se muestra en la figura 5.6, el bloque ALU se divide en unidad aritmética y unidad
lógica. La lógica de control toma la decisión de realizar instrucciones aritméticas o lógicas según
el estado de la lógica de decodificación.
Fig. 5.6 Microarquitectura ALU
Tabla 5.2 Conectividad de la Dirección
Signal_name Ancho Descripción
señal ALU en el nivel superior
clk 1 Señal de reloj común Aporte
restablecer_n 1 Entrada de restablecimiento bajo activo Aporte
operando_1 dieciséis
operando uno Aporte
operando_2 dieciséis
operando 2 Aporte
op_code 4 4 bits para las 16 instrucciones Aporte
resultado_alu dieciséis
Salida de 16 bits de ALU Salidas
Marcar_fuera 1 Para indicar el desbordamiento Salidas
Durante la fase de diseño de RTL, esta fase puede desempeñar un papel importante. El ingeniero de
diseño de RTL puede utilizar una estrategia de uso de múltiples subbloques funcionales para dividir y
codificar el diseño. Esto será útil para lograr una sincronización mejor y más limpia. Ya sea que el tamaño
del diseño sea moderado o complejo, esto puede brindar una mayor claridad al usar las construcciones
VHDL para que el diseño pueda admitir y ejecutar solo una instrucción a la vez.
1. Confiabilidad entre bloques: tenga un proceso de pensamiento sobre la confiabilidad y el tiempo entre bloques.
Considera lo siguiente
a. La lógica de decodificación de instrucciones debe usar el op_code de la instrucción y debe decodificarlo.
b. Es necesario recuperar operando_1 y operando_2.
La Tabla 5.2 brinda información sobre las señales para este bloque.
Riesgo: La ejecución de un solo ciclo es posible para las instrucciones lógicas de suma, resta. El riesgo son los
algoritmos de multiplicación y división. Requiere características adicionales y soporte de canalización.
5.4.1.2 Interfaz Io serie
Los dispositivos en serie pueden comunicarse con el procesador mediante una línea de entrada y salida en serie.
Para entender el nivel de subbloque, podemos pensar en:
1. Velocidad máxima de datos de E/S en serie.
2. Frecuencia de reloj máxima de la E/S serie frente a la velocidad de reloj del procesador.
3. Cómo segregar los datos de la entrada en serie para obtener los datos paralelos requeridos.
4. Cómo transferir los datos paralelos a formato serial.
Entonces, en el nivel alto, la lógica se puede desarrollar usando el cambio bidireccional
registros y lógica de control de dirección.
Como se muestra en la figura 5.7, el registro de desplazamiento bidireccional se utiliza para comunicarse con
Fig. 5.7 Microarquitectura de E/S serie
la E/S serial, la lógica de control de dirección, dependiendo de la instrucción de E/S, decide sobre la
transferencia de datos hacia o desde el procesador.
Durante la fase de diseño de RTL, esto es útil para codificar el diseño utilizando dos bloques de
procedimientos diferentes. Uno se puede usar para muestrear los datos de entrada y el otro se
puede usar para transferir los datos en serie. Se debe tener cuidado al escribir el RTL para el control
de dirección. Este tipo de lógica utiliza los registros de desplazamiento secuencial para muestrear o
transferir los datos.
La información de la señal de la interfaz serial se proporciona en la Tabla 5.3.
Tabla 5.3 Conectividad de interfaz serial
Signal_name ancho Descripción Dirección
Serial_in 1 Entrada serial a la lógica Aporte
Salida_serie 1 Salida serial a la lógica Salidas
entrada_datos dieciséis Bus de datos bidireccional para transferir los datos bidireccional
decode_serial_out 1 Entrada al bloque desde la lógica de decodificación Aporte

Fig. 5.8 Registros internos y punteros
5.4.1.3 Registros Internos
Los registros se pueden usar para almacenar el resultado o pueden actuar como operandos de datos. La
microarquitectura se puede ver como registros paralelos de entrada y salida paralela (PIPO) con el control de
lectura y escritura. Según el tipo de instrucción, los datos se pueden transferir o almacenar en estos registros.
Incluso los punteros de propósito especial pueden ser del tipo PIPO.
¿Cuál es la lógica adicional con estos registros?
1. Lógica de selección de registro que es lógica de decodificación.
2. El control de dirección usando las señales de habilitación de la unidad de control y temporización.
Como se muestra en la figura 5.8, la representación del subbloque tiene la lógica de decodificación, la
memoria y los punteros de la memoria interna.
Durante la fase de diseño de RTL, esto es útil para codificar el diseño. Implemente el diseño RTL usando
diferentes bloques de procedimientos para seguir 1. Lógica PIPO para los registros y punteros.
2. Control de dirección.
3. Lógica de decodificación de direcciones.
4. Lógica de lectura/escritura, incremento/decremento y lógica de puntero de dirección.
La Tabla 5.4 proporciona información sobre las interfaces de señal y la descripción de este bloque funcional.
5.4.1.4 Control de interrupciones
Para desarrollar la microarquitectura para este tipo de lógica, el proceso de pensamiento puede ser
1. Información sobre el tipo de interrupciones (flanco o nivel sensible).
Tabla 5.4 Interfaz de control de interrupción
Signal_name ancho Descripción Dirección
dirección_de_registro 2 Para seleccionar uno de los registros a la vez Aporte
leer escribir 1 Entrada para indicar lectura o escritura Aporte
int_data_bus dieciséis
Leer o escribir datos desde/hacia el registro bidireccional
dirección_valor 20 Entrada al puntero de memoria Aporte
puntero_dirección 20 La dirección del bus de memoria externa Salidas
2. ¿Cuál es la prioridad de las interrupciones (en caso de múltiples interrupciones de hardware)?
3. Habilitación y deshabilitación de interrupciones y la lógica.
4. La lógica de ubicaciones de vectores (dirección de bifurcación) (si no es compatible con ningún otro
mecanismo).
Como se muestra en la figura 5.9, la representación a nivel de subbloque puede detectar el nivel o el
borde, puede detectar la prioridad y puede procesar la interrupción según el estado de la interrupción
habilitada (Tabla 5.5).
Durante la fase de diseño de RTL, esto es útil para codificar el diseño. Implementar el
RTL usando diferentes bloques de procedimiento para lo siguiente
1. Lógica de detección de borde o nivel.
2. Lógica de detección de prioridad.
Fig. 5.9 Lógica de control de interrupción
Tabla 5.5 Los registros internos y las interfaces de puntero
Signal_name Ancho Descripción Dirección

En t 1 Entrada para indicar el nivel o entrada sensible al borde Aporte
int_data_bus 16 Para generar la dirección de vector y aceptar la información bidireccional

de dirección/estado programable
inta 1 Confirmación de interrupción Salidas
3. Estado de interrupción y bifurcación/programación de la lógica de interrupción.
5.5 Diseño y síntesis de alto nivel de RTL [1]
El diseño del procesador se puede lograr de manera eficiente utilizando el enfoque de diseño modular o el
enfoque de abajo hacia arriba. Tener la partición del diseño a nivel de arquitectura y usar el documento de
referencia como microarquitectura y codificar el RTL para el
1. Superior_RTL.vhd
a. ALU.vhd b.
memoria_interna.vhd c.
Bus_interface.vhd d.
registro_interno.vhd e.
Interrumpir_control.vhd f.
Timing_control.vhd
la. Temporizadores_contador.vhd
g. Serial_IO_control.vhd
Use los sincronizadores, la lógica de tres estados y la red de reinicio del reloj en el bloque superior.
5.5.1 Diseño a nivel de bloque
Los miembros del equipo (diseño RTL, verificación, síntesis y equipo STA) pueden realizar lo siguiente:
1. Codifique el RTL eficiente para cada bloque funcional.
2. Verificar el diseño utilizando las pruebas requeridas.
3. Utilice las restricciones a nivel de bloque y sintetice el diseño.
4. Verifique si las restricciones pueden cumplirse o no.
5. Realice la simulación de temporización y el STA previo al diseño. Corrija las infracciones de tiempo de configuración
usando los ajustes RTL, ajustes de arquitectura.
5.5 Diseño y síntesis de alto nivel de RTL [1] 85
5.5.2 Diseño de alto nivel
El equipo puede realizar las siguientes tareas
1. Cree Top.vhd utilizando la creación de instancias y verifique el diseño.
2. Verificar si las metas de cobertura se cumplieron o no?
3. Sintetice el diseño utilizando restricciones de nivel superior.
4. Verifique si las restricciones se cumplen o no.
5. Realice la temporización previa al diseño para top.vhd.
6. Verifique las violaciones de tiempo y corríjalas usando los ajustes necesarios.
5.6 Estrategias para la verificación del SOC
Para verificar la corrección funcional del diseño, se puede usar el banco de pruebas. El controlador o
generador de estímulos puede forzar las señales requeridas, como 'clk', 'reset_n' y 'data_in', de acuerdo
con los requisitos de diseño. Pero esto es útil para el diseño que tiene un número moderado de puertas.
Para los SOC complejos, la verificación debe llevarse a cabo a nivel de bloque, nivel superior y nivel de
chip.
La mayor parte del tiempo se utiliza para encontrar los errores funcionales en el diseño y, para ahorrar
tiempo, el proceso se puede automatizar utilizando los HVL y los bancos de pruebas en capas de
autocomprobación.
El objetivo es cumplir con las metas de cobertura especificadas. Los HVL como System
Verilog es popular en las industrias y se utiliza para la verificación impulsada por la cobertura.
La verificación de RTL para el diseño complejo puede consumir casi alrededor del 6570 % del tiempo
total del ciclo de diseño, y se puede hacer lo siguiente para lograr los objetivos de cobertura.
1. Mejor planificación de verificación: tener un plan de verificación para la verificación a nivel de bloque
verificación de nivel superior y verificación de chip completo.
2. Ciclo de verificación y lanzamiento: Inicia la fase de verificación simultáneamente con la fase de diseño
de RTL y usa el modelo funcional como referencia dorada durante la verificación.
3. Casos de prueba: al comprender la funcionalidad de diseño a nivel de bloque y de chip, documente los
casos de prueba requeridos y utilice el plan de prueba para lograr los objetivos de cobertura a nivel
de bloque y de chip especificados.
4. Aleatorizar casos de prueba: Crear los casos de prueba y aleatorizarlos para realizar la verificación del
diseño a nivel de bloque.
5. Mejor arquitectura de banco de pruebas: Desarrolle la arquitectura de banco de pruebas multicapa
automatizada usando controlador, monitor y marcadores.
6. Definir objetivos de cobertura: defina los objetivos de cobertura, como funcional, de código, alternar y
cobertura aleatoria restringida a nivel de bloque y a nivel de chip.
El banco de pruebas debe realizar lo siguiente:
1. Generar el estímulo requerido.
2. Aplique estímulo al DUT o DUV.
3. Debe capturar la respuesta.
4. Debe verificar la corrección funcional del diseño.
5. Debe utilizarse para medir el progreso con respecto a los objetivos generales de verificación.
¿Qué se debe pensar acerca de las entradas de diseño durante la aleatorización?
1. Información sobre la configuración del dispositivo.
2. Información sobre la configuración del entorno.
3. ¿Cuál es el flujo de datos de entrada y la información sobre los paquetes de entrada?
4. ¿Cuáles son los diferentes protocolos y cuáles son las excepciones del protocolo?
5. ¿Qué tipo de retrasos y rutinas de retraso?
6. ¿Dónde informar sobre los errores y violaciones?
La arquitectura del banco de pruebas en capas se muestra en la figura 5.10.
Capa de comando: la capa de comando tiene el controlador que envía el comando al DUT, y el
monitor captura la transición de las señales y las agrupa en forma de comando. Considere el comando
de escritura o lectura de bus en AHB.
Las afirmaciones también impulsan el DUT.
Capa funcional: por encima de la capa de comando, la capa funcional en la que el agente o el
transactor maneja el controlador después de recibir la transacción de alto nivel, como la lectura y
escritura de DMA. Este tipo de transacción se puede dividir en varios comandos para controlar al
conductor.
Marcador y verificador: para predecir el resultado de las transacciones, estos comandos se envían
al marcador y el verificador compara los comandos del monitor con el marcador.
Si consideramos el codificador H.264, entonces para probar el procesamiento de tramas múltiples,
el tamaño de la trama, el tipo, estos parámetros se pueden configurar utilizando el aleatorio restringido
Prueba
medioambiente
Generador
Marcadores
juego de damas
Agente COBERTURA
afirmación
monitores
Conductores
Extensión del dispositivo bajo prueba
Fig. 5.10 Banco de pruebas en capas [1]
5.6 Estrategias para la verificación del SOC 87
valores de estos parámetros. Esto es lo que llamamos crear el escenario para verificar la funcionalidad
particular.
Los siguientes son los puntos importantes para resumir este capítulo.
1. Tener una mejor definición de la especificación de diseño utilizando la arquitectura y
documento de microarquitectura.
2. Durante el diseño trate de tener una mejor comprensión del paralelismo, prioridad
Lógica y velocidad de la interfaz.
3. Durante el diseño de RTL, trate de comprender mejor los bloques funcionales y su confiabilidad.
4. Durante la integración de nivel superior, utilice la lógica de configuración, prueba y depuración.
5. Trate de identificar las IP probadas funcionales y de tiempo disponibles en el mercado,
antes del inicio del diseño de RTL.
6. Si se utilizan direcciones IP en el diseño, comprenda los tiempos y las interfaces y cree los envoltorios
para la conectividad.
7. Tener un mejor plan de verificación y generación de casos de prueba para el nivel de bloque, superior
diseños de nivel y nivel de chip.
8. Defina los objetivos de cobertura para la verificación aleatoria restringida.
9. Utilice el banco de pruebas en capas y controle la cobertura deseada.
Este capítulo nos ha permitido comprender el diseño RTL y las estrategias de verificación para
los diseños complejos. Incluso hemos discutido sobre la arquitectura y la microarquitectura del
diseño básico del procesador. El siguiente capítulo trata sobre la FSM, la síntesis de FSM, las
técnicas de mejora del rendimiento y los buses, los mecanismos de transferencia de datos, los
árbitros de bus, la arquitectura del sistema basado en DSP y sus requisitos en los SOC complejos.
Las estrategias de síntesis se discutirán con algunos escenarios de diseño importantes.
Referencia
1. www.springer.com: “Síntesis avanzada de HDL y creación de prototipos SOC: Vaibbhav Taraate”.
Capítulo 6
Diseño VHDL y ajustes RTL
"El rendimiento del diseño se puede mejorar utilizando una
mejor arquitectura y ajustes de RTL".
Resumen Durante la fase de diseño de RTL, la forma en que el equipo de diseño de RTL
transforma la capacidad funcional utilizando construcciones VHDL eficientes para inferir la lógica
prevista es un aspecto muy importante. Usando construcciones sintetizables y un enfoque
modular, el RTL a nivel de bloque se puede dividir en múltiples bloques funcionales. Los ajustes
de RTL y los ajustes de arquitectura antes de la síntesis para inferir la lógica prevista pueden
producir el mejor resultado de síntesis para las restricciones requeridas. En tales circunstancias,
el capítulo es útil para comprender el diseño, la optimización, los ajustes de RTL y otras técnicas
de mejora del rendimiento de FSM. El capítulo también analiza los árbitros de bus, los esquemas
de transferencia de datos y cómo pensar en el diseño del sistema basado en DSP.
Palabras clave Máquinas de estado Moore Mealy Reinicio asíncrono Reinicio síncrono Detector
de secuencia Síntesis de FSM Optimización de FSM Topología de bus _
Arbiter Procesador DSP Elementos DSP Ajustes VHDL RTL Mejora del rendimiento _
La mayoría de las veces, debido a RTL ineficiente, la herramienta de síntesis no podrá inferir la
lógica prevista. Por ejemplo, si el diseñador de RTL desea inferir la lógica paralela y el RTL está
codificado usando 'ifthenelse', entonces la herramienta de síntesis inferirá la lógica de prioridad.
O si es necesario ejecutar varios bloques secuenciales en paralelo y el diseño RTL tiene un solo
bloque de 'proceso', entonces la herramienta de síntesis no podrá inferir el paralelismo. En tales
circunstancias, la optimización requerida y los ajustes de RTL se analizan en las siguientes
secciones.
https://doi.org/10.1007/9789811513145_6
90 6 Diseño VHDL y Ajustes RTL
6.1 Estrategias de reinicio
Restablecer se utiliza para la inicialización del diseño. Podemos tener reinicio asíncrono o síncrono
dependiendo de los requisitos de diseño. Puede ser reinicio activo bajo o activo alto. Para evitar problemas
debido al reinicio, podemos tener el árbol de reinicio.
6.1.1 Restablecimiento asíncrono
Este tipo de reinicio es independiente del borde del reloj activo y, por lo tanto, se denomina reinicio
asíncrono. Se utiliza para inicializar el diseño independiente del borde del reloj. El RTL que usa VHDL se
describe en el Ejemplo 1 y usa el reinicio asíncrono.
Ejemplo 1: RTL con reinicio asíncrono
biblioteca
utilizar
la entidad asynchronous_reset es
Puerto (data_in : en std_logic;
clk : en
std_logic; :reset_n
en
std_logic; fecha
fin de
fuera
de sstd_logic ); :
alida
reinicio_asincrónico;

Descripción funcional del reinicio asíncrono
arquitectura arch_async_reset de asynchronous_reset es
comenzar
proceso ( clk , reset_n)
comenzar
Si ( reset_n='0') entonces
<= '0';
data_out elsif
(clk data_out= '1' yclk'event)
luego data_in;
<=
terminara
si ;
final arch_async_reset;
La herramienta de síntesis infiere la lógica que se muestra en la Fig. 6.1 para el reinicio asíncrono.
Como se muestra, la lógica inferida no tiene ningún elemento en la ruta de reinicio. Entonces, este tipo
de lógica tiene un área menor en comparación con el restablecimiento síncrono.
6.1 Estrategias de reinicio 91
Fig. 6.1 Resultado de la
síntesis para el reinicio asíncrono
6.1.2 Restablecimiento síncrono
La inicialización del elemento secuencial debido al reinicio síncrono depende del flanco activo del
reloj. Como se describe en el Ejemplo 2, la salida de la celda secuencial se asigna a cero mediante
el restablecimiento síncrono que se muestrea en el flanco ascendente del reloj.
Ejemplo 2: RTL para reinicio síncrono
biblioteca
utilizar
entidad synchronous_reset es
: std_logic clk in
Puerto (data_in in ;
std_logic :
std_logic );
in std_logic
fin d
; e
out
reset_n : ;
data_out :
restablecimiento_sincrónico;

La descripción funcional del registro usando la arquitectura de
reinicio síncrono arch_sync_reset de synchronous_reset es
comenzar
proceso (Clk)
comenzar
si _ = '1' y clk'event) entonces
If ( reset_n = '0') luego
data_out <= '0';
else
data_out <= fecha en;
end if; end if
;
terminar arch_sync_reset;
El resultado de la síntesis se muestra en la Fig. 6.2 y, como se muestra, la lógica inferida tiene
el elemento combinacional adicional en la ruta de reinicio. Esto aumenta el área.
noventa y dos
6 Diseño VHDL y Ajustes RTL
Fig. 6.2 Resultado de la síntesis para reinicio síncrono
6.2 Máquinas de estado
Los controladores de la máquina de estado se utilizan para detectar la secuencia así como para generar la
secuencia. Las máquinas de estado de Moore y Mealy se pueden diseñar utilizando un enfoque modular y el
objetivo durante el diseño RTL es tener una salida sin fallas. En este tipo de diseños, el objetivo previsto del
ingeniero de diseño de RTL es lograr la optimización con una sincronización limpia. Según la necesidad, el
diseñador puede utilizar los esquemas de codificación binarios, grises o onehot para lograr los resultados
requeridos.
Los contadores aleatorios, los detectores de secuencia y la secuencia de actualización de DRAM se pueden
codificado mediante el uso de la máquina de estado.
6.2.1 Máquina de Moore
En la máquina de Moore, la salida es función del estado actual únicamente. Debe esperar un ciclo de reloj para
reflejar el cambio en la salida después de los cambios en la entrada.
Este tipo de máquina necesita un estado adicional más en comparación con la máquina Mealy.
Los siguientes son algunos aspectos destacados de Moore FSM:
1. En el Moore FSM, la salida es función del estado actual únicamente.
2. Como la salida es función del estado actual, es estable durante un ciclo de reloj.
3. Debido a la ruta combinacional más corta, el STA es simple para los controladores diseñados con Moore
FSM. Esto da como resultado una mayor frecuencia de operación en comparación con la máquina Mealy.
4. Necesita más estados en comparación con la máquina Mealy, pero la salida es un error
libre ya que es función del estado actual solamente (Fig. 6.3).
6.2 Máquinas de estado 93
Fig. 6.3 Diagrama de bloques de la máquina de Moore
6.2.2 Máquina harinosa
En la máquina Mealy, la salida es función del estado actual y también de la entrada. Este tipo de máquina puede
dar como resultado fallas en la salida. Este tipo de máquina necesita un estado menos en comparación con la
máquina Mealy si se codifica mediante técnicas de codificación binaria.
Los siguientes son algunos aspectos destacados de Mealy FSM:
1. En Mealy FSM, la salida es función del estado actual y también de la entrada.
2. Como la salida es función del estado actual y la entrada, puede cambiar varias veces
durante el período del reloj.
3. Debido a la ruta combinacional más grande, la STA es compleja para los controladores diseñados con Mealy
FSM. Esto da como resultado una frecuencia de operación más baja en comparación con la máquina de
Moore.
4. Necesita menos estados en comparación con la máquina de Moore, pero la salida es propensa a fallas (Fig.
6.4).
Fig. 6.4 Diagrama de bloques de la máquina harinosa
Algunos trucos para mejorar el rendimiento de los FSM:
Para mejorar el rendimiento de los FSM, utilice las siguientes técnicas en el nivel RTL.
1. No use un solo bloque de 'proceso' para codificar las FSM, ya que no cede en el
resultados eficientes.
2. Para lograr la síntesis eficiente para el FPGA/ASIC, utilice el 'proceso' múltiple
bloquear. En la práctica, podemos pensar en usar.
a. Use un bloque de proceso separado para la siguiente lógica de estado que debería inferir la lógica combinacional.
b. Use otro bloque de proceso para el registro de estado y sensible al borde activo del reloj. C. Tercer bloque
de proceso para la lógica de salida y debe inferir la combinación
lógica.
3. Use el bloque de proceso sensible al nivel para el siguiente estado y la lógica de salida tal como están
de naturaleza combinacional.
4. Use el evento clk = '1' y clk' o clk='0' y clk'event dentro del bloque de registro de estado, ya que este bloque se activa
en el borde del reloj activo, puede ser positivo o negativo.
5. Utilice el método de codificación deseado.
no
a. Necesidades de codificación binaria no chanclas para los 2 estados
no
b. La codificación gris necesita flipflops estados
no para el 2c. La codificación
no no
onehot necesita 2 flipflops para los 2 estados
6. Para evitar la inferencia del pestillo, use la condición 'cuando otros' o cubra todo el caso
condiciones durante el uso de la construcción del caso.
7. Para asignar el valor del estado actual en función de la salida lógica del siguiente estado, utilice la construcción 'if
thenelse' y tenga cuidado de que la lógica deseada sea sensible al flanco activo del reloj.
8. Si el área no es un cuello de botella en el diseño y se requiere una sincronización limpia, utilice FSM de codificación
onehot.
9. Para una salida sin fallos, utilice la salida registrada.
6.3 Diseño RTL de la máquina de Moore
Como se discutió anteriormente en la máquina de Moore, la salida es función del estado actual. Para detectar la
secuencia de '101', el RTL se describe utilizando las construcciones sintetizables y se muestra en el Ejemplo 3. El
resultado de la síntesis para Moore FSM se muestra en la Fig. 6.5.
6.3 Diseño RTL de la máquina de Moore 95
Fig. 6.5 Resultado de la síntesis de la máquina de Moore para detectar "101"
Ejemplo 3: Diseño RTL usando VHDL para Moore Machine
biblioteca
ieee;
la entidad moore_machine es
Puerto (clk en std_logic : ;
data_in a std_logic : ;
reset_in a std_logic : ;
data_out fuera : std_logic);
end moore_máquina;
arquitectura arch_moore de moore_machine es
escriba state_type es ( S0, S1, S2, S3);
señal presente_estado, siguiente_estado : tipo_estado;
comenzar
registro_estado : proceso (clk, reset_in)
comenzar
si (restablecer_en = '0') entonces
estado actual <= S0;
otra cosa = '1' y clk'event ) entonces
estado actual <= siguiente_estado;
terminara
si ;
next_state_logic : proceso (estado_presente, datos_en)
comienza
<= S0;
next_state caso
(present_state) es
when S0 => si (datos_en = '1') entonces

next_state <= S1;
else
next_state <= S0;
end if; cuándo
S1 => si (datos_en = '1') entonces
<= S1;
siguiente_estado
más
<= S2;
siguiente_estado
final si; cuándo
next_state <= S3;
else
next_state <= S0;
end if; cuándo
next_state <= S1;
else
next_state <= S2;
end if;
cuando otros => siguiente_estado <= S0;

terminan
el caso;
proceso
finalizado ;
salida_comb_logic : proceso (estado_presente)
comenzar
case (present_state) es
=>
cuando S0 data_out <=
'0'; cuándo
=>
S1 data_out <=
'0'; cuándo
=>
S2 data_out <=
'0'; cuándo
=>
S3 data_out <= otros
'1'; cuando
=>
data_out '0'; caso
final <=
;
final arch_moore;
6.4 Diseño RTL de Mealy Machine
En la máquina Mealy, la salida es función del estado actual y la entrada. Para
detectar la secuencia de '101', el RTL se describe usando las construcciones sintetizables y
se muestra en el Ejemplo 4. El resultado de la síntesis para Mealy FSM se muestra en la Fig. 6.6.
6.4 Diseño RTL de Mealy Machine 97
Fig. 6.6 Resultado de la síntesis de la máquina Mealy para detectar "101"
Ejemplo 4: Diseño RTL usando VHDL para Mealy Machine
biblioteca
ieee;
entidad harinosa_máquina es
Puerto (clk en std_logic : ;
data_in a std_logic : ;
reset_in a std_logic : ;
data_out fuera : std_logic);
final harinoso_máquina;
arquitectura arch_mealy de harinoso_máquina es
escriba state_type es ( S0, S1, S2, S3);
señal presente_estado, siguiente_estado : tipo_estado;
comenzar
registro_estado : proceso (clk, reset_in)
=
comenzar si (reset_in '0') entonces
estado actual <= S0;
otra cosa = '1' y clk'event ) entonces
estado actual <= siguiente_estado;
terminara
si ;
next_state_logic_and_output_decoder : proceso (estado_presente, datos_en)
comenzar
fecha de salida <= '0';
caso (estado_presente) es
cuándo S0 => si (datos_en = '1') entonces
siguiente_estado <= S1;
más
terminara si;
cuándo S1 => si (datos_en = '1') entonces
más
terminara si;
cuando S2 => si (datos_en = '1') entonces
más
terminara si;
cuando otros => siguiente_estado <= S0;
caso final ;
fin arch_mealy;
6.5 Síntesis y optimización de FSM 99
6.5 Síntesis y optimización de FSM
El FSM descrito usando VHDL se puede sintetizar para obtener el tiempo limpio y el área menor. En
tal escenario, se pueden utilizar las mejores técnicas de partición y optimización. La síntesis FSM se
elabora en los Caps. 8 y 9 con más escenarios. • Tenga un diseño separado para el controlador
FSM: use la partición del diseño a nivel funcional o de síntesis para tener una lógica dedicada para
los controladores FSM. Después de la síntesis, si se cumple el rendimiento, utilice el atributo
'no_tocar' para evitar la resíntesis.
• Aísle los controladores de la máquina de estado: si el diseño del SOC tiene varios dominios de reloj
y necesita los controladores de FSM, aísle los controladores de FSM.
Use los límites secuenciales y agrupe la lógica según las regiones del reloj. • Tiempo limpio y
optimización: para un mejor tiempo, use el FSM de codificación onehot, pero esto afectará el área. •
Enfoque de diseño modular: si el requisito de diseño es de múltiples FSM, codifique el RTL
separado para cada controlador de FSM. • Uso del compilador FSM: Para el mejor diseño de partición
de la lógica y para
extraiga los estados en forma de tabla de estado, use el compilador FSM.
• Optimización para una salida sin fallas: Codifique el FSM con una salida sin fallas
y se puede garantizar teniendo los límites de salida secuenciales.
• Retardo combinacional más corto: en general, el rendimiento de temporización de FSM se puede
mejorar al reducir el retardo combinacional de la lógica del siguiente estado. Esto dará como
resultado un mejor rendimiento de FSM. • El resultado de la síntesis del controlador FSM debe
inferir la lógica separada para el 'siguiente estado', el 'registro de estado' y la 'salida'.
6.6 Transferencia de datos y diseño del árbitro
Para transferir los datos entre los diferentes bloques funcionales, comúnmente se utilizan buses de
alta velocidad. Pero esto también se puede lograr mediante el uso de la memoria compartida,
registros con capacidades de lectura/escritura, FIFO e incluso utilizando los protocolos de bus.
La mayoría de las veces, durante el diseño usamos los buses que pueden ser buses de alta
velocidad en los que el procesador puede iniciar transacciones o buses de baja velocidad que pueden
usarse para la transferencia de datos más lenta. Entonces, durante la evolución de la arquitectura,
se deben definir las estrategias para modelar los autobuses. En lugar de usar el bus único, es
recomendable usar los buses múltiples dependiendo de la tasa de datos requerida.
Los buses de uso común para la transferencia de datos en serie son I2C, SPI e incluso la
transferencia de datos asíncrona se puede lograr controlando la velocidad en baudios de UART.
Para los diseños de SOC de gama alta, la velocidad del diseño depende de los buses utilizados
para la comunicación. Los buses AHB/APB pueden ser una buena opción para diseños SOC de gran
densidad. Los IP de este tipo de buses están disponibles en el mercado y, dado que son funcionales
y están probados en tiempo, pueden usarse durante la fase de diseño del SOC.
Dado que varios bloques de diseño utilizan los buses comunes, el equipo de diseño de RTL
debe poder comprender los esquemas de arbitraje de bus necesarios, y estos pueden
implementarse durante la fase de diseño. Algunos de los esquemas de arbitraje son el
encadenamiento tipo margarita, el roundrobin, el arbitraje estático, etc. La siguiente sección trata sobre el árbitro d
6.6.1 Arbitraje de bus
El bus compartido puede ser compartido por varios módulos funcionales (componentes) en el
entorno de diseño. Dependiendo de la solicitud generada por uno de los módulos, se puede
conceder el bus si no está ocupado.
El arbitraje de bus se utiliza para muestrear las solicitudes generadas por los diferentes
componentes del SOC junto con el bus compartido y para otorgar la solicitud a uno de los
componentes del SOC.
Como se muestra en la Fig. 6.7, los componentes múltiples (módulo 1 a módulo n) generan la
solicitud al árbitro de bus y esperan las señales de concesión de los árbitros. Después de recibir
la señal de concesión del árbitro de bus, uno de los componentes obtiene el control del bus
compartido.
En el entorno práctico, hay muchos esquemas para diseñar el arbitraje de bus, y pueden ser
arbitrajes de conexión en cadena, roundrobin y estáticos. Dependiendo de los requisitos de
diseño, estos esquemas se pueden utilizar en los diseños SOC (Fig. 6.8).
El arbitraje estático usando VHDL se describe en el Ejemplo 5. 'request_0' tiene la prioridad
más alta y 'request_2' tiene la prioridad más baja. El resultado de la síntesis se muestra en la Fig.
6.8.
Fig. 6.7 Arbitrajes de bus [1]
6.6 Transferencia de datos y diseño del árbitro 101
Fig. 6.8 Resultado de la síntesis del esquema de árbitro estático
Ejemplo 5: Diseño RTL usando VHDL para árbitro estático
Biblioteca ieee;
Utilice ieee.std_logic_1164.all;
La entidad static_arbiter es
Puerto (
clk, reset_n, request_0, request_1, request_2 a std_logic : ;
concesión_0, concesión_1, concesión_2: fuera std_logic);
final árbitro_estático;
arquitectura arch_arbiter de static_arbiter
es
comenzar
proceso (clk,reset_n,request_0, request_1,request_2)
comenzar
concesión_0 <= '0';

elseif(clk = '1' clk'event) y luego
concesión_0 <= solicitud_0;

concesión_1 <= (solicitud_1 y (no solicitud_0)); ( y
concesión_2 <= (no(solicitud_1 solicitud_0))); solicitud_2
o
terminara
si ;
final arch_árbitro;
Ahora, consideremos cómo podemos agregar las señales de concesión de bus para las múltiples
solicitudes de bus. Considere que el bus es compartido por el procesador, el controlador de datos de alta
velocidad y el controlador de memoria. Como se trata de un bus compartido, si el bus no está ocupado, la
señal de concesión debe proporcionarse al bloque funcional que ha solicitado el bus. En tal escenario, el
arbitraje de bus debe implementarse para evitar la contención de bus y lograr la transferencia de datos entre
los elementos.
El RTL para el árbitro con entrada de bus ocupado se describe en el Ejemplo 6. El
el resultado de la síntesis se muestra en la Fig. 6.9.
Ejemplo 6: Diseño RTL utilizando VHDL para el árbitro con señal de ocupado
biblioteca
ieee;
La entidad arbitrator1 es
Puerto (
clk , reset_n, request_0, request_1, request_2 en std_logic : ;
: en std_logic (2 ;
bus_ocupado
std_logic_vector downto 0)); otorgar: fuera
Fig. 6.9 Resultado de la síntesis del árbitro de bus con señal de ocupado
6.6 Transferencia de datos y diseño del árbitro 103
fin
árbitro1; arquitectura arch_arbiter de árbitro1 es
Señales Bus_ocupado_1, Bus_ocupado_2 : Std_logic ;
comenzar
p1: (clk, reset_n) proceso
comenzar
si (reset_n '0') =
entonces
busy_bus_1 '0'; e<=
lsif(clk
y '1'
= bus_ocupado_1
clk'event) luego
<=
bus_ocupado; terminara
si;
fin p1; proceso
p2: comienza el proceso (busy_bus,
busy_bus_1 )
if = '0' y bus_ocupado_1 = '1' ) entonces
<= '1';
<= '0';
;
(autobus_ocupado_autobus_ocupado_2
else_autobus_ocupado_2 fin si
fin p2; proceso
proceso (clk, reset_n) p3:
comenzar
otorgar e<= "000";
lsif
(clk
'1' y clk'event)
luego i=f
(busy_bus_2 '1') luego “000”;
conceder otra cosa (= bus_ocupado
<=
= '0') entonces
subvención(0) <= solicitud_0;

subvención(1) <= solicitud_1 y no(solicitud_0);
subvención(2) <= solicitud_2 y (solicitud_0);
no (solicitud_1) y no
terminara
si ;
terminara
si ;
final arch_árbitro;
6.7 Diseños basados en DSP y estrategias RTL
Mientras diseñamos el SOC para las aplicaciones DSP, ¿qué debemos pensar?
Esto se responde en esta sección.
1. ¿Qué tipo de núcleo de procesador DSP puedo elegir?
Las aplicaciones DSP requieren un gran ancho de banda debido a la complejidad de los algoritmos
de procesamiento de datos de alta gama. Entonces, la mayoría de las veces, intentaremos usar las IP
disponibles durante la fase de diseño del SOC. La capacidad de las IP y el núcleo decide la velocidad
general y el rendimiento del diseño.
a. El núcleo debe tener la capacidad de realizar las operaciones de coma flotante. b. Para
aplicaciones DSP, se requieren mayores cantidades de memoria interna y registros de almacenamiento.
Entonces, el núcleo debe tener la capacidad de tener los registros requeridos que se pueden usar
durante el cálculo.
C. La necesidad adicional son los búferes circulares y los mecanismos FIFO para admitir la puesta en
cola de los datos. d. El núcleo debe tener multiplicadores de alta densidad y acumuladores y
desplazadores de gran densidad. Estos se pueden utilizar durante las operaciones de filtrado. Y. La
arquitectura debe admitir el acceso separado a la memoria de datos y programas, así como
funciones de canalización y multitarea. F. El núcleo debe tener interfaces de transferencia de datos
adicionales para datos de alta velocidad
transferir.
2. El núcleo debe tener capacidad DMA en el chip: para la ráfaga de la transferencia de datos, el sistema
DSP debe tener el controlador DMA en el chip. Esto se usará durante la ráfaga de transferencias de
datos sin involucrar al procesador DSP. Al diseñar los sistemas DSP, la velocidad del DMA es un
parámetro importante, y durante el diseño de nivel superior, el equipo de integración debe tener cuidado
de implementar los sincronizadores necesarios para los diseños de dominio de múltiples relojes.
3. El núcleo debe tener las interfaces seriales: las capacidades como la transferencia de datos seriales
usando I2C o SPI pueden ser una ventaja adicional. Se pueden utilizar para interconectar los dispositivos
seriales eternos con el SOC [1]. La mayoría de las veces, los dispositivos seriales se usan para
transferir o aceptar los datos seriales y, en este escenario, se pueden usar las capacidades del
controlador de bus serial.
4. El núcleo debe tener el PLL en el chip: los bucles de bloqueo de fase se utilizan para generar el reloj y la
lógica de distribución de reloj adicional para la distribución de reloj con sesgo de reloj uniforme [1].
Entonces, si imaginamos la estructura de reloj para el prototipo que usa múltiples FPGA, entonces
podemos imaginar el árbol de reloj que puede generar relojes con un sesgo de reloj uniforme.
5. El núcleo debe tener el procesamiento de datos en tiempo real: considere la aplicación como codificación
de cuadros de video de tamaño HD, y para tales aplicaciones, los datos en tiempo real deben
comprimirse y deben ser emitidos por el codificador. En tal escenario de ios, los datos en tiempo real,
los temporizadores y las capacidades de reloj en tiempo real deben estar presentes en el DSP SOC [1].
6.7 Diseños basados en DSP y estrategias RTL 105
6. Controladores USB adicionales para la transferencia de datos en serie: la interfaz USB para la
transferencia de datos en serie entre el sistema host y el núcleo del procesador DSP se puede
utilizar en la mayoría de las arquitecturas.
7. Interfaces y bloques analógicos adicionales: los bloques analógicos como ADC y
Los DAC deben estar presentes para la conversión de datos.
Además de todo lo anterior, es necesario pensar en los controladores de bus y sus capacidades para
la transferencia de datos a alta velocidad. Al considerar todas estas características, la arquitectura del
SOC para las capacidades de DSP se puede diseñar y desarrollar. La Figura 6.10 describe componentes
importantes del sistema DSP.
Reloj en tiempo real
Controladores USB
Núcleos de procesador DSP
Temporizador
ExternoBus De serie
interfaz interfaces I2c
Almacenamiento interno
y SPI
extensión DMA
controladores
anuncio CAD extensión PL
Fig. 6.10 Arquitectura para el sistema de procesamiento DSP [1]
6.8 Ajustes RTL recomendados
Como se discutió en los capítulos anteriores, durante la fase de diseño RTL, los diseños complejos se
dividen en los límites secuenciales al considerar la funcionalidad del diseño. Las siguientes pueden
ser algunas de las recomendaciones importantes para los ajustes de RTL.
1. El diseño RTL para cualquier bloque funcional debe dar como resultado la lógica prevista.
Ahora imagine que la funcionalidad está codificada usando el único 'caso de fin de caso' con
estructuras y tiene más de 16 condiciones, luego se recomienda modificar el RTL usando
múltiples 'casos'. Esto dará como resultado un paralelismo mejorado y una sincronización limpia.
2. Ahora imagine otro escenario, el diseño usa la construcción 'ifthenelse' y el requisito es de lógica
paralela sin ninguna prioridad. En tales circunstancias, el RTL se puede modificar utilizando los
bloques de procesos múltiples y la construcción de 'caso'.
3. Si el RTL usa la lógica de tres estados, modifique la lógica usando los multiplexores.
Aunque se recomienda tener una lógica de tres estados en el nivel superior.
4. Considere el diseño de dominio de reloj múltiple RTL y luego implemente los sincronizadores para
el diseño ASIC. Para los diseños de FPGA, tenga un diseño de sincronizador separado (ya sea
de nivel o de pulso) y despliéguelos en las rutas de control requeridas.
5. Modifique el RTL utilizando la técnica de agrupación para obtener la inferencia de la lógica
en dos rutas de datos múltiples.
6. Modifique el RTL empujando los recursos comunes en el lado de salida y la cadena de lógica de
selección en el lado de entrada.
7. Si hay varios estados no utilizados en el controlador FSM, modifique el RTL para eliminar los
estados redundantes o use 'cuando otros' para inicializar la salida de estados no utilizados a la
secuencia de inicialización.
8. Si los factores comunes o las expresiones se usan durante el RTL, modifique el RTL para evitar la
inferencia lógica repetida debido a los factores comunes.
9. Modifique el RTL de tal manera que el diseño debería tener una mejor estructura, legibilidad y una
mejor partición en los límites secuenciales.
10. Si se desarrolla FIFO RTL y el problema es la generación de direcciones de escritura y lectura,
modifique el RTL utilizando los punteros grises.
1. El controlador FSM se puede diseñar utilizando las máquinas de Moore o Mealy.
2. En la máquina de Moore, la salida es función del estado actual, mientras que en la máquina de
Mealy la salida es función de la entrada actual y el estado actual.
3. Use los múltiples bloques de 'proceso' durante el diseño RTL de máquinas de estado, secuencia
generador.
4. Para una sincronización limpia, use el FSM de codificación onehot.
5. Para una salida sin fallas en Moore FSM, use la salida registrada y controle el comportamiento de la ruta de
registro a registro.
6. Los árbitros de bus se utilizan para evitar la contención de bus, y existen muchos esquemas como el árbitro
estático, el árbitro de todos contra todos.
7. En lugar de usar el bus único en SOC, intente usar múltiples buses para el procesador
y periféricos.
8. Las capacidades de DSP deben incluir las operaciones de punto flotante y los controladores DMA en el chip.
Este capítulo nos ha permitido comprender la síntesis de FSM, la máquina de Moore y Mealy y cómo
mejorar el rendimiento de la máquina de estados. Incluso hemos discutido sobre los ajustes de RTL,
el árbitro y cómo explorar la arquitectura para aplicaciones basadas en DSP. El siguiente capítulo
tratará sobre la síntesis ASIC usando Synopsys DC y los comandos importantes de DC usados durante
la síntesis.
Referencia
Capítulo 7
Restricciones de diseño y síntesis de ASIC
"El equipo de síntesis de ASIC debería comprender mejor las
restricciones de diseño a nivel de bloque, nivel superior y nivel de chip".
Resumen El capítulo analiza la síntesis ASIC y los comandos de Synopsys DC de uso frecuente y
su función durante la síntesis ASIC. Incluso el capítulo trata sobre la partición del diseño, las pautas
de síntesis y las restricciones de diseño. Los comandos DC utilizados durante la síntesis y su
función se describen para una mejor comprensión de los scripts de síntesis o para crear scripts de
síntesis para las restricciones requeridas.
El capítulo es útil para comprender el área, las restricciones de velocidad y la síntesis lógica
utilizando Synopsys DC.
Palabras clave ASIC ∙ SOC ∙ Síntesis lógica ∙ Síntesis física ∙ Restricciones ∙
Área Velocidad Potencia Comandos CC Reloj Latencia Relojes generados _ _ _ _
Ruta falsa Ruta multiciclo Retardo de entrada Retardo de salida Informe de temporización
Optimización ∙ Reloj red
7.1 Diseño de particiones para diseños complejos
La mayoría de las veces, discutimos sobre la arquitectura de nivel superior con la mejor partición
del diseño. La partición del diseño para cualquier ASIC o SOC es un hito importante para realizar el
prototipo eficiente con una ruta de tiempo limpia. El diseño SOC o ASIC tiene bloques analógicos y
digitales, y el equipo de diseño necesita tener una mejor comprensión de la cadena de herramientas
EDA utilizada durante varios hitos. Durante la síntesis lógica y física, el objetivo del equipo es tener
la optimización del diseño para el área, la velocidad y la potencia. El diseño se puede particionar a
nivel de arquitectura, a nivel de síntesis o de netlist. En tales circunstancias, el seguimiento puede
ser un proceso de pensamiento mientras se dividen los diseños complejos.
1. Partición de hardware y software: para los SOC complejos, la partición de software y hardware
es el requisito principal. La razón es que el tiempo
https://doi.org/10.1007/9789811513145_7
110 7 Restricciones de diseño y síntesis de ASIC
instancia en la que se ejecutan las llamadas funcionales del software y la latencia requerida para transferir
o recuperar los datos juega un papel importante para obtener el rendimiento deseado. El objetivo principal
del equipo de arquitectos es tener una latencia baja durante la transferencia de datos de alta velocidad.
Los bloques funcionales que deben implementarse con el software y los bloques que deben diseñarse con
el lenguaje de construcción de hardware (HCL) o HDL deben decidirse a nivel de arquitectura para lograr
un mejor rendimiento, velocidad, potencia y ancho de banda.
2. Particionamiento para el aislamiento del dominio de potencia: durante esta década, el requisito real son los
diseños de dominio de baja potencia y múltiples potencias. Los requisitos de potencia para los bloques
analógicos y digitales varían según la densidad lógica, por lo que la pregunta fundamental que debemos
abordar es si podemos tener una estrategia para aislar los dominios de potencia según los requisitos de
los bloques analógicos y digitales. La respuesta es 'sí', ya que el diseño debe tener aislamientos de
dominio de potencia analógicos y digitales, y se recomienda tener la arquitectura de baja potencia con la
secuencia de potencia.
3. Dividir el diseño en límites secuenciales: la mayoría de las veces, para la sincronización limpia, el requisito
principal es la partición eficiente del diseño y eso debe lograrse en los límites secuenciales. Por ejemplo,
si consideramos el codificador H.264 que necesita los bloques funcionales como predicción, cuantificación,
transformación y codificación de entropía, entonces podemos dividir el diseño a nivel de bloque a través
de límites secuenciales. Nuevamente, al utilizar el enfoque modular, podemos dividir el diseño funcional a
nivel de bloque mediante el uso de entradas registradas y salidas registradas.
4. Particionamiento considerando múltiples dominios de reloj: la mayoría de los SOC tienen múltiples relojes.
Por ejemplo, considere el SOC que tiene varios procesadores, un controlador de bus y un controlador de
memoria; en este tipo de diseños, el procesador, el controlador de bus y el controlador de memoria pueden
funcionar a diferentes frecuencias de reloj. La necesidad inmediata es tener múltiples arquitecturas de
dominio de reloj para este tipo de diseño. Las estrategias para implementar sincronizadores deben
decidirse al más alto nivel. Por lo tanto, la partición del diseño considerando el procesador como dominio
CLKI, el controlador de bus en el dominio CLKII y el controlador de memoria en el dominio CLKIII será útil
para crear los grupos de ruta y diseño separados.
5. Particionamiento para diseños basados en FPGA: los FPGA son buenos candidatos para la implementación
de lógica digital. El SOC tiene bloques digitales y analógicos, así que divida el diseño para tener un
prototipo separado para bloques digitales y analógicos. La estrategia de implementación debe ser mediante
el uso de FPGA individuales o múltiples para implementar el diseño digital. Para los bloques analógicos,
como ADC, DAC, estructuras de reloj, suministro de energía y bloques de monitoreo/enfriamiento de
temperatura, use las placas equivalentes analógicas separadas con las interfaces requeridas.
Algunos de los puntos destacados importantes para este tipo de implementación de diseño y
prototipo usando FPGA se enumeran a continuación.
a. Comprobar si el diseño necesita un prototipo de FPGA único o múltiple b. Compruebe la
disponibilidad de E/S y la velocidad de transferencia de datos y la partición en los límites secuenciales.
7.2 Síntesis ASIC 111
C. Si se requieren múltiples FPGA, use la conexión de bus requerida
idad/topología como conexión en cadena, estrella o interconexión mixta.
6. Partición para tener controladores FSM modulares: la mayoría de los SOC necesitan los algoritmos
de secuenciación de energía, DDR necesita los ciclos de actualización y el controlador de bus
necesita la transferencia de datos de alta velocidad. En este tipo de diseños, utilice el enfoque
modular al implementar los controladores FSM. El objetivo debe ser el tiempo limpio y el área
menor. Utilice las técnicas de codificación gray o onehot al implementar los controladores FSM.
Intente tener el diseño del controlador FSM con una salida sin fallas.
7. Particionar para una mejor gestión de la configuración: Particionar el diseño a nivel de arquitectura
para tener registros de configuración dedicados, memorias para inicializar la secuencia para el
SOC.
7.2 Síntesis ASIC
Como la mayoría de nosotros estamos familiarizados con el término síntesis, la síntesis es el proceso
de convertir el diseño del nivel superior de abstracción al nivel inferior de abstracción.
Es necesario llevar a cabo la síntesis lógica y física para lograr los objetivos deseados para tener el
área y el poder mínimos. Otro objetivo importante es que el diseño cumpla con las restricciones de
velocidad requeridas. Durante la fase de síntesis, el equipo de diseño puede utilizar las técnicas de
optimización y mejora del rendimiento para lograr mejores resultados. La herramienta de síntesis utiliza
las siguientes entradas para realizar la síntesis:
1. Diseño RTL 2.
Las bibliotecas ASIC 3. Las
restricciones de diseño.
El resultado de la síntesis de ASIC y FPGA es la lista de conexiones a nivel de puerta. Para los
diseños ASIC, la herramienta de síntesis ASIC utiliza las celdas estándar, macros, componentes DW
para tener la lista de conexiones a nivel de puerta. Durante la síntesis de FPGA, la herramienta de
síntesis utiliza los recursos de FPGA, como CLB, IOB, bloques DSP, BRAM, RAM distribuida e IP de
procesador duro. Considere la implementación de H.264 usando ASIC (Fig. 7.1). En este tipo de
diseños complejos, se debe decidir la estrategia para el prototipo de FPGA y para el diseño de ASIC.
La síntesis ASIC y la síntesis FPGA diferirán en muchos aspectos y se analizarán en algunos capítulos
posteriores.
Synopsys Design Compiler (DC) lee las bibliotecas de celdas estándar y la descripción RTL para
generar la lista de conexiones a nivel de puerta dependiente de la tecnología. La síntesis es el proceso
de convertir el diseño del nivel superior de abstracción al nivel inferior de abstracción del diseño.
La herramienta de síntesis debe ser lo suficientemente eficiente como para optimizar el diseño para
las restricciones dadas. Las entradas a la herramienta de síntesis son bibliotecas, uso de descripción
RTL, ya sea VHDL o Verilog, y restricciones de diseño. La salida de la herramienta de síntesis es netlist
a nivel de puerta (Fig. 7.2).
Fig. 7.1 Diseño de nivel superior del codificador H.264
Fig. 7.2 Entradas y salidas de la herramienta de síntesis
La herramienta de síntesis realiza muchos pasos durante la optimización para generar el
netlist requerido a nivel de puerta, y estos pasos se describen en esta sección:
DC lee las bibliotecas de símbolos, tecnología y DesignWare para realizar la síntesis. La
herramienta Synthesis es lo suficientemente inteligente como para identificar los componentes
de DesignWare y la biblioteca de tecnología. La biblioteca de tecnología consta de puertas
lógicas, flipflops y pestillos. Los componentes complejos como comparadores, sumadores,
multiplicadores son parte de la biblioteca DesignWare. Mediante el uso eficiente de estos
componentes, ya sea de DesignWare o de la biblioteca de tecnología, el DC realiza la síntesis
para generar la lista de conexiones a nivel de puerta.
En el siguiente paso, el controlador de dominio lee el RTL escrito en VHDL o Verilog y
continúa con el siguiente paso, donde puede asignarse a la biblioteca de enlaces si está en el
formato de nivel de puerta. La herramienta de síntesis realiza la optimización de RTL antes de
asignar las celdas a la tecnología o biblioteca de destino.
La herramienta de síntesis utiliza las restricciones de diseño, como el área, la velocidad, la
potencia y las restricciones ambientales mientras realiza la síntesis. Las restricciones son
específicas del diseño y deben especificarse para el resultado deseado o requerido del diseño.
El principal punto importante es que el diseño de RTL y el equipo de síntesis deben conocer
la biblioteca de células estándar de destino para que el diseño pueda optimizarse para obtener
el resultado funcional requerido.
7.3 Síntesis usando Design Compiler (DC) 113
En el entorno práctico, al utilizar Synopsys DC, siempre se debe tener cuidado con las restricciones
requeridas, que son principalmente el área, la velocidad y la potencia.
Hay muchos diseños en los que la restricción está en la utilización total del área. Para el diseño de un millón
de puertas, la síntesis y la optimización es un proceso iterativo, ya que requiere una partición de diseño
eficiente e incluso restricciones estrictas para obtener el rendimiento deseado. Para diseños ASIC complejos,
los equipos de diseño, síntesis y STA de RTL trabajan en estrecha colaboración para lograr la funcionalidad
de diseño prevista para las restricciones dadas.
Los siguientes son los pasos importantes durante la síntesis con Synopsys DC:
1. Leer bibliotecas de celdas estándar
2. Leer Netlist 3. Asignar a la biblioteca
de enlaces 4. Aplicar restricciones de
diseño 5. Asignar y optimizar para la
biblioteca de destino 6. Escribir una lista de conexiones
optimizada.
7.3 Síntesis usando Design Compiler (DC)
Synopsys Design Compiler (DC) es una poderosa herramienta de síntesis utilizada por industrias líderes
para realizar la síntesis lógica. Esta sección analiza los comandos de CC importantes que se utilizan durante
la síntesis lógica.
1. Configuración y entorno de CC:
Después de invocar Synopsys Design Compiler, lee el archivo de inicio del directorio de trabajo actual. El
archivo de inicio es synopsis_dc.setup. Debe haber dos archivos de inicio: uno debe estar en el directorio de
trabajo actual y otro debe estar en el directorio raíz donde está instalado Design Compiler. Para utilizar la
herramienta, es necesario configurar los siguientes parámetros importantes.
1. search_path: este parámetro se utiliza para buscar la biblioteca de tecnología de síntesis como referencia
durante la síntesis. 2. target_library: este parámetro lo utiliza el controlador de dominio al mapear las
celdas lógicas durante la síntesis. La biblioteca de destino consiste en las celdas lógicas.
3. symbol_library: Todas las celdas lógicas tienen representación simbólica utilizada para la visualización
después de la síntesis. Este parámetro se utiliza para pintar la biblioteca que contiene la información
visual de las celdas lógicas presentes en la biblioteca de síntesis de tecnología.
4. link_library: la herramienta usa las celdas de target_library para mapear la funcionalidad deseada, este
parámetro se usa para señalar la referencia de las puertas lógicas en la biblioteca de tecnología de
síntesis.
Los cuatro parámetros anteriores para .synopsys_dc.setup se describen utilizando lo siguiente:
Tabla 7.1 Objetos de diseño utilizados por la herramienta de síntesis
Objeto de diseño Descripción
célula Cell también se llama como una instancia. El nombre instanciado del subdiseño se denomina celda.
Referencia Es diseño original a que celda o instancia se refiere. Por ejemplo, el subdiseño ejemplificado debe referirse
al diseño que consiste en la descripción funcional del subdiseño.
Puertos Las entradas y salidas primarias o IO del diseño se denominan puertos.
Patas Las entradas, salidas y E/S primarias de las celdas en el diseño se denominan pines.
neto Los cables utilizados para la conexión entre los puertos de los pines de los diferentes diseños se denominan
red.
Reloj El puerto de entrada o pin utilizado como fuente de reloj se denomina reloj.
biblioteca Las celdas específicas de la tecnología que se utilizan para orientar la síntesis, la vinculación o la
referencia se denominan biblioteca.
establezca search_path “./synopsys/libraries/syn/cell_library/syn” establezca
target_library “tcbn65lpwc.db, tcbn65lpbc.db” establezca link_library
“$target_library $symbol_library” establezca symbol_library “standard.sldb
dw_foundation.sldb”
Una vez que la variable o los parámetros anteriores se configuran para la biblioteca de destino, el
La herramienta de síntesis se puede invocar mediante el símbolo del sistema.
2. Objetos de diseño: Los objetos de diseño se describen en la siguiente tabla y se utilizan durante la
síntesis. Cada diseño es la descripción del circuito lógico para realizar algunas de las operaciones
lógicas. El diseño puede ser una descripción de un solo sistema o puede consistir en múltiples
subsistemas. Los objetos de diseño se describen en la Tabla 7.1.
Como se indica en el Cap. 2, los comandos de CC de uso frecuente se enumeran en la Tabla 7.2.
7.4 Comandos DC usados durante la síntesis
El diseño se describe usando lenguajes VHDL o Verilog usando las construcciones sintetizables. Este
diseño se utiliza como una de las entradas de CC. La Tabla 7.3 describe los comandos importantes
utilizados por DC para analizar, elaborar y leer el diseño.
7.4 Comandos DC usados durante la síntesis 115
Tabla 7.2 Comandos de CC importantes [1]
dominio Descripción
formato de lectura <tipo_de_formato> <nombre de archivo> Leer el diseño
analizar –format <tipo_de_formato> <lista de nombres de archivos> Analice el diseño en busca de
errores de sintaxis y traducción
antes
construyendo la lógica
genérica
procesado –formato <lista de nombres de módulos> Se utiliza para elaborar el
diseño.
cheque_diseño Para verificar los problemas
de diseño como cortos,
abiertos, conexiones múltiples
e instancias sin conexiones
create_clock –name <nombre_del_reloj> period <período_del_reloj> Crear el reloj para el diseño.
<nombres_del_reloj>
set_clock_skew –rise_delay <rising_clock_skew> <nombre_del_reloj> Definir el sesgo de reloj para
el diseño.
set_input_delay –clock <nombres_reloj> <retraso_entrada> <puerto_entrada> Para configurar el retraso del puerto
set_output_delay –clock <nombres_reloj> <retraso_salida> <puerto_salida> de entrada
Para configurar el retraso del puerto
de salida
compilar –map_effort <map_effort_level> Para compilar con el nivel de
esfuerzo de mapa bajo, medio o
alto
write –format <tipo_formato> salida <nombre_archivo> Para guardar la salida
generada por la
herramienta de síntesis
set_false_path –from [get_ports <lista de puertos>] –to get_ports <lista de puertos>] Para establecer la ruta falsa
set_multicycle_path – configurar <período> desde [obtener_células] –hasta Para impulsar la configuración para
[obtener_células[ el diseño que tiene una ruta de varios
ciclos
set_multicycle_path –mantener <período> desde [obtener_células] –hasta Para empujar la retención para el
[obtener_células[ diseño que tiene una ruta de varios
ciclos
establecer_reloj_incertidumbre Para definir el sesgo de red
estimado
set_clock_latency Para definir el estimado
fuente y red
latencia
establecer_reloj_transición Definir el sesgo de reloj
estimado
establecer_no_tocar Se utiliza para evitar la
optimización de las puertas
mapeadas.
Tabla 7.3 Comandos utilizados para leer el diseño
dominio Descripción El
read –format <tipo_de_formato> <nombre de archivo> comando se utiliza para leer el diseño. Por ejemplo, el
diseñador necesita leer el procesador de diseño.vhd y
luego sigue el comando readformat vhdl processor.vhd
analizar –format <tipo_de_formato> <lista de archivos Se utiliza para analizar el diseño en busca de errores
nombres> de sintaxis y también para la traducción antes de
construir la lógica genérica. La lógica genérica es parte de
la biblioteca independiente de tecnología genérica de
Synopsys. Los componentes se nombran como GTECH.
Esta lógica es una representación no mapeada de las
funciones booleanas.
El siguiente es el comando analizar
–formato vhdl procesador_top.vhd
procesado –formato <lista de nombres de módulos> Se utiliza para elaborar el diseño y se puede utilizar para
especificar las diferentes arquitecturas durante la
elaboración para el mismo diseño analizado. El comando
puede ser elaborado – trabajo de biblioteca processor_top
7.4.1 Comandos DC para leer el diseño
1. Los comandos de análisis y elaboración se utilizan para aprobar los requisitos
parámetros al elaborar el diseño.
2. Utilizando los comandos de análisis y elaboración, se pueden especificar las diferentes
arquitecturas durante la elaboración para el mismo diseño analizado.
3. El comando de lectura se usa al ingresar para los diseños precompilados o netlists
en CC.
4. El comando de lectura no permite el uso de las diferentes arquitecturas.
7.4.2 Comandos DC para verificar el diseño
Después de que el DC haya leído el diseño, check_design se usa para verificar los problemas en el
diseño. La Tabla 7.4 describe el comando utilizado para verificar los errores en el diseño.
Tabla 7.4 Comando utilizado para comprobar el diseño
check_design Se usa para verificar los problemas de diseño como cortos, abiertos, conexiones múltiples,
e instanciaciones sin conexiones check_design
Tabla 7.5 Comandos para definición de reloj
create_clock –name <nombre_reloj>period Se usa para crear el reloj para el diseño y
<período_reloj> <nombre_pin_reloj> se usa como referencia durante el análisis de
tiempo. El reloj siempre está asociado con el
pin del reloj del diseño. Si el diseño no tiene
reloj, se tratará como un reloj virtual. Por
ejemplo, el siguiente comando se puede usar
para generar un reloj de 500 MHz con un ciclo
de trabajo del 50 %: create_clock –name clock
period 2 master_clock
7.4.2.1 Comando DC para definir reloj
El reloj se define mediante el comando create_clock. La Tabla 7.5 describe los comandos de
definición de reloj.
Si el diseñador desea usar el reloj para un ciclo de trabajo variable con flanco ascendente en 1 ns y
un período de reloj de 5 ns, entonces el mismo comando puede modificarse como create_clock –
name clock period 5 –waveform {1,5} –name master_clock If el diseño no tiene el pin del reloj,
entonces el reloj virtual se crea usando los siguientes comandos.
Este comando genera un reloj virtual de frecuencia de 200 MHz con un ciclo de trabajo del 50%.
create_clock –name clock period 5 Este comando genera un reloj virtual de frecuencia de 200 MHz.
con ciclo de trabajo variable con flanco ascendente a 1 ns y flanco descendente a 5 ns. create_clock
–nombre reloj periodo 5 –forma de onda {1,5}
7.4.3 Comandos DC para definir sesgo
El sesgo es la diferencia entre las llegadas de los bordes del reloj en varios pines del flipflop.
Sesgo de reloj positivo: si el reloj en el flipflop de destino se retrasa con respecto al flipflop de
origen, entonces el sesgo se denomina sesgo de reloj positivo y es útil para la configuración. La
razón es que el reloj en el flipflop de destino se retrasa y, debido a eso, permite mucho margen de
tiempo adicional para el diseño.
Sesgo de reloj negativo: si el reloj en el flipflop de origen se retrasa con respecto al flipflop de
destino, entonces el sesgo se denomina sesgo de reloj negativo y es útil para la retención.
Design Compiler no podrá sintetizar el árbol del reloj, por lo que para solucionar el problema, se
usa el sesgo del reloj para modelar el retraso de propagación que existe en el árbol del reloj.
La Tabla 7.6 describe los comandos utilizados por DC al definir el sesgo de reloj para el diseño.
7.4.4 Comandos de CC para especificar el retardo de entrada y salida
Para especificar los retardos de entrada y salida, utilice los comandos set_input_delay y
set_output_delay , respectivamente. La Tabla 7.7 describe el comando utilizado con la definición
de parámetros requerida.
7.4.5 Comandos DC para especificar el retardo mínimo (Min)
y máximo (Max)
Los retrasos de entrada y salida se pueden especificar como mínimo o máximo según los
requisitos de diseño. La Tabla 7.8 describe las definiciones de retraso mínimo y máximo.
Tabla 7.6 Comandos utilizados para las definiciones de sesgo
set_clock_skew –rise_delay Este comando se utiliza para definir el sesgo de reloj para el
<ascendente_desviación_del_reloj> diseño. Esto se puede describir como
fall_delay <descendente_desviación_del_reloj> set_clock_skew –rise_delay 2 – fall_delay 1 master_clock
<nombre_del_reloj>
Tabla 7.7 Comandos utilizados para las definiciones de retardo de entrada y salida
set_input_delay –clock <nombre_reloj> Se utiliza para definir el retraso del puerto de
<retraso_entrada> <puerto_entrada> entrada con referencia al reloj. Para definir un retraso
de 1 ns con referencia al reloj, el comando se puede
usar como set_input_delay –clock reloj_maestro 1
entrada_datos
set_output_delay –clock <nombre_reloj> Se utiliza para definir el retraso del puerto de salida
<retraso_salida> <puerto_salida> con referencia al reloj. Para definir un retraso de 1 ns
con referencia al reloj, el comando se puede usar como
set_output_delay –clock master_clock 1 data_out
Tabla 7.8 Comandos utilizados para las definiciones de retardo de E/S
dominio mínimo y
set_input_delay –clock < nombre_del_reloj> max máximo Descripción Se utiliza para definir el retardo
<retraso> <puerto_de_entrada> máximo del puerto de entrada con referencia al reloj.
Para definir un retraso de 2 ns con referencia al reloj,
el comando se puede usar como set_input_delay –
clock master_clock –max 2 data_in
set_input_delay –clock < nombre_reloj> min <retraso> Se utiliza para definir el retraso mínimo del puerto de
<puerto_entrada> entrada con referencia al reloj. Para definir un retraso
de 1 ns con referencia al reloj, el comando se puede
usar como set_input_delay –clock master_clock –min
1 data_in
set_output_delay –clock < nombre_reloj> max <retraso> Se utiliza para definir el retraso máximo del puerto de
<puerto_salida> salida con referencia al reloj. Para definir un retraso de
2 ns con referencia al reloj, el comando se puede usar
como
set_output_delay –reloj reloj_maestro –max 2
data_out
set_output_delay –clock < nombre_reloj> min <retraso> Se utiliza para definir el retraso mínimo del puerto de
<puerto_salida> salida con referencia al reloj. Para definir un retraso de
1 ns con referencia al reloj, el comando se puede usar
como set_output_delay –clock master_clock –min 1
data_out
Tabla 7.9 Comando utilizado para compilar el diseño
compile –map_effort <map_effort_level> Este comando se utiliza para realizar la síntesis del
diseño con diferentes niveles de esfuerzo, como bajo, medio
y alto. El comando para el nivel de esfuerzo medio se puede
compilar –map_effort medio
7.4.6 Comando utilizado para realizar la síntesis
Usando el comando compile , se realiza la síntesis del diseño, antes de la síntesis, se deben
especificar las restricciones del diseño. El diseño se puede sintetizar para los diferentes niveles
de esfuerzo como bajo, medio y alto.
La Tabla 7.9 describe el comando de compilación.
Tabla 7.10 Comando utilizado para guardar la lista de conexiones
dominio a nivel de
write –format <tipo_de_formato> output puerta Descripción Este comando se utiliza para
<nombre_de_archivo> guardar la salida generada por la herramienta de
síntesis en varios formatos. Para el formato VHDL, el
comando se puede escribir –format vhdl output
procesador_netlist.vhd
7.4.7 Comando DC para guardar el diseño
Para guardar la salida de síntesis se utiliza el comando de escritura . Este comando puede guardar la salida en
varios formatos especificados por Design Compiler. El formato puede ser VHDL o formato de base de datos (ddc).
La Tabla 7.10 describe el comando utilizado para guardar el diseño.
7.5 Restricciones de optimización de diseño y secuencias de comandos básicas
Deben cumplirse las restricciones de diseño, como la velocidad del área y la potencia, y esta sección analiza algunos
de los comandos de Synopsys DC utilizados al restringir los diseños de ASIC.
Los siguientes pasos son realizados por la herramienta de síntesis:
1. La herramienta de síntesis lee las bibliotecas DesignWare, la tecnología y las bibliotecas de símbolos.
2. El segundo paso es leer el RTL descrito por Verilog.
3. Realice la optimización para asignar la lógica utilizando la biblioteca de tecnología que se
también llamada biblioteca de destino.
4. Use las restricciones de diseño como área, velocidad y potencia y realice las
mejoramiento.
5. Asigne el diseño a la biblioteca de destino y optimice el diseño.
6. Finalmente, escriba la lista de conexiones optimizada en formato (.vhd) o (.ddc).
El script de restricción de diseño de muestra se proporciona a continuación.
Ejemplo 1: Script básico clk.src para diseño de 1 GHz
/*establece el reloj*/
establece el reloj
/* establece el período del reloj */
establece el período_del_reloj 1
/* establecer la latencia */
7.5 Restricciones de optimización de diseño y secuencias de comandos básicas 121
establecer latencia 0.025
/* establecer el desfase del
reloj*/ establecer el desfase_temprano_del_reloj [expr $período_del_reloj/
10.0] establecer el sesgo_del_reloj tardío [expr $período_del_reloj/20.0]
/* establece la transición del reloj
*/ establece la transición_del_reloj [expr $periodo_del_reloj/100.0]
/* establece el retraso externo*/
establece external_delay [expr $ clockperiod*0.2]
/* definir la incertidumbre del reloj */
establecer clock_uncertainty –setup $early_clock_skew set
clock_uncertainty –mantener $late_clock_skew
Use el script anterior como clk.src y para generar los informes use los siguientes comandos.
Ejemplo 2: Comandos de generación de informes
dc_shell> informe_timing
Dc_shell> informe_reloj
Dc_shell> report_constraintsall_violators
El informe de tiempo para la verificación de configuración se muestra en el Informe 1. Como se muestra en el
informe, la demora de configuración, que es la diferencia entre el tiempo requerido de datos y el tiempo de llegada
de datos, es positiva. Esta holgura se cumple y, por lo tanto, el diseño no tiene ninguna violación de tiempo.
Informe 1: informe de tiempo para el análisis de configuración
Fig. 7.3 Latencia de la red del reloj
7.6 Latencia de la red del reloj
Si consideramos cualquier chip ASIC o SOC, la latencia de la red del reloj y la
distribución del reloj deciden el rendimiento de cualquier diseño síncrono. El PLL se
utiliza como fuente de reloj y, durante STA, es fundamental definir la fuente de reloj y
la latencia de la red de reloj. La figura 7.3 muestra ambas latencias.
7.9 Activación de reloj 123
7.7 Relojes generados
Los relojes generados en el ASIC o SOC se pueden utilizar como fuente de reloj para los
bloques secuenciales. Los relojes se generan utilizando las redes divisoras de relojes.
La Figura 7.4 muestra el reloj generado utilizando el divisor de reloj. Los útiles comandos de
Synopsys PT se describen en la Tabla 7.11.
7.8 Muxing de reloj y rutas falsas
La mayoría de las veces, necesitamos multiplexación de reloj. Los relojes de frecuencia
mínima y máxima se pueden utilizar en el diseño dependiendo de los requisitos de diseño.
Durante la prueba ASIC, se puede utilizar el reloj de frecuencia mínima. Las rutas falsas
entre estos relojes deben informarse al analizador de tiempos. Para establecer la ruta falsa,
use el comando que se muestra en la Tabla 7.12 (Fig. 7.5).
7.9 Activación de reloj
El analizador de tiempo debe realizar las comprobaciones de sincronización del reloj y el
comando se describe en la Tabla 7.13 (Fig. 7.6).
Fig. 7.4 Reloj generado
Tabla 7.11 Reloj y comandos de reloj generados
create_clock –período 10 forma de onda {0 5} Se utiliza para definir un reloj que tiene un período de 10 nseg.
[get_ports clk_PLL] El flanco ascendente a 0 nseg y el flanco descendente
a 5 nseg
crear_reloj_generado –nombre CLK_DIV_2 –fuente Reloj generado CLK_DIV_2 en q
UPLL0/clkout –divide_by 2 [get_pins
DEPT0/Q]
Tabla 7.12 Comandos para especificar ruta falsa
set_false_path –desde [get_clock Tclk_max] –hasta Se utiliza para establecer la ruta falsa entre el
[get_clocks Tclk_min] Tclk_max y Tclk_min
set_false_path –a través de [get_pins Para establecer la ruta falsa con respecto a clk_select
UMUX/clk_select]
Fig. 7.5 Muxing de reloj y ruta falsa
7.10 Rutas multiciclo
Las trayectorias multiciclo en el diseño necesitan ser reportadas. Las rutas se pueden configurar para que
el analizador de tiempo pueda realizar la verificación de configuración y espera (Fig. 7.7).
Tabla 7.13 Comandos de verificación de sincronización de reloj
create_clock –periodo 10 [get_ports Para crear el reloj del sistema de período 10 nsec
Sistema_CLK]
crear_reloj_generado nombre divide_by 1 Para obtener el mismo reloj CLK_gate
System_CLK [obtener pines UAND1/Z]
Fig. 7.6 Activación del reloj
Fig. 7.7 Trayectoria multiciclo
Tabla 7.14 Comandos de ruta multiciclo
create_clock –nombre clk_master periodo 5 Para crear el reloj maestro de período 5 nseg.
[get_ports clk_master]
set_multicycle_path 3 setup desde [get_pins Esto establece la ruta multiciclo de 3 ciclos.
DEPT/Q] –a [get_pins DEPT1/D]
set_multicycle_path 2 –mantener –desde [get_pins Esto se usa para mover la verificación de retención al segundo
DEPT/Q] –a [get_pins DEPT1/D] ciclo de reloj, ya que la configuración se verifica en el tercer
ciclo de reloj.
Los comandos utilizados para establecer la ruta de varios ciclos se enumeran en la Tabla 7.14.
1. La síntesis es el proceso de traducir el diseño de un nivel más alto de abstracciones a
bajo nivel de abstracciones.
2. Synopsys DC es una potente herramienta de síntesis y se utiliza para la síntesis lógica.
3. La herramienta de síntesis utiliza las bibliotecas, el diseño RTL y las restricciones durante el
síntesis.
4. El resultado de la síntesis es una lista de conexiones a nivel de puerta y se usa durante la STA previa al diseño.
5. Los miembros del equipo de síntesis deben trabajar en la síntesis a nivel de bloque y en la parte superior
síntesis de nivel.
6. DC da máxima prioridad a la optimización de la velocidad en comparación con el área.
7. DC realiza la optimización del diseño para cumplir con las restricciones durante la síntesis.
8. Si no se cumplen las restricciones de diseño, las técnicas de mejora del rendimiento
a nivel de síntesis, RTL y arquitectura se debe utilizar.
9. Durante la fase de síntesis, reportar los caminos falsos y los caminos multiciclo.
Este capítulo nos ha brindado una comprensión básica sobre los comandos DC que se usan con
frecuencia y cómo usarlos. El próximo capítulo trata sobre el diseño.
optimización utilizando Synopsys DC y los detalles sobre cómo lograr el
objetivo deseado durante la síntesis.
Referencia
1. www.synopsys.com.
Capítulo 8
Optimización del diseño
"Synopsys DC es la herramienta EDA eficiente y se puede utilizar
para la optimización y síntesis del diseño".
Resumen El capítulo analiza las restricciones de las reglas de diseño y la optimización con deformaciones
utilizadas durante la síntesis de ASIC. El objetivo de este capítulo es comprender los comandos importantes
de DC y cómo desempeñan un papel importante durante la síntesis. El capítulo también analiza los
escenarios de diseño importantes que pueden surgir durante la síntesis de ASIC.
Palabras clave ASIC DRC Optimización Fanout Capacitancia Transición _ _ _ _ _
Max Min STA Rutas de temporización Rutas multiciclo Restricciones — Restricciones a nivel de chip
Restricciones a nivel de bloque Ruta falsa FSM Área Velocidad Potencia
Potencia estática Potencia dinámica
8.1 Restricciones de diseño y síntesis de ASIC
Durante el ciclo de diseño que se inicia desde la encuesta de mercado hasta el diseño, enfrentamos muchos
desafíos en cada fase. Los diseños complejos de SOC para el nodo de proceso requerido deben cumplir
con las restricciones de diseño. Estas restricciones son principalmente "Restricciones de reglas de diseño
(DRC)" y "Restricciones de optimización". Por lo tanto, es muy necesario que el equipo de síntesis
comprenda las restricciones a nivel de bloque, superior y chip. Según los requisitos de velocidad, área y
potencia, se pueden extraer las restricciones de nivel de bloque y de nivel superior. Nuestro objetivo en
este capítulo es comprender las restricciones de optimización y DRC.
Para tener una mayor claridad sobre la síntesis, las restricciones y la optimización, consideremos el
diseño de nivel superior que tiene una complejidad de casi alrededor de 200 000 celdas lógicas.
Como se muestra en la Fig. 8.1 , los múltiples bloques funcionales están integrados en el nivel superior.
Estos bloques se pueden particionar como
https://doi.org/10.1007/9789811513145_8
128 8Optimización del diseño
interno
Procesador
E/S en paralelo
Memoria
Control &
lógica DSP E/S en serie
Sincronización
Memoria Alta velocidad
Controladores
Extensión BIST
interfaz
Fig. 8.1 Diseño de nivel superior de SOC
(1) Lógica de procesamiento: La partición 1 que es una agrupación de bloques funcionales principalmente
procesador, lógica DSP y memoria interna.
(2) Controlador y lógica de memoria: la partición II puede ser el controlador de memoria
e interfaces de alta velocidad
(3) IO y otras interfaces: la tercera partición puede ser IO paralela y serial
(4) Lógica de prueba y control: la cuarta partición puede ser la lógica de prueba y control
para el SOC.
Al considerar esto, las restricciones de nivel de bloque y de nivel superior se pueden extraer
dependiendo de la velocidad, potencia y requisitos de área para el nodo de proceso de destino.
Los pasos importantes para compilar el diseño se muestran en el Script 1
Script 1: Script para compilar el diseño
/* */
diseño
leer el
especificar
leer
formato
vtecnológicos
hdl dsel
oc_top.vhd /*
*/
olos
bjeto
requisitos
de

biblioteca_objetivo =
= my_library.sdb
my_library.db biblioteca_de_símbolos
”*”
link_library /* = + target_library
define
entorno
el ddiseño
e */
8.1 Restricciones de diseño y síntesis de ASIC 129
set_load < valor >< puerto_entrada>

.
.
.
< input_port
set_load valor >< >
FD1
set_driving_cell celda all_inputs()
set_drive 0 cdiseño
lk_name /*
set_input_delay
*/ establecer
las restricciones
value clock
de
clk {
< > < lista de entradas > }
.
.
.
set_input_delay < valor > reloj reloj { < lista de entradas > }
set_max_area 0 /*
Realiza la síntesis del diseño*/
compila /* genera informes */
informe_restricción informe_área
/* */ guardar la base de datos de diseño
escribir formato db jerarquía salida soc_top.db
Los comandos importantes para la optimización y DRC se describen en la Tabla 8.1 y
estos comandos se utilizan en las próximas secciones.
8.1.1 Síntesis y restricciones a nivel de bloque
Las restricciones a nivel de bloque para cumplir con el área, la velocidad y la potencia deseadas
se especifican mediante los comandos tcl'tk.
Por qué es esencial especificar las restricciones a nivel de bloque es una de las razones comunes
¿preguntas? Los pocos puntos importantes se enumeran a continuación:
1. Los diseños complejos de SOC o ASIC pueden tener múltiples bloques funcionales y
pueden tener múltiples dominios de reloj, dominios de potencia y funcionalidad.
2. Para una mejor optimización; la funcionalidad del diseño se divide en varios dominios
para lograr los requisitos de velocidad, área y potencia; es necesario especificar las
restricciones de diseño y optimización.
3. Considere el diseño que tiene cuatro particiones como se discutió anteriormente. La
frecuencia de operación de la partición I es de 500 MHz, la partición II opera a 333.33
MHz, la partición III a 200 MHz y la partición IV opera a la frecuencia de 250 MHz.
Otros buses y lógica de unión funcionan a la frecuencia de 150 MHz, y el diseño se
divide en cinco dominios de reloj. En tales circunstancias, las restricciones de diseño
Tabla 8.1 Comando Synopsys para la optimización y tipo de DRC
set_max_transition extensión de la República Democrática del Congo
Se utiliza para definir el mayor tiempo de transición
set_max_fanout extensión de la República Democrática del Congo
Se utiliza para establecer el fanout más grande para
el diseño.
set_max_capacitance extensión de la República Democrática del Congo
Se utiliza para establecer la capacitancia máxima
permitida para el diseño
set_min_capacitancia extensión de la República Democrática del Congo
Se utiliza para establecer la capacitancia mínima
permitida para el diseño.
set_operating_conditions Restricciones de optimización Se utiliza para establecer las condiciones de PVT, ya que afecta el tiempo
set_load Restricciones de optimización Utilizadas para modelar la carga en el puerto de salida
establecer_reloj_incertidumbre Restricciones de optimización Se utiliza para definir el sesgo de red estimado
set_clock_latency Restricciones de optimización Se utilizan para definir los retrasos estimados de la fuente y
la red
establecer_reloj_transición Restricciones de optimización Se utiliza para definir el sesgo de entrada estimado
set_max_dynamic_ power Restricciones de potencia Se utiliza para establecer la potencia dinámica
máxima
set_max_leakage_ power Restricciones de potencia Se utiliza para establecer la potencia de fuga
máxima
set_max_total_ power Restricciones de energía Se utiliza para establecer la potencia total máxima
set_dont_touch Restricciones de optimización Se utiliza para evitar la optimización de puertas mapeadas.
para lograr la velocidad, la potencia y el área requeridas se especifican en el archivo connections.sdc
a nivel de bloque.
4. Lo que hace exactamente la herramienta de síntesis es usar el diseño RTL, las restricciones y tratar de
generar la lista de conexiones a nivel de puerta para estos bloques funcionales. Las herramientas de
síntesis son lo suficientemente inteligentes a medida que pasan por las diversas fases de optimización
para cumplir con las restricciones.
5. A nivel de bloque, si no se cumplen las restricciones, entonces es esencial modificar el RTL o ajustar la
arquitectura y puede tener un impacto muy bueno en las etapas posteriores del diseño.
6. Esta fase incluso puede ser útil para comprender y congelar los riesgos en el diseño.
Guión 2: La síntesis a nivel de bloque usando Synopsys DC [1]
establecer active_design procesador_funcionalidad
–
formato vhdl elaborar $active_design
$active_design.vhd analizar
8.1 Restricciones de diseño y síntesis de ASIC 131
enlace de diseño_actual $diseño_activo
uniquify set_wire_load_model – name SMALL
set_wire_load_mode top set_operating_conditions
WORST create_clock
period 10 waveform [list 0 5] matser_clk
set_clock_latency –1.0 –master_clk]
[get_clocks
set_clock_uncertainty
[get_clocks
master_clk]
2.0 setup set_clock_transition
0.1 [get_clocks tck] set_dont_touch_network
cell] smaster_clk
et_driving cmell_BUFF1
[list tck msaster_Xreset
aster_reset] et_BUFF1 0 p[list
utin
set_input_delay 2.0
–
reloj master_clk max [todas las eset_fix_multiple_port_nets
ntradas]
master_clk
set_output_delay
max [todas
set_max_area c2ompilar
.0
0 reloj
las salidas]
– –
– –
– –
– constantes_búfer – todas
–
–
escanear check_test remove_unconnected_ports [encontrar jerarquía celular {“*”}]
– h – normas
change_names
set_dont_touch current_design salida de
– de escritura $
jerarquía –active_design.db
formato de escritura
salida
jerarquía de
vhdl
$active_design.vhd
– – –
8.1.2 Síntesis y restricciones a nivel de chip
En el nivel superior, el diseño es la integración de los diferentes bloques funcionales, IP y procesadores.
Las restricciones de nivel superior deben derivarse según los requisitos de velocidad, potencia y área.
En las etapas iniciales del ciclo de diseño, durante el nivel de arquitectura, se recopila y documenta la
información al respecto.
Por ejemplo, mi diseño SOC debería funcionar a una frecuencia operativa de 1 GHz y tiene
múltiples dominios de reloj. Entonces, ¿es esencial que cada bloque funcional deba operarse a 1 GHz?
¡La respuesta es no! La razón es que la frecuencia de reloj general para realizar una sola operación en
un ciclo es de 1 GHz y como el diseño tiene múltiples bloques funcionales según la partición, se pueden
operar individualmente a alta o baja velocidad también.
El arquitecto y el equipo de diseño deben encargarse de la sincronización de dichos diseños. Para
las IP funcionales y de sincronización comprobada, es posible establecer los atributos de no tocar
durante la fase iterativa de síntesis y optimización.
Script 3: Script de restricciones de nivel superior usando Synopsys [1]
activo
conjunto
sub_módulos
de procesador
{conjunto
dde
e
diseño
memoria de interfaz de bus de decodificación de procesador_lógico
interrupt_control} módulo foreach $sub_módulos {
colocar
syn_db $module.db read_db syn_db
}
– formato vhdl
analizar $active_design.vhd
–
proceso $active_design actual
diseño $active_design
Enlaces
uniquify set_wire_load_model
– nombre GRANDE
set_wire_load_mode adjunto set_operating_conditions PEOR
crear_reloj – –
período 10 forma de onda [lista 0 5] master_clk
set_clock_latency 1.0 [get_clocks
[get_clocks
master_clk]
master_clk]
[get_clocks set_clock_uncertainty
set_clock_transition
master_clk] setup
0.1 2.0
set_dont_touch_network
–
[lista master_clk master_reset] [all_inputs]
masterlist
smax
et_driving_cell
set_lk_drivelkin
[clock
all_inputs]
c2ell
r.0
eset_master
master_clk B
set_output_delay
UFF1X pinZ
clock
max [all_outputs]
2.0 0 set_max_area set_fix_multiple_port_nets compilar
– –

– –
– –
– todas – constantes_búfer
–
escanear remove_attribute [encontrar
–
diseño de jerarquía {“*”}] dont_touch
current_design $active_design
–
uniquify check_test create_test_patterns preview_scan muestras 5
only_design_rule
insert_scan check_test compilar
–
remove_unconnected_ports [buscar jerarquía celular {“*”}]
set_dont_touch current_design salida
– –
de escritura
vhdl
$active_design.vhd
$active_design.db
formato de esscritura
alida de
jerarquía
jerarquía
– – –
8.2 Restricciones de reglas de diseño (DRC) 133
Fig. 8.2 fanout de la celda
8.2 Restricciones de reglas de diseño (DRC)
Las principales restricciones importantes de las reglas de diseño son el fanout, la capacitancia y la transición.
Estas restricciones tienen alta prioridad durante la síntesis en comparación con las restricciones de optimización.
8.2.1 max_fanout
Se utiliza para medir la cantidad de cargas que puede manejar un puerto o una carga.
Considere la puerta lógica que maneja las puertas múltiples como se muestra en la figura 8.2.
La biblioteca de tecnología tiene información sobre el fanout predeterminado. El diseñador puede usar el
siguiente comando para obtener el fanout
get_attribute nombre_biblioteca default_fanout_load
8.2.2 max_transición
La transición máxima de '0' a '1' o de '1' a '0' para una red específica o un diseño completo se puede especificar
mediante Synopsys DC, ya que sabemos que el tiempo de transición se debe a la constante de tiempo RC.
Fig.8.3 Transición desde '0'
a '1' y '1' a '0'
Fig. 8.4 Capacitancia en la celda impulsora
¿Cómo cumple DC la transición máxima especificada?
Considere la biblioteca que especifica la transición máxima de '4' y el diseñador especifica
max_transition de '2'. Lo que hace DC es eso, intentará cumplir con el max_transition de 2
(Fig. 8.3).
El siguiente comando Synopsys DC se usa para especificar max_transition (Fig. 8.4).
set_max_transition < valor >< nombre_diseño/nombre_puerto >
8.2.3 max_capacitancia
Se utiliza para proporcionar información sobre la capacitancia neta máxima.
Durante la compilación, el controlador de dominio se encarga de las violaciones debidas
a max_capacitance.
8.2 Restricciones de reglas de diseño (DRC) 135
Entonces, como sabemos que la restricción max_capacitance en la salida de la celda de control
se debe a la capacitancia neta y la capacitancia de los pines controlados por la celda, el diseñador
puede usar el siguiente comando para definir max_capacitance.
set_max_capacitance < valor >< nombre_puerto/nombre_diseño>

Como se discutió, use los siguientes comandos para definir las restricciones de la regla de diseño
set_max_transition v<alue >< nombre_diseño/nombre_puerto >

set_max_fanout v<alue ><
port_name/design_name >
<
set_max_capacitance value >< design_name/port_name >
8.3 Restricciones de optimización
Para la optimización del diseño, durante la síntesis lógica, el DC utiliza las restricciones de
área y velocidad. Ambas restricciones deben cumplirse. La administración de energía y las
restricciones de energía para el diseño de ASIC se considerarán durante la síntesis física.
Entonces, intentemos entender cómo el DC realiza la optimización. ¿Es que el
DC intentará realizar la optimización para el área y la velocidad al mismo tiempo?
La respuesta es 'no', ya que si soy el diseñador y deseo tener la optimización,
intentaré llevar a cabo la optimización del diseño para lograr la velocidad deseada.
Entonces, la optimización de velocidad se lleva a cabo primero y luego DC
optimizará para el área.
Como se discutió en el Cap. 7, DC usa algunos de los comandos mientras restringe
el diseño y estos comandos son
create_clock set_input_delay set_output_delay set_max_delay set_min_delay set_fix_hold set_max_area set_driving_cell set_load
Para la ruta asíncrona, los retrasos punto a punto se especifican mediante los siguientes
comandos.
set_max_delay set_min_delay
La siguiente sección analiza los comandos DC utilizados durante la optimización y durante la
mejora del rendimiento del diseño.
8.3.1 establecer_no_usar
Se puede usar el comando 'set_dont_use', si el ingeniero de síntesis no desea consultar las celdas
de la biblioteca de tecnología.
Si se usa el atributo 'no_tocar', este comando ignora las celdas de la biblioteca de tecnología.
El comando se describe a continuación.
set_dont_use nombre_biblioteca/nombre_célula
Considere el nombre de la celda como XOR2, luego, durante la optimización, la celda XOR2 no
se usa.
8.3.2 establecer_no_tocar
La mayoría de las veces, durante la fase de optimización, no necesitamos optimizar el diseño que
ya cumplió con las restricciones de tiempo y área. Por ejemplo, considere el diseño que se muestra
en la Fig. 8.5.
Si los bloques de diseño funcional, como el procesador, la lógica DSP y el controlador de
memoria, han cumplido las restricciones de tiempo y área y no se requiere una mayor optimización,
se puede usar el comando dont_touch.
set_dont_touch design_name
Esto nos puede prevenir la reoptimización de la síntesis de la funcionalidad de diseño.
Durante la síntesis lógica, necesitamos usar los árboles de reloj instanciados a mano y como DC
no realiza la síntesis para el árbol de reloj, use el atributo don't_touch para el mismo.
Entonces, si el diseño actual es soc_top, entonces podemos hacer lo siguiente para permitir que no se toque
el bloque funcional
diseño actual =
soc_top set_dont_touchu1
set_dont_touch u2
set_dont_touch u3
8.3 Restricciones de optimización 137
interno
Procesador E/S en paralelo
Memoria
Control &
Sincronización
Extensión BIST
Controladores interfaz
Fig. 8.5 Diagrama de diseño de nivel superior del SOC
Donde u1, u2 y u3 son las instancias del procesador, la lógica DSP y el controlador de
memoria, respectivamente.
8.3.3 establecer_preferencia
Este comando se usa cuando el ingeniero de síntesis desea cambiar la prioridad de las
celdas elegidas por el DC durante la traducción de la tecnología.
Ahora, considere que la lista de redes de diseño debe asignarse a otra biblioteca de
tecnología, luego se puede usar el comando y se describe a continuación
set_prefer nombre_biblioteca/libaray_nombre
8.3.4 Comando para el Aplanamiento del Diseño
Podemos tener el diseño jerárquico o aplanado. Ahora, considere las siguientes expresiones
utilizadas dentro de la arquitectura del diseño VHDL
Y1 <= a_in y b_in;
Y2 <= c_in y Y1;
Fig. 8.6 Estructura a nivel de
puerta sin aplanamiento
La herramienta de síntesis inferirá la lógica en cascada y se muestra en la Fig. 8.6.
Después de aplanar, podemos obtener la expresión como
Y2 <= (c_in y a_in) y (c_in y b_in);
El comando set_flatten se usa para aplanar el diseño.
El comando se describe como o se puede denominar como el interruptor
set_flatten verdadero
Si nos referimos a los circuitos digitales básicos, entonces la lógica combinacional se expresa utilizando la
suma del producto (sop). La expresión SOP mejorará el paralelismo y la velocidad del diseño.
Ahora pensemos, ¿puedo usar el aplanamiento para los multiplexores, las puertas XOR y los sumadores?
La respuesta es que no se recomienda usar aplanamiento para este tipo de lógica debido al uso de los
elementos de control. Durante la optimización, el controlador de dominio nunca realizará el aplanamiento a
menos que se especifique.
Aún así, siempre hay una limitación para obtener la netlist aplanada. Se recomienda que
si el diseño tiene 10 o menos entradas, entonces se puede usar el interruptor plano.
8.3.5 Comandos utilizados para la estructuración
Si el objetivo es mejorar el conteo de áreas o puertas, entonces se recomienda la estructuración.
conjunto_estructura – tiempo cierto
Podemos tener la estructuración booleana o la estructuración impulsada por el tiempo. De forma predeterminada, el
controlador de dominio utiliza la estructuración impulsada por el tiempo. Para ejecutar la estructuración booleana,
necesitamos dirigir la herramienta de síntesis.
8.3.6 Comandos Agrupar y Desagrupar
Para eliminar la jerarquía se usa el comando 'desagrupar' y para crear la jerarquía se usa el comando
'agrupar'.
8.3 Restricciones de optimización 139
– aplanar – todas
desagrupar
Esto permitirá desagrupar todos los niveles por debajo del diseño soc_top. Pero DC se
encargará de que la funcionalidad de diseño para la que se aplicó el atributo set_dont_touch
no se vea afectada.
Para desagrupar todos los diseños sintéticos antes de compilarlos, se puede usar el
siguiente comando
reemplazar_sintético –
desagrupar
Para agrupar el comando se puede utilizar para tener la nueva jerarquía. El comando se da a
continuación
– –
Grupo (u1, u2) diseño_nombre nombre_bloque nombre_celda soc_top_inst
Entonces, como se discutió, la agrupación forma la nueva instancia soc_top_inst usando las instancias
u1, u2.
8.4 Optimización de FSM
Para la optimización de las máquinas de estados finitos se utiliza el compilador FSM. El uso
del compilador FSM es lograr la optimización del área con un rendimiento de diseño mejorado.
En los diseños prácticos de ASIC, el controlador de la máquina de estado está diseñado como
un bloque de diseño separado.
Más detalles se dan en el Cap. 6 sobre la máquina de estados de Moore y Mealy.
El Script 4 se puede utilizar para la extracción y optimización de FSM
Guión 4: Guión de extracción de FSM
/* lee el objeto de diseño */
>el
dc_shell lee vhdl
state_machines_controller.vhd /*
formato Mapea el diseño */ dc_shell
compile /* s i
e l
d
fsm design_name
estado iseño nextract /*
o ees
de netlist
dc_shell ,…} dec_shell
fsm_design_name
dn
c_shell set_fsm_state_vector
l formato dge
formato Froup /*
tabla
*/ dee
set_fsm_encoding
SM xtrae md{áquina
,…}
la m{“state0
scribe láquina
a
el de
e
iseño c_shell
ed
stado
e
el */
dc_shell
n
> –
formato dc_shell write st output state_machine.st
map_effort medio
dividido luego */
la glógica
rupo
flip_flop_name
flip_flop_name
> < > ,<
>
> – – < >
> conjunto_fsm_estado_vector { < flip_flop_name > , < flip_flop_name

>
> = 0", "estado1 = 1”, …….}
>
> – –
/* si el diseño ya está en formato de máquina de estado, lea el diseño */ dc_shell read format
state_machine.st
defina la
st /*
codificación
defina el oerden
stilo *d/
el
dc_shell
*/ state sdet_fsm_encoding_style /*
c_shell set_fsm_order {state0,state1,….} /*
compila el diseño */
>
dc_shell compila –
map_effort
alto
>
> < estilo_codificación >
> –
Los siguientes son puntos importantes para concluir el capítulo.
1. Synopsys DC utiliza las restricciones de optimización y las restricciones de las reglas de diseño al
realizar la síntesis.
2. Para diseños complejos, extraiga las restricciones de nivel de chip, nivel superior y nivel de bloque.
3. Las restricciones de la regla de diseño se especifican para el fanout, la transición y la capacitancia.
tancia
4. Se especifican restricciones de optimización para el área y la velocidad.
5. Synopsys DC no se optimiza para la potencia. La planificación energética debe llevarse a cabo
durante el diseño físico.
6. Para informar el área, use report_area y use report_timing para obtener el informe de tiempo.
7. La agrupación se utiliza para crear una nueva jerarquía de diseño.
8. El aplanamiento del diseño elimina la jerarquía del diseño.
9. La optimización de FSM se puede llevar a cabo utilizando el compilador FSM.
Este capítulo nos ha proporcionado una buena comprensión de las restricciones de las reglas
de optimización y diseño. Incluso hemos discutido sobre los comandos DRC y los comandos
de optimización. El próximo capítulo discutirá acerca de las importantes estrategias de
optimización y mejora del rendimiento de la síntesis ASIC. ¡Incluso el capítulo discutirá sobre
el área, los informes de tiempo y los scripts utilizados para la configuración y los controles de
espera!
Referencia
Capítulo 9
Escenarios de optimización de diseño
“Synopsys DC otorga la máxima prioridad a la optimización de tiempo en
comparación con la optimización de área”.
Resumen El capítulo analiza las estrategias de optimización del diseño para lograr las restricciones de velocidad
y área durante la síntesis utilizando Synopsys DC. La mayoría de las veces, observamos las violaciones de
tiempo y las violaciones de DRC. Para optimizar el diseño para cumplir con las restricciones, en este capítulo se
analizan los esquemas que se utilizan durante la síntesis y la optimización. El capítulo incluso analiza el uso de
los comandos de Synopsys DC para informar la ruta de varios ciclos y la ruta falsa y para realizar el balanceo de
registros y la reprogramación de registros.
Palabras clave ASIC Síntesis Optimización Ruta falsa Configuración Retener Área máxima STA Rutas de
tiempo Rutas multiciclo Restricciones Restricciones a nivel de chip _
Restricciones a nivel de bloque Optimización FSM Área Velocidad Potencia Potencia estática
Potencia dinámica ∙ Grupo ∙ Rutas asincrónicas ∙ Configuración de holgura ∙ Retención de holgura
9.1 ¿Dónde está el problema en la optimización?
En el nivel superior, podemos imaginar que no se cumplen las restricciones de diseño para el diseño SOC. Hay
muchas razones detrás de esto. ¿Cuáles pueden ser?
1. La densidad de la lógica de diseño es tan alta que el diseño de nivel superior no puede cumplir
las restricciones del área.
2. El diseño tiene muchas rutas de tiempo que fallan en el nivel superior. Es decir, el diseño no puede cumplir
con las restricciones de tiempo.
3. El diseño a nivel de bloque no tiene ninguna violación de tiempo, pero cuando está integrado
en el nivel superior no se cumplen las restricciones de nivel superior.
4. El diseño en el nivel superior solo tiene infracciones de retención, pero no hay ningún problema con el tiempo
de configuración. Es mejor trabajar en las infracciones de configuración durante el STA previo al diseño y
durante el diseño físico corregir las infracciones de retención.
Taraate, síntesis lógica y creación de prototipos SOC, https://
doi.org/10.1007/9789811513145_9
142 9 escenarios de optimización del diseño
Fig. 9.1 Diseño de nivel superior del SOC. Nota La discusión sobre el diseño analógico está fuera del alcance de este libro.

El grupo analógico que tiene diferentes bloques se muestra en la Fig. 9.1
5. Mi diseño cumple con todas las restricciones, pero aún existe la posibilidad de mejorar el
rendimiento de mi diseño.
6. Si consideramos la Fig. 9.1, muchas veces podemos enfrentar problemas de tiempo y área para la
interfaz del procesador con el controlador de memoria y la interfaz del procesador de video con el
controlador de memoria. El problema puede deberse a los límites de partición o al tiempo de pin a
pin. O la partición no es adecuada ya que todos están en los diferentes grupos de relojes.
7. La cuestión de no cumplir con las restricciones de poder en la discusión de este libro sobre las
restricciones de poder está fuera del alcance.
8. Otro problema puede ser la generación de informes de ruta falsa y multiciclo. Si no se informan las
rutas de varios ciclos y las rutas falsas, entonces la optimización es realmente un gran problema.
9. Si mi diseño utiliza el controlador de máquina de estado, considere el controlador de máquina de
estado para la inicialización del controlador DDR3 o para realizar la canalización y el control en el
procesador de propósito general. Si la optimización y las restricciones no se extraen a nivel de
bloque, será difícil obtener la optimización y la mejora del rendimiento tanto en el bloque como en
el nivel superior.
10. Si mi diseño tiene los pestillos previstos, entonces se debe considerar el tiempo prestado y el trabajo
del diseño para la ventana de habilitación activa.
9.1 ¿Dónde está el problema en la optimización? 143
En todos estos escenarios, las estrategias deben ser decididas por el equipo de síntesis y
optimización para lograr el tiempo limpio y cumplir con las restricciones de diseño. Tengamos una
estrategia para cumplir con el tiempo primero y luego trabajemos en las restricciones del área.
El diseño y la optimización son temas amplios y puedo documentar cientos de escenarios. Pero
este capítulo analiza algunos de los escenarios con las estrategias de optimización y las técnicas de
mejora del rendimiento.
9.2 Estrategias de optimización de diseño para el SOC
Ahora imaginemos como equipo de síntesis cuáles deberían ser nuestras estrategias durante el diseño
y la optimización de los SOC de gran densidad. Los siguientes son algunos puntos importantes:
1. Haga que se ejecute la síntesis inicial para el diseño a nivel de bloque e informe a todos los
infractores. 2. Mire más de cerca el informe de tiempo y área y luego intente aplicar las restricciones a
nivel de bloque. Reporte todas las rutas violadas usando report_constraints –all_violators 3. Si la
mejora en el tiempo es un requisito, entonces use la agrupación de rutas asincrónicas y luego use
las estrategias de compilación.
4. Si los bloques de gran densidad ya cumplieron con el tiempo, para evitar la recompilación, use el ' 5.
un requisito, use aatributo.
no_tocar'
Si la minimización del área es grupación, uso compartido de recursos y
otras técnicas con el ' establecer_área_máxima' atributo.
6. Reporte las trayectorias multiciclo en el diseño. Considere el SOC que se muestra en la Fig. 9.1 que
tiene un motor de procesador y necesita el multiplicador de coma flotante. Si el registro de destino
recibe los datos después de varios ciclos de reloj, entonces es esencial informar la ruta de varios
ciclos. Esta será información útil para el analizador de tiempo para comprender dónde verificar la
configuración y dónde verificar la retención.
7. Informe la ruta falsa para el diseño a nivel de bloque.
8. Si se cumplen los requisitos de tiempo y área a nivel de bloque para el diseño, utilice las restricciones
de diseño de nivel superior para optimizar el diseño de nivel superior.
9. Para la optimización de nivel superior, imaginemos que se cumplen los tiempos individuales del
procesador, el procesador de video y el controlador de memoria, pero en el nivel superior hay un
problema para cumplir con las restricciones. Entonces, ¿qué debemos hacer?
a. Verifique la violación de tiempo del informe de tiempo, la violación de configuración se debe a
la llegada tardía de los datos. Así que intente modificar el RTL para limpiar el límite de la
partición. b. Si el límite de la partición está limpio, entonces podemos usar las técnicas de
balanceo de registros para eliminar la violación del tiempo de configuración. C. Si el informe de
tiempo indica las violaciones de retención, entonces indica que en la interfaz del bloque la
llegada de datos es muy rápida, por lo que podemos usar las estrategias para agregar los búferes
en la ruta de datos teniendo cuidado de que no tenga el problema de violación de tiempo de
configuración. .
d. Después de todas las posibilidades, si no se cumple el tiempo, intente modificar la
arquitectura RTL o la última opción es usar las restricciones relajadas.
9.3 Estrategias de compilación
Podemos elegir un enfoque de compilación de arriba hacia abajo o de abajo hacia arriba durante
la síntesis del diseño. Cada método de compilación tiene sus propias ventajas y desventajas.
9.3.1 Compilaciones de arriba hacia abajo
La compilación de arriba hacia abajo utiliza las restricciones de diseño de nivel superior. Las
siguientes son las ventajas y desventajas de la compilación de arriba hacia abajo
Ventajas
1. Los motores de optimización funcionan en diseño completo, rutas completas
2. Por lo general, obtienen el mejor resultado de optimización 3. No se requiere
iteración 4. Restricciones simples 5. Administración de datos simple.
Desventajas
1. Mayor tiempo de
ejecución 2. Más requisitos de memoria
3. Más tiempo de ejecución.
Los comandos utilizados para la compilación de arriba hacia abajo son
dc_shell > diseño actual TOP

–
dc_shell > compilar timing_high_effort_script
9.3.2 Compilaciones ascendentes
La compilación ascendente realiza primero la compilación a nivel de submódulo y luego avanza
hacia el nivel superior. El diseñador debe tener cuidado de establecer el atributo ' en los
'
establecer_no_tocar submódulos para evitar la recompilación de los submódulos. El diseñador
necesita conocer la información de tiempo para las entradas y
9.3 Estrategias de compilación 145
salidas para cada uno de los submódulos. Las ventajas y desventajas se discuten a continuación.
Ventajas
1. Más rápido en comparación con la compilación descendente
2. Se requiere menos procesamiento por ejecución 3. Se
requiere menos memoria.
Desventajas
1. La optimización funciona en el submódulo o subdiseño 2.
Se requiere más iteración 3. Más jerarquías para mantener.
Considere que el diseño tiene dos submódulos. Los comandos utilizados para la compilación
ascendente son
dc_shell > diseño_actual submódulo1 compilar

–
dc_shell > timing_high_effort_script
set_dont_touch submódulo1
dc_shell > diseño_actual submódulo2 compilar
dc_shell > timing_high_effort_script set_dont_touch
–
dc_shell > submódulo2
diseño_actual
dc_shell >
dc_shell > TOP
dc_shell –
> compilar timing_high_effort_script
9.4 Estrategias para la optimización del área
Hay varias técnicas utilizadas para minimizar el área general del diseño. La máxima prioridad
del diseñador es optimizar para el tiempo y luego para el área.
Hay varias técnicas eficientes de minimización de área a nivel de RTL. En los capítulos
anteriores, hemos discutido el uso compartido de recursos mediante ajustes RTL. Esta sección
brindará más información sobre la optimización del área y las técnicas que utilizan Synopsys
DC. Las siguientes son las pautas importantes que se utilizan para optimizar para el
área.
1. Evitar el uso de la lógica combinacional como bloque o diseño individual.
2. No utilice la lógica de pegamento entre dos diseños.
3. Utilice atributos mientras sintetiza el diseño.
establecer_área_máxima
9.4.1 No use lógica combinacional como bloque individual
Se recomienda evitar el uso de la lógica combinacional como bloque individual.
Si se utiliza el bloque de diseño combinacional individual, Design Compiler no podrá
optimizar el bloque individual. Esta no es una buena partición de diseño. La jerarquía
del módulo es fija y Design Compiler no podrá modificar la jerarquía del diseño.
Considere el escenario que se muestra en la figura 9.2. Tiene módulo I y módulo II.
Como se muestra, el módulo II es un bloque combinacional separado, por lo que Design
Compiler no podrá optimizar el módulo II, ya que Design Compiler no optimiza las
interfaces de puerto.
Si el diseño se divide teniendo en cuenta los límites, la optimización general
impulsará el rendimiento del diseño. Un mejor diseño de ASIC particionado debería
tener la funcionalidad combinada del módulo I y el módulo II. La funcionalidad de A + B
en el módulo único I se muestra en la Fig. 9.3 y da como resultado una optimización
más rápida para el diseño.
Módulo I Módulo II
estruendo
combinados combinados
Lógica1: A Lógica2 : B
chanclas D
clk
Fig. 9.2 Lógica combinacional como módulo individual [2]
Módulo I
estruendo
combinados
lógica: una
+B
chanclas D
clk
Fig. 9.3 Eliminación del módulo combinacional individual
9.4 Estrategias para la optimización del área 147
Fig. 9.4 Lógica de pegado entre dos bloques
9.4.2 No use Glue Logic entre dos módulos
Si el módulo II en la Fig. 9.3 se reemplaza por la lógica de pegado que es una instancia de la
puerta lógica, entonces se pega entre los diferentes módulos y se muestra en la Fig. 9.4. Este
tipo de particionamiento del diseño no es bueno, ya que el Design Compiler no puede
optimizar la puerta lógica, ya que el diseño no se particiona correctamente. Para evitar este
tipo de escenarios, se recomienda utilizar emódulo
grupo l comando.
I o eAn
grupe la lógica
el módulo II. de pegamento en el
El siguiente comando se utiliza para agrupar la lógica de pegado en el módulo II (Fig. 9.4).
>
dc_shell grupo –
{m2, m2} módulo design_name tercero nombre_celular
nand_gate
9.4.3 Uso del atributo set_max_area
Para obtener la mínima área posible, se recomienda utilizar el atributo Este atributo es efectivo
establecer_área_máxima . durante la optimización del diseño.
Design Compiler otorga la máxima prioridad a la optimización del tiempo. Si se cumple el tiempo, solo puede
comenzar la fase de optimización del área. Las prioridades para la optimización del diseño son DRC, tiempo,
potencia y luego área.
9.4.4 Área de informe
El informe de área es generado por Design Compiler usando El informe de informe_area dominio.
área de muestra se muestra en el Informe 1. El informe de área para cualquier diseño consiste en el número
de puertos, redes, referencias. También proporciona información sobre el área de celda combinacional,
secuencial y total. Los campos del informe de área se enumeran a continuación
Informe 1:Campos de informe de área [2]
Número de puertos:
Número de redes:
Número de celdas:
Número de referencias:
Área combinacional:
Zona no combinatoria:
Área de interconexión neta: indefinida (la carga del cable tiene un área neta cero)
Área total de la celda:
Área total:
9.5 Estrategias para la optimización del tiempo y la mejora del
rendimiento
Durante la optimización, el tiempo tiene la máxima prioridad en comparación con la potencia y el área. No
estamos utilizando Synopsys DC para la optimización de energía. La planificación de energía se realizará
durante una etapa posterior utilizando un compilador físico. Durante la primera fase de optimización, Design
Compiler verifica las violaciones de las restricciones de las reglas de diseño (DRC), luego las violaciones de
tiempo y las restricciones de energía y finalmente las restricciones de área. En esta sección se analizan los
pocos comandos de optimización de tiempo admitidos por Design Compiler.
9.5 Estrategias para la optimización del tiempo y la mejora del rendimiento 149
9.5.1 Compilación de diseño con 'map_effort_high'
La mayoría de las veces, el ingeniero de diseño usa la opción como medio map_effort mientras
forma la síntesis. Es recomendable que durante la síntesis de la primera fase, el diseñador pueda
utilizar la opción como medio map_effort ya que reduce el tiempo de compilación. Si no se cumplen
las restricciones de diseño, el diseñador puede optar por la compilación incremental con la opción
map_effort alta. Esto puede mejorar el rendimiento del diseño en al menos un 510%.
El comando sdc se muestra a continuación.
dc_shell –
> compilar map_effort_high –
incremental_mapping
9.5.2 Uso del comando group_path
El rendimiento del diseño puede aumentar hasta un 10 % mediante el uso de la opción map_effort
high. Pero si el tiempo no se cumple con la compilación incremental mediante el uso de restricciones
de diseño, entonces es esencial agrupar las rutas de tiempo críticas y usar el factor de ponderación
para aumentar el rendimiento del diseño. Este comando es útil para mejorar el rendimiento del tiempo.
El comando se muestra a continuación.
>
dc_shell group_path – – de < nombre de entrada>– a < afuera
nombre Critical1 put_name
>–
peso factor de peso < >
Considere el escenario de diseño que tiene una violación de configuración de 0,38 ns. La infracción de
configuración es la diferencia entre la hora requerida de los datos y la hora de llegada de los datos. Entonces,
la holgura es negativa y se viola el tiempo de configuración.
– de lectura vhdl
dc_shell > formato diseño_combinacional.vhd
– nombre
dc_shell > create_clock período el reloj – set_input_delay
15 sdet_input_delay 3 cclk
lock
clk
3 cin_a
in_b lock
dc_shell > set_input_delay 3 clock –
c_out
clk
diseño_combinatorio
cc_in
urrent_design
smap_effort
et_output_delay
report_timing
medio
compilar
3 creloj
amino
dc_shell > retraso completo –
dc_shell > –
dc_shell > –
dc_shell > =
dc_shell > –
dc_shell > – – máximo – – peor 1

ruta_máxima 1
Después de la síntesis de diseño exitosa, use el comando report_timing mientras realiza el
análisis de tiempo. El informe de tiempo para el diseño se puede obtener con las múltiples
opciones que se muestran en el script anterior y en el Informe 2.

Punto de inicio: c_in (puerto de entrada)
Punto final: c_out (puerto de salida)
Grupo de ruta: clk
Tipo de ruta: máx.
punto incluido Camino

retardo externo de entrada 0.00 0,00 f

c_in (in) 0.00 0,00 f
U19/Z (AN2) 0.87 0,87 f
U18/Z (EO) 1.13 2,00 f
add_8/U1_1/CO (FA1A) add_8/ 2.27 4,27 f
U1_2/CO (FA1A) add_8/U1_3/ 1.17 5,45 f
CO (FA1A) add_8/U1_4/CO 1.17 6,62 f
(FA1A) add_8/U1_5/CO (FA1A) 1.17 7,80 f
add_8/U1_6/ CO (FA1A) add_8/ 1.17 8,97 f
U1_7/CO (FA1A) 1.17 10,14 f
1.17 11,32 f
U2/Z (EO) 1.06 12,38 f
C_out (salida) 0.00 12,38 f
fecha hora de llegada 12,38 f
clock clk (flanco ascendente) 15.00 15.00

clock network delay (ideal) salida 0.00 15.00
external delay datos tiempo 3.00 12.00
requerido 12.00

Fecha hora requerida 12.00
Fecha hora de llegada 12.38
Slack (violado) 0.38

Informe 2 Informe de tiempo con holgura negativa
Para corregir la infracción de configuración y aumentar el rendimiento del diseño, el diseñador
puede usar group_path con el factor de peso. Más el factor de peso más es el tiempo de
compilación.
dc_shell > group_path nombre – – – –

Critical1 de c_in a c_out compilar map_effort
mapeo peso 5
dc_shell – –
> incremental alto report_timing path full delay max_path 1
dc_shell > – – máximo – – peor 1
Como se muestra en el informe de tiempo, el diseño tiene una holgura positiva ya que elimina la configuración
violación y se muestra en el Informe 3.

Punto de inicio: c_in (puerto de entrada)
Punto final: c_out (puerto de salida)
Grupos de rutas: máx.
Tipo de ruta: máx.
punto incluido Camino

retardo externo de entrada 0.00 0.00f
c_in (in) 0.00 0.00f
U19/Z (AN2) 0.87 0.87f
U18/Z (EO) 1.13 2,00 rublos
add_8/U1_1/CO (FA1A) add_8/ 2.27 4.27f
U1_2/CO (FA1A) add_8/U1_3/ 1.17 5.45f
CO (FA1A) add_8/U1_4/CO 1.17 6.62r
(FA1A) add_8/U1_5/CO (FA1A) 1.17 7,80 euros
add_8/U1_6/ CO (FA1A) add_8/ 1.19 8,99 rublos
U1_7/CO (FA1A) 1.15 10.14 f

0.79 10.93f
U2/Z (EO) 1.06 11.99f
C_out (salida) 0.00 11.99f

fecha hora de llegada 11.99f
clock clk (flanco ascendente) 15.00 15.00
clock network delay (ideal) salida 0.00 15.00
external delay datos tiempo requerido 3.00 12.00

12.00

Fecha hora requerida 12.00
Fecha hora de llegada 11.99
Slack (cumplido) 0.01

Informe 3 Informe de tiempo con la holgura positiva
Como se muestra en el informe de tiempo 3 para el análisis máximo con la opción alta de compile_map,
debido al factor de peso de 5, se cumple la holgura.
9.5.3 Análisis y comprobación del tiempo de configuración
La demora de configuración es la diferencia entre el tiempo requerido de datos (RT) y el tiempo de llegada
de datos (AT). Si se cumple la holgura de configuración, significa que la diferencia entre RT y AT es positiva.
La secuencia de comandos que usa los comandos de Synopsys PT para la verificación del tiempo de configuración se describe en la secuencia
de comandos 1.
Guión 1: Comprobación de configuración [1]
active_design soc_top
colocar
–
current_design
netlist_only
$active_design
$active_design.db
set_wire_load_model
read_db
grande set_wire_load_mode top set_operating_conditions
PEOR set_load 40.0 – nombre
– célula BUFF1X –
[todas_las_salidas] set_driving_cell pinZ [all_inputs] period
crear_reloj – –
10 waveform
1.0 [[0
get_clocks
5set_clock_transition
] master_clk
master_clk]
s[get_clocks
et_clock_latency
master_clk]
0.1
set_clock_uncertainty 2.0 s[all_inputs]
etup clock
[get_clocks
mset_input_delay
master_clk]
aster_clk 2.0
clock
set_output_delay
2m.0
[all_outputs] aster_clk
report_constraint all_violators
report_timing
report_timing
[all_outputs]
[all_registers
a dwata_pins]
salida $active_design.sdf rite_sdf
vahdl
contexto
–
–
–
–
– –
–
– –
El informe de tiempo de muestra se muestra en el Informe 4. Como se muestra, la diferencia entre el
tiempo requerido de los datos y el tiempo de llegada de los datos es positiva. Esto indica que no hay
violación de tiempo debido a la holgura positiva.
Informe 4 Informe de tiempo para el análisis de configuración [1].
Si no se cumple con la holgura, ¿qué debe hacer?
1. Considere las señales de llegada tardía en la ruta de datos.
2. Modifique el RTL.
3. Modificar la microarquitectura de la arquitectura.
9.5.4 Análisis y comprobación del tiempo de espera
La holgura de retención se define como la diferencia entre la hora de llegada de los datos y la hora requerida de los
datos. La holgura debe ser positiva, lo que significa que durante la ventana de tiempo de espera, no hay ninguna
transición. La secuencia de comandos que utiliza los comandos de Synopsys PT para la verificación del tiempo de
espera se describe en la secuencia de comandos 2.
Guión 2: Comprobación del tiempo de espera [1].
establecer active_design soc_top
–
netlist_only $active_design.db read_db
diseño_actual $diseño_activo
largo set_wire_load
set_wire_load_mode top
set_operating_conditions MEJOR set_load
50.0
– célula BUFF1X –
[todas_las_salidas] set_driving_cell pin Z [todas las entradas]
create_clock – –
período 10
[get_clocks
forma de onda
master_clk]
[0 5] master_clk
0.1 1.0
set_clock_latency
set_clock_transition [get_clocks master_clk] set_clock_uncertainty
–
0.5 hold [get_clocks master_clk] [todas
set_input_delay
las
0.0
ecntradas]
lock
0m
las .0
saster_clk[todas
cslock
et_output_delay
m
alidas] aster_clk
report_constraint
–
all_violators report_timing
context
to [all_registers data_pins].write_sdf context vhdlf
–
–
– – –
– –
–
El informe de tiempo de muestra se muestra en el Informe 5. Como se muestra, la diferencia entre el
tiempo de llegada de los datos y el tiempo requerido de los datos es positiva. Esto indica que no hay
violación de tiempo debido a la holgura positiva.
Informe 5 Informe de tiempo para el análisis de espera [1].
Si no se cumple con la holgura, entonces, ¿qué se debe hacer?
1. Considere las primeras señales de llegada en la ruta de datos.
2. Modifique el RTL.
3. Modificar la arquitectura, microarquitectura.
9.5.5 Caracterización de submódulos
En los diseños prácticos de ASIC, el diseño puede tener múltiples jerarquías. Considere
que el diseño de nivel superior consta de submódulos X, Y, Z. Si estos submódulos se
sintetizan y optimizan de forma independiente para las restricciones de diseño, podrían
cumplir los requisitos de tiempo de forma independiente. Cuando estos submódulos se
instancian en el nivel superior de jerarquía superior, entonces puede ser posible que no
cumplan con el tiempo. La razón de esto puede ser la lógica de unión utilizada entre los
submódulos X, Y, Z o las estrictas restricciones en la jerarquía de nivel superior.
En tales circunstancias, para cumplir con las restricciones de diseño, es recomendable
utilizar el comando de caracterización . Este comando permite capturar las condiciones de
contorno para el submódulo en función del entorno de jerarquía de nivel superior. Cada
submódulo se puede compilar y caracterizar de forma independiente.
El siguiente es el pequeño script que puede permitir la caracterización de los submódulos
individuales. Considere los nombres de instancia del submódulo X, Y, Z como I1, I2 e I3
dc_shell > current_design = CIMA

dc_shell > caracterizar I1
dc_shell > compila m–ap_effort
high current_design– mapeo incremental
dc_shell > = TOP
dc_shell > caracterizan I2
dc_shell > compila m–ap_effort
alto –
mapeo incremental
dc_shell > = TOP
current_design caracterizar
dc_shell > I3
dc_shell > compilar h–igh
map_effort
current_design
–
mapeo incremental
dc_shell > = CIMA
9.5.6 Equilibrio de registros
El balanceo de registros es una técnica muy eficiente y poderosa para mover la lógica
combinacional de una etapa segmentada a otra etapa segmentada. Esta técnica mejora el
rendimiento del diseño al mover la lógica y, por lo tanto, reduce el retraso de registro a
registro. Considere el diseño canalizado que se muestra en la figura 9.5 y que consta de
los tres flipflops y la lógica combinacional. En la primera etapa canalizada, el combinacional
estruendo
combinados
combinados
lógica:
lógica:
b
A chanclas D
chanclas D chanclas D
clk
Fig. 9.5 Etapas canalizadas
la lógica es una función de 4 variables y la segunda etapa canalizada tiene una lógica combinacional
como una función de 8 variables y tiene más retraso de propagación en comparación con la lógica
combinacional de 4 variables. Debido al diferente retraso de propagación en dos etapas diferentes
canalizadas, el rendimiento del diseño lo decide el registro para registrar la ruta de tiempo que tiene
más retraso.
En tales circunstancias, el balanceo de registros se puede usar para cambiar la lógica
combinacional de una de las etapas segmentadas a otra etapa segmentada sin afectar la funcionalidad
del diseño. Esto lo logra el compilador usando el siguiente conjunto de comandos.
dc_shell >
> report_timing
saldo_registro
dc_shell – – – – peor 1
camino lleno demora máximo ruta_máxima 1
9.5.7 Rutas multiciclo
Las trayectorias multiciclo en el diseño necesitan ser reportadas. Las rutas se pueden configurar para que el
analizador de tiempo pueda realizar la verificación de configuración y retención (Fig. 9.6).
Los comandos utilizados para establecer la ruta de varios ciclos se enumeran en la Tabla 9.1.
Considere el escenario de diseño para el bloque del procesador. El procesador necesita realizar
la instrucción de multiplicación y tiene una arquitectura segmentada. Como la multiplicación requiere
más cantidad de ciclos, los datos lanzados por FF1 a FF2 son de tres ciclos.
Fig. 9.6 Trayectoria multiciclo
Tabla 9.1 Comandos utilizados para reportar ruta multiciclo
create_clock –nombre clk_master periodo 5 Para crear el reloj maestro de periodo 5 nseg.
[get_ports clk_master]
set_multicycle_path 3 setup desde [get_pins Esto establece la ruta multiciclo de 3 ciclos.
DEPT/Q] –a [get_pins DEPT1/D]
set_multicycle_path 2 –mantener –desde [get_pins Esto se usa para mover la verificación de retención en 2
DEPT/Q] –a [get_pins DEPT1/D] ciclos de reloj, ya que la configuración se verifica en el tercer
ciclo de reloj.
ruta, en este tipo de escenarios, la configuración debe ser empujada por tres ciclos y necesita mover la
verificación de espera por 2 ciclos.
1. Use la ejecución de síntesis inicial e intente encontrar a todos los infractores durante el nivel de bloque
síntesis.
2. Si se cumplen las restricciones de tiempo a nivel de bloque, solo intente optimizar para el área si es un
requisito.
3. Para optimizar el área, use el atributo set_max_area.
4. Para informar el área, use report_area y para informar el tiempo, use report_timing 5. Para informar
a todos los infractores, use el comando report_cosntraints –all_violators 6. Las restricciones de
tiempo se cumplen indica la configuración positiva y la espera.
7. Para optimizar el diseño para la compilación de uso de tiempo, caracterizar con peso
factor.
8. Utilice las técnicas de optimización de área y velocidad requeridas para cumplir con el bloque y
Restricciones de tiempo a nivel de chip.
9. Reporte los caminos multiciclo y falsos para el diseño.
Este capítulo nos ha brindado una buena comprensión de las estrategias y escenarios de
optimización a nivel de bloque y de chip. En el próximo capítulo, discutiremos por qué el FPGA
es el mejor candidato para el prototipo. Incluso el próximo capítulo discutirá la arquitectura FPGA
y las FPGA de la serie Xilinx 7.
Referencias
1. www.springer.com: “Síntesis avanzada de HDL y creación de prototipos SOC: Vaibbhav Taraate”. 2.
www.springer.com: “Diseño de lógica digital usando Verilog: Vaibbhav Taraate”.
Capítulo 10
FPGA para prototipos SOC
“Los FPGA de alta densidad de Xilinx e Intel son los mejores candidatos para
la creación de prototipos de SOC”.
Resumen Este capítulo analiza la arquitectura de FPGA, el flujo de diseño de FPGA y cómo utilizar los
recursos de FPGA para la creación de prototipos de SOC. El capítulo analiza la síntesis de FPGA y cómo
se infiere la lógica utilizando las herramientas de diseño de FPGA. El diseño de VHDL con pocos escenarios
y cómo modificar el RTL para el diseño de FPGA también se analiza en el capítulo para una mejor
comprensión de la síntesis de FPGA.
Palabras clave FPGA SOC Spartan 3A Artix 7 LUT CLB Slice BRAM _ _ _
Multiplicador ∙ Síntesis ∙ RTL ∙ VHDL ∙ Implementación ∙ Memoria ∙ Distribuida
RAM ∙ Reloj ∙ PLL ∙ Lógica de decodificación ∙ Uso compartido de recursos ∙ Duplicación de lógica
10.1 FPGA de la serie Xilinx 7
El objetivo de esta sección es tener los aspectos más destacados sobre el FPGA de la serie Xilinx 7.
Posteriormente, intentaremos usar la placa Artix7 para comprender el flujo del prototipo SOC y cómo
obtener el prototipo eficiente utilizando la herramienta Xilinx Vivado.
Aspectos destacados de la arquitectura FPGA de la serie Xilinx 7:
(1) Tiene la arquitectura unificada y opera a 1 V para la biblioteca de tecnología de
28 norte.
(2) La arquitectura FPGA tiene bloques CLB, IOB, transceptores, DSP, PCIe,
ADC y mosaicos de administración de reloj (CMT) .
(3) La serie de gama media de la arquitectura de la serie Xilinx 7 es Kintex y la gama baja es
Artix.
(4) Si consideramos la arquitectura de la familia Virtex de gama alta, entonces la arquitectura tiene
interconexiones de silicio apiladas (SSI) de matriz múltiple 3D, hasta 1200 pines de E/S de usuario,
hasta 8 MB de RAM, hasta 2 M de celdas lógicas y Chanclas de 2,4M.
© Springer Nature Singapore Pte Ltd. 2020 V. Taraate, 159
síntesis lógica y creación de prototipos SOC, https://doi.org/
10.1007/9789811513145_10
160 10 FPGA para prototipos de SOC
Para obtener más información, visite www.xilinx.com para la arquitectura y la información
del paquete de Artix7 FPGA. La figura 10.1 brinda información sobre los diferentes bloques
funcionales en la arquitectura de la serie Xilinx 7.
Las características importantes de la FPGA de la serie Xilinx 7 se muestran en la Fig. 10.2
y los recursos clave son CLB, BRAM, bloques DSP, recursos de reloj, bloques IO, IP integradas,
recursos de interconexión y enrutamiento, transceptor y características del monitor del sistema .
Fig. 10.1 Recursos de la serie Xilinx 7
Fig. 10.2 Bloques de arquitectura FPGA de la serie Xilinx 7
10.1 FPGA de la serie Xilinx 7 161
Esta sección los analiza con algunos escenarios de diseño que pueden ser útiles durante la creación
de prototipos.
10.1.1 Arquitectura CLB de la serie Xilinx 7
El CLB de la serie Xilinx 7 se muestra en la Fig. 10.3, y como se muestra, los siguientes son aspectos
destacados importantes
1. Tiene dos segmentos por CLB, y cada CLB consta de LUT de seis entradas.
2. Dos rebanadas se denominan SLICEM y SLICEL; SLICEM consiste en RAM/SR, y SLICEL consiste
solo en lógica.
3. Tiene cuatro flipflops o pestillos y se puede configurar según el flujo de bits
de la funcionalidad.
4. La arquitectura CLB tiene amplios multiplexores y lógica de cadena de acarreo. Por lo tanto, la
arquitectura de CLB es lo suficientemente eficiente como para diseñar seis entradas y múltiples
salidas de lógica combinacional o secuencial.
El ejemplo 1 a continuación brinda información sobre el uso de CLB. La herramienta de síntesis
inferirá la lógica utilizando múltiples sumadores, restadores y puertas lógicas requeridas para este
tipo de diseño. La lógica del multiplexor se utiliza para generar una de las salidas según el código
único para la instrucción que se denomina código de operación.
Fig. 10.3 Arquitectura CLB de la serie Xilinx 7 [1]
Ejemplo 1: descripción de VHDL para la ALU de 8 bits
Biblioteca
ieee; ieee.std_logic_1164.all;
Utilice
La entidad alu_logic es
Puerto (clk, op_code
en std_logic
en reset_n: ;
: a_in,b_in
std_logic_vector ( 3 heasta
n 0); (15
std_logic_vector hasta 0); cin
: hasta
en std_logic :
alu_out
0); co
out:
ut sotd_logic_vector
ut std_logic); (15
;
:
fin
alu_logic; arquitectura arch_alu de alu_logic es
comenzar
proceso (clk, reset_n, op_code, a_in, b_in, cin)
variable resultado_salida : sin firmar (16 hasta 0);
comenzar
si (reset_n='0') entonces
result_out :=(otros =>'0');
más
caso (op_code) es
cuando ”0000”=> result_out s:in = firmar ('0' & a_in);
=result_out
cuando ”0001” sin :f=irmar
> b_in); cuando & a_in) yresult_out
” ( '0'
0010” a_in) sin sfirmar + ('0' (y'0'
in firmar
=> := +
no firmado ('0' &
b_in)+cin; cuando
"0011" := sin firmar ('0' & a_in) sin firmar ('0' & b_in);
= >result_out
cuando ”0100” = > result_out := sin firmar ('0' & a_in)
sin firmar ('0'
”0101”
&when
b_in)
result_out
>result_out
”0110”
cin;
”1000”
ww hen
hen
result_out when ”1001”
= result_out := sin signo ('0' & a_in) '1'; + sin
when ”1010” result_out
= > when := firmar ('0' &
firmar
a_in) ('1';
'0' &s
in
(a_in
”1011” result_out
= > when other: = O b_in));
=> := sin firmar ('0' & (a_in XOR b_in));
=> := sin firmar ('0' & (a_in Y b_in)); sin
=> := firmar ('0' & NO (a_in));
= > resultado_fuera := (otros=>'0');
casos finales;
terminara si;
alu_out< = std_logic_vector( result_out(15 hasta 0));
= std_logic(resultado_salida(16));
cout < finalizar
proceso
;
fin arco_alu;
El resultado de la síntesis se muestra en la Fig. 10.4. Todavía existe la posibilidad de optimizar el
diseño utilizando el concepto de recursos compartidos.
10.1.2 RAM de bloque de la serie Xilinx 7
Los BRAM se requieren en muchas aplicaciones y la arquitectura de BRAM depende del proveedor. Se
pueden configurar utilizando la herramienta EDA dependiente del proveedor para la configuración de
memoria requerida. Los siguientes son aspectos destacados importantes para la serie BRAM de Xilinx
7
1. La arquitectura tiene 36 KB de BRAM y se puede mostrar como 2 × 18 KB
BRAM.
2. La BRAM es RAM síncrona y se puede conectar en cascada sin ninguna lógica
gastos generales para obtener 64K×1.
Fig. 10.4 Resultado de la síntesis para la ALU de 8 bits
3. El BRAM se puede utilizar como puerto único y puerto dual. En el modo de puerto dual, la
BRAM de 18 KB se puede usar y configurar como 18K × 1, 9K × 2, 8K × 4, 4K × 9, etc., y la
BRAM de 36 KB se puede usar como 1K × 36, 2K × 9, 4K×9, etc
4. La arquitectura BRAM tiene corrección de errores incorporada (ECC de 64 bits), y también se
pueden usar en modo FIFO (Fig. 10.5).
Todo tipo de diseño SOC utiliza las memorias de tipo RAM, ROM, contenido direccionable.
Así que pensemos cómo se pueden implementar este tipo de memorias.
Las memorias se pueden instanciar desde la biblioteca de celdas o desde el generador de
memoria.
Para implementar las memorias pequeñas de pocos bits se pueden utilizar las LUTs. Es
importante que estas memorias puedan ser lo suficientemente eficientes para cargar, almacenar
y pasar los datos. Pero tener la arquitectura mejor y más eficiente para el diseño en lugar de distribuir la
Figura 10.5 BRAM de la
serie Xilinx 7 [1]
memorias sobre el tejido FPGA, siempre es mejor usar las BRAM. Las principales características de
BRAM son:
1. Memoria síncrona: las BRAM pueden implementar la memoria síncrona de uno o dos puertos.
Una de las verdaderas bellezas de estos bloques de memoria es que, cuando se configuran
como RAM de doble puerto, cada puerto puede operar a diferentes frecuencias de reloj.
2. Se pueden configurar: el bloque BRAM es un bloque RAM síncrono de puerto dual dedicado y se
puede configurar como se explicó anteriormente. Cada puerto se puede configurar de forma
independiente.
3. Las BRAM y su uso en los diseños FIFO: Las BRAM se pueden usar para almacenar los datos,
ya que son bloques de memoria dedicados y se pueden configurar. Con lógica adicional, los
FIFO se pueden implementar utilizando BRAM. La profundidad de los FIFO se puede configurar
con la restricción de que tanto el lado de lectura como el de escritura deben tener el mismo
ancho.
4. Corrección de errores: Considere que la BRAM está configurada como RAM de 64 bits, y luego,
cada BRAM puede almacenar bits de código Hamming adicionales. Estos bits se utilizan para
realizar las correcciones de errores de un solo bit y de doble bit durante el proceso de lectura.
Para BRAM de 64 bits, cada BRAM puede almacenar el código Hamming de ocho bits. La
lógica de corrección de errores también se puede utilizar mientras se escribe o lee desde las
memorias externas.
Entonces, pensemos cómo se infieren las BRAM.
La herramienta de síntesis divide las memorias más grandes en pequeños bloques, y cada bloque
se puede implementar usando BRAM. Efectivamente, en palabras simples, las BRAM son bloques
de construcción muy efectivos que se infieren automáticamente durante la síntesis y se organizan
para implementar la amplia gama de memorias utilizadas para el SOC.
El ejemplo 2 describe 16 × 2 BRAM y tiene 4 líneas de dirección y entrada de datos de 2 bits
y salida de datos de 2 bits. Utiliza señales de control adicionales como 'clk' y 'write_en'.
Ejemplo 2: descripción de VHDL para 16 × 2 BRAM
biblioteca ieee;
entidad BRAM_16x2 es
puerto (q_out: out std_logic_vector(1 a 0);
escribir_es : en std_logic ;
clk: a std_logic ;
d_in: en std_logic_vector (1 a 0);
a_in: en std_logic_vector(3 hasta 0));
fin BRAM_16x2;
arquitectura BRAM_arco de BRAM_16x2 es
componente RAM16x1S es
puerto(o : std_logic
salida ;
D : en std_logic ;
A3, A2, A1, A0 : en std_logic;
NOSOTROS, WCLK : en std_logic);
componente final ;
comenzar
U0 : RAM16x1S
puerto mapa (O = > q_out(0), = > escribir_es, WCLK = > clk, D=> d_en(0), A0 =
> a_in(0), A1 = > NOSOTROS un_en(1),
A2
=> a_en(2), A3 = > a_in(3));
: RAM16x1S
(O = > q_out(1),
puerto mapa
U1 = > escribir_es, WCLK = > clk, D=> d_en(1), A0 =
> a_in(0), A1 = > NOSOTROS un_en(1),
A2
= > a_en(2),A3 = > a_in(3));
fin BRAM_arco;
El resultado de la síntesis del BRAM 16×2 inferido por Vivado se muestra en la Fig. 10.6.
10.1.3 DSP de la serie Xilinx 7
La arquitectura de segmento DSP48E1 de la serie Xilinx 7 se muestra en la Fig. 10.7 y es compatible con la operación
de acumulación múltiple (MACC) de 96 bits. Algunos de los aspectos más destacados del bloque DSP
están
(1) El segmento DSP tiene un sumador previo de 25 bits, un multiplicador con signo de 25 × 18 bits y una ALU de 48 bits.
(2) Se utiliza principalmente para implementar los algoritmos DSP; los cambiadores se pueden implementar usando un
cambiador de 17 bits y un detector de patrones.
(3) El segmento también tiene rutas en cascada para implementar una amplia gama de funciones y algoritmos DSP.
(4) También proporciona la implementación de la lógica canalizada para el bit 12/24 del
fecha.
El ejemplo 3 describe la implementación del multiplicador utilizando el bloque DSP. la
La herramienta de síntesis intentará introducir la lógica en el bloque DSP para este tipo de diseños.
Fig. 10.6 Resultado de la síntesis para la BRAM de 16 × 2 bits
Ejemplo 3: VHDL RTL para el multiplicador de 32 bits
biblioteca
ieee;
entidad sin_compartir_recursos es el puerto
hasta 0); sel_in:
en esn
td_logic_vector
std_logic
fuera
y_out:
d(e
31
std_logic_vector
;
(0)); 63 hasta
terminar sin_compartir_recursos; Descripción funcional sin empujar los recursos comunes
arquitectura arch_without_sharing de without_resource_sharingis
comenzar
Procesar todas las entradas y señales de control
sensibles a
proceso comienza
(a_in, bs_in,
i (sel_in='1')
c_in, d_in,
entonces
sel_in) eal _in
b_in; tu_fuera más
*
<=
*
< = c_en
terminas estruendo;
si ;
end arch_sin_compartir;
Este tipo de diseño infiere la cadena de multiplicadores en la entrada y, dependiendo
del estado de la entrada seleccionada, el resultado de uno de los multiplicadores se
asigna a la salida (Fig. 10.8). Al compartir recursos, se puede usar el multiplicador único
y se analiza en la Secc. 10.3.
Fig. 10.7 Segmento DSP de la serie Xilinx 7 [1]
Fig. 10.8 Resultado de la síntesis del multiplicador de 32 × 32 bits
Fig. 10.9 Utilización del dispositivo Artix7 para multiplicador
La Figura 10.9 brinda información sobre la utilización del dispositivo. La lógica inferida utiliza
los cuatro DSP, que es solo un 4,44 % de utilización de los bloques DSP disponibles.
10.1.4 Reloj de la serie Xilinx 7
Para cualquier diseño, el rendimiento depende de la lógica de generación de reloj y la
arquitectura utilizada para sincronizar los múltiples CLB. La arquitectura de reloj para los
dispositivos de la serie Xilinx 7 se muestra en la Fig. 10.10, y los siguientes son algunos de los
puntos importantes
(1) El reloj se divide en regiones de reloj y, efectivamente, tiene la mitad del ancho por cada 50
CLB.
(2) Cada región de reloj se puede tratar como un grupo de 20 DSP, 10 BRAM, 4 transceptores,
50 IOB y PCIe.
(3) Tiene CMT y los mosaicos se usan junto a las columnas de E/S, es decir, 1 mosaico por
región y 2 columnas por dispositivo.
(4) Tiene un lomo de reloj central y eso es 1 fila/región de reloj horizontal.
Fig. 10.10 Reloj de la serie Xilinx 7 [1]
10.1.5 E/S de la serie XILINX 7
Como se discutió en la sección anterior, el rendimiento general del SOC depende de los IO
disponibles y su ancho de banda para la transferencia de datos. Los siguientes son puntos
importantes
(1) Las IOB de gama alta admiten estándar hasta 3,3 V y las IOB de alto rendimiento admiten
estándar hasta 1,8 V.
(2) La serie Xilinx 7 tiene varios tipos de IO, y se enumeran en la Tabla 10.1:
E/S de la serie Xilinx 7.
10.1.6 Transceptores de la serie Xilinx 7
La arquitectura tiene el transceptor gigabit de baja potencia. Debido a la arquitectura de bajo
consumo, la interfaz de chip a chip está optimizada y esta es una de las características poderosas
de este FPGA. Los siguientes son algunos aspectos destacados con respecto al rendimiento de
estos transceptores.
(1) El transceptor de alto rendimiento es capaz de admitir una velocidad de datos de 6,6 a 28,05
Gb/s según la familia de FPGA Virtex 7.
(2) La cantidad de transceptores es de 16 en la familia Artix7 FPGA, hasta 32 transceptores en la
familia Kintex 7 y hasta 96 transceptores en la familia Virtex 7.
Tabla 10.1 E/S de la serie Xilinx 7
Sr. no. yo Descripción
1 Bloques de entradasalida (IOB) La arquitectura tiene 2 columnas por dispositivo y 50
IOB por banco. Dos tipos distintos de IOB son de
alto rango y alto rendimiento
2 Transceptores de E/S serie de alta velocidad Los transceptores están disponibles en quads, es
decir, 4 por bloque. Tienen diferentes tipos y múltiples
estándares: GTH/GTP/GTX/GTZ con un ancho de
banda de 3.75–28 Gbps
3 Bloques PCI Express (PCIe) Están integrados en transceptores de E/S serie GTX y
son compatibles con los protocolos Gen 1,2,3 que
tienen un ancho de banda de 2,5, 5 y 8 Gbps
4 XADC Para cada convertidor de analógico a digital, hay un
sensor analógico y la arquitectura tiene dos ADC de
12 bits
(3) Para mejorar la portabilidad de IP, la arquitectura del transceptor en serie utiliza los osciladores de
anillo y el circuito de tanque LC.
(4) Los circuitos del transmisor y del receptor son diferentes y usan el PLL para multiplicar el reloj de
referencia por el número programable hasta 100 para obtener el reloj de serie de bits.
10.1.6.1 Transmisores
Las siguientes son las características clave de los transmisores gigabit:
1. El transmisor es un convertidor paralelo a serie con una relación de conversión de 16, 20, 32,
40, 64 u 80.
2. El transmisor GTZ admite un ancho de datos de hasta 160 bits.
3. Utiliza TXOUTCLK y se usa para registrar los datos paralelos.
4. Los datos paralelos entrantes se alimentan a través de un FIFO opcional y proporciona la cantidad
suficiente de transiciones, tiene soporte adicional de esquemas de codificación 8B/10B, 64B/66B.
5. La salida de estos transmisores impulsa la placa de PC con el canal único
señal de salida diferencial.
6. Para compensar las pérdidas de la placa de circuito impreso, el par de señales de salida tiene
oscilación de la señal.
7. Para reducir el consumo de energía, este swing se puede reducir para el más corto
canales
10.1.6.2 Receptores
Las siguientes son características clave de los receptores gigabit:
1. El receptor es un convertidor de serie a paralelo con una relación de conversión de 16, 20, 32,
40, 64 u 80.
2. El receptor GTZ admite un ancho de datos de hasta 160 bits.
3. Para garantizar una transición de datos suficiente, utiliza codificación sin retorno a cero (NRZ)
ing.
4. Los datos paralelos se transfieren a la FPGA mediante RXUSRCLK.
5. Para canales cortos para reducir el consumo de energía en casi un 30%, el transceptor ofrece un
modo especial de baja potencia (LPM).
10.1.7 IP integradas
Hoy en día, las FPGA son más capaces de usarse en las áreas de comunicaciones, imágenes
médicas y redes debido a PCIe, Ethernet MAC, Phy y núcleos de procesador disponibles en la
estructura FPGA.
El FPGA de la serie Xilinx Virtex 7 tiene PCIe, Ethernet MAC, Phy integrado en
el tejido FPGA.
• Ethernet: Puede operar con la velocidad de 2.5 Gbits/s, y el bloque Ethernet es
diseñado con el estándar IEEE 802.32005
– Los cuatro bloques MAC trimodales (10/100/1000 Mb/s) se pueden conectar al
Tejidos FPGA, transceptores.
• PCIe: La FPGA tiene el bloque de interfaz integrado para PCI Express y se puede configurar como
punto final. Puede operar a la velocidad de datos de 2,5 y 5 Gbit/s.
• Núcleo duro de CPU: el núcleo ARM IP optimizado que puede funcionar a mayor velocidad (10
veces más) en comparación con RTL, y puede usarse durante la creación de prototipos si las
características del núcleo del procesador SOC coinciden con el núcleo IP disponible. Si se
requieren múltiples procesadores durante la creación de prototipos, entonces use múltiples FPGA
con la lógica dividida, pero esto puede reducir el rendimiento del prototipo debido al tiempo de
acceso al bus. Estos bloques no se infieren directamente mediante la herramienta de síntesis,
sino que deben crearse instancias mediante generadores de núcleo.
10.1.8 Monitor integrado
Se puede utilizar durante la creación de prototipos para obtener la información térmica y de suministro de
energía, y no necesita ninguna instanciación en el diseño. Una vez que se realizan las conexiones de
alimentación, se puede acceder a los datos en cualquier momento utilizando el puerto de acceso de prueba (TAP).
10.2 Flujo de síntesis e implementación [2]
La síntesis durante el ciclo del prototipo se puede realizar antes o después de la partición del diseño. La
síntesis es el proceso de convertir el RTL en netlist de nivel de puerta equivalente. Si consideramos los
ASIC, entonces la síntesis es el proceso para obtener la lista de conexiones utilizando las celdas estándar
para el nodo de proceso objetivo. En el caso de FPGA, el resultado de la síntesis es la lista de conexiones
utilizando los recursos de FPGA. En el Cap. 11
Según el dispositivo o la familia de FPGA de destino, la herramienta de síntesis genera la lista de
conexiones de FPGA y la herramienta de backend de FPGA utiliza las restricciones de diseño y la lista de
conexiones durante la implementación. La mayor parte del tiempo durante el prototipo, necesitamos
comprender la velocidad o el rendimiento esperados para el diseño y eso se puede lograr con herramientas
de síntesis y puede ser útil durante la fase inicial del ciclo de diseño para modificar las arquitecturas y las
restricciones para lograr el rendimiento requerido.
Para el diseño de FPGA, el flujo de diseño desde el RTL hasta la programación del dispositivo se
describe en la figura 10.11.
El diseño de RTL para el prototipo SOC es uno de los principales hitos, y en este hito, el RTL se ajusta
para que encaje en el FPGA de destino. Esto puede implicar los cambios en las IP, los recursos del reloj y
el cambio de tamaño de los bloques de memoria, etc.
La partición del diseño es necesaria si las especificaciones de diseño son complejas y el diseño no
encaja en el FPGA único. Si se necesitan varios FPGA para el prototipo y probar el diseño, el diseño se
puede particionar manualmente o mediante las herramientas de partición. La partición del diseño se analiza
en detalle en los próximos capítulos.
Para la herramienta de implementación, debemos proporcionar las restricciones y estas restricciones
son para definir la velocidad requerida y las ubicaciones de los pines. Estos pueden ser utilizados por las
herramientas de backend para optimizar el diseño. Aunque las directivas y los algoritmos dependientes del
proveedor en el nivel de síntesis pueden optimizar el diseño para lograr el rendimiento deseado, es esencial
utilizar las restricciones de implementación.
Una herramienta de ubicación y ruta utiliza la lista de redes FPGA y las restricciones de diseño para
ubicar y mapear el diseño para la FPGA de destino. El archivo de flujo de bits de la FPGA se cargará en la
FPGA para lograr la funcionalidad deseada. Aunque parece simple, este proceso implica varios pasos,
como mapeo, ubicación, enrutamiento y análisis de tiempo.
Las siguientes pueden ser algunas de las herramientas de backend útiles al crear prototipos del SOC
1. Herramienta de planificación: Considere que necesito colocar cientos de IO para lograr el rendimiento,
entonces, ¿qué debo hacer? Usaré la herramienta de planificación de pisos que puede
Fig. 10.11 Diseño de FPGA
flujo
lograr la colocación de IO, y para algunos diseños críticos puede ser útil colocar la lógica para
cumplir con el rendimiento.
2. Generadores de núcleos: este tipo de herramienta se utiliza para inferir los núcleos de IP para el RTL
específico. El objetivo y el uso del generador de núcleos son comprender las estructuras RTL y
reemplazarlas por los núcleos IP existentes disponibles para esa FPGA. En lenguaje sencillo, es
como reemplazar el RTL con su lógica equivalente FPGA.
3. Editores de FPGA: esto se puede usar para modificar el diseño de FPGA después de la ubicación y el
enrutamiento. Esto se puede utilizar como herramienta de depuración en el nivel de implementación,
lo que permite al diseñador modificar las ubicaciones de los bloques FPGA, el enrutamiento, etc.
4. Herramienta de depuración en circuito: Esto le permite al diseñador capturar y ver los nodos de diseño
internos.
Ahora centrémonos en el aspecto práctico importante sobre cómo se mapea la lógica dentro de la
FPGA. (más detalles en Cap. 11, 12)
10.2.1 ¿Cómo se asigna la lógica mediante CLB?
La lógica se mapea utilizando los CLB, ya que cada CLB consta de múltiples LUT y registros de entrada.
Si consideramos la arquitectura Virtex7, entonces para la lógica de seis entradas
10.2 Flujo de síntesis e implementación [2] 175
la lógica de la función se mapea utilizando LUT de 6 entradas. Para una mayor cantidad de entradas, las
LUT se pueden conectar en cascada, y para una menor cantidad de variables de entrada, las LUT se
dividirán para realizar la función.
Considere el escenario práctico donde la función lógica utiliza 4 o 5 entradas, y luego puede mapear
la lógica dentro de un CLB.
El registro de desplazamiento o RAM distribuida se infiere utilizando SLICEM.
Si usamos la herramienta de síntesis de FPGA eficiente, entonces puede detectar la posibilidad de las
afirmaciones de set/reset para set y reset asíncrono y síncrono para evitar el mal funcionamiento dentro
del FPGA.
10.2.2 ¿Cómo se asignan los bloques DSP?
El Virtex7 tiene el bloque DSP dedicado, y para mejorar el rendimiento de la FPGA y evitar el uso de otros
bloques funcionales, la herramienta de síntesis puede mapear la funcionalidad DSP usando los bloques
DSP dedicados.
Considere la función de multiplicar y acumular (MAC), esto se puede mapear usando el bloque DSP
para mejorar el rendimiento. Si el algoritmo DSP es más complejo, se pueden usar varios bloques DSP
para implementar una gama más amplia de algoritmos aritméticos. Si deseamos tener la canalización en
el algoritmo DSP, entonces la lógica canalizada se puede mapear utilizando los bloques DSP.
10.2.3 ¿Cómo se mapean los bloques de memoria dentro de FPGA?
Necesitamos tener el almacenamiento interno en forma de RAM distribuida o RAM en bloque. El
rendimiento del diseño general depende del mapeo de estos bloques de manera eficiente mediante la
herramienta de síntesis. Lo que debemos investigar es si la herramienta de síntesis infiere estos bloques
o no.
La herramienta de síntesis debe inferir automáticamente las memorias RAM de uno y dos puertos y,
para mejorar el rendimiento del diseño, los registros canalizados adyacentes deben seleccionarse
automáticamente en la entrada y la salida. Para mejorar la velocidad y el área, es esencial que la
herramienta de síntesis pueda dividir las memorias grandes en múltiples BRAM e incluso estas deberían
poder tener la dirección y los datos de acuerdo con los requisitos funcionales.
Si consideramos las características de la herramienta de síntesis, entonces, para el diseño del SOC,
las herramientas de síntesis son lo suficientemente inteligentes debido al uso de algoritmos para particionar
y realizar el diseño. Durante la creación de prototipos, el diseñador debe tener cuidado al utilizar las
características dependientes del proveedor de dichas herramientas para lograr los resultados deseados.
La mayoría de las veces, observamos que dicho proceso está automatizado en la industria mediante el
uso de scripts de síntesis.
Pero prácticamente qué cuidado debe tener el equipo de diseño: Permítanme compartir mi experiencia
cuando estaba trabajando en uno de los proyectos SOC durante la última década!
1. El primer punto importante que pensé al visualizar la arquitectura es que el diseño es demasiado
complejo y necesita particiones.
2. Si la funcionalidad de mi SOC es mayor que la densidad lógica de FPGA, ¿qué debo hacer? Necesito
usar múltiples FPGA.
3. ¿Es posible que pueda lograr la velocidad deseada de los SOC usando FPGA? Prácticamente no
porque la velocidad de SOC es más rápida en comparación con FPGA.
4. ¿Es que mi RTL puede mapear directamente en el FPGA? La respuesta es no. Necesito ajustar el
RTL y hacer los cambios y hacerlo compatible con los recursos de FPGA; por ejemplo, la
implementación del reloj cerrado en ASIC y FPGA es diferente.
10.3 Las Técnicas para la Mejor Optimización
Esta sección analiza las pocas técnicas de optimización durante la fase de diseño de RTL para obtener
resultados de síntesis eficientes.
10.3.1 Multiplicadores y uso compartido de recursos
La mayoría de las veces, podemos haber observado que los multiplicadores consumen grandes áreas.
Debido a eso, siempre afecta el tiempo de llegada de los datos si se utilizan multiplicadores en la ruta
de registro a registro. Para los FPGA, hay bloques dedicados de DSP y se pueden usar para implementar
los multiplicadores de área más grandes. El ejemplo 4 describe el uso de un multiplicador de 32 × 32
bits utilizando la técnica de compartición de recursos.
Ejemplo 4: diseño de VHDL utilizando recursos compartidos para multiplicador
biblioteca
in std_logic in std_logic_vector
out std_logic_vector (63 downto 0));
(31
y_out:
downto
fin d0e
); puerto sel_in:
compartir_recursos ; ;
arquitectura arch_with_sharing de resource_sharing es señal sig_1,
: std_logic_vector
sig_2 (31 hasta 0); comenzar
P1: (a_in,
comienza
b_in,
sci _in,
(sel_in='1')
d_in, sel_in)
luego
esl ig_1
proceso
a_in ;
<=
10.3 Las Técnicas para la Mejor Optimización 177
sig_2 < = compartimiento;
más
sig_1 < = c_en;
sig_2< = estruendo;
terminar
si ;
P2: ( sig_1,
comienza
sig_2)
y_out
proceso
final proceso
final arch_with_sharing;
< = sig_1 * sig_2;
;
El resultado de la síntesis para el multiplicador de 32 × 32 bits utilizando un recurso común
como multiplicador se muestra en la figura 10.12. En lugar de usar los dos multiplicadores para
realizar “a_in * b_in”, “c_in * d_in”, el recurso común (multiplicador) se empuja en el lado derecho.
La cadena de multiplexores para seleccionar la entrada deseada se utiliza en el lado de entrada.
Este tipo de técnica se denomina uso compartido de recursos y, la mayoría de las veces,
necesitamos usarla durante los ajustes de RTL. Esto usa cuatro bloques DSP si la síntesis se
realiza para xc7a35tcsg3241.
10.3.2 Duplicación de lógica para la lógica de decodificación más grande
La lógica de decodificación más grande debe dividirse durante la fase de diseño de RTL. Para
ese propósito, podemos imaginar múltiples bloques de procesos en paralelo. Así que considere
si deseamos tener un diseño de decodificador 8:256, entonces usando las técnicas de diseño
lógico necesitamos diecisiete decodificadores 4:16 y por lo tanto un área más grande. Esto se
puede evitar usando el ajuste RTL para mejorar el área, y esta técnica se denomina duplicación
lógica. Usando la duplicación lógica, solo necesitamos dos decodificadores 4:16 y puertas AND
256 y, por lo tanto, un gran ahorro de área. Esto puede descartarse para la síntesis ASIC. ya que
puede consumir más área!
Fig. 10.12 Resultado de la síntesis del multiplicador que usa recursos compartidos
Fig. 10.13 Resultado de la síntesis de la técnica de duplicación lógica
El ejemplo 5 describe la funcionalidad de duplicación lógica para el decodificador 4:16. La
síntesis se muestra en la figura 10.13 e infiere los dos decodificadores 2:4 y 16 puertas AND.
Ejemplo 5: descripción de VHDL para la lógica de decodificación más grande usando
duplicación lógica
biblioteca
utilizar
entidad logic_duplication
(data_in en es puerto
std_logic_vector :n data_out
enable_in (e 3 shtd_logic; :
asta 0); out
std_logic_vector
(15 hasta 0)); : fin
logic_duplication;
arquitectura arch_logic_duplication de logic_duplication es ( 0); señal
std_logic_vector 3 downto : comenzar
enable_in)
el proceso
comenzar y_0_reg,
(data_in(1 y_1_reg
downto 0),
si (enable_in '1') =entonces
casas (data_in(1
0)) es cuando
downto
"00" y_0_reg
=> < = "0001";
10.3 Las Técnicas para la Mejor Optimización 179
cuando ”01” = > y_0_reg < = "0010";

cuando ”10” = > y_0_reg < = "0100";
”11” = > y_0_reg < = "1000";
cuando fin
de caso
y_0_reg
si n;o fin
si
< = "0000";
;
proceso (data_in (3 a 2), enable_in)
empezar si =entonces
(enable_in '1')
casas (data_in(3
2)) es cuando
downto
”00” ”0001”;
=>
cuando ””0100”;
01” ”0010”; cuando
cuando
y_1_reg = casos
”11” ””<10”
1000”;
finales; = > y_1_reg < =
= > y_1_reg < =
= > y_1_reg < =
más
y_1_reg < = "0000";
termina ;si
fin
proceso; fecha_salida(0) < = y_0_reg(0) y y_1_reg(0);
salida_datos(1) < = y_0_reg(1) y yy_0_reg(2)
_1_reg(0);
y_1_reg(0); y
salida_datos(2) < = y_0_reg(3) y_1_reg(0);
y_1_reg(1);
y_0_reg(0)
y y
salida_datos(3) < = y_0_reg(1) y_1_reg(1);
y_1_reg(1);
y_0_reg(2)
y y
salida_datos(4) < = y_0_reg(3) y yy_1_reg(2);
_1_reg(1);
y_0_reg(0) y
salida_datos(5) < = y_0_reg(1) y yy_1_reg(2);
_1_reg(2);
y_0_reg(2) y
salida_datos(6) < = y_0_reg(3) y y_1_reg(2);
salida_datos(7) < =
salida_datos(8) < =
salida_datos(9) < =
salida_datos(10) < =
salida_datos(11) < =
< =y_0_reg(0) y y_1_reg(3);
salida_datos(12)
< =ysalida_datos(14)
salida_datos(13) _0_reg(1) y yy_1_reg(3);
_1_reg(3);
y_0_reg(2) y
< =yterminar
salida_datos(15) _0_reg(3)
y y_1_reg(3);
arch_logic_duplication;
<=
10.4 Estrategias para la creación de prototipos de SOC
Las estrategias para lograr el objetivo deseado de área, velocidad y potencia durante la fase de
prototipo pueden desempeñar un papel importante durante la fase de creación de prototipos. ¿Cuál
debería ser la estrategia del equipo prototipo SOC? Y lo que debería ser un proceso de pensamiento
se aborda en esta sección.
1. Usando la síntesis inicial y la estimación temprana de la densidad lógica, intente encontrar la
FPGA adecuado.
2. La cifra de referencia debe ser el 60% de utilización de los recursos de la FPGA.
3. Si la lógica no se puede mapear en un solo FPGA, intente estimar los múltiples FPGA necesarios para el
prototipo.
4. Trate de tener un plan para los ajustes de RTL y los ajustes de síntesis para obtener el FPGA
equivalente del diseño.
5. Trate de tener una mejor comprensión de la arquitectura FPGA y los bloques funcionales para que los bloques
requeridos dedicados puedan usarse para realizar el prototipo.
6. Tener una mejor comprensión de las IP, los bloques analógicos y digitales y contar con una estrategia para las
placas analógicas que interactúan con las FPGA.
7. Tener las estrategias para la partición del diseño en funcional, síntesis y lista de conexiones.
nivel para prototipos rápidos.
8. Use las restricciones a nivel de bloque, nivel superior y nivel de chip y use los analizadores de tiempo para
lograrlas durante la fase de implementación y síntesis del diseño.
9. Tener la estrategia para múltiples diseños de dominios de reloj, asignaciones de E/S, multiplexación de pines,
transferencia de datos de alta velocidad.
10. Tenga un plan de prueba y use las metodologías de prueba deseadas para capturar
el resultado.
11. En el escenario práctico, es posible que el diseño no funcione a la velocidad de ASIC, así que use la escala
del reloj y reduzca la velocidad del prototipo.
1. El FPGA es el mejor candidato para el prototipo ASIC o SOC debido a sus características programables, bajo
costo y ciclo de implementación más corto.
2. El equipo de prototipos debe tener estrategias implementadas para un solo FPGA y múltiples
Diseños de FPGA.
3. Se recomienda utilizar 60–70 % de recursos FPGA durante el prototipo.
4. Tenga estrategias implementadas para ajustes de síntesis y ajustes RTL para obtener FPGA
equivalente.
5. Utilice recursos dedicados como bloques DSP, BRAM, multiplicadores, transceptores para mejorar la calidad y
la velocidad del prototipo.
6. Identifique las herramientas de partición requeridas, el equipo de prueba y tenga un plan de prueba establecido.
7. Tener la estrategia para la interfaz de las tarjetas analógicas con la FPGA.
8. Utilizar las técnicas comunes de uso compartido de recursos para multiplicadores de gran densidad.
9. Use las técnicas de duplicación de lógica para la lógica de decodificación más grande.
Este capítulo nos ha permitido comprender la arquitectura de FPGA, el flujo
de diseño de FPGA y cómo crear prototipos utilizando FPGA. El siguiente
capítulo analiza el prototipo utilizando FPGA simples y múltiples. El capítulo
es importante para comprender los desafíos del prototipo durante los prototipos
de FPGA únicos y múltiples y cómo superarlos.
Referencias
1. www.xilinx.com. 2.
www.springer.com: “Síntesis avanzada de HDL y creación de prototipos SOC: Vaibbhav Taraate”.
Capítulo 11
Creación de prototipos usando solo y múltiple
FPGA
“Para los SOC de gran densidad, es posible que el diseño no se ajuste
a un solo tejido FPGA y, por lo tanto, se debe crear un prototipo utilizando
múltiples FPGA”.
Resumen El capítulo analiza la creación de prototipos utilizando FPGA simples y múltiples. En
este capítulo se analiza la necesidad de dividir el diseño, los desafíos importantes durante la
implementación del diseño y las pautas para la creación de prototipos de diseño. Durante la
creación de prototipos, necesitamos tener el equivalente de FPGA para ASIC RTL, las
conversiones de sincronización de reloj y los ajustes de RTL también se analizan en este capítulo.
Palabras clave Particionamiento FPGA Multiplexación LVDS SerDes IO restricciones _ _
Almohadilla E/S de síntesis
Durante esta década, la complejidad del diseño ha crecido y los diseños deben realizarse para
la funcionalidad requerida para lograr alta velocidad, baja potencia y área mínima. Cumplir con
las restricciones de diseño y optimización con la realización de la funcionalidad equivalente de
FPGA es el objetivo principal del prototipo de FPGA. En tal escenario, dependiendo de la
complejidad del diseño, el diseño debe ser prototipado utilizando FPGA únicos o múltiples. Las
siguientes secciones describen los escenarios y aspectos destacados importantes sobre el
prototipo que utiliza FPGA únicos y múltiples.
11.1 Elección de la FPGA de destino
Para el prototipo discutido, el mejor candidato puede ser FPGA. FPGA es programable en
campo y tiene los recursos adecuados para realizar los diseños de gran densidad. Una de las
principales preguntas importantes que deben responderse es cómo puedo elegir el FPGA
objetivo para el diseño.
¡La respuesta a la pregunta no es tan simple como pensamos! La razón es que requiere una
buena cantidad de experiencia para percibir la funcionalidad de la arquitectura usando el FPGA
https://doi.org/10.1007/9789811513145_11
184 11 Creación de prototipos utilizando FPGA individuales y múltiples
bloques equivalentes. Por lo tanto, durante el diseño de la arquitectura de los SOC, la mayor parte
del tiempo, el equipo podría tener una discusión sobre lo mismo. Entonces, con referencia a esto, lo
que debemos considerar para seleccionar el FPGA objetivo para el prototipo se analiza en esta sección.
1. Comprensión de la arquitectura: a partir de la arquitectura, podemos obtener información sobre los
recursos necesarios para implementar la lógica, los requisitos de memoria, los requisitos de IP y
la estimación inicial sobre el número de puertas y las interfaces necesarias.
Al considerar todos estos puntos, podemos elegir el FPGA objetivo.
2. Comprensión de la arquitectura y los recursos de FPGA:
(1) Necesitamos considerar la cantidad de CLB que tiene el FPGA, ya que brinda información
sobre la densidad lógica. La lógica combinacional y secuencial se implementa utilizando el
CLB. Considere que el FPGA Artix7 tiene 215 000 celdas lógicas, y nuestro objetivo es
utilizar entre el 40 % y el 70 % de los recursos para implementar la lógica personalizada.
(2) Como se discutió en el capítulo anterior, necesitamos conocer los requisitos de memoria para
el diseño. Entonces, debemos considerar las BRAM disponibles en la FPGA. Durante la
implementación, la RAM, la ROM y la FIFO se pueden configurar mediante BRAM. Si
consideramos la familia Artix7, entonces tiene 143 Mb BRAM. Incluso debemos considerar
el rendimiento de la BRAM.
(3) Para operaciones de mayor densidad y complejidad compleja, necesitamos estimar sobre el
requisito de la lógica. Considere los multiplicadores de gran densidad, la aritmética de
punto flotante o el procesamiento de datos en tiempo real para audio y video.
En este tipo de aplicaciones, la funcionalidad ASIC debe impulsarse mediante el uso de
bloques DSP. Por lo tanto, cuántos segmentos DSP están disponibles en la FPGA y cuál
es el rendimiento son otros parámetros importantes que deben tenerse en cuenta. Si
consideramos el FPGA Artix7, entonces tiene 740 segmentos DSP.
(4) Ahora entendamos acerca de la disponibilidad de IO. Como los SOC necesitan cientos de
pines de E/S, debemos tener en cuenta la disponibilidad de E/S al elegir la FPGA. ¿Cuál
es el nivel de voltaje de IO y cuál es la velocidad de IO que deben tenerse en cuenta al
elegir la FPGA? Artix7 FPGA tiene 500 pines de E/S y el nivel de voltaje de E/S es de 1,2
a 3,3 V.
(5) También es necesario comprender los transceptores y otras interfaces. El FPGA Artix7 tiene
16 transceptores y tiene una velocidad de 6,6 Gb/s.
(6) Además de todo lo anterior, debemos pensar en las otras interfaces, como PCIe y la velocidad
de reloj máxima permitida para la FPGA. Obviamente, depende de la arquitectura FPGA y
la velocidad de las interfaces IO.
11.2 Creación de prototipos de SOC con un solo FPGA 185
11.2 Creación de prototipos de SOC con un solo FPGA
Imagine un escenario de diseño para crear un prototipo del diseño que se muestra en la figura 11.1.
A partir de la comprensión de la arquitectura y de la síntesis inicial, el equipo puede obtener información sobre los
requisitos de conteo de puertas. Por ejemplo, si el requisito de densidad lógica es de 200 000 compuertas y la familia
de FPGA tiene el mismo número de conteos de compuertas, siempre es una buena decisión elegir la FPGA de la
familia con un conteo de compuertas alto.
Los siguientes son algunos de los puntos importantes para elegir el FPGA, mientras que el prototipo para los diseños
de conteo moderado de puertas. La regla general durante el prototipo es que el diseño debe usar del 60 al 70 % de los
recursos de FPGA durante el prototipo.
Los siguientes son algunos de los puntos importantes para elegir el FPGA, durante el prototipo para los diseños de
conteo moderado de puertas.
1. Tener una mejor comprensión de la arquitectura: tratar de tener una mejor comprensión de la arquitectura y los
resultados de la síntesis inicial para encontrar la estimación de los recursos de FPGA necesarios. Considere el
pequeño bloque de densidad lógica del procesador. Si solo se requieren de 16 a 20 instrucciones para realizar las
operaciones aritméticas, lógicas, de transferencia de datos y de bifurcación, entonces se puede acomodar en una
pequeña parte de los FPGA. Si la estimación inicial del conteo de puertas es de 10,000 puertas, intente encontrar
el conteo de CLB mientras elige el FPGA.
interno
Memoria
Control &
Sincronización
Extensión BIST
Controladores interfaz
Fig. 11.1 SOC en un solo FPGA
2. Requisitos de memoria interna: intente encontrar el almacenamiento interno necesario para el
diseño. Si el requisito de memoria interna es de 64 Kbytes, intente encontrar las BRAM disponibles
en las hojas de datos de la arquitectura FPGA.
3. Funcionalidad DSP requerida: si se requiere la funcionalidad DSP, como filtrar, multiplicar y
acumular, entonces la cadena multiplicadora de gran densidad debe impulsarse utilizando los
bloques DSP. En tal escenario, intente identificar la complejidad de la funcionalidad DSP y luego
elija la FPGA adecuada que pueda admitir la implementación utilizando los bloques DSP.
4. Interfaces FPGA requeridas: durante el prototipo para lograr la velocidad objetivo, es esencial
utilizar las interfaces de alta velocidad. Por lo tanto, el equipo de prototipos debe identificar las
diferentes IO de acuerdo con los niveles de voltaje y la velocidad de transferencia de datos.
5. Requisito de E/S de alta velocidad: según el requisito de velocidad, intente apuntar al prototipo
utilizando las E/S de alta velocidad para la transferencia de datos entre la FPGA y otras placas.
6. Particionamiento y multiplexación de pines: para un mejor prototipo, divida el diseño en límites
secuenciales y use TDM y LVDS para la transferencia de datos en los límites de FPGA.
7. Soporte para IPs: Trate de entender si la arquitectura FPGA puede soportar los núcleos IP
configurables o duros. Dependiendo del requerimiento, elija la familia FPGA.
8. Gestión y prueba de la configuración: Trate de identificar si la familia FPGA tiene los bloques
dedicados para la gestión de la configuración y para la prueba.
11.3 ¿Cómo reducir el riesgo durante la creación de prototipos?
Reducir el riesgo durante el prototipo es el objetivo importante, y para ese propósito necesitamos
tener mejores estrategias durante la selección de la plataforma de creación de prototipos FPGA.
Podemos pensar en estrategias a nivel de arquitectura para estimar la densidad lógica e identificar las
interfaces e IP requeridas.
Pero es muy difícil o imposible durante la fase inicial estimar con precisión la densidad lógica
requerida para el diseño, e incluso es difícil predecir el número total de celdas lógicas para el diseño.
En este contexto, el mejor enfoque es realizar la síntesis al final de la fase de diseño de RTL y pasar
por el resumen de utilización de recursos. La regla general es que la utilización de recursos para el
diseño de SOC debe estar en el rango de 60 a 70 % de los recursos de FPGA para el diseño de FPGA
único. Si la utilización es superior al 70 %, es una mejor opción dividir el diseño en varias FPGA. Esa
llamada debe ser atendida por el equipo prototipo.
Para el enrutamiento, la lógica de depuración y para los requisitos de funcionalidad adicionales o
las mejoras de especificación, puede ser necesaria una lógica adicional. Por lo tanto, al crear
prototipos o elegir el FPGA, no consuma los recursos del 100 % del FPGA.
Si la utilización de recursos resulta en una utilización de más del 100 %, definitivamente el diseño
SOC no se puede mapear en el FPGA único y puede necesitar el
11.3 ¿Cómo reducir el riesgo durante la creación de prototipos? 187
múltiples FPGA. Aunque hay ajustes de arquitectura y RTL para reducir el área, es posible
que no se conviertan en el prototipo eficiente debido al alto requisito de celda lógica, el
enrutamiento y los grandes esfuerzos durante la síntesis. En lugar de eso, encuentre las LUT
disponibles en la FPGA y tome la relación de (LUT requeridas para el diseño del SOC/LUT
disponibles en la FPGA).
Esta relación es útil para concluir el número de FPGA. Pero en lugar de pensar en el uso
de 100% de recursos FPGA, es mejor pensar en un máximo de 60% de recursos FPGA. Si
soy el líder del equipo, entonces consideraré la utilización de recursos de FPGA en torno al
4050 %.
Entonces, el número de FPGAs = (LUTs requeridos para el diseño del SOC)/(LUTs
disponibles en el FPGA * 40%). Esto puede dar mayor libertad al equipo de arquitectura para
hacer frente a los cambios de arquitectura/diseño y agregar la lógica de prueba y depuración
para el diseño SOC.
Por ejemplo; Considere que el FPGA Virtex7 7VX200T tiene LUT = 1,221,600 y el diseño
necesita 2,100,000 LUT, entonces el número de FPGA requerido = (2,100,000)/(1,221,600 *
0.4) = 4.29 entonces podemos pensar en el diseño usando los cinco FPGA y para el prototipo
eficiente el diseño debe estar bien repartido!
11.4 Creación de prototipos usando múltiples FPGA
Considere el diseño SOC que tiene el procesador para la informática de uso general, el
controlador de memoria DDR3 y el codificador de video y el decodificador de IP. Si la necesidad
de diseño es de 200 000 compuertas lógicas, entonces el diseño no puede caber en el único
FPGA de Artix7. En tales circunstancias, necesitamos usar la partición del diseño para apuntar
al diseño usando múltiples FPGA. Para la mayoría de los SOC, debemos apuntar al prototipo
utilizando las múltiples arquitecturas FPGA. Los FPGA se pueden conectar utilizando una
topología de tipo anillo o estrella. La Figura 11.2 muestra la lógica en múltiples FPGA usando el cable
Fig. 11.2 Múltiples FPGA durante el prototipo SOC
conectividad.
Las siguientes son algunas de las recomendaciones importantes útiles durante el
Prototipo utilizando múltiples FPGA.
1. Comprender mejor el diseño: trate de comprender la funcionalidad analógica y digital del diseño y
divida el diseño en los dominios de diseño analógico y digital. Utilice las herramientas de partición
para obtener los mejores resultados. Las herramientas de partición automática se pueden utilizar
para tener una mejor partición del diseño a través de límites secuenciales.
2. Funcionalidad analógica e interfaces adicionales: como FPGA es bueno, se puede realizar el diseño
digital, pero prácticamente el diseño tiene bloques tanto analógicos como digitales. Por lo tanto,
intente elegir la interfaz FPGA de las placas hijas adicionales con el ADC y el DAC.
3. Uso eficiente de los recursos: trate de tener una estrategia mientras realiza el particionamiento para
permitir que la herramienta EDA tenga un máximo del 70% de los recursos de FPGA.
Esto permitirá que el equipo de prototipos agregue el BIST y la lógica de depuración durante la
fase de activación de la placa.
4. Requisito de IO y multiplexación de pines: la velocidad de IO es un factor importante que decide el
rendimiento general del prototipo. Hay estrategias de multiplexación adicionales que deben
implementarse para los múltiples diseños de FPGA.
5. Estrategias de sincronización: según los requisitos de la topología de estrella y anillo, es esencial
pensar en las estrategias de sincronización para los diseños de FPGA múltiples.
El sesgo del reloj y otros retrasos de la placa deben tenerse en cuenta durante la fase de
depuración y prueba.
6. Interfaces IO: a nivel de arquitectura SOC, la decisión debe tomarse sobre el requisito de
características del prototipo. ¡Siempre es una mejor opción considerar la velocidad de E/S, el
voltaje de E/S, el ancho de banda, el reloj y la red de restablecimiento, las interfaces externas al
diseñar el prototipo utilizando una o varias FPGA!
7. Requisitos de IP: los IP están disponibles en el siguiente formato, y el equipo de prototipos debe
utilizar los IP durante el ciclo de diseño en las diferentes etapas.
1. Código fuente RTL de IP: está disponible el código fuente abierto o la versión de licencia del
código fuente IP. El código fuente usando VHDL o Verilog está disponible.
2. IP suave: este tipo de núcleos de IP a veces son versiones encriptadas y necesitan
tener algún procesamiento durante el diseño y la reutilización.
3. IPs en forma de netlist: Están disponibles en forma de presintetizados
netlist de los componentes SOC o Synopsys GTECH.
4. IP física: también se denominan IP duras y están establecidas previamente por el
fundición.
5. Código fuente cifrado: el RTL está protegido con la clave cifrada y
debe descifrarse para obtener la fuente RTL.
8. Conectividad FPGA: el equipo de prototipos debe pensar en la conectividad de tipo anillo, estrella o
mixta para el prototipo que utiliza múltiples FPGA. Los siguientes son algunos de los aspectos
más destacados:
11.4 Creación de prototipos usando múltiples FPGA 189
a. Conectividad de tipo anillo entre FPGA: en este
tipo de disposición, las múltiples FPGA están conectadas para formar el anillo.
En tal tipo de conectividad, aumenta el retraso general de la ruta. A medida que la
señal pasa a través de la FPGA, la lógica del prototipo equivalente puede parecerse a la
lógica de prioridad. Este tipo de conectividad tiene una velocidad más lenta en
comparación con otros tipos de placas.
Si tratamos de visualizar las conexiones de tipo anillo, entonces en un nivel alto
podemos pensar en la conexión de pin usando este tipo de conectividad entre FPGA.
El desperdicio de IO no se puede limitar en este tipo de conectividad. Los FPGA están a
la baja; Los IO se desperdiciarán, y es una sobrecarga adicional para el diseñador de la
placa y el equipo de diseño de la placa para conectar estos IO a estados de alta
impedancia. b. Conectividad en estrella: este tipo de conectividad entre FPGA es más
rápida en comparación con la disposición en anillo debido a las conexiones directas con las
otras FPGA. Para un mejor rendimiento del prototipo, utilice las interconexiones de
alta velocidad entre las FPGA y configure los pines no utilizados como estado de alta
impedancia. C. Conectividad mixta: durante el diseño y el diseño de la placa, podemos
usar la combinación de conexiones de tipo anillo y conectividad en estrella. Este tipo de
conectividad puede tener un rendimiento moderado. Las placas disponibles en el mercado de
los proveedores tienen conectividad fija y pueden no ser adecuadas durante la
creación de prototipos, ya que no cumplen con las especificaciones y los requisitos. Bajo
tales circunstancias, dependiendo de la complejidad del diseño, es mejor elegir la
conectividad de la interfaz para un mejor rendimiento del prototipo.
11.5 Interconexiones diferidas
Es muy recomendable utilizar la interconexión diferida utilizando los cables en las múltiples
plataformas FPGA. Como las conexiones no son fijas, le da flexibilidad al equipo de prototipos
para usar los cables con las conexiones requeridas. La Figura 11.3 muestra una conectividad
FPGA múltiple utilizando los cables.
Como se muestra en la Fig. 11.3, la matriz de enrutamiento conmutado se puede utilizar para
establecer la conectividad entre las diferentes placas FPGA. El equipo de diseño y diseño de la
placa debe tener una mejor estrategia para proporcionar este tipo de conectividad para los diseños
de múltiples FPGA. El número de capas para las placas SOC complejas puede ser de un mínimo
de 40 a 50, y estas conexiones pueden dar libertad al equipo de prototipos debido a las
características programables.
Este tipo de conectividad utiliza los interruptores programables con la matriz de interruptores
para establecer las conexiones entre las FPGA. Así que en lugar de tener la estática
Fig. 11.3 Conexión diferida entre las FPGA
Conexiones, las conexiones de la placa se pueden programar y configurar. Este tipo de conectividad puede tratarse
como conectividad dinámica con reutilización.
Una de las principales ventajas de este tipo de conectividad es agregar circuitos de depuración y prueba cuando
sea necesario en el campo o fuera del campo debido a la disposición programable plugandplay.
Se debe tener cuidado de fijar las ubicaciones de los pasadores durante la división del diseño para
programar los interruptores, para lo cual se pueden utilizar las herramientas de porcionado EDA.
La velocidad es el aspecto importante para cualquier tipo de prototipo y, como se discutió, la velocidad del
prototipo depende de las impedancias de interconexión y las capacitancias parásitas. Los retrasos de interconexión
dependen de la longitud del cable y pueden ser propensos a cruces debido a las diferentes impedancias. Durante las
estimaciones de tiempo, se requiere considerar los retrasos entre los FPGA (retrasos a bordo) y los retrasos lógicos
(retrasos en el chip). En la terminología simple, podemos tratar los retrasos como retrasos fuera de FPGA y dentro
de FPGA. Para mejorar el rendimiento del prototipo, se recomienda utilizar señales diferenciales de alta velocidad
entre las FPGA (Fig. 11.4).
11.6 Tiempo de retraso a bordo [1]
Consideremos la interconexión directa entre dos FPGA. Necesitamos considerar los retrasos para averiguar la
transferencia de datos general entre los dos FPGA.
Como se discutió, podemos tener la conexión directa entre los FPGA y los siguientes son los principales
parámetros de retraso importantes que se pueden usar para encontrar la velocidad del diseño.
tpffl Reloj hasta q retraso del lanzamiento del flipflop
toutbuf El retardo del búfer de salida en la plataforma FPGA de lanzamiento
tinbuf El retraso del búfer de entrada en la captura del pad FPGA
tsu Tiempo de configuración del flipflop
11.6 Tiempo de retraso a bordo [1] 191
Fig. 11.4 Una conectividad FPGA múltiple utilizando matriz de conmutación
ton_board Retraso a bordo de las interconexiones entre las FPGA.
Por lo tanto, para obtener el tiempo de rendimiento deseado, es esencial cumplir con el tiempo de configuración
en el borde de captura. Entonces, el tiempo máximo de demora para alcanzar los datos en la entrada de datos del
FPGA#2 (Fig. 11.5).
tmax = tpffl + teuttbuf + ton_board + tinbuf
Por lo tanto, la frecuencia máxima se puede calcular utilizando
fmax = (1/tmax) = 1/ tpffl + toutbuf + ton_board + tinbuf
Si se utilizan conexiones de cable entre múltiples FPGA, al calcular la frecuencia
operativa máxima, considere el retardo máximo a bordo como una función de la longitud del
cable. El retardo de cable máximo entre los FPGA puede tratarse como un retardo integrado
(Fig. 11.6).
Fig. 11.5 Múltiples tiempos de diseño de FPGA
Fig. 11.6 Comunicaciones FPGA múltiples usando conectores de cable
fmax = (1/tmax) = 1/ tpffl + toutbuf + tcable + tinbut
Si los interruptores programables se usan para establecer la conectividad entre los
FPGA, entonces use el retardo de la matriz de interruptores (Fig. 11.7).
La frecuencia operativa máxima se puede calcular utilizando la siguiente fórmula
Fig. 11.7 Comunicaciones FPGA múltiples usando matriz de interruptores
11.6 Tiempo de retraso a bordo [1] 193
fmax = (1/tmax) = 1/ tpffl + touttouf + tswitch_matrix + tinbut
En tal tipo de conectividad, el retraso a bordo se indica mediante tswitch_matrix.
Para concluir, el ingeniero de prototipos debe ocuparse de los siguientes puntos importantes
durante la creación de prototipos SOC.
1. Estilo de codificación RTL y mapeo de diseño en FPGA individuales o múltiples 2.
Complejidad de buses e interconexiones 3. Uso de bloques de IP y su sincronización 4. %
de utilización general para cada dispositivo FPGA 5. Velocidad de E/S y ancho de banda
para la transferencia de datos entre los FPGA.
11.7 Estrategias y Directrices para el Prototipado Eficiente
Mejores estrategias durante la planificación del proyecto y durante el diseño y la síntesis de RTL
pueden dar como resultado un prototipo eficiente. En esta sección se analizan las estrategias y
directrices importantes durante la fase de diseño, implementación y creación de prototipos.
11.7.1 Directrices generales y planificación del proyecto [1]
¿Qué debo pensar sobre la plataforma de prototipado eficiente para validar el SOC?
¡Esta es la primera pregunta fundamental que necesita ser respondida! La respuesta es que la
plataforma debe tener la arquitectura eficiente y el mejor plan de prueba y depuración para lograr
el rendimiento deseado para el SOC. En el siguiente apartado se da información sobre el mismo:
1. Asignar las responsabilidades primarias y secundarias: es muy necesario asignar las
responsabilidades primarias y secundarias a los miembros del equipo que trabajan para el
prototipo. Siempre es recomendable tener la comunicación entre el equipo de diseño de RTL
y el equipo de prototipos SOC. Esto dará como resultado un mejor resultado, y ambos equipos
podrán comprender el riesgo durante el diseño y el prototipo.
2. Hitos comparativos: Es recomendable comparar el resultado del prototipo SOC con la referencia
dorada. Este método comparativo es útil para comprender la etapa del prototipo. Por ejemplo,
la convergencia funcional durante la verificación es del 97 % ya nivel de prototipo es de casi
el 80 %. Si se captura esta información, se pueden realizar mejoras en el entorno de diseño/
prueba y depuración existente para lograr una mayor cobertura también a nivel de placa.
3. Control de versiones: utilice el control de versiones para el software y la modificación de RTL,
ya que esta base de datos es útil durante el ciclo del prototipo SOC.
4. Lista de entregables e hitos: Crear la base de datos de los entregables o hitos del prototipo. Los
siguientes pueden ser entregables para el diseño del SOC:
• Especificaciones de requisitos del sistema •
Documento de riesgo y confiabilidad • Diseño
de referencia dorada funcional C/C++ • Arquitectura del
SOC • Microarquitectura para el SOC • Red de relojería
y distribución • Número de pines del SOC y su
funcionalidad • Versiones de diseño RTL • Verificación
RTL planes y versiones • Guiones de síntesis y temporización
del SOC con las restricciones de diseño • Informes de
temporización, área y potencia para los bloques funcionales
individuales • Restricciones de área, temporización y potencia de nivel superior,
y los informes • Restricciones de implementación y arquitecturas de FPGA de destino •
Múltiples FPGA diseño de placas y particiones • Planes de prueba y depuración • Diseño
independiente de la tecnología: Tiene una práctica para utilizar el diseño independiente de
la tecnología. Para conservar el RTL, utilice las directivas del compilador.
11.7.2 Planificación y estrategias de E/S para minimizar el recuento de pines [1]
11.7.2.1 Multiplexación de E/S
Para minimizar el número de pines, los pines IO se pueden multiplexar. La sección analiza las diferentes
técnicas de multiplexación de E/S utilizadas en el prototipo SOC.
Como se discutió anteriormente, la multiplexación IO se puede lograr usando el
1. Multiplexación de E/S basada en MUX
2. Multiplexación de E/S basada en SerDes
3. Multiplexación de E/S mediante el cambiador.
11.7.2.2 Multiplexación de E/S basada en MUX
En este tipo de técnica se utilizan multiplexores y demultiplexores. Considere el MUX n:1 que recibe las
señales de E/S dentro de la FPGA #1. El FPGA #1 opera en 'reloj de transferencia'. Los n IO están
multiplexados y para transferir datos utilizan el 'reloj de transferencia'. El FPGA #2 usa 'reloj de recepción'
para recibir o muestrear las señales de E/S, y se demultiplexan usando un demultiplexor 1:n (Fig. 11.8).
11.7 Estrategias y Directrices para el Prototipado Eficiente 195
Fig. 11.8 Multiplexación de E/S basada en MUX
Si n = 4, entonces 4 IO multiplexadas necesitan transferir la señal de IO a la velocidad de reloj
de n * 4. En*clk.
ntonces, el reloj
El reloj de tdransferencia
el sistema FyPGA#1 es 'clk',
recepción entonces
para el reloj de
la multiplexación transferencia
de E/S basada deebe
ser
n MUX
debe ser el mismo, es decir, deben tener la misma frecuencia de reloj.
11.7.2.3 Multiplexación de E/S mediante SerDes
Esta es una de las técnicas para multiplexar IO, y en esta técnica, SerDes y LVDS se utilizan para
transferir la señal de IO desde el FPGA de lanzamiento para capturar el FPGA.
La FPGA de lanzamiento puede transferir la señal diferencial usando el reloj de transferencia, y
esta señal es recibida por la FPGA de captura (Fig. 11.9).
Lanzar FPGA Capturar FPGA
OSERDES ISERDES
Extensión LVDS Extensión LVDS
Fig. 11.9 LVDS y IO SerDes para transferencia en serie
11.8 Planificación y restricciones de IO [1]
Para el prototipo eficiente, las tareas importantes son la planificación, documentación y restricción de
IO. La planificación de IO con Xilinx Vivado se describe a continuación.
Utilice el diseño de planificación de IO que se muestra en la figura 11.10 [2].
Para realizar la planificación de IO, utilice la siguiente vista auxiliar después de hacer clic en
Planificación de IO (Fig. 11.11).
En la vista auxiliar se muestra el paquete y después de la selección del dispositivo; limitaciones,
los puertos IO se muestran en el área de la consola. Con múltiples estándares de IO, las entradas y
salidas de diseño se enumeran en el área de la pestaña IO.
En el área de la pestaña IO, haga clic en el cuadro (+) para entradas (d_in) y salida (y_out)
( Figura 11.12).
Ahora, puede ver los estándares IO. Para d_in (de 6 a 0) e y_out (de 6 a 0), se usa el estándar de
E/S LVCMOS33, y para d_in (7) y y_out (7) se usa el estándar de E/S predeterminado LVCMOS18.
Dependiendo de los requisitos de IO, se puede elegir uno de los estándares de IO. Ahora, para cambiar
el estándar IO para y_out (7) a LVCMOS33, use lo siguiente (Fig. 11.13).
Mediante el uso de los comandos tcl, también se pueden asignar estándares IO. Utilice los
siguientes comandos:
set_property package_pin V5 [get_ports {y_out [7]}] set_property
iostandard LVCMOS33 [get_ports [lista {y_out [7]}]]
Incluso utilizando las propiedades del puerto IO, se pueden asignar los estándares IO. Después
asignación de estándares IO, guarde las restricciones en el archivo comb_design.xdc.
Pero para el diseño de SOC más grande, la planificación de E/S manual no es la opción correcta.
El error manual puede ocurrir al seleccionar los estándares IO y los dominios de voltaje
Fig. 11.10 Diseño de
planificación de E/S [2]
11.8 Planificación y restricciones de IO [1] 197
Fig. 11.11 Vista auxiliar de planificación de E/S [2]
Fig. 11.12 Estándares IO [2]
Fig. 11.13 Selección para E/S estándar [2]
y al asignar las restricciones. Por lo tanto, utilice el script para bloquear las ubicaciones de E/S para los
respectivos estándares de E/S y para restringir los retrasos de E/S.
Los siguientes son algunos puntos importantes para concluir el capítulo:
1. Use FPGA únicos o múltiples para tener un prototipo de SOC.
2. Use las pautas del prototipo mientras crea el prototipo del diseño.
3. Divida el diseño para lograr los mejores resultados de síntesis.
4. Utilice los ajustes de arquitectura y RTL mientras crea prototipos con FPGA.
5. Use conectividad en estrella, en anillo o mixta para los múltiples diseños de FPGA.
6. Utilice las herramientas de partición mientras realiza la partición del diseño.
7. Divida el diseño considerando los límites secuenciales.
8. Use los esquemas de multiplexación para IO para minimizar el número de pines.
Este capítulo nos ha permitido comprender la creación de prototipos utilizando FPGA simples y
múltiples. Hemos discutido sobre las estrategias, las pautas, los riesgos, la planificación de IO
y los esquemas de multiplexación. El siguiente capítulo se centra en el particionamiento y la
síntesis de FPGA. Incluso en el próximo capítulo, discutiremos los ajustes necesarios para
obtener el equivalente de FPGA para el diseño de ASIC.
Referencias 199
Referencias
2. www.xilinx.com
Capítulo 12
Síntesis e
implementación del diseño SOC
"Una mejor partición y síntesis del diseño para lograr la sincronización
deseada puede resultar en una implementación eficiente del diseño".
Resumen La mayoría de nosotros sabemos que la síntesis ASIC difiere de la síntesis FPGA en muchos
aspectos. Cuando finaliza la fase de diseño de RTL y los resultados iniciales de la síntesis de ASIC están
disponibles, comienza la fase de creación de prototipos de FPGA. El recuento de densidad lógica durante
la síntesis inicial se puede utilizar para crear prototipos de diseños de FPGA únicos o múltiples. En tales
escenarios, el capítulo analiza la síntesis y la implementación del diseño para la creación de prototipos de
SOC. El capítulo también analiza los escenarios para obtener el equivalente de FPGA para la funcionalidad
ASIC.
Palabras clave ASIC FPGA Síntesis Particionamiento Particionamiento manual _ _ _
Particionamiento automático ∙ Herramientas de particionamiento ∙ Síntesis incremental ∙ Estrategias
de compilación ∙ Conversiones de reloj cerradas ∙ Modelado de memoria ∙ Contenedor ∙ Equivalente
analógico
Como se indicó en los capítulos anteriores, el objetivo del equipo de creación de prototipos es lograr los
resultados funcionales y de temporización en poco tiempo utilizando diseños de FPGA simples o múltiples.
Ahora comprendamos cómo se puede cumplir este objetivo y cómo podemos obtener el prototipo eficiente.
Para lograr el objetivo deseado, el diseño debe dividirse y debe llevarse a cabo una síntesis para obtener
el diseño equivalente de FPGA.
Considere la funcionalidad de diseño que se muestra en la Fig. 12.1 y debe realizarse en el único
FPGA de gran densidad.
Considere el diseño de nivel superior que se muestra en la figura 12.1 y se lleva a cabo la síntesis
inicial. El diseño cumple con las restricciones, y apuntamos al diseño para tener un prototipo eficiente. En
este contexto, la siguiente sección analiza la partición del diseño y la síntesis para obtener el equivalente
de FPGA.
https://doi.org/10.1007/9789811513145_12
202 12 Síntesis e implementación del diseño SOC
interno
Memoria
Control &
Sincronización
Controladores
Extensión BIST
interfaz
Fig. 12.1 Diseño de nivel superior de SOC
12.1 Diseño de particiones y objetivos
La partición de diseño se puede lograr en el
• Nivel de arquitectura •
Nivel de síntesis • Nivel
de netlist.
Para lograr una mejor partición del diseño, necesitamos tener las siguientes estrategias.
1. Analizar la arquitectura y la microarquitectura: Durante la fase de diseño de RTL, la arquitectura y la
microarquitectura se utilizaron como documento de referencia. El documento tiene información sobre
los bloques funcionales, los requisitos de memoria, las interfaces y el tiempo. Por ejemplo, los clústeres
de particionamiento se pueden
la. Procesador, lógica DSP y memoria interna ii. E/S en serie
E/S en paralelo iii. Controlador de memoria e interfaces de
alta velocidad iv. Unidad de control y temporización v. Extensión
BIST.
Este tipo de partición a nivel de arquitectura es útil para tener la mejor
rendimiento debido a retrasos de interconexión más pequeños.
12.1 Diseño de particiones y objetivos 203
2. Defina los límites del hardware y el software: se deben definir qué bloques deben implementarse en
el hardware y cuáles deben implementarse en el software. Por ejemplo, la instalación y configuración
iniciales pueden ser controladas por el software; Se puede implementar un gran almacenamiento
de datos mediante software. Los bloques de DSP, audio, video y procesamiento se pueden
implementar usando hardware [1].
3. Utilice herramientas de partición: intente utilizar las herramientas de partición automática e intente
dividir el diseño a nivel de síntesis y netlist.
4. Equivalente de FPGA: intente estimar los recursos a nivel de síntesis mientras divide el diseño e
intente percibir las modificaciones necesarias para obtener el diseño equivalente de FPGA.
5. Enfoque de diseño modular: al particionar, use los rangos de límite secuencial y use el enfoque de
diseño modular. Los bloques de gran densidad deben descomponerse en diseños más pequeños
para obtener un mejor resultado de partición.
6. Comprender los múltiples dominios de reloj: use la partición separada para cada dominio de reloj.
Esto será útil para obtener el equivalente de FPGA para el grupo de reloj en particular, y la
implementación del diseño será fácil.
7. Esquemas de IO: Divida el diseño considerando los requisitos de diferentes esquemas de IO
ment y la información de conectividad externa.
12.2 Desafíos en la partición del diseño
El particionamiento lógico a nivel de arquitectura puede resultar en una síntesis ineficiente. Si la
estimación de recursos no se percibe a nivel de arquitectura, será difícil cumplir con las restricciones de
diseño. Bajo tal escenario, es mejor usar las herramientas de partición mientras se divide el diseño.
El principal desafío para el equipo de prototipos es cumplir con las restricciones de diseño, como
potencia, velocidad y área. Esto se puede lograr mediante la optimización de la síntesis para el área y
la velocidad.
La mayoría de las veces, es posible que hayamos observado cómo ajustar la arquitectura de diseño
para cumplir con las restricciones de diseño, ya que ayuda durante la fase de diseño de RTL. En tal
contexto, se desperdicia mucho tiempo y energía del equipo de diseño de RTL para percibir los cambios
de diseño si no se utilizan herramientas de partición.
¡División de diseño lógico para una mejor síntesis y optimización!
Las siguientes son algunas de las ideas para dividir el diseño para una mejor síntesis y optimización
del diseño.
Enfoque modular durante la partición: conserve la jerarquía del diseño y utilice el enfoque modular
al dividir el diseño. Esto permitirá que el equipo de diseño y verificación de RTL tenga rutas de tiempo
mejores y más limpias durante la síntesis lógica.
Tenga en cuenta la reutilización del diseño: si el diseño se divide conservando la jerarquía
del diseño, entonces el diseño se puede reutilizar para lograr los objetivos de síntesis.
Esto incluso mejorará el tiempo de diseño. Si consideramos la figura 12.1, entonces la partición del
diseño en múltiples grupos donde los bloques de procesamiento, control, prueba y E/S se pueden agrupar
en los diferentes grupos puede resultar en una mejor implementación. Durante el ciclo de diseño, si
deseamos reutilizar el bloque de procesamiento, es posible debido a una mejor partición. Es mejor
reutilizar el diseño para los elementos de procesamiento de gran densidad.
Las siguientes son algunas de las técnicas para la partición lógica del diseño.
1. Divida el diseño considerando los límites secuenciales. no dividir
el diseño a través de los límites combinacionales.
2. Divida el diseño para la reutilización del diseño, ya que ayuda al equipo de prototipos a obtener el
prototipo eficiente.
3. Divida el diseño que puede tener BIST y lógica de configuración separados.
4. Divida el diseño según los grupos de reloj y aísle el controlador de la máquina de estado y otra lógica
de control.
5. Use los bloques separados, como sincronizador, prueba y lógica de depuración, e implemente
luego en el nivel superior.
6. Tener una mejor comprensión de la arquitectura y la planificación inicial del piso antes
división del diseño.
Para la síntesis eficiente, el diseñador puede utilizar las siguientes pautas.
1. El diseño debe ser independiente de la tecnología [1]
El diseñador debe tener en cuenta que el RTL debe escribirse de tal manera que sea independiente de
la tecnología. Solo es posible cuando se minimizan las instancias de núcleo duro de las puertas de la
biblioteca. ¡Intenta entender la diferencia entre la instanciación y la inferencia! La preferencia durante el
diseño RTL se debe dar a la inferencia en lugar de la creación de instancias.
La principal ventaja de la inferencia de la lógica es que el diseño se puede implementar para
cualquier biblioteca ASIC y nodo de nueva tecnología a través de la resíntesis. Si se utilizan núcleos IP
sintetizables en el diseño, HDL independiente de la tecnología puede mejorar el resultado de la síntesis.
Administre la lógica instanciada según el uso de la biblioteca en módulos separados para que consuma
menos tiempo al migrar a otras bibliotecas de tecnología.
2. ¿Cómo puedo dividir la lógica relacionada con el reloj en el diseño? [1]
Use el diseño separado para la lógica de activación del reloj y la lógica de reinicio y debe configurarse
como no tocar. Esto ayudará en la sincronización limpia si usamos los diferentes grupos de relojes.
En un solo módulo, evite el uso de múltiples relojes ya que esto ayudará mientras escribe
las restricciones a nivel de bloque con referencia al reloj.
En los diseños de dominio de múltiples relojes, no es posible mantener las lógicas de múltiples relojes
en diferentes bloques. En tal escenario, realice la síntesis independiente de los sincronizadores y use el
atributo don't_touch al instanciar los sincronizadores en el bloque principal.
En los diseños jerárquicos, use el mismo nombre para el reloj en todo
la jerarquía, ya que ayuda durante la escritura del guión y durante la síntesis.
12.2 Desafíos en la partición del diseño 205
3. Particionamiento ¿Desafíos en los diseños de FPGA simples y múltiples? [1]
Ya sea que se trate de un diseño de FPGA único o de múltiples diseños de FPGA, la partición del
diseño tiene muchos desafíos y algunos de ellos se enumeran en esta sección.
1. Sincronización del diseño 2.
Identificación de los bloques de gran densidad
3. Identificación de los bloques funcionales altamente interdependientes
4. Agrupación de los bloques interdependientes 5. Identificación de los
bloques funcionales de hardware y software y su sincronización
ción
6. Interconectividad entre múltiples FPGA 7. Partición del
diseño con el objetivo de minimizar los problemas de interconexión 8. Problemas de integridad
de señal para múltiples FPGA 9. Dominios de voltaje de E/S y conectividad 10. Disponibilidad
de FPGA, recursos y limitación en el conteo de pines 11. Retraso de la red del reloj y distribución
uniforme del reloj.
4 ¿Qué estamos tratando de lograr exactamente con una mejor partición? [1]
1. Mejor mapeo de diseño en múltiples FPGA 2. Mejores
restricciones de IO a nivel de FPGA ya nivel de placa. Uso de estas restricciones
directamente por la herramienta de ubicación y enrutamiento
3. Replicación o duplicación lógica para los múltiples diseños de FPGA y uso eficiente de la
multiplexación IO 4. Mejor uso de la combinación de síntesis, partición y ubicación y
herramientas de enrutamiento para obtener el rendimiento deseado
5. Útil para identificar la topología correcta en la que los múltiples FPGA deben
estar conectado.
12.3 Cómo superar los desafíos de la partición [1]
Las diferentes técnicas a nivel de arquitectura y a nivel de netlist se pueden usar para dividir el diseño
para el mejor prototipo. La mejor partición se puede lograr utilizando la herramienta de partición. En
esta sección se analizan algunas de las técnicas de partición.
12.3.1 Nivel de arquitectura
Tener una mejor comprensión de la arquitectura del SOC, las especificaciones funcionales y los
recursos clave. Una mirada más cercana a la arquitectura y la microarquitectura puede brindar una
comprensión justa de la partición del diseño a nivel de hardware y software.
Por ejemplo, si estamos diseñando el SOC que consiste en un procesador de propósito general y un
procesador DSP con audio, video y otra lógica asociada, pensaré de la siguiente manera.
1. ¿Cuáles son las características del procesador y cuál es la estimación aproximada de la
¿recursos requeridos?
2. ¿Cuáles son las especificaciones funcionales del procesador DSP y los decodificadores de audio y video
utilizados en el diseño? ¿Cuántos recursos se requieren durante la implementación?
3. Otras lógicas asociadas, como controlador de memoria, lógica de bus serieparalelo,
capacidad y especificaciones de la memoria interna.
Entonces, al dividir el diseño, el grupo I puede ser el procesador, el controlador de memoria, los buses
y el almacenamiento interno y otro grupo puede ser el procesador DSP y los decodificadores de audio y
video. Esta puede ser una mejor manera al crear prototipos del SOC utilizando múltiples FPGA. Nuevamente,
la funcionalidad del grupo I y el grupo II debe dividirse en bloques más pequeños para tener un diseño
modular.
Si tratamos de hablar en el contexto de la creación de prototipos del SOC, entonces el diseño puede ser
dividido por identificación:
1. Bloques de diseño que deben ser validados utilizando los FPGA (para el FPGA
validación)
2. Diseñar bloques interconectados con la FPGA (fuera de la FPGA).
La partición del diseño para obtener el RTL compatible con FPGA se muestra en la Fig. 12.2.
El RTL compatible con FPGA se puede particionar utilizando el enfoque de arriba hacia abajo para
obtener el RTL requerido para los múltiples FPGA (Fig. 12.3).
12.3.2 Síntesis a nivel de Netlist [1]
Si el diseño no se divide en el nivel de arquitectura, entonces el diseño se puede dividir en el nivel de
síntesis. Pero este no es el mejor enfoque para el diseño complejo.
Para el diseño de recuento moderado de puertas, esto puede funcionar después de realizar la síntesis.
Durante la síntesis inicial, podemos comprender el área y los recursos necesarios para realizar el diseño.
Para tener la mejor creación de prototipos, usar la menor área o menos recursos de FPGA es uno de los
desafíos importantes. Bajo tales circunstancias, el diseño puede dividirse examinando los informes de área,
la confiabilidad funcional del bloque, la conectividad entre los diferentes bloques y el reloj, el análisis del
dominio de voltaje.
La mejor manera en este tipo de enfoque es usar el informe de área generado durante la síntesis para
encontrar los informes por bloques usando la herramienta de partición. La principal tarea importante debe
realizarse mediante la herramienta de partición para encontrar los IO para cada bloque y su conectividad
con otros bloques.
12.3 Cómo superar los desafíos de la partición [1] 207
Fig. 12.2 Diseño de particiones para obtener RTL compatible con FPGA
Fig. 12.3 Partición de arriba hacia abajo para múltiples FPGA
La herramienta como Synopsys Certify [1, 2] puede brindar información sobre los recursos y el
recuento de IO. Lo que hace la herramienta es que sobreestima los requisitos de recursos pero
proporciona un recuento correcto de IO [1, 2]. La mayoría de las veces, la sobreestimación de los
requisitos de recursos es una mejor manera de elegir múltiples FPGA, ya que durante la etapa posterior,
el equipo de prototipos estará al menos seguro de que se realizará el diseño (Fig. 12.4).
Fig. 12.4 Particionamiento a nivel de netlist
12.4 Necesidad de las herramientas EDA para la partición del diseño [1] 209
12.4 Necesidad de las herramientas EDA para la partición del diseño [1]
Como se discutió anteriormente, la complejidad del diseño del SOC es muy alta y para tener el
prototipo rentable, la opción puede ser el uso de placas de interfaz plugandplay con el FPGA.
Esto puede brindar una solución de prototipo rápida y eficiente si el tiempo en el nivel de la interfaz
coincide. Pero el problema serio en el diseño complejo se puede observar si el diseño no encaja
en el FPGA único. Bajo tales circunstancias, es esencial dividir el diseño en múltiples FPGA.
Los problemas serios de particionamiento pueden deberse a la densidad lógica, la velocidad,
los relojes múltiples en el diseño y los problemas de temporización/sincronización. Las diferentes
formas en el diseño se pueden dividir en múltiples FPGA, tal vez a nivel de arquitectura o a nivel
de lista de conexiones. La mejor visibilidad que podemos obtener si el diseño se divide en el nivel
de netlist porque tenemos la información sobre la estimación del área para el diseño de los
informes de área.
En el escenario actual, si consideramos los SOC de compuerta multimillonarios, entonces la
mitad o un tercio del diseño se puede instalar en el FPGA de mayor densidad. La principal
consideración al diseñar una plataforma de creación de prototipos es la equivalencia de la lógica
con FPGA. El FPGA puede no tener suficientes BRAM, bloque DSP para acomodar la lógica. Bajo
tales circunstancias, es esencial encontrar la cantidad de FPGA requeridas para la creación de
prototipos. El recuento de pines de ASIC siempre es mayor que el de FPGA, por lo que el mayor
cuello de botella es la disponibilidad y el tiempo de los pines. Otro punto importante a considerar
es ajustar el ASIC RTL al equivalente de FPGA. Por ejemplo, los relojes cerrados, la activación del
reloj y las memorias ASIC necesitan modificaciones.
La partición puede ser manual o automática, y los siguientes son algunos aspectos destacados
y consideraciones.
12.4.1 Particionamiento manual
La mayoría de las veces, intentamos particionar el diseño manualmente. Considere el diseño
anterior y su entorno y menos cambios para actualizar el diseño. En circunstancias como las que
se prueban con el diseño anterior, la partición manual puede ser rentable.
Como no hay inversiones adicionales en las herramientas de partición, el tiempo y el presupuesto
generales de dicha plataforma son menores en comparación con la partición automática. Los
siguientes son puntos importantes que deben tenerse en cuenta al particionar el diseño
manualmente:
1. Tener la comprensión de la arquitectura de diseño y la microarquitectura. mantener
los diseños críticos de sincronización están cerca uno del otro.
2. Tenga el plano de planta para comprender los datos, las rutas de control y otras interfaces
límites para el diseño.
3. Comprenda los recursos de FPGA con muchos más detalles y luego divida el diseño en múltiples
FPGA. Si los recursos de FPGA son limitados y el diseño
Fig. 12.5 Partición de diseño
se divide en múltiples FPGA, el prototipo no puede rendir al rendimiento deseado.
4. Si no está disponible la cantidad suficiente de IO, utilice multiplexación y tenga cuidado de que la lógica adicional
no se coloque en la salida de MUX.
5. Use los registros disponibles en el bloque IO para tener los límites secuenciales.
6. Use las conversiones de reloj controlado y las conversiones de memoria ASIC en el nivel RTL.
El enfoque de particionamiento manual es adecuado para los diseños de conteo de puertas moderado que
tienen una lógica de puerta de alrededor de 100K. Pero si el diseño tiene millones de compuertas lógicas y
múltiples dominios de reloj/energía, entonces hacer las cosas manualmente nunca es la solución rentable. La
planificación de planta manual para los diseños multimillonarios no es la buena solución, ya que siempre es
propensa a errores. No es posible mantener el registro de los ajustes y conversiones de RTL para la partición
manual (Fig. 12.5).
12.4.2 Particionamiento automático
La mayoría de los proveedores de herramientas EDA como Synopsys ofrecen herramientas de partición
automática, y las siguientes deberían ser algunas de las características utilizadas para la partición automática del
diseño.
1. La herramienta de partición debe ser compatible con los comandos TCL. Si es compatible con los comandos
Synopsys Design Compiler (SDC), se pueden usar las secuencias de comandos/restricciones ASIC.
2. Debe poder definir los puntos de sondeo para la verificación del diseño. ¡Debería permitir la integración con las
herramientas de depuración como Xilinx ChipScope Pro, Intel FPGA Signal Tap y Synopsys Identity [1]!
3. La herramienta de partición debe ser compatible con la placa de creación de prototipos de FPGA y el entorno.
mente
12.4 Necesidad de las herramientas EDA para la partición del diseño [1] 211
4. La herramienta debe poder optimizarse para las restricciones de área de acuerdo con los
requisitos.
5. La herramienta debe poder comprender los requisitos de los pines y debe optimizar
el número de pines.
6. Debería poder adaptarse a los pequeños cambios de diseño en el nivel de netlist.
7. Debe ser capaz de adaptarse a la gran cantidad de cambios de diseño en el
nivel RTL.
8. Debe proporcionar la estimación de recursos rápidamente para el FPGA de destino para
garantizar que el diseño se ajuste al FPGA.
9. Debe identificar las líneas de reloj y E/S de alta velocidad y utilizarlas para mejorar
la temporización.
10. Debe permitir la asignación de la lógica a cada FPGA. El límite máximo para la mejor creación
de prototipos puede ser del 60 al 70% de los recursos FPGA disponibles.
11. Debe dar la señal para rastrear el informe de asignación para el análisis detallado de la
creación de prototipos.
Todavía existen limitaciones para identificar la IP de caja negra y la inferencia BRAM y DSP.
Entonces, la mayoría de las veces, observamos el uso combinado de la partición manual y
automática.
12.5 Síntesis para el mejor resultado del prototipo [1]
Como los diseños de SOC son más rápidos que el FPGA y la densidad lógica es mayor, la
partición del diseño para el SOC de un millón de puertas es la tarea más importante. El diseño se
puede dividir antes de la síntesis o después de la síntesis. El equipo de prototipos debe elegir el
enfoque correcto para dividir el diseño.
La verdad es que es posible que el diseño no se ejecute a la velocidad del SOC y es esencial
modificar el diseño del SOC en recursos equivalentes a FPGA. Por lo tanto, durante la síntesis,
es esencial tener claridad sobre la arquitectura o el plano de planta inicial, las restricciones y los
recursos de FPGA. El flujo de creación de prototipos debería lograr un mejor rendimiento en
comparación con la emulación SOC, y ese es el objetivo principal durante la síntesis. Hay múltiples
formas en que se puede realizar la síntesis para lograr mejores resultados. Los siguientes son
algunos de los enfoques utilizados durante la síntesis.
12.5.1 Síntesis rápida para la estimación inicial de recursos
Si elegimos la síntesis rápida, puede ser útil para comprender la utilización inicial o aproximada
del dispositivo y el rendimiento en la etapa inicial. Pero en este tipo de síntesis, la herramienta de
síntesis ignora la optimización completa. La razón es que el tiempo de ejecución es casi dos o
tres veces. Pero esto puede ser útil para ahorrar el tiempo de la semana/día para los diseños
complejos y para la partición del diseño inicial.
12.5.2 Síntesis incremental
La síntesis incremental es el mejor enfoque para los diseños complejos de SOC.
Los esfuerzos incrementales de las herramientas P y R se pueden usar de manera eficiente mientras se
sintetizan los diseños de mayor densidad. Los subbloques o árboles de diseño del SOC se pueden sintetizar
por separado según los cambios de versión.
Por ejemplo, considere el diseño SOC que tiene 100 subbloques y los cambios RTL se incorporan en
solo 10 subbloques; luego, durante la síntesis de incrementos, la herramienta puede sintetizar el RTL para
los 10 subbloques. Esto reduce los esfuerzos generales y el tiempo durante la fase de síntesis.
Es decir, si la arquitectura del subbloque o del árbol no se modifica, la herramienta de síntesis lo ignora
y conserva la versión anterior. Esto reduce el tiempo de semana/día para la síntesis compleja de SOC.
La belleza de la herramienta EDA como Synopsys Certify [1] o las herramientas Xilinx P y R [3] es que
conservan la jerarquía, la lógica de la versión anterior, la ubicación, las restricciones, el mapeo como durante
la resíntesis y si el RTL no es modificado. Reduce el tiempo de respuesta.
Si se modifica una pequeña parte del diseño, entonces, debido a la síntesis incremental, el
el tiempo de ejecución del diseño se reduce y las herramientas P y R pueden utilizar los resultados de la síntesis.
El equipo del prototipo debe ser capaz de utilizar las características de las herramientas de síntesis y P
y R. El uso combinado de estas características puede reducir la cantidad significativa de tiempo durante la
creación de prototipos. El punto más importante es que el tiempo de ejecución P y el tiempo de ejecución R
siempre son mayores que el tiempo de ejecución de síntesis para los diseños complejos. Entonces, la
estrategia debe ser usar las herramientas de síntesis y P y R usando el flujo incremental (Fig. 12.6).
El flujo de backend de la herramienta Xilinx EDA se muestra en la Fig. 12.7 [3].
12.6 Restricciones y síntesis para diseños de FPGA [1]
Esta sección analiza el uso de la herramienta Synopsys DC para la síntesis de FPGA. Los comandos de
síntesis de FPGA se enumeran en la siguiente tabla.
set_port_is_pad <port_list> <design_list> El comando es útil para colocar atributos en la lista de
puertos especificados en command. El atributo
permite a DC mapear pads IO
set_pad_type <tipo de pad> <port_list> El comando se utiliza para elegir el tipo de los pads a los
que se va a asignar el diseño
insertar_pad El comando se usa para insertar los pads.
reemplazar_fpga El comando se usa para convertir la base de datos
FPGA sintetizable al esquema. En lugar de visualizar,
el esquema tiene CLB, IOB y puertas
12.6 Restricciones y síntesis para diseños de FPGA [1] 213
Fig. 12.6 Síntesis e
implementación del diseño
HDL o
generador de núcleo
Diseño de síntesis
Definir partición
Implementar Diseño
Se pueden seguir los siguientes pasos para la síntesis de FPGA usando Synopsys DC
1. Lea el archivo de diseño Verilog/VHDL.
2. Establezca las restricciones de diseño.
3. Inserte las almohadillas.
4.Realizar la síntesis del diseño.
5. Ejecute el comando replace_fpga.
6. Escriba la base de datos.
El script de muestra para la síntesis de FPGA de top_processor_core se muestra a continuación.
dc_shell > read –format verilog top_processor_core.vhd dc_shell > create_clock
clock –name clk –period 10 dc_shell > set_input_delay 2 –max – < liste todos
los puertos de entrada usando el mismo comando y el atributo de retardo requerido> dc_shell >
set_port_is_pad
Fig. 12.7 Flujo de herramientas de
backend de Xilinx [3]
dc_shell> insert_pad
dc_shell> compilar –map_effort high dc_shell>
report_timing dc_shell> report_area dc_shell>
report_cell
El informe de temporización consiste en la información de la ruta de temporización y los datos requeridos
hora, fecha hora de llegada, holgura.
El informe del área da la lista de lo siguiente:
Número de puertos
Número de celdas
Número de redes
Número de referencias Área
combinacional Área no
combinacional Área neta de
interconexión Área total de
celdas Área total.
12.6 Restricciones y síntesis para diseños de FPGA [1] 215
Para obtener la información sobre los recursos de la FPGA, se puede utilizar el siguiente comando:
dc_shell > informe_fpga –one_level
Proporciona la siguiente información sobre el uso de los recursos FPGA.
Generadores de funciones:
Número de CLB
Número de puertos
Número de pads de reloj
Número de IOB
Número de chanclas
Número de buffers triestado
Número total de celdas
Para escribir la lista de conexiones en formato de base de datos, use el comando
dc_shell > formato de escritura db jerarquía salida top_procesor_core.db
La base de datos sintetizable (netlist) y la información de tiempo pueden ser utilizadas por la herramienta
de lugar y ruta. En esta sección se analizan algunos de los escenarios y ajustes importantes.
1. Instanciación de reloj cerrado: la estructura de reloj cerrado para el SOC puede no coincidir con la estructura
equivalente de FPGA y, por lo tanto, es esencial modificar el RTL para inferir la estructura de reloj cerrado
(Figs. 12.8 y 12.9).
2. IPs SOC: En la mayoría de las IPs, el RTL no está disponible, por lo que es imprescindible
tener el equivalente FPGA de tales IPs.
Fig. 12.8 Reloj cerrado utilizado para el diseño
Fig. 12.9 Activación de reloj equivalente de FPGA
3. Memorias ASIC/SOC: La estructura de memoria para ASIC o SOC no es idéntica a las
memorias FPGA y, por lo tanto, requiere la modificación durante la etapa de prototipo.
4. Pads de nivel superior: como la herramienta FPGA no comprende la creación de instancias del
pad, es esencial modificarlos durante el prototipo. No maneja el pad IO en el RTL e infiere el
pad FPGA. Por lo tanto, debe dejar las almohadillas con conexiones colgantes e inactivas en
el límite de nivel superior. Para el prototipo, reemplace cada instancia de IO pad con un
modelo sintetizable del equivalente de FPGA.
El modelo debe tener las conexiones lógicas en el nivel RTL, y eso se puede hacer
escribiendo un pequeño fragmento de código en RTL. Para el prototipo eficiente, prepare la
biblioteca de almohadillas SOC. La celda FPGA IO básica se muestra en la figura 12.10.
5. IPs en los formularios netlist: El formulario netlist puede no ser el equivalente de FPGA y
por lo tanto, necesita modificaciones durante la creación de prototipos.
6. Células de hoja: Es posible que la FPGA no entienda las células de hoja de la biblioteca ASIC
y, por lo tanto, necesita modificaciones.
7. Circuito de prueba: la autoprueba integrada (BIST) y otras pruebas o circuitos de depuración
deben tener el equivalente de FPGA y, por lo tanto, necesitan la modificación.
8. Entradas no utilizadas: para los pines de entrada no utilizados, es esencial ajustar el RTL.
9. Relojes generados: durante la creación de prototipos para lograr un mejor rendimiento, los
relojes generados deben ser modificados por su equivalente FPGA.
tri
I/P
regla
registro
controlar
O/P ALMOHADILLA
registro
Fig. 12.10 Celda de E/S básica de FPGA
12.7 Síntesis de IO Pad para FPGA 217
12.7 Síntesis de IO Pad para FPGA
Como las herramientas FPGA no comprenden la instanciación de los pads, es fundamental modificarlos
durante la fase de prototipo. No maneja el pad IO en el RTL e infiere el pad FPGA. Por lo tanto, debe
dejar las almohadillas con conexiones colgantes e inactivas en el límite de nivel superior. Para el
prototipo, reemplace cada instancia de almohadilla IO con un modelo sintetizable del equivalente de
FPGA.
El modelo debe tener las conexiones lógicas en el nivel RTL, y eso se puede hacer escribiendo un
pequeño fragmento de código en RTL. Para el prototipo eficiente, prepare la biblioteca de almohadillas
SOC. La celda IO básica para la FPGA se muestra en la figura 12.10.
Use los siguientes comandos usando Synopsys DC. Para obtener más información sobre la síntesis
de FPGA, consulte la Secc. 12.6 [2]
dc_shell > set_port_is_pad
dc_shell > insert_pad dc_shell >
compile –map_effort alto
12.8 Qué cuidados debo tener durante la síntesis
y prototipos?
12.8.1 Evite el uso de pestillos
Aunque el diseño basado en pestillo es mejor para ahorrar energía, es recomendable utilizar un diseño
basado en flip flop. El diseño basado en flipflop puede garantizar rutas de tiempo limpias.
12.8.2 Evitar rutas combinadas más largas
Dado que dentro de la lógica combinacional de la FPGA se mapea utilizando las LUT, se recomienda
evitar las rutas combinatorias más largas. Aunque el retraso de LUT es uniforme, las rutas de
combinación más largas degradan el rendimiento del prototipo SOC. Es aconsejable dividir los caminos
combinados largos en caminos más cortos utilizando los registros segmentados. Aunque hay una
sobrecarga adicional en el área debido al uso de los registros canalizados, el diseño de la ruta más
corta se ubica, mapea y enruta mejor utilizando los recursos CLB adyacentes. El escenario práctico se
describe en el ejemplo.
Escenario práctico 1: El impacto de la salida registrada : Si la salida del
diseño no está registrada, entonces tiene un impacto en el otro módulo. En el diseño, la salida es
combinacional, y dada como entrada a otros módulos, aumentará el retraso combinacional en el
diseño. A medida que aumenta el retraso de la ruta de datos, afecta el tiempo y puede violar el
tiempo de configuración.
Para evitar esto, registre todas las entradas y salidas.
Síntesis de FPGA: en el diseño de FPGA, la ruta de registro a registro es
entre los flipflops CLB. Cada CLB tiene flipfops y LUT.
Síntesis ASIC: En el ASIC, se utilizan las celdas estándar y la ruta de registro a registro está
entre los flipflops. La biblioteca de celdas estándar tiene las puertas lógicas y los flipflops.
Considere el siguiente diseño donde la salida es de lógica combinacional que no está
registrada.
Si q1_out impulsa otros bloques de diseño, entonces, como se indicó anteriormente, aumenta
la demora en la ruta de datos. Consideremos el escenario de diseño que se muestra en la figura
anterior.
La salida del primer diseño es q1_out y se entrega a la entrada data_in del segundo diseño.
Esto reducirá la velocidad del diseño. La hora de llegada de los datos (AT)
= Tpdff + tcombo1 + tecombo2, y el tiempo requerido de datos (RT) = Tclktsu.
Entonces, para una holgura positiva, RT > = AT, y el período del reloj es Tclk = Tpdff + tcombo1
+ tecombo2 + tsu.
Si el retraso del flipflop (tpdff) = 1 ns, el retraso de la lógica combinada 1 (tcombo1) = 0,5 ns,
el retraso de la lógica combinada 2 (tcombo2) = 0,5 ns, el tiempo de configuración (tsu) = 0,5 ns
y el tiempo de espera (th) = 0,25 ns, entonces el período de tiempo del reloj (Tclk) = Tpdff +
tcombo1 +tcombo2 +tsu = 2,5 ns y la frecuencia operativa máxima es de 400 MHz.
Si se registran las entradas y salidas de todos los diseños, entonces el diseño tiene una ruta
de registro limpia y más corta. Incluso mejora el rendimiento del diseño.
El diseño mejorado se muestra a continuación y mejora la sincronización de la ruta de registro
a registro.
12.8 ¿Qué cuidados debo tener durante la síntesis y la creación de prototipos? 219
Escenario práctico 2: Entradas y salidas registradas: A medida que
se registran las entradas y salidas del diseño, tiene un impacto en el desempeño del diseño.
El retardo de la ruta de datos se mejora con esta técnica.
El período de tiempo del reloj (Tclk) es Tclk = Tpdff + tcombo1 + tsu para el primer diseño
y para el retraso del segundo diseño (Tclk) es Tclk = Tpdff + tcombo2 + tsu. Si el retraso del
flipflop (tpdff) = 1 ns, el retraso de la lógica combinada 1 (tcombo1) = 0,5 ns, el retraso de la
lógica combinada 2 (tcombo2) = 0,5 ns, el tiempo de configuración (tsu) = 0,5 ns y el tiempo
de espera (th) = 0,25 ns, entonces el período de tiempo del reloj (Tclk) = Tpdff + tcombo1
+tsu = 2,0 ns y la frecuencia operativa máxima es de 500 MHz.
Por lo tanto, el rendimiento del diseño ha mejorado. Anteriormente, sin las entradas
registradas y la salida registrada, la frecuencia era de 400 MHz y con las entradas y salidas
registradas, la frecuencia era de 500 MHz.
12.8.3 Evite los bucles combinacionales
Para evitar el comportamiento oscilatorio, se recomienda evitar los bucles combinacionales.
El comportamiento oscilatorio es impredecible y puede deberse a señales faltantes en la lista de
sensibilidad, declaraciones de casos incompletas, declaraciones if anidadas incompletas .
12.8.4 Usar envoltorios
La mayoría de los proveedores de FPGA admiten la descripción RTL en la forma lógica genérica o
en la forma del componente Synopsys Design Ware. Así que no utilice las células dependientes de
la tecnología. A nivel de hoja, presenta los detalles específicos de la tecnología.
Es obligatorio tener cuidado de que los cambios de fuente tengan el menor impacto en el diseño.
Para ello, utilice los envoltorios y realice cambios dentro de los elementos de diseño.
Si la arquitectura SOC usa RAM, realice cambios dentro de los elementos de la biblioteca en lugar
de en el RTL. Esto mejora la portabilidad general del diseño.
12.8.5 Modelado de memoria
Si consideramos el diseño SOC, entonces la memoria es específica de la tecnología y puede no ser
equivalente a FPGA. En tales circunstancias, utilice las versiones de memoria compatibles con FPGA
durante el prototipo. Como se indicó anteriormente, use los envoltorios alrededor de los elementos
dependientes de la tecnología en el diseño. Esto debe hacerse para las macros, RAM en la biblioteca de
tecnología.
12.8.6 Uso de generadores centrales
Utilice los generadores de núcleo de Xilinx y especifique la tecnología de destino, el tipo de núcleo y la
secuencia de inicialización. La herramienta FPGA se utiliza para generar la lista de conexiones y los archivos
de inicialización. Las herramientas de ubicación y ruta utilizan la lista de conexiones para realizar la ubicación
del bloque funcional en la estructura FPGA. La inicialización se puede lograr mediante los archivos de plantilla.
Cree una instancia de los archivos de plantilla en el diseño. La mayoría de las veces, observamos que el
archivo contenedor generado por la herramienta consta de los datos de estímulo funcional y se puede utilizar
para la simulación funcional del diseño.
12.8.7 Verificación Formal
La gran pregunta que debe abordarse es cómo puedo verificar la funcionalidad de FPGA y SOC RAM.
¿Tienen el mismo comportamiento o no? La respuesta es simple; se puede hacer mediante el uso de
verificación formal (FV) durante la etapa inicial de creación de prototipos. ¡Esto puede verificar la verificación
de equivalencia para FPGA y SOC RAM!
12.8.8 Bloques que no se mapean en la FPGA
Es posible que los bloques analógicos y las direcciones IP no se mapeen directamente en la FPGA, ya que
el código RTL o la lista de conexiones de estos bloques no están disponibles. En tal circunstancia, utilice las
placas de evaluación proporcionadas por el proveedor de IP o diseñe el FPGA funcional equivalente para
los IP y conéctelos con el FPGA.
12.8 ¿Qué cuidados debo tener durante la síntesis y la creación de prototipos? 221
12.8.9 Mejor diseño de arquitectura
Siempre es un mejor enfoque tener la arquitectura eficiente y la microarquitectura para los diseños de SOC
y FPGA. El documento de arquitectura puede tener información adicional sobre los ajustes o la modificación
necesarios para el prototipo de FPGA.
12.8.10 Usar lógica de reloj en el NIVEL SUPERIOR
Para una buena portabilidad y modularidad, mantenga la distribución del reloj o la lógica de generación en
el nivel más alto.
12.8.11 Enfoque de abajo hacia arriba
Utilice el enfoque de abajo hacia arriba para el diseño, y esto puede ser bueno para generar las restricciones
a nivel de bloque y chip. El equipo puede pensar en mantener los módulos de alto nivel libres del uso de
parámetros y genéricos.
Los siguientes son algunos de los puntos importantes para concluir el capítulo:
1. El diseño debe estar bien dividido considerando los límites secuenciales.
2. El diseño se puede dividir a nivel de arquitectura, síntesis y netlist.
3. Use la optimización del diseño y las restricciones de IO mientras realiza la temporización
análisis.
4. Es posible que la partición lógica no proporcione el resultado óptimo. Por lo tanto, use las herramientas
de creación de particiones de diseño mientras realiza la partición.
5. En los diseños de dominio de múltiples relojes, implemente los sincronizadores.
6. Use las conversiones de activación del reloj para obtener el equivalente de FPGA para el diseño.
7. Evite los bucles combinacionales en el diseño, ya que da como resultado la oscilación
conducta. Utilice la entrada registrada y la salida registrada.
8. Use solo el 6070% de los recursos de FPGA para lograr un mejor rendimiento para el
prototipo.
Este capítulo nos ha permitido comprender la síntesis del SOC y la implementación
del diseño. Incluso hemos discutido sobre la partición de diseño y las diferentes
formas de lograr la partición de diseño. El siguiente capítulo se centra en las
técnicas de prueba y depuración utilizadas durante la fase de prototipo del SOC,
las herramientas y el equipo de EDA disponibles durante la fase de prueba.
Referencia
1. www.springer.com: “Síntesis avanzada de HDL y creación de prototipos SOC: Vaibbhav
Taraate”. 2. https://www.synopsys.com/ 3. https://www.xilinx.com
Capítulo 13
Escenarios de prueba y depuración de SOC
"Un mejor plan de prueba y depuración de SOC puede dar como resultado un
prototipo eficiente para una respuesta rápida de la idea del producto".
Resumen El capítulo analiza la depuración, los desafíos de prueba y las características importantes de
las placas de creación de prototipos SOC. La fase de prueba del prototipo es un hito importante y final,
y durante esto, tratamos de capturar los resultados. El rendimiento del prototipo depende del plan de
partición, prueba y verificación. En tal escenario, el capítulo analiza los escenarios importantes de prueba
y depuración. En este capítulo también se analiza cómo usar algunos de los equipos de prueba, los
núcleos ILA y el analizador lógico.
Palabras clave FPGA Prueba Depuración ILA Particionamiento Reloj Restablecimiento Analizador
lógico Síntesis Prototipo _ _ _ _ _ _ _ _
Como se discutió en los capítulos anteriores, los diseños SOC de un millón de puertas se pueden crear
prototipos utilizando el FPGA. El verdadero desafío para lograr el rendimiento deseado en este tipo de
diseño se debe a la arquitectura de múltiples FPGA, la partición del diseño y la conectividad entre ellos.
El capítulo trata sobre el riesgo, los desafíos y cómo elegir el FPGA objetivo para tener el mejor prototipo
de SOC.
13.1 Diseño y consideraciones del SOC
En los últimos años, mientras trabajaba en el campo de los diseños de FPGA, he observado la mayoría
de las veces que el diseño complejo no encaja en el FPGA único. Durante las discusiones del equipo,
los aspectos importantes como diseñadores que pensamos que nos permiten modificar la arquitectura
para descubrir si hay espacio para que los recursos se adapten al diseño utilizando el FPGA único.
Era un pensamiento lógico, así como el pensamiento de evitar el uso de múltiples FPGA.
El resultado de este tipo de discusión fue positivo, y con la arquitectura
10.1007/9789811513145_13
224 13 escenarios de prueba y depuración de SOC
ajustando y usando las directivas de la herramienta de síntesis para usar los recursos de FPGA de
manera eficiente, logramos mapear el diseño en un solo FPGA.
Al crear prototipos para los SOC complejos, ¿cuál debería ser nuestro enfoque? En los entornos
prácticos, cada organización tiene sus flujos estándar mientras crea prototipos de los SOC. ¿Pueden
el gerente y el líder del equipo pensar cuándo comenzar con la creación de prototipos? ¿En qué
pasantía? ¿Después de lograr las metas de cobertura deseadas a nivel de bloque? O espere para
completar la verificación funcional completa.
¡Todas estas preguntas pueden responderse si analizamos el flujo del prototipo! No podemos
tener la estimación real de los recursos de la FPGA al principio e incluso la lógica que se puede
mapear dentro de la FPGA o la lógica mapeada fuera de la FPGA. Como equipo, debemos centrarnos
en la corrección funcional del diseño desde el principio. Entonces, como líder del equipo, debería
pensar en el inicio de la fase de creación de prototipos después de pasar todas las pruebas básicas
a nivel de cordura. Al menos los miembros del equipo estarán seguros de que los datos pasan de un
bloque funcional a otro bloque funcional, e incluso ellos estarán seguros de la corrección funcional
básica del diseño.
Si intentamos usar el modelo en cascada, es decir, la primera fase de diseño RTL, la segunda
fase de verificación RTL usando HDL y luego la fase final como prototipo y prueba, entonces esto
puede retrasar el proyecto unas pocas semanas o meses. En lugar de un inicio secuencial para la
fase de diseño, verificación y preparación de la junta de RTL, los equipos pueden trabajar
simultáneamente para lograr los hitos deseados de la mejor manera.
¿Cuáles son los ajustes importantes durante el prototipo usando FPGA?
El punto importante a considerar es que ¿qué pasa con los anillos de almohadilla IO? ¿Qué pasa con
las grandes memorias externas? ¿Qué pasa con los bloques analógicos? Efectivamente, ¡no
podremos mapear las grandes memorias externas, los bloques analógicos y los anillos de pad IO
dentro de la FPGA!
A nivel de arquitectura, se debe decidir qué funcionalidad se debe probar con la FPGA y qué tipo
de placas de creación de prototipos se requieren para probar o emular el SOC general.
Así que permítanme poner esto en el escenario real de crear prototipos de los SOC con bloques
analógicos y núcleos IP duros. En la práctica, no es posible tener la lista de conexiones de FPGA
para bloques analógicos ni para bloques de IP duros. En la realidad absoluta, las casas de diseño de
IP proporcionan las placas de evaluación y el equipo de prototipos necesita crear la plataforma de
prototipos SOC con una o varias FPGA interconectadas con dicho tipo de placa de evaluación para
lograr el rendimiento y la funcionalidad deseados. Discutamos los aspectos importantes de este tipo
de diseños.
1. Señales de interfaz: la FPGA y la placa de evaluación deben tener interfaces compatibles. Si los
IO no son compatibles, habrá problemas con la integridad de la señal.
2. Conectividad entre FPGA y placa de evaluación: RTL debe proporcionar la conectividad entre la
funcionalidad de diseño realizada en la placa FPGA y la placa de evaluación externa.
3. Temporización: es uno de los aspectos importantes debido a los retrasos en la interfaz entre la
FPGA y la placa IP externa. Por lo tanto, debe tener un análisis de recursos de reloj con el
tiempo entre retrasos.
13.1 Diseño y consideraciones del SOC 225
4. Sincronización: Arrancar el hardware externo puede tomar menos tiempo en comparación con la
lógica FPGA, por lo que durante el prototipo, se debe tener cuidado de que el flujo de bits de
la FPGA se cargue primero dentro de la FPGA. De nuevo, es necesario analizar las duraciones
de los pulsos de reinicio o eliminación de reinicio síncrono y asíncrono.
5. Fuente de alimentación: debe tener aislamiento de tierra digital y analógico y múltiples niveles
de voltaje según los requisitos. Incluso se debe tener cuidado de que la FPGA y la conectividad
de la placa externa mantengan el voltaje y los niveles lógicos deseados.
6. Montaje mecánico: se debe tener cuidado de tener un montaje mecánico bueno y duradero para
que durante las diferentes ubicaciones geográficas/durante el tránsito, la placa no se dañe.
13.2 Desafíos de creación de prototipos y cómo superarlos
¿Cómo puedo encontrar el rendimiento del prototipo?
Imaginemos el diseño complejo de SOC, y para el prototipo eficiente, necesitamos tener la
estimación de los recursos de FPGA. Cómo puedo encontrar la estimación correcta es uno de los
desafíos. ¿Hay alguna manera eficiente de obtener estimaciones y requisitos de FPGA precisos?
La respuesta de alto nivel es un gran 'no'; como se dijo anteriormente, la estimación de los recursos
necesarios puede no ser suficiente para elegir la FPGA. La razón es que debemos pensar en el
rendimiento deseado de la FPGA. Discutamos los parámetros clave que deben pensarse para
cumplir con los requisitos de rendimiento.
Recuerde que la estimación de los recursos de diseño mediante la herramienta de síntesis
puede brindarnos información sobre la cifra aproximada. Esta técnica puede dar información del
rendimiento para el diseño a un alto nivel. La captura de rendimiento con la herramienta de síntesis
no tiene demoras de enrutamiento, pero con la herramienta de ubicación y enrutamiento, se puede
evaluar el rendimiento de tiempo. El parámetro del que depende el rendimiento de la FPGA son las
restricciones. Las restricciones son utilizadas por la herramienta de síntesis, lugar y ruta para
cumplir con el rendimiento deseado.
Si tengo un diseño de FPGA múltiple, los siguientes parámetros clave afectan el
desempeño del diseño:
1. Arquitectura segmentada: el diseño sin segmentación se ejecuta con menos velocidad en
comparación con el diseño que utiliza la arquitectura segmentada. Por lo tanto, se debe tener
cuidado de tener múltiples controladores de etapa canalizados para el diseño.
2. Utilización del dispositivo FPGA: si la utilización de FPGA cruza casi alrededor del 60%, entonces
el rendimiento del diseño se ralentiza. La razón es la congestión en la ubicación y el
enrutamiento. Incluso ese tipo de diseño tiene altos retrasos de interconexión y, por lo tanto,
una velocidad más lenta. Consulte el cap. 11 para obtener información sobre los retrasos y
tiempos de interconexión.
3. Fanout y carga: el diseño que tiene un alto fanout funciona más lento en comparación con
el diseño que tiene baja fanout.
4. Herramienta de síntesis y entorno: El uso de la herramienta de síntesis para optimizar el diseño
es uno de los factores responsables de la velocidad del diseño.
5. Conectividad entre FPGA: El principal factor importante para limitar la velocidad general del
prototipo en el sistema de múltiples FPGA son los retrasos de interconexión y la conectividad.
Esto se debe a la conectividad entre FPGA y la velocidad de E/S. Como la mayoría de nosotros
sabemos, la velocidad de E/S es mucho más baja en comparación con la velocidad de la lógica
en la estructura FPGA.
6. Funciones de multiplexación: la multiplexación de pines es uno de los principales factores que
limitan la velocidad del prototipo. Considere el ejemplo práctico del uso del IO multiplexado, y
si la lógica multiplexada de n bits se ejecuta a la frecuencia operativa de 25 MHz, entonces
para muestrear las señales de n bits, la entrada multiplexada debe ejecutarse en n tiempos de
25 MHz.
7. Retrasos: los retrasos de propagación en la placa y la velocidad de datos de las señales
individuales son otros factores responsables de limitar el rendimiento de la FPGA.
13.3 Arquitectura FPGA múltiple y factores limitantes
Como se indicó anteriormente, si el diseño no encaja en el FPGA único, entonces debemos usar
los FPGA múltiples para crear un prototipo del SOC. Pensemos que, ¿hay algún límite para el uso
de múltiples FPGAs? En teoría, puedo documentar el diseño a nivel de arquitectura usando muchos
FPGA, pero el prototipo eficiente es tal que el SOC se puede validar usando el número mínimo de
FPGA y las siguientes son las razones:
Interconectividad entre múltiples FPGA: en la arquitectura de múltiples FPGA, la interconectividad
depende del uso de la cantidad de FPGA. A medida que crece la cantidad de FPGA en el sistema,
surgen problemas como la integridad de la señal y grandes retrasos en la interconexión. El sistema
puede volverse lento y no producir el rendimiento deseado. En tales circunstancias, se recomienda
usar menos FPGA ajustando la arquitectura. Para superar el problema de conectividad entre FPGA,
use la multiplexación por división de tiempo para los IO que usan la frecuencia de reloj más alta.
En este tipo de técnicas, el riesgo es la velocidad del reloj, ya que las E/S multiplexadas deben
ejecutarse a una velocidad de reloj más alta en comparación con la lógica de la estructura FPGA.
Partición de diseño: la partición de diseño manual es uno de los cuellos de botella más importantes
en el sistema multiFPGA, ya que el diseñador debe pensar en las listas de conexiones para las
múltiples FPGA y su conectividad. Como la partición del diseño usando las herramientas es una
tarea compleja y la partición del diseño manual no es la solución factible en el diseño del sistema
multiFPGA, el equipo de prototipos puede pensar en la combinación de las técnicas de partición.
Propagación de señales y conectividad: En el sistema multiFPGA, otro tema importante es el
tiempo de establecimiento requerido para la señal debido a la conectividad entre FPGA. Los
retrasos de IO suman el efecto acumulativo y ralentizan el sistema.
13.3 Arquitectura FPGA múltiple y factores limitantes 227
Generación de reloj y distribución de reloj: para el sistema FPGA síncrono múltiple, el sesgo de reloj es uno
de los factores limitantes para lograr el rendimiento deseado.
Se convierte en una sobrecarga adicional para el diseñador administrar la distribución del reloj en el tablero
para equilibrar el sesgo de reloj.
Uso de múltiples licencias durante el prototipo: la mayoría de las veces observamos que para el diseño de
múltiples FPGA, la lista de conexiones para cada FPGA debe generarse simultáneamente.
Esto reduce el tiempo total requerido durante la creación de prototipos y mejora la productividad del equipo.
Pero esto aumenta el costo de las pruebas, la depuración y el prototipo, ya que se necesita emplear una mayor
cantidad de ingenieros de diseño para lograr lo mismo y se necesita una cantidad de licencias.
13.4 Presentación de la placa y qué probar?
¿Cuál debería ser la estrategia al probar el SOC de un millón de puertas? ¡Esta es la primera pregunta
importante que debe responderse! Como equipo prototipo, debe haber un plan de prueba y depuración. El
mejor plan de depuración para probar el diseño de FPGA único o el diseño de FPGA múltiple puede crear una
cantidad significativa de mejora en la productividad para el diseño de SOC. Los siguientes son algunos pasos
importantes que deben seguirse para los diseños de SOC más grandes.
1. Pruebe la placa en busca de lecturas y escrituras
básicas 2. Pruebe las placas complementarias y la
conectividad 3. Configure la FPGA única con el diseño más pequeño 4.
Configure varias FPGA con la partición del diseño 5. Comprenda los
problemas de implementación 6. Utilice el diseño real Diseño de SOC y casos
de prueba 7. Verificar los problemas y solucionarlos 8. Documentar los
resultados.
13.5 Planes de depuración y listas de verificación
El plan de actualización y depuración de la placa debe documentarse de manera eficiente durante la
planificación del diseño y la fase de arquitectura. No es posible que el diseño descargado en el FPGA pueda
funcionar bien por primera vez. Es una de las tareas difíciles depurar el diseño a nivel de placa. Para los
diseños de FPGA individuales y múltiples, se puede incluir lo siguiente en el plan de depuración:
1. Es necesario realizar una prueba básica para los diseños de FPGA individuales 2.
Prueba para las placas complementarias interconectadas con FPGA 3. Pruebas de E/S
de alta velocidad 4. Prueba de interfaz
5. Prueba y depuración usando el analizador
lógico 6. Conectividad y depuración de múltiples FPGA.
El objetivo principal de todo lo anterior es atrapar los errores a nivel del tablero. Es posible
que la mayoría de los errores no se encuentren durante la verificación funcional, y el mejor plan
de depuración que utiliza las herramientas EDA, los analizadores lógicos y los traductores puede
dar más visibilidad a este tipo de errores. Estos errores a nivel del sistema se pueden identificar
y corregir en la síntesis, P y R o en el nivel de la placa. Las siguientes son algunas de las pautas
utilizadas para depurar el prototipo de FPGA (Tabla 13.1).
Tabla 13.1 Algunas pautas para la depuración
Pautas Descripción
Usa el diseño más pequeño Utilice el diseño más pequeño para configurar el único
FPGA por primera vez y realizar las pruebas básicas de
lectura/escritura
Verifique la conectividad de la placa adicional Verifique la conectividad de la placa adicional con el FPGA
Compruebe el IO Comprobar el funcionamiento de las E/S multiplexadas
Verifique la conectividad múltiple FPGA Verifique la conectividad FPGA múltiple dividiendo el diseño
más pequeño en múltiples
FPGA
Verifique la configuración de la almohadilla IO ¿Verificar si los IO están configurados de la manera
correcta o no?
Verifique la conectividad del mundo externo Verifique la conectividad con las placas externas como la
interfaz del controlador flash, la interfaz DDR
Verifique el chipset externo y las interfaces IP Es necesario verificar si las direcciones IP y el conjunto de
chips tienen el comportamiento requerido.
Usar elementos de retardo Xilinx IO Utilice retardos de E/S programables para controlar los
tiempos de E/S y establecer la conectividad con el elemento
externo
Ajustar la frecuencia del reloj Para la frecuencia de reloj más alta, el sistema no
funciona para lectura o escritura; luego, para asegurar y
concluir el problema, reduzca la frecuencia del reloj.
Si a una frecuencia de reloj baja el sistema responde, intente
depurar el problema para obtener una frecuencia de reloj más alta
Comprobar la conectividad del autobús Verifique y confirme la conectividad entre el FPGA y el
analizador lógico para el extremo pequeño y grande
Compruebe las impedancias de terminación La mayoría de las veces a nivel de placa, el diseño no
funciona debido a una terminación incorrecta
Pruebas de E/S de alta velocidad Verifique los transceptores de alta velocidad para la
transferencia de datos gigabit y luego pruebe el protocolo
13.5 Planes de depuración y listas de verificación 229
13.5.1 Pruebas básicas para la FPGA
Ejecute las pruebas básicas para comprender la programabilidad de la FPGA.
1. Prueba de lectura/escritura: lea y escriba los registros de la FPGA y confirme que la FPGA está
configurada con el archivo de mapa de bits correcto.
2. Prueba de contador: use los interruptores existentes en la placa FPGA para verificar la conectividad,
verifique el reloj y reinicie el FPGA programado.
13.5.2 Pruebas de placa adicional
Escriba una pequeña rutina para configurar las placas complementarias interconectadas con la FPGA y
confirme que la FPGA puede leer o escribir la información de las placas complementarias.
El equipo de depuración puede usar pequeñas rutinas para configurar los registros múltiples en la placa
FPGA principal y en la placa complementaria y confirmar la conectividad y la configuración.
13.5.3 Probar los buses del analizador lógico externo
Pruebe el bus del analizador lógico trabajando con la placa FPGA principal. La transferencia del paquete
pequeño desde el bus FPGA puede confirmar la conectividad.
13.5.4 Conectividad FPGA múltiple y prueba de E/S
Verifique la multiplexación de pines y la multiplexación por división de tiempo de alta velocidad. Cree el
entorno de prueba para comprobar el TDM y la velocidad de datos en los pines de E/S multiplexados.
13.5.5 Prueba para el Particionamiento Múltiple de FPGA
Si el prototipo tiene múltiples FPGA en el diseño, verifique la comunicación entre FPGA escribiendo el diseño
pequeño. Diseño pequeño para garantizar que la conectividad entre FPGA se pueda particionar rápidamente
en múltiples FPGA.
Estos pueden ser pequeños controladores para un tipo similar de lectura/escritura dentro de múltiples FPGA.
13.6 ¿Cuáles son los diferentes problemas en las placas FPGA?
Documente los principales problemas en la pizarra y el plan de acción para probarlos. Algunos de los
problemas se enumeran en la Tabla 13.2.
13.7 Pruebas para la interfaz FPGA múltiple
Las siguientes pueden ser las estrategias para las pruebas de diseño para el FPGA múltiple:
1. Comprobaciones de tiempo para el diseño particionado a nivel del sistema.
2. El efecto de la lógica redundante o la eliminación de lógica en la conectividad a través de múltiples FPGA.
3. ¿Está intacta la conectividad entre FPGA? Esto puede ser probado por lectura/escritura
transacciones a través de múltiples FPGA.
4. Si los relojes controlados están asignados al equivalente de FPGA o si el diseño presenta algún problema
debido a la sincronización no convertible mediante MUX.
5. ¿Hay alguna violación de tiempo debido a los relojes generados internamente?
6. ¿Las interconexiones multiplexadas funcionan a la velocidad del reloj de transferencia o necesitan
para ajustar el reloj de transferencia.
7. La compatibilidad de las interconexiones e interfaces con referencia a la fuente
y disipar las corrientes al nivel del tablero.
8. Si se validan todas las ubicaciones y restricciones de los pines.
Considere el problema práctico a nivel de la junta mientras se comunica entre los
múltiples FPGA (Fig. 13.1).
Considere que el FPGA de lanzamiento y captura tiene System_clk y el diseño se ejecuta en la frecuencia
de reloj del sistema. La señal de E/S se lanza mediante Transfer_clk y se captura en la entrada de deMUX
mediante Transfer_clk. La frecuencia máxima se puede calcular usando
Fmax = (1/ (Tmux_delay+Ton_board+Tdemux_in))
Donde Tmux_delay = Retardo de salida del multiplexor
Ton_board= Retraso a bordo
Tdemux_in= Retardo de entrada en la FPGA de captura
Por ejemplo, considere Tmux_delay = 4 nsec
Ton_board = 2 nseg
Tdemux_in= 2 nseg
Entonces Fmax= 1/8 nseg= 125 MHz
13.7 Pruebas para la interfaz FPGA múltiple 231
Tabla 13.2 Problemas y soluciones de las pruebas de la placa
Problema de depuración Escribe Descripción El acción
El diseño no funciona Sincronización diseño puede tener Revise el informe de

en relojes más altos. violaciones de tiempo a tiempo de implementación
alta velocidad y, para y verifique las advertencias.
confirmarlo, reduzca la velocidad
del reloj y luego verifique el Compruebe las rutas críticas.
diseño. Si el diseño funciona a Faltan restricciones
la velocidad de reloj más baja,
depure Esto puede deberse a la
relación incorrecta entre el reloj
del sistema en el que funciona
La multiplexación IO no funciona velocidad de E/S el diseño y el reloj de Verifique las restricciones de

transferencia en el que se tiempo para el reloj de
transfieren los datos transferencia y el reloj del
sistema. Compruebe el informe
de tiempo
El diseño no funciona a Sincronización Esto puede deberse a una Verifique los informes de

baja frecuencia de reloj infracción de retención. tiempo y las restricciones, y
luego corríjalos ajustando el
análisis mínimomáximo
El diseño no tiene la violación retrasos en la junta Una de las razones puede Compruebe los
de tiempo durante P y R, pero ser que los retrasos a bordo no retrasos a bordo del proveedor

el diseño tiene un problema a se consideren durante el e incluya
nivel de placa análisis de tiempos. ellos durante el análisis

de tiempo. Use el margen de
retraso de seguridad o
modifique los retrasos de E/S
El diseño no funciona para los Sincronización El problema es la Verifique el uso de
múltiples. metaestabilidad y la sincronización para los diseños

FPGA que tienen sincronización. de dominio de reloj múltiple.
diferentes dominios Una razón más puede ser la
de reloj partición del diseño en los
límites de múltiples dominios de
reloj.
El diseño tiene un reloj cerrado violación de tiempo El diseño puede tener violaciones Verifique las conversiones de

y no funciona en el tablero. de tiempo de espera reloj cerradas.
Compruebe los
relojes no convertibles
y los informes de
advertencia.
(continuado)
Cuadro 13.2 (continuación)
Problema de depuración Escribe Descripción acción
Los datos están disponibles configuración de E/S Esto puede ser un problema a Compruebe la
en la salida del lanzamiento. asunto bordo debido a los estándares configuración de E/S

Pad FPGA pero no de Io de un solo extremo y la
capturado en el registro de configuración de E/S
entrada del flipflop de captura diferencial. Asegúrese de que
se utilicen los estándares de
E/S correctos durante el
mapeo de E/S
El diseño funciona para algunas Conectividad de E/S Puede deberse a la Compruebe las

condiciones pero no para todas terminación indebida de la IO impedancias de E/S en
las condiciones el extremo de transmisión
y recepción. Verifique más
detalles en las impedancias
controladas digitales específicas
del proveedor de FPGA
El diseño funciona Conectividad de E/S Esto puede deberse a la Compruebe las
individualmente en conectividad IO, restricciones de E/S y la

FPGA pero no Niveles de voltaje IO, asignación de pines de E/
funciona cuando se niveles de señal S. Incluso verifique la
configura en múltiples terminación IO
FPGA
Las placas FPGA tienen Fallos de conectividad o de Esto puede ser debido a la Verifica la rescisión
múltiples cables y el diseño no cables terminación
funciona impedancia, retrasos, impedancias para cada cable,

violación de tiempo o y luego use los datos
integridad de la señal dependientes del proveedor y
solucione el problema
Fig. 13.1 Múltiples problemas de transferencia de FPGA IO
13.7 Pruebas para la interfaz FPGA múltiple 233
Para el lado más seguro, tome una tolerancia en el diseño de alrededor de 1 ns; entonces, el máximo
frecuencia para el diseño es 111,11 MHz.
La pregunta es si el diseño funciona en esta frecuencia. Si se refiere al Cap. 11, he declarado que la
multiplexación de IO usando n: 1 MUX necesita el reloj de transferencia de n*system_clock. Ahora bien,
si system_clock es de 25 MHz, entonces transfer_clk debe tener un mínimo de 100 MHz o un máximo de
125 MHz. Pero en la práctica, no es posible lograr esta frecuencia de reloj para transferir la señal de E/S.
En la práctica, la frecuencia máxima de diseño de este tipo de E/S multiplexada está limitada por la
latencia del reloj. Si la frecuencia del reloj de transferencia es de 111,11 MHz, entonces la frecuencia de
System_clk debería estar entre 12,35 y 15,70 MHz.
Así que el equipo prototipo debería
1. Calcule la frecuencia de transferencia máxima utilizando los retrasos de E/S, los retrasos integrados
y el retraso del margen de tolerancia adicional 2. Encuentre la relación de system_clk y transfer_clk
3. Dé las restricciones en síntesis y P y R para transfer_clk y system_clk 4. Dé las restricciones de reloj
a reloj en la síntesis y P y R para transfer_clk y System_clk.
13.8 Lógica de depuración y uso de analizadores lógicos
La siguiente sección analiza el uso de los analizadores lógicos y algunas consideraciones y escenarios
prácticos durante la depuración del diseño.
Depuración de FPGA:
1. Característica de la herramienta EDA para ver los nodos internos
2. La herramienta debe observar el límite de FPGA y la lógica circundante de FPGA 3. Depuración
y prueba, caracterización de E/S de alta velocidad: para las E/S rápidas que funcionan a 1 MHz, la PC
los rastros de la placa actúan como línea de transmisión y debido a ese problema de la integridad
de la señal.
13.8.1 Sondeo mediante pines de E/S
Use los pines FPGA IO y la sonda usando el analizador lógico (Fig. 13.2).
Las señales requeridas para sondear se pueden enrutar en los pines FPGA y se pueden probar
usando el analizador lógico externo. Pero para el diseño que necesita la mayor cantidad de señales para
sondear, esta no es la mejor solución, ya que siempre hay una limitación en el número de pines de la
FPGA.
Fig. 13.2 Palpación con los puntos de palpación
Figura 13.3 Prueba MUX
13.8.2 Usar el MUX de prueba
La ventaja es que necesita la menor cantidad de pines, pero el problema es que solo es
posible probar las líneas de salida MUX (Fig. 13.3).
Si es necesario sondear 16 señales, utilice el MUX 4X 4:1 y dos líneas de selección. En
Output_pins, cuatro señales pueden estar disponibles según el estado de select_pins, y
pueden ser utilizadas por el analizador lógico externo para la depuración.
13.8.3 Uso del analizador lógico: escenario práctico (para detectar que
el paquete de datos está dañado)
Considere el diseño de FPGA que tiene múltiples controladores de máquina de estado y
otras interfaces asociadas como CODEC de video/audio, interfaz Ethernet de 10/100 MB,
13.8 Lógica de depuración y uso de analizadores lógicos 235
Fig. 13.4 Analizador lógico para detectar el paquete de datos dañado
y otras interfaces físicas. Si el paquete de datos transferido desde Ethernet está dañado y no se
identifica en la simulación funcional, entonces el diseño general tiene el error. Bajo tales
circunstancias, es esencial sondear el controlador de la máquina de estado diseñado para
aceptar los paquetes de datos de Ethernet.
Utilice el analizador lógico e intente sondear el controlador de la máquina de estado
identificando el estado del controlador de la máquina de estado donde el paquete está dañado.
Así que mire dentro del FPGA antes del paquete corrupto y pruebe el diseño. Identifique el
estado en el que el paquete está dañado y active el analizador lógico para el sondeo.
Cree el escenario de depuración en la simulación y solucione el problema (Fig. 13.4).
13.8.4 Osciloscopio para depurar el diseño
Otra solución de depuración es usar el osciloscopio para monitorear las señales en el límite de
la FPGA. Es mejor tener el osciloscopio para monitorear las señales mixtas. Los canales
analógicos y digitales pueden monitorear el comportamiento de la FPGA y la actividad de la
señal en el límite de la FPGA.
Considere el controlador DDR interconectado con el FPGA, y la dirección se actualiza de
01FFH a 0200H, pero el problema está en la lectura de los datos. Durante la operación anterior
usando la dirección de lectura, los datos se leyeron en el FPGA desde la memoria, pero ahora
el problema está en la lectura. Esto debe corregirse y, en tales escenarios, el osciloscopio de
señal mixta se puede usar para monitorear el comportamiento de la señal en el límite de la
FPGA.
Fig. 13.5 Osciloscopio de señal mixta para depuración
Al activar el osciloscopio para este evento, se puede capturar la naturaleza de la selección de la
dirección de lectura. La razón puede ser el sesgo, la transición lenta de la señal o la fuerza de
conducción débil. Esto se puede arreglar a nivel de diseño y a nivel de tablero (Fig. 13.5).
13.8.5 Depuración con núcleos ILA
Para seleccionar muchos nodos, la mejor técnica es usar el analizador lógico incorporado o integrado
(ILA) con RAM de bloque (BRAM). Esta es una solución económica y no se requieren pines adicionales.
Pero aumenta el tamaño de la memoria dentro de la FPGA.
En este mecanismo, se pueden seleccionar los nodos requeridos y luego capturar y enviar los
seguimientos a ChipScope Pro a través de JTAG (Fig. 13.6).
El uso de ChipScope Pro para establecer comunicación vía JTAG con el ILA
se muestra en la Fig. 13.7.
Hay formas de insertar el ILA en el diseño. Se pueden instanciar en el nivel RTL; luego realice la
síntesis del diseño, coloque la ruta del diseño y luego genere el archivo de flujo de bits.
La otra forma es insertar los bloques ILA según los requisitos en el diseño presintetizado y luego
realizar la ruta de ubicación y generar el archivo de bits.
ChipScope puede descargar el archivo de flujo de bits en FPGA, incluidos los núcleos ILA.
Fig. 13.6 Uso de núcleos ILA para depuración
13.8 Lógica de depuración y uso de analizadores lógicos 237
Fig. 13.7 Uso de Xilinx ChipScope Pro para la depuración [1]
Como se muestra, el bloque del controlador JTAG está interconectado con los núcleos ILA,
y los datos se pueden extraer de los núcleos ILA a través de JTAG y ChipScope Pro puede
verlos en la PC anfitriona (Fig. 13.8).
Fig. 13.8 Vista de ChipScope Pro durante la depuración [1]
13.9 Verificación y depuración a nivel del sistema
Para obtener un mejor resultado de verificación, utilice la integración del entorno de herramientas EDA
existente, los modelos de software y las placas de creación de prototipos de FPGA. Esto puede tratarse
como una verificación híbrida. Esto permite la verificación y prueba general del prototipo de FPGA con
objetivos de alta cobertura de verificación e incluso la detección de errores que no se determinaron en la
fase de verificación inicial.
1. Hay simuladores basados en eventos y ciclos estándar de la industria disponibles para permitir que la
tarea de verificación tenga una cobertura más funcional. Incluso los transactores y el modelado a nivel
de transacción se pueden usar para verificar el diseño de conteo de millones de puertas.
¿Es posible que si conectamos el simulador con el sistema y funcione en el primer intento? La respuesta
es un rotundo no, ya que existen diferentes escenarios, interfaces y problemas de transferencia de datos
para el complejo diseño del SOC.
La verificación y depuración necesita una cantidad significativa de esfuerzos, y es un
tarea que requiere mucho tiempo.
Para el diseño de conteo moderado de puertas, la simulación para comprender y corregir los desajustes
funcionales puede cumplir el propósito. Pero para los diseños SOC de un millón de puertas, la verificación y
la depuración son tareas rigurosas y que consumen mucho tiempo. Casi alrededor del 6070% del tiempo
del ciclo de diseño se invierte en la verificación del SOC. Si consideramos el prototipo de FPGA, entonces
para la codificación RTL, se requiere alrededor de un 1015 % del tiempo del ciclo de diseño. Y para las
fases restantes, desde la síntesis hasta la preparación de la placa, consume alrededor del 85 al 90 % del
tiempo del ciclo de diseño.
Los siguientes pueden ser dos enfoques importantes para verificar el SOC de millones de puertas.
13.9.1 Coverificación de hardware/software
En esto, el enlace bidireccional de nivel de señal se puede utilizar desde el simulador hasta el prototipo de
FPGA. Al usar las llamadas a la API del simulador, se puede establecer la comunicación para verificar el
diseño bajo prueba. Esto se puede usar para la detección temprana de errores escribiendo el banco de
pruebas automatizado. Pero si es necesario verificar más funciones, este tipo de enfoque de verificación
ralentiza la velocidad general.
La estrategia es tener la coverificación del hardware/software mediante el uso del enlace preciso del
ciclo bidireccional entre la placa de prototipos FPGA y el simulador.
Esto se puede lograr teniendo el envoltorio sintetizable para Verilog o VHDL y otros envoltorios para el
simulador de software. El diseño sintetizable puede ser controlado por los envoltorios de hardware, y el
código no sintetizable puede ser controlado por el simulador. En esto, el diseño está controlado por el banco
de pruebas del simulador, y los datos del contenedor de hardware y software se pueden pasar a la interfaz
PLI bidireccional.
Pero podemos decir que este tipo de enfoque tiene limitaciones ya que el hardware funciona a alta
velocidad y el simulador a baja frecuencia operativa, por lo que puede no ser viable para el
13.9 Verificación y depuración a nivel del sistema 239
SISTEMA C Tableros FPGA
medioambiente Función
llamar a C/C++
Fig. 13.9 Llamadas de Transactor utilizando el Sistema C
interfaz en tiempo real. Si la supervisión de los registros más internos es el requisito, esto
ralentiza el rendimiento.
13.9.2 Transactores y modelado a nivel de transacción
Este es uno de los enfoques que se recomiendan para la creación de prototipos híbridos, y en
este se utiliza el enlace de transacción entre el simulador y el prototipo de FPGA.
Esto se puede lograr teniendo el banco de pruebas al nivel del sistema.
Esto se puede hacer usando el entorno SystemC usando los transactores en el software
de la PC host y el DUT en el hardware. Si se establece el enlace bidireccional entre el modelo
virtual y la placa FPGA, al pasar el mensaje del transactor, se puede establecer la comunicación.
Este tipo de estrategia de verificación da como resultado una verificación más rápida en
comparación con la coverificación de hardware/software (Fig. 13.9).
13.10 Futuro de creación de prototipos SOC
Durante la última década, hemos sido testigos del crecimiento sustancial en las áreas de VLSI.
Las empresas EDA y las casas de fabricación de chips han evolucionado los diseños de SOC
nanométricos. En tales circunstancias, la era de la miniaturización está al borde de la evolución
de las nuevas tendencias y cambios tecnológicos.
1. Inteligencia artificial: La necesidad de este siglo es la innovación de los productos utilizando
los mecanismos de inteligencia artificial. Los SOC se pueden diseñar integrando la
inteligencia artificial y los algoritmos. A medida que el nodo del proceso se reduce aún
más, puede haber una evolución como la incorporación de la inteligencia en el SOC. Los
SOC se pueden utilizar en las aplicaciones de propósito general o en cualquier tipo de
sistema sofisticado; la inteligencia integrada se puede controlar y configurar utilizando la
reprogramabilidad utilizando los FPGA complejos.
2. Computación cuántica: los algoritmos que utilizan mecanismos cuánticos para mejorar las velocidades de
diseño evolucionarán en el futuro. El precio de las máquinas de computación cuántica caerá exponencialmente
en las próximas décadas. Realmente seremos testigos de los diseños ASIC de alta velocidad y baja potencia
y la creación de prototipos de FPGA utilizando las nuevas técnicas evolucionadas.
3. FPGA de alta densidad: Seremos testigos de la evolución de FPGA utilizando el nodo de proceso inferior. La
evolución puede darnos FPGA inteligentes y de alta densidad con interconexión de alta velocidad, núcleos
y capacidad de redes neuronales e inteligencia programable. Estos FPGA se pueden utilizar para validar
los diseños de SOC en el área de
1. Procesamiento de video de alta resolución y alta velocidad 2. Pruebas
de algoritmos de redes neuronales 3. Diagnóstico e imágenes médicas
4. Comunicaciones por satélite 5. Inteligencia artificial.
Los siguientes son algunos de los puntos para concluir el capítulo:
1. La creación de prototipos con diseños de FPGA simples y múltiples debe tener el plan de prueba y depuración.
2. Use la lista de verificación para obtener los mejores resultados de prueba y depuración.
3. Utilice las pruebas básicas para encontrar la conectividad FPGA.
4. Use la lógica BIST para obtener mejores resultados y los resultados de la prueba.
5. Utilice analizadores lógicos y núcleos ILA mientras realiza la prueba y la depuración.
Referencia
1. www.xilinx.com.
Apéndice
Familia de la serie Xilinx 7
La familia de FPGA de la serie Xilinx 7, la comparación con el resumen de características se enumeran a
continuación. Para obtener más información, visite www.xilinx.com.
• Comparación de la familia de la serie Xilinx 7
Capacidad máx. espartano7 Artix7 Kintex7 Virtex7
celdas lógicas 102K 215K 478K 1955K
RAM de bloque (1) 4,2 MB 13 MB 34 MB 68 MB
rebanadas DSP 160 740 1920 3600
extensión DSP 176 929 GMAC/s 2845 GMAC/s 5335 GMAC/s
rendimiento(2) GMAC/s
Transceptores – dieciséis 32 96
Velocidad del – 6,6 Gb/s 12,5 Gb/s 28,05 Gb/s
transceptor
Ancho de banda serie – 211 Gb/s 800 Gb/s 2784 Gb/s
interfaz PCIe – x4 generación 2 x8 generación 2 x8 generación 3
interfaz de 800 MB/s 1066 MB/s 1866 MB/s 1866 MB/s

memoria
pines de E/S 400 500 500 1200
voltaje de E/S 1,2–3,3 V 1,2–3,3 V 1,2–3,3 V 1,2–3,3 V
Opciones de paquete Unión por Flipchip sin Flipchip sin tapa y Flip chip

cable de bajo costo tapa, de bajo flipchip de alto de mayor rendimiento
costo y con rendimiento
conexión de alambre
Notas:
1. Memoria adicional disponible en forma de RAM distribuida 2. Las cifras máximas
de rendimiento de DSP se basan en la implementación de un filtro simétrico
• Resumen de funciones de Virtex 7 FPGA
10.1007/9789811513145
y
1.
Los Notas:
FPGA
EasyPathTM7
también
están
disponibles
para
brindar
una
solución
rápida,
simple
sin
riesgos
para
reducir
los
costos
de
los
diseños
de
FPGA
Virtex7
T
y
XT
2.
Cada
porción
de
FPGA
de
la
serie
7
contiene
cuatro
LUT
y
ocho
flip
flops ;
solo
algunos
segmentos
pueden
usar
sus
LUT
como
RAM
distribuida
o
SRL
3.
Cada
segmento
DSP
contiene
un
sumador
previo,
un
multiplicador
de
25
×
18,
un
sumador
y
un
acumulador
4.
Las
RAM
de
bloque
tienen
fundamentalmente
un
tamaño
de
36
Kb;
cada
bloque
también
se
puede
usar
como
dos
bloques
independientes
de
18
Kb
5.
Cada
CMT
contiene
un
MMCM
y
un
PLL
6.
Los
bloques
de
interfaz
Virtex7
T
FPGA
para
PCI
Express
admiten
hasta
x8
Gen
2.
Virtex7
XT
y
HT
Los
bloques
de
interfaz
para
PCI
Express
admiten
hasta
x8
Gen
3,
con
la
excepción
del
dispositivo
XC7VX495T,
que
admite
xB
Gen
2
7.
No
incluye
el
banco
de
configuración
0
8.
Este
número
no
incluye
los
transceptores
GTX,
GTH
o
GTZ
9.
Super
Las
regiones
lógicas
(SLA)
son
las
partes
constituyentes
de
las
FPGA
que
utilizan
tecnología
SSI.
Los
dispositivos
Virtex7
HT
usan
tecnología
SSI
para
conectar
SLR
con
transceptores
de
28,05
Gb/
s
XC7VH870T
976.160XC7VH590T
590.480 XC7VX1140T
1.139.200
179.000
17.700XC7VX990T
979.200
XC7VX690T
693.120
XC7VX550T
554.240
XC7VX485T
485.760
XC7VX415T
412.160
XC7VX330T
326.400
XC7V2000T
1.954.560
305.400
21.550
XC7V585T Dispositivos(1)
562,720 celdas
lógicas
136.900
13.275 90,700 153.000
13.838
108.300
10.888 96,600 75,900 64.400 51,000 91.050 lógicos
configurables
(CLB)
Rebanadas
(2)
máx. Bloques
8850 8725 8175 6525 4388 6938 (KB) RAM repartido
2520 3360 3600 3600 2880 2800 2160 2160 Rebanadas
DSP(3)
1680 1120 1260
2820
1410
50.760
18 1880 1880
67.690
24 3000 1470
1500 52.920
20 2360
54,000
18 2940
940 3760 1180
42.490
20 2060
1030
37.090
14 1760 1292
46.512
880 1500
750 2584
24 1590
795 18Kb Bloquear
bloques
de
RAM(4)
36Kb
máx.
33.840
12 14
31.680
12 27,000 28.620
18 (KB)
CMT(5)
PCIe(6)
GTX
GTH
GTZ
XADC
3 2 4 3 3 2 4 2 2 4 3
0 0 0 0 0 0 56 0 0 36 36
72 48 96 72 80 80 0 48 28 0 0
dieciséis 8 0 0 0 0 0 0 0 0 0
bloques
11111111111
6 12 22 18 20 dieciséis 14 12 14 24 17 Bancos
de
E/
S(7) Total
300 600 900N/
D N/ N/
A 700
A 600
N/ N/
A 700 850
N/
A E/
S(8) usuario máximo
1100
4 1000
N/
A 600 A 1200
4
3 2 SLR(9)
Apéndice: Familia de la serie Xilinx 7 242
Apéndice: Familia de la serie Xilinx 7 243
• Información sobre pedidos de Xilinx Artix, Kintex, Virtex 7
Para obtener más información, utilice el siguiente enlace http://
www.xilinx.com/
Índice
A b
CAD, 110, 118 flujo de fondo, 212
víboras, 39 herramientas de fondo, 173
ancho de banda, 193
Algoritmos, 166
Matrices de bases, 5
Alterar, 23
Pruebas básicas, 224
analógico, 4
Binario a gris, 47 ECC
Bloques analógicos, 224
de 64 bits, 164
Tableros equivalentes analógicos, 110
Multiplicador de 32x32 bits, 177
Analizar, 116 Registro de 4 bits, 63
API, 238 flujos de bits, 236
Uso de una herramienta de lugar y ruta, 173 ; Restricciones a nivel de bloque, 129
Circuito Integrado de Aplicacion Especifica Bloque RAM (BRAM), 164, 175, 209, 236
(ASIC), 6, 70 Diseños de tablero, 189
Arquitectura, 18, 69, 71, 130, 155, 185, 205 De abajo hacia arriba, 144
Arquitectura y microarquitectura, 202 BRAM 16X2, 166
Autoprueba integrada (BIST), 188, 202
Cambios de arquitectura/diseño, 187
Árbitro de autobús, 100
Área y potencia, 111
Minimización de área, 143
Área de informe, 214 C
Área, velocidad y potencia, 20
Retardo de cable, 191
IP ARM, 172 Capacidad, 133
inteligencia artificial, 13 Cascada, 34, 56
Artix7, 184 Casas, 32, 57
ASIC controlados por reloj, 43 Estuche de fondo de caja, 50
biblioteca ASIC, 111, 204 Diseño de celda, 5
memorias ASIC, 209 biblioteca celular, 164
Matrices de puertas canalizadas, 5
síntesis ASIC, 177
Arreglos de puertas sin canales, 5
Pruebas ASIC, 123
Caracterizar, 155
Claro asíncrono, 61
Cheque_diseño, 116
Ruta asíncrona, 136, 143
ChipScope pro, 236
Atributos, 147 topes circulares, 71
procesadores de audio, 4 CLB, 161, 174
Automático, 209 Divisor de reloj, 123
Partición automática, 188, 210 Dominio del reloj, 203
10.1007/9789811513145
246 Índice
Habilitar reloj, 44 retraso, 51
Reloj de compuerta, 124 Diseñador, 99
Células de control de reloj, 42 Compilador de diseño (DC), 25, 66, 113
Lógica de activación del reloj, 204 Restricciones de diseño, 20, 111, 143, 203
Grupos de reloj, 142 Biblioteca de diseño, 24
Arquitectura relojera, 169 Objetos de diseño, 114
Estrategias de fichaje, 188 Diseño de mamparas, 23, 109, 146, 173, 190, 201
Mosaicos de gestión de reloj (CMT), 159
relojes multiplexores, 123 Planificación del diseño, 227
Retraso de la red del reloj, 205 Restricciones de reglas de diseño (DRC), 127, 129
Latencia de la red del reloj, 122 artículos de diseño, 112
Reloj sesgado, 227 Biblioteca DesignWare, 112
Enchufes de reloj, 169 Señales diferenciales, 190, 195
Síntesis del árbol del reloj, 2, 20 digitales, 4
Límites combinacionales, 204 comunicaciones digitales, 2
Bucles combinacionales, 29 Conexiones de puerto directas, 74
Caminos combinacionales, 217 RAM distribuida, 175
Interfaces compatibles, 224 no tocar, 131, 136, 204
DSP, 4, 159
Compilar, 119
Compiladores, 139 Algoritmo DSP, 175
Bloques DSP, 166, 175, 177, 184, 209
Funcionalidad compleja, 23
DSP48E1, 166
Competición, 53
Configuración, 49, 229 funcionalidad DSP, 186
Puertos duales, 164
Configuración, pruebas y depuración, 72
RAM de dos puertos, 175
Congestión, 225
Restricciones, 18, 70, 111, 143, 180, 201, 225, 233 Ciclo de trabajo del 50 %, 117
Conectividad dinámica, 190
Contenido direccionable, 164
Controlabilidad, 21
Y
Generadores de núcleo, 174
Herramientas EDA, 109, 188, 190
metas de cobertura, 224
Síntesis eficiente, 176 .
Coverificación, 239
Niveles de esfuerzo, 119
Coverificación y uso de PI, 21
elaborado, 116
Interfaces personalizadas, 21
Emulación, 20
Basado en ciclos, 238
habilitar, 62
Claves encriptadas, 188
Código fuente encriptado, 188
d
entidades, 49
CAD, 110, 188
Codificación de entropía, 70
Conexión en cadena, 100 Corrección de errores, 165
Ruta de datos y control, 55 Estimación de la lógica, 180
fecha de llegada hora, 152
paridad par e impar, 60
convergencia de datos, 40 Simulador basado en eventos, 238
Integridad de datos, 40 Tarjeta IP externa, 224
Ruta de datos, 154 Memorias externas, 224
Controladores DDR3, 142
Controladores de memoria DDR3, 187
Depuración, 21 F
Circuitos de prueba y depuración, 190 Manufactura, 20
Depuración y fase de prueba, 188 . Camino falso, 123, 143
Planes de depuración, 227 abanico, 133, 225
Descifrado, 188 Matrices de puertas programables en campo (FPGA), 70,
Interconexiones diferidas, 189 183
Índice 247
FIFO, 164 HardIP, 188, 224
Máquina de estados finitos (FSM), 29, 53, 139 Núcleos IP duros, 186
Aplanado, 137 Lenguaje de construcción de hardware (HCL), 110
planos de planta, 2
Herramienta de planificación de suelos, 173 Software de hardware, 239
Verificación formal (FV), 220 Tamaño HD, 71 Codificador
arquitectura FPGA, 180 H.264, 70, 110 Jerárquico, 137
Archivos de flujo de bits FPGA, 173 Diseños jerárquicos, 6, 204 Alta
Límites de FPGA, 233 impedancia, 36, 189 IOB de alto
FPGA controlados por reloj, 43 rendimiento, 170 Interfaces de alta
conectividad FPGA, 226 velocidad, 186 E/S de alta velocidad,
editores de FPGA, 174 186, 211 Mantener holgura , 153
Diseño equivalente de FPGA, 201 Infracciones de retención, 141
Tejidos FPGA, 165, 172, 226
interfaces FPGA, 21
E/S de FPGA, 216
Listas de conexiones de FPGA, 173, 224
Almohadillas FPGA, 217 LA
rendimiento de FPGA, 225 Estándar IEEE 802.32005, 172 If else, 58
Placas de prototipos FPGA, 210 Ifthenelse, 50, 55 Bloques ILA, 236
recursos FPGA, 180, 188, 215, 224 Herramienta de implementación, 173
síntesis de FPGA, 212 Mejora, 111 Herramienta de depuración en
Controladores FSM, 111
circuito, 174 Lista de sensibilidad incompleta,
síntesis FSM, 54 30 Compilación incremental, 149 Flujo
personalizado completo, 2
incremental, 212 Síntesis incremental, 212
IPs funcionales y de temporización comprobada, 131 Inferencia, 204 Síntesis inicial, 143, 185,
Corrección funcional, 72, 224
201 Instanciación, 204 Ejecución de
cobertura funcional, 238 instrucciones, 74 Analizador lógico integrado
Verificación funcional, 19, 70, 224, 228
(ILA), 236 Latches previstos, 142 Retrasos
de interconexión, 225 Problemas de
interconexión, 205 Interconectividad, 205
gramo
Interfaz, 19, 227 Retardos de interfaz, 224
Matrices de puertas, 4 Comunicación entre FPGA, 229 Memoria
reloj cerrado, 215 interna, 186 Hoja de ruta de tecnología internacional
Implementación de reloj cerrado, 176 para semiconductores (ITRS), 5 Disponibilidad de
Netlist a nivel de puerta, 111 E/S, 110 Celda de E/S, 217 Columnas de E/S, 169
estrategia de apertura, 42 Retrasos de E/S, 226 Multiplexación de E/S, 194
SGD II, 20 PAD de E/S, 216, 217 Instancia IO PAD, 217 Anillos
Registros de propósito general, 74 IO PAD, 224 Pines IO, 24, 184, 194
relojes generados, 123
Fallas, 29, 42
Mundial, 51
reloj mundial, 25
Lógica de pegamento, 145
Gris a binario, 48
Grupo, 138, 147
Agrupación, 33, 139, 205
ruta_grupo, 150
GTECH, 188
código Hamming, 165
248 Índice
colocación de OI, 174 Generadores de memoria, 164
planificación de OI, 196 Estructura de la memoria, 216
esquemas de IO, 203 Estado metaestable, 41
Velocidad IO, 193 Microarquitectura, 2, 69, 71, 77, 155, 205
Normas OI, 196 Migración, 23
pruebas IO, 227 mínimo o máximo, 118
voltaje de E/S, 184 Conectividad mixta, 189
IP, 2, 23, 71, 193, 220 Máquinas Moore, 30
bloques de IP, 224 Multiciclo y falso camino, 142
Núcleos IP, 174, 204 Carril bici, 124, 143, 156
validación IP, 73 Múltiples arquitecturas, 49
Múltiples dominios de reloj, 25, 40
Múltiples dominios, 129
j Múltiples FPGA, 21, 111, 176, 180, 187, 224, 226, 228
JTAG, 236
controladores JTAG, 237 Múltiples etapas canalizadas, 225
Múltiples dominios de poder, 110
Múltiples procesos, 53
L
Múltiples descripciones de procesos, 53
Multiplicadores de área más grande, 176 E/S multiplexadas, 226, 229
Mayor lógica de decodificación, 177 Multiplexor 2:1, 56
Diseño basado en pestillo, 217 Multiplexores, 39
Pestillos, 61 Cadena multiplicadora, 168
Circuito del tanque LC, 171 Multiplicar y acumular (MAC), 166, 175
Bibliotecas, 20, 112 Multitarea, 19
Biblioteca de enlaces, 112 Lógica basada en mux, 36
locales, 52
Particionamiento lógico, 203
Analizadores lógicos, 228, 229, 233 No
Lógica y síntesis física, 109 nanómetro, 22
Densidad lógica, 141, 185 Bordes negativos, 65
Duplicación lógica, 178 Sientoncesotro anidado, 32
Réplica lógica, 205 Listas de redes, 8
síntesis lógica, 136 Redes, 148
Tiempos de ejecución más largos, 144 Sin retorno a cero (NRZ), 172
Baja latencia, 110 costo NRE, 6
Transceptores gigabit de baja potencia, 170
Retardo LUT, 217
LUT, 164, 175, 187 O
LVDS, 195 Observabilidad, 21
Fuera de FPGA, 190
retrasos a bordo, 190
metro
Retrasos en el chip, 190
Macros, 4, 220 En FPGA, 190
manuales, 209 Optimización, 20, 129, 211
Manual de planificación de suelos, 210 Restricciones de optimización, 127
mapa_esfuerzo, 149 Comportamiento oscilatorio, 219
Asignaciones, 205 Osciloscopio, 235
Max_capacitancia, 134 Retardos de salida, 118
Max_fanout, 133
Frecuencia máxima de operación, 191
Frecuencia máxima de transferencia, 233 PAG
Max_transición, 133 Librería de pads, 217
máquina harinosa, 30 PyR, 212, 228
Índice 249
Tiempos de ejecución de P&R, 212 RC constante de tiempo, 133
herramientas P&R, 212 Leer, 116
Lógica paralela, 35, 57 receptores, 4
Lógica paralela y diseño prioritario, 31 Recompilación, 143
Convertidor paralelo a serie, 171 Marcos de referencia, 71
Igualdad, 60 Referencias, 148
Partición, 21, 99, 176, 203, 209, 229 Matrices de registros, 63
Límites de partición, Los, 142 Balanceo de registros, 143, 155
Herramientas de partición, 188, 206, 209 Entradas registradas, 110
Particiones, 165 Salida registrada, 110
Detectores de patrones, 166 Ruta de registro a registro, 176
PCIe, 159 Regístrese para registrar la ruta de tiempo, 156
PCIe Ethernet MAC físico, 172 Nivel de transferencia de registro (RTL), 145, 217
Diseño físico, 6 Report_timing, 150
IP física, 188 Restablecer lógica, 204
Recuento de pines, 194 Compartir recursos, 38, 39, 163
Pines multiplex, 180, 229 Osciladores de anillo, 171
Colocaciones de pines, 173 Conectividad tipo anillo, 189
Requisitos de pines, 211 Flanco ascendente, 64
Registros canalizados, 217 robots, 13
Etapa canalizada, 155 ROM, 164
Canalización, 225 todos contra todos, 100
Lugar y ruta, 20, 220 Enrutamiento, 2
colocación, 2 Retrasos en el enrutamiento, 225
Colocación y enrutamiento, 174, 225 Diseños RTL, 19, 73, 111, 203, 224
Herramientas de colocación y enrutamiento, 205 Directrices de diseño RTL, 72
PLL, 122, 171 diseños RTL, 50
Interfaces de puerto, 146 RTL Código fuente de IP, 188
Puertos, 148 síntesis RTL, 53
Bordes positivos, 65 Ajustes RTL, 177
holguras positivas, 152 Verificación RTL, 224
Verificación del diseño de la publicación, 20
Restricciones de energía, 142
Disipación de potencia, 39 S t
plan de energía, 2 Buscar_ruta, 113
Planificación energética, 20 semiconductores, 6
netlists presintetizados, 188 Semia medida, 2
Prioridades, 148 Lista de sensibilidad, 66, 219
codificadores de prioridad, 58 Límites secuenciales, 203
Lógica de prioridad, 32, 56 SerDes, 195
Puntos de sonda, 210 Convertidor serie a paralelo, 172
Procesadores, 3 Transceptores seriales, 171
Interruptores programables, 189 Establecer_no_tocar, 136, 144
Retardo de propagación, 156, 226 Establecer_no_usar, 136
Prototipo, 23, 179, 201 Conjunto_aplanar, 138
Prototipos y pruebas, 224 Establecer_preferencia, 137
flujo prototipo, 224 tiempo de asentamiento, 226
Tableros de prototipos, 224 Comprobación de configuración y retención, 124, 156
Flujo de prototipos, 211 Configuraciones de holgura, 152
Infracción de configuración, 149
Autobuses compartidos, 100
R Asignaciones de señales, 51
RAM, 220 Integridad de la señal, 205, 224, 226, 233
250 Índice
Multiplicador con signo, 166 T
Complejidad de silicio, 6 Oblea Biblioteca de destino, 112
de silicio, 4 Simulación, 19 Comandos TCL, 210
Simulador, 238 Puerto único, MDT, 229
164 Función lógica de seis TDM y LVDS, 186
entradas, 175 Sesgo, transición Biblioteca de tecnología, 112, 133, 204, 220
lenta, 236 Slack, 149 SLICEL, 161 Puerto de acceso de prueba (TAP), 173
SLICEM, 161 Arquitectura SOC, 188 Lógica de prueba y depuración, 187
Bancos de pruebas, 19, 239
Prototipo SOC, 22, 217, 223 Velocidad
Casos de prueba, 73
SOC, 211 Particionamiento de software
prueba, 6
y hardware, 109 Bajo consumo especial,
Inserciones de prueba, 8
172 Especificaciones, 18 Síntesis de
Rendimiento, 8, 74
voz, 13 Velocidad, 226 Velocidad, área
tiempo de comercialización, 6
y potencia, 127 Velocidad o rendimiento,
Tiempo, 19, 209
173 Interconexiones de silicio apiladas (SSI) , 159
Estimaciones de tiempo, 190
Biblioteca de celdas estándar, 4, 112 Celdas estándar,
Optimización del tiempo, La, 148
4 Conectividad en estrella, 189 Controlador de máquina
Rutas de temporización, 141, 217
de estado, 139, 142, 204 Arbitrajes estáticos, 100
Rendimiento de tiempo, 225
Análisis de tiempo estático, 20 Matriz de puerta
Informes de tiempos, 143, 154, 214
estructurada, 5 Estructuración, 138 Matriz de
Violaciones de tiempo, 143, 152
enrutamiento conmutada, 189 Matriz de conmutación ,
De arriba hacia abajo, 144
189 Symbol_library, 113, 120 Sincronización, 131, 205
Límites de nivel superior, 217
Sincronizadores, 110 Sincronizador, lógica de prueba y Restricciones de nivel superior, 131
depuración, 204 Restablecimiento síncrono y asíncrono, Módulo superior, 70
225 Synopsys Certify, 208 Synopsys_dc.setup, 113 Modelado a nivel de transacciones, 238
Synopsys Design Compiler (SDC), 111, 133, 213 , 217 Transactores, 239
Compilador de diseño Synopsys (S Comandos DC), 210 Transceptores, 159, 184
Síntesis, 20, 48, 211 Optimización de síntesis, 143, 203 Transiciones, 133
Herramienta de síntesis, 225, 226 Directivas de la línea de transmisión, 233
herramienta de síntesis, 224 Ajustes de síntesis, 180 remitente, 4
Construcciones sintetizables, 69 Modelo sintetizable, Triestatal, 21
217 Reloj del sistema, 195 Lógica de tres estados, 36
tu
Desagrupar, 138
Pestillos no intencionales, 30, 57 % de
utilización, 193
Asignaciones de variables, 52
Controles de vehículos, 13
Verificación, 6
Verilog o VHDL, 238
Decodificadores de video, 2
Caminos violados, 143 .
Vírtex, 159
Virtex7 7VX200T, 187
Relojes virtuales, 117
Niveles de voltaje y lógicos, 225
Índice 251
w X
Fuerza motriz débil, 236 Xilinx, 23
factor de peso, 149
Generadores de núcleo Xilinx, 220
directorios de trabajo, 113
Envoltorios de archivos, 220 Xilinx vivo, 196

Logic Synthesis SOC Prototyping, RTL Design Using VHDL - 2020 - Taraate - SP

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Logic Synthesis SOC Prototyping, RTL Design Using VHDL - 2020 - Taraate - SP

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

Procesador Memoria Video

Red AUTOBÚS Extensión BIST

Interfaces interfaz lógica

Estilo de descripción El objetivo principal codificar la La descripción es Registro

Recursos y uso La intención principal del El diseñador debe considerar los

Solicitud Debe usarse como lenguaje de Debe usarse para describir el

Construcciones de flujo Debido a la ejecución secuencial, HDL admite el flujo de datos y

Verilog­AMS Verilog para señales Estándar abierto y utilizado Derivado de IEEE

VHDL­AMS VHDL para señales analógicas y mixtas Lenguaje estándar para la IEEE 1076.1­2007

ABEL Lenguaje de expresiones Utilizado para el No lo es

Sistema C El lenguaje de Utiliza las clases de C++ IEEE 1666­2011

Sistema Verilog Superconjunto de Verilog Se utiliza para abordar IEEE 1800­2017

Video Arbitraje de autobuses interfaz

FPGA Copia impresa Célula estándar ASIC estructurada

Herramientas Hasta unos Un par de Un par de Un millón de dólares

Precio unitario Alto Medio­bajo Medio­bajo Bajo

Tiempo para volumen Inmediato Casi alrededor de Casi alrededor de Casi alrededor de

puede requerir para puede requerir para 18 semanas

Recursos de Mínimo Mínimo de Nominal pero para Alto, ya que la mayor

FPGA Mismo dispositivo Para ASIC Depende del tipo de Mismo RTL pero

correlación estructurado en papel: IP utilizada y la bibliotecas,

b_in ( a_in, puerto : en std_logic ;

tu_fuera < = a_en + b_en ­c_en ­d_en;

puerto ( a_in, b_in, c_in, d_in : en std_logic_vector (1 a 0);

tu_fuera < = (a_en +

tu_fuera < = entrar;

señal tmp_binary_data : 3 hasta (0); std_logic_vector

y1_out , y2_out fuera : std_logic);

<= xor d_en);

tu_fuera < = estruendo xor c_en;

y1_fuera < = e_in f_in; xor

y1_fuera < = b_en a_en; xor

tu_fuera < = fecha_en(0);

tu_fuera < = fecha_en(1);

tu_fuera < = fecha_en(2);

tu_fuera < = fecha_en (3);

( puerto sel_in : en std_logic_vector ( 1 hasta 0); data_in

cuando "00" = > tu_fuera < = fecha_en(0);

cuando “01” = > tu_fuera < = fecha_en(1);

cuando "10" = > tu_fuera < = fecha_en(2);

cuando otros = > tu_fuera < = fecha_en(3);

INT3 INT2 INT1 INT0 tu_fuera(1) tu_fuera(0)

tu_fuera < = “11” ;

tu_fuera < = “10” ;

tu_fuera < = "01" ;

tu_fuera < = "00";

puerto ( fecha en : en std_logic_vector (3 hasta 0); y_out

temp_q_salida: = temp_q_out xor fecha_en (recuento);

tu_fuera < = temp_q_salida;

tu_fuera < = "0000";

tu_fuera < = "0000";

tmp_q_out < = '0';

tmp_q_out <= estruendo;

q_fuera < = tmp_q_out xor estruendo;

externo Alto CAD

Memoria Velocidad extensión DMA

Bus de datos dieciséis Bus bidireccional para transferir los datos

restablecer_n 1 Entrada de restablecimiento bajo activo Aporte

op_code 4 4 bits para las 16 instrucciones Aporte

Marcar_fuera 1 Para indicar el desbordamiento Salidas

clk 1 Señal de reloj común Aporte

restablecer_n 1 Entrada de restablecimiento bajo activo Aporte

VerilogAMS Verilog para señales Estándar abierto y utilizado Derivado de IEEE

VHDLAMS VHDL para señales analógicas y mixtas Lenguaje estándar para la IEEE 1076.12007

Sistema C El lenguaje de Utiliza las clases de C++ IEEE 16662011

Sistema Verilog Superconjunto de Verilog Se utiliza para abordar IEEE 18002017

Precio unitario Alto Mediobajo Mediobajo Bajo

tu_fuera < = a_en + b_en c_en d_en;