Autobús VME

ImprimirCitar
Estandar de bus informático basado en tamaños de Eurocard
VME64 caja con, desde la izquierda, un módulo ADC, un módulo de escalador y un módulo de procesador

VMEbus (bus Versa Module Eurocard) es un estándar de bus de computadora, desarrollado originalmente para la línea de CPU Motorola 68000, pero luego se usó ampliamente para muchas aplicaciones y estandarizado por IEC como ANSI/IEEE 1014-1987. Se basa físicamente en los tamaños, la mecánica y los conectores de Eurocard (DIN 41612), pero utiliza su propio sistema de señalización, que Eurocard no define. Fue desarrollado por primera vez en 1981 y continúa teniendo un uso generalizado en la actualidad.

Historia

En 1979, durante el desarrollo de la CPU Motorola 68000, uno de sus ingenieros, Jack Kister, decidió crear un sistema de bus estandarizado para sistemas basados en 68000. El equipo de Motorola hizo una lluvia de ideas durante días para seleccionar el nombre VERSAbus. Las tarjetas VERSAbus eran grandes, 370 por 230 mm (14+12 por 9+ 14 in) y conectores de borde usados. Solo unos pocos productos lo adoptaron, incluido el controlador de instrumentos IBM System 9000 y los sistemas de visión artificial y robot Automatix.

Tarjeta de memoria VERSAbus

Más tarde se unió a Kister John Black, quien perfeccionó las especificaciones y creó el concepto de producto VERSAmodule. Julie Keahey, una joven ingeniera que trabajaba para Black, diseñó la primera tarjeta VERSAmodule, el módulo adaptador VERSAbus, que se utiliza para ejecutar las tarjetas existentes en el nuevo VERSAbus. Sven Rau y Max Loesel de Motorola-Europa agregaron una especificación mecánica al sistema, basándose en el estándar Eurocard que en ese momento estaba avanzado en el proceso de estandarización. El resultado se conoció primero como VERSAbus-E, pero luego se le cambió el nombre a VMEbus, por VERSAmodule Eurocard bus (aunque algunos se refieren a él como Versa Module Europa).).

En este punto, varias otras empresas involucradas en el ecosistema de 68000 acordaron usar el estándar, incluidas Signetics, Philips, Thomson y Mostek. Pronto fue estandarizado oficialmente por IEC como IEC 821 VMEbus y por ANSI e IEEE como ANSI/IEEE 1014-1987.

El estándar original era un bus de 16 bits, diseñado para adaptarse a los conectores DIN Eurocard existentes. Sin embargo, ha habido varias actualizaciones del sistema para permitir anchos de bus más amplios. El VME64 actual incluye un bus completo de 64 bits en tarjetas de tamaño 6U y 32 bits en tarjetas de 3U. El protocolo VME64 tiene un rendimiento típico de 40 MB/s. Otros estándares asociados han agregado intercambio en caliente (plug-and-play) en VME64x, 'IP' tarjetas que se conectan a una sola tarjeta VMEbus y varios estándares de interconexión para vincular sistemas VME entre sí.

A fines de la década de 1990, los protocolos síncronos demostraron ser favorables. El proyecto de investigación se llamó VME320. La Organización de Estándares VITA solicitó un nuevo estándar para backplanes VME32/64 no modificados. El nuevo protocolo 2eSST fue aprobado en ANSI/VITA 1.5 en 1999.

A lo largo de los años, se han agregado muchas extensiones a la interfaz de VME, proporcionando 'banda lateral' canales de comunicación en paralelo al propio VME. Algunos ejemplos son Módulo IP, RACEway Interlink, SCSA, Gigabit Ethernet en VME64x Backplanes, PCI Express, RapidIO, StarFabric e InfiniBand.

VMEbus también se utilizó para desarrollar estándares estrechamente relacionados, VXIbus y VPX. El VMEbus tuvo una fuerte influencia en muchos buses de computadora posteriores como STEbus.

Primeros años de VME

Los conceptos arquitectónicos de VMEbus se basan en VERSAbus, desarrollado a fines de la década de 1970 por Motorola. El grupo European Microsystems de Motorola en Munich, Alemania Occidental, propuso el desarrollo de una línea de productos similar a VERSAbus basada en el estándar mecánico Eurocard. Para demostrar el concepto, Max Loesel y Sven Rau desarrollaron tres placas prototipo: (1) una placa de CPU 68000; (2) una placa de memoria dinámica; (3) una placa de memoria estática. Llamaron al nuevo autobús VERSAbus-E. Más tarde, Lyman (Lym) Hevle, entonces vicepresidente de Motorola Microsystems Operation, cambió su nombre a "VME", abreviatura de Versa Module European. (Más tarde fue el fundador de VME Marketing Group, posteriormente rebautizado como VME International Trade Association, o VITA). A principios de 1981, Motorola, Mostek y Signetics acordaron desarrollar y respaldar conjuntamente la nueva arquitectura de bus. Todas estas empresas fueron las primeras en apoyar la familia de microprocesadores 68000.

John Black de Motorola, Craig MacKenna de Mostek y Cecil Kaplinsky de Signetics desarrollaron el primer borrador de la especificación VMEbus. En octubre de 1981, en la feria comercial System '81 en Munich, Alemania Occidental, Motorola, Mostek, Signetics/Philips y Thomson CSF anunciaron su apoyo conjunto al VMEbus. También colocaron la Revisión A de la especificación en el dominio público. En agosto de 1982, la Revisión B de la especificación VMEbus fue publicada por la recién formada VMEbus Manufacturers' Grupo (VITA). Esta nueva revisión refinó las especificaciones eléctricas para los controladores y receptores de la línea de señal y alineó aún más la especificación mecánica con el estándar IEC 297 en desarrollo (la especificación formal para los formatos mecánicos de Eurocard). A fines de 1982, la delegación francesa de la Comisión Electrotécnica Internacional (IEC) propuso la Revisión B del VMEbus como estándar internacional. El subcomité IEC SC47B nombró a Mira Pauker de Philips, Francia, presidenta de un comité editorial, iniciando así formalmente la estandarización internacional del VMEbus.

En marzo de 1983, el Comité de estándares de microprocesadores (MSC) del IEEE solicitó autorización para establecer un grupo de trabajo que pudiera estandarizar el VMEbus en los EE. UU. Esta solicitud fue aprobada por la Junta de Normas de IEEE y se estableció el Grupo de Trabajo P1014. Wayne Fischer fue nombrado primer presidente del grupo de trabajo. John Black se desempeñó como presidente del Subcomité Técnico P1014. El grupo de fabricantes de IEC, IEEE y VMEbus (ahora VITA) distribuyó copias de la Revisión B para comentarios y recibió las solicitudes resultantes de cambios en el documento. Estos comentarios dejaron en claro que era hora de pasar la Revisión B. En diciembre de 1983, se llevó a cabo una reunión que incluyó a John Black, Mira Pauker, Wayne Fischer y Craig MacKenna. Se acordó que se debe crear una Revisión C y que debe tomar en consideración todos los comentarios recibidos por las tres organizaciones. John Black y Shlomo Pri-Tal de Motorola incorporaron los cambios de todas las fuentes en un documento común. El grupo de fabricantes de VMEbus etiquetó el documento Revisión C.1 y lo colocó en el dominio público. El IEEE lo etiquetó como P1014 Draft 1.2 y el IEC lo etiquetó como IEC 821 Bus. Las votaciones posteriores en el Grupo de trabajo de IEEE P1014 y el MSC dieron como resultado más comentarios y requirieron que se actualizara el borrador de IEEE P1014. Esto resultó en la especificación ANSI/IEEE 1014-1987.

En 1985, Aitech desarrolló bajo contrato para US TACOM, la primera placa VMEbus de 6U refrigerada por conducción. Aunque eléctricamente proporcionaba una interfaz de protocolo VMEbus compatible, mecánicamente, esta placa no era intercambiable para su uso en chasis de desarrollo VMEbus de laboratorio refrigerado por aire.

A fines de 1987, se formó un comité técnico bajo VITA bajo la dirección de IEEE para crear el primer 6U militar refrigerado por conducción × 160 mm, totalmente compatible eléctrica y mecánicamente, placa VMEbus copresidida por Dale Young (DY4 Systems) y Doug Patterson (Plessey Microsystems, luego Radstone Technology). ANSI/IEEE-1101.2-1992 fue posteriormente ratificado y publicado en 1992 y sigue vigente como el estándar internacional de refrigeración por conducción para todos los productos 6U VMEbus.

En 1989, John Peters de Performance Technologies Inc. desarrolló el concepto inicial de VME64: direcciones de multiplexación y líneas de datos (A64/D64) en VMEbus. El concepto se demostró el mismo año y se colocó en el Comité Técnico de VITA en 1990 como una mejora del rendimiento de la especificación VMEbus. En 1991, el IEEE concedió la PAR (Solicitud de autorización de proyecto) para P1014R (revisiones de la especificación VMEbus). Ray Alderman, director técnico de VITA, copresidió la actividad con Kim Clohessy de DY-4 Systems.

A fines de 1992, las mejoras adicionales a VMEbus (A40/D32, ciclos bloqueados, DTACK rescindible*, Autoslot-ID, controlador de sistema automático y mecánica mejorada del conector DIN) requirieron más trabajo para completar este documento. El Comité Técnico de VITA suspendió el trabajo con el IEEE y buscó la acreditación como organización desarrolladora de estándares (SDO) con el Instituto Nacional Estadounidense de Estándares (ANSI). El IEEE Par P1014R original fue posteriormente retirado por el IEEE. El Comité Técnico de VITA volvió a utilizar la especificación VMEbus C.1 de dominio público como su documento de nivel básico, al que agregaron nuevas mejoras. Este trabajo de mejora fue realizado en su totalidad por el Comité Técnico de VITA y resultó en ANSI/VITA 1-1994. Kim Clohessy de DY-4 Systems, copresidente técnico de la actividad, llevó a cabo la tremenda tarea de editar el documento, con la gran ayuda de Frank Hom, quien creó los dibujos mecánicos y las contribuciones excepcionales de cada editor de capítulo.

Las mejoras adicionales propuestas al Subcomité VME64 se colocaron en el Documento de Extensiones VME64. Otras dos actividades comenzaron a fines de 1992: BLLI (especificaciones de inserción en vivo a nivel de placa VMEbus) y VSLI (inserción en vivo a nivel de sistema VMEbus con tolerancia a fallas).

En 1993, se iniciaron nuevas actividades en la arquitectura VME básica, lo que implicaba la implementación de subbuses paralelos y en serie de alta velocidad para su uso como interconexiones de E/S y subsistemas de transferencia de datos. Estas arquitecturas se pueden utilizar como conmutadores de mensajes, enrutadores y pequeñas arquitecturas paralelas multiprocesador.

La solicitud de reconocimiento de VITA como organización de desarrollo de estándares acreditada de ANSI se concedió en junio de 1993. Se han colocado muchos otros documentos (incluidos los estándares de bus serial, P2 y mezzanine) con VITA como administrador de dominio público de estos tecnologías

Evolución del VME
Topología Año Ciclo de autobús Velocidad máxima (MB/s)
VMEbus32 Parallel Bus Rev. A 1981 BLT40
VMEbus IEEE-1014 1987 BLT40
VME64 1994 MBLT80
VME64x 1997 2eVME 160
VME320 1997 2eSST 320

Descripción

En muchos sentidos, el VMEbus es equivalente o análogo a los pines del 68000 que se ejecutan en un backplane.

Sin embargo, una de las características clave del 68000 es un modelo de memoria plana de 32 bits, libre de segmentación de memoria y otras "antifunciones". El resultado es que, si bien VME es muy similar a 68000, 68000 es lo suficientemente genérico como para que esto no sea un problema en la mayoría de los casos.

Al igual que el 68000, VME utiliza buses de direcciones y datos de 32 bits separados. El bus de direcciones 68000 es en realidad de 24 bits y el bus de datos de 16 bits (aunque internamente es de 32/32), pero los diseñadores ya estaban buscando una implementación completa de 32 bits.

Para permitir ambos anchos de bus, VME utiliza dos conectores Eurocard diferentes, P1 y P2. P1 contiene tres filas de 32 pines cada una, implementando los primeros 24 bits de dirección, 16 bits de datos y todas las señales de control. P2 contiene una fila más, que incluye los 8 bits de dirección y los 16 bits de datos restantes.

El bus está controlado por un conjunto de nueve líneas, conocido como el bus de arbitraje. Todas las comunicaciones están controladas por la tarjeta en la ranura uno del chasis Eurocard, conocida como módulo árbitro. Se admiten dos modos de arbitraje: Round Robin y Prioritized.

Independientemente del modo de arbitraje, una tarjeta puede intentar convertirse en la maestra del bus manteniendo baja una de las cuatro líneas de solicitud de bus. Con el arbitraje por turnos, el árbitro alterna entre las líneas de solicitud de bus BR0–BR3 para determinar a cuál de los solicitantes potencialmente simultáneos se le otorgará el bus. Con el arbitraje de prioridad, BR0–BR3 usa un esquema de prioridad fijo (BR0 más bajo, hasta BR3 más alto) y el árbitro otorgará el bus al solicitante de mayor prioridad.

Cuando el árbitro ha determinado cuál de las solicitudes de bus otorgar, afirma la línea Bus Grant correspondiente (BG0–BG3) para el nivel que ganó la maestría del bus. Si dos maestros solicitan simultáneamente el bus usando la misma línea BR, una conexión en cadena de concesión de bus rompe efectivamente el empate al otorgar el bus al módulo más cercano al árbitro. El maestro al que se le otorgó el bus indicará entonces que el bus está en uso afirmando Bus Busy (BBSY*).

En este punto, el maestro ha obtenido acceso al bus. Para escribir datos, la tarjeta conduce una dirección, un modificador de dirección y datos al bus. A continuación, activa la línea de luz estroboscópica de dirección y las dos líneas de luz estroboscópica de datos bajas, para indicar que los datos están listos, y activa el pin de escritura para indicar la dirección de transferencia. Hay dos luces estroboscópicas de datos y una línea *LWORD, por lo que las tarjetas pueden indicar si el ancho de datos es de 8, 16 o 32 bits (o 64 en VME64). La tarjeta en la dirección del bus lee los datos y tira de la línea baja reconocimiento de transferencia de datos cuando la transferencia puede completarse. Si la transferencia no se puede completar, puede bajar la línea de error de bus. La lectura de datos es esencialmente la misma, pero la tarjeta de control controla el bus de direcciones, deja el bus de datos en tres estados y controla el pin de lectura. La tarjeta esclava impulsa la lectura de datos en el bus de datos y reduce los pines estroboscópicos de datos cuando los datos están listos. El esquema de señalización es asincrónico, lo que significa que la transferencia no está vinculada a la sincronización de un pin de reloj de bus (a diferencia de los buses síncronos como PCI).

Un protocolo de transferencia en bloque permite que ocurran varias transferencias de bus con un solo ciclo de dirección. En el modo de transferencia en bloques, la primera transferencia incluye un ciclo de dirección y las transferencias posteriores requieren solo ciclos de datos. El esclavo es responsable de asegurarse de que estas transferencias utilicen direcciones sucesivas.

Los maestros del bus pueden liberar el bus de dos maneras. Con Release When Done (RWD), el maestro libera el bus cuando completa una transferencia y debe volver a arbitrar para el bus antes de cada transferencia posterior. Con Release On Request (ROR), el maestro retiene el bus al continuar afirmando BBSY* entre transferencias. ROR permite que el maestro retenga el control sobre el bus hasta que otro maestro que desee arbitrar el bus afirme un Bus Clear (BCLR*). Por lo tanto, un maestro que genera ráfagas de tráfico puede optimizar su rendimiento arbitrando el bus solo en la primera transferencia de cada ráfaga. Esta disminución en la latencia de transferencia tiene el costo de una latencia de transferencia algo más alta para otros maestros.

Los modificadores de direcciones se utilizan para dividir el espacio de direcciones del bus VME en varios subespacios distintos. El modificador de dirección es un conjunto de señales de 6 bits de ancho en el backplane. Los modificadores de dirección especifican la cantidad de bits de dirección significativos, el modo de privilegio (para permitir que los procesadores distingan entre los accesos al bus por software a nivel de usuario o a nivel de sistema) y si la transferencia es o no una transferencia en bloque. A continuación se muestra una tabla incompleta de modificadores de dirección:

Hex Code Función Explicación
3f Transferencia de bloques de supervisión estándar Transferencia de bloques A24, privilegiado
3e Acceso al programa de supervisión estándar A24 acceso a la instrucción, privilegiado
3d Supervisor estándar Acceso a los datos A24 acceso a datos, privilegiado
3b Standard Non-privileged block transfer Transferencia de bloques A24 para programas normales
3a Standard Non-privileged Acceso al programa Acceso de instrucción A24, no privatizado
39 Standard non-privileged Acceso a los datos A24 data access, non-privileged
2d Supervisión corta Acceso A16 acceso privilegiado.
29 Short non-privileged Acceso A16 acceso no privativo.
0f Supervisión ampliada Transferencia de bloques A32 traslado privilegiado de bloques.
0e Supervisión ampliada Acceso al programa A32 acceso privilegiado a la instrucción.
0d Supervisión ampliada Acceso a los datos. A32 acceso privilegiado a datos.
0b Extended Non-privileged Transferencia de bloques A32 traslado de bloques no privilegiados.
0a Extended Non-privileged Acceso al programa A32 acceso de instrucción no privatizado.
09 Extended non-privileged data access. A32 acceso a datos no privilegiados.
NotaAn como en A16, A24, A32 se refiere a la anchura de la dirección

VME también decodifica los siete niveles de interrupción del 68000 en un bus de interrupción de 7 pines. El esquema de interrupción es uno de interrupciones vectoriales priorizadas. Las líneas de solicitud de interrupción (IRQ1–IRQ7) priorizan las interrupciones. Un módulo de interrupción afirma una de las líneas de solicitud de interrupción. Cualquier módulo en el bus puede manejar potencialmente cualquier interrupción. Cuando un módulo de manejo de interrupciones reconoce una solicitud de interrupción en una prioridad que maneja, arbitra para el bus de la manera habitual descrita anteriormente. Luego realiza una lectura del vector de interrupción conduciendo la versión binaria de la línea IRQ que maneja (por ejemplo, si se está manejando IRQ5, entonces el binario 101) en el bus de direcciones. También afirma la línea IACK, junto con las luces estroboscópicas de transferencia de datos apropiadas para el ancho del estado/ID que se lee. De nuevo, LWORD*, DS0* y DS1* permiten que los ciclos de lectura de ID/estado sean transferencias de 8, 16 o 32 bits de ancho, pero la mayoría de los interruptores de hardware existentes utilizan ID/estado de 8 bits. El interruptor responde transfiriendo un estado/ID en el bus de datos para describir la interrupción. El módulo de manejo de interrupciones (generalmente una CPU) generalmente usará este estado/número de identificación para identificar y ejecutar la rutina de servicio de interrupción de software adecuada.

En el bus VME, todas las transferencias son DMA y cada tarjeta es maestra o esclava. En la mayoría de los estándares de bus, se agrega una cantidad considerable de complejidad para admitir varios tipos de transferencia y selección de maestro/esclavo. Por ejemplo, con el bus ISA, ambas características tuvieron que agregarse junto con los "canales" modelo, en el que todas las comunicaciones eran manejadas por la CPU host. Esto hace que VME sea considerablemente más simple a nivel conceptual y más potente, aunque requiere controladores más complejos en cada tarjeta.

Herramientas de desarrollo

Al desarrollar y/o solucionar problemas del bus VME, el examen de las señales de hardware puede ser muy importante. Los analizadores lógicos y los analizadores de bus son herramientas que recopilan, analizan, decodifican y almacenan señales para que las personas puedan ver las formas de onda de alta velocidad cuando lo deseen.

VITA ofrece preguntas frecuentes integrales para ayudar con el diseño y desarrollo de front-end de los sistemas VME.

Ordenadores que utilizan un VMEbus

Las computadoras que usan VMEbus incluyen:

  • HP 743/744 PA-RISC Computador de tablero único
  • Sol-2 a Sol-4
  • HP 9000 estaciones de trabajo industriales
  • Atari TT030 y Atari MEGA STE
  • Motorola MVME
  • Signatura
  • PACE del Grupo de Investigación y Análisis Numérico avanzado.
  • ETAS ES1000 Rapid Prototyping System
  • Varios Motorola 88000 Datos Generales AViiON computadoras
  • Sistemas de primeros gráficos de silicona basados en MIPS incluyendo IRIS Profesional, IRIS Personal, Power Series y Onyx
  • Convergent Technologies Poderoso Frame

Distribución de pines

Visto mirando el zócalo de la placa posterior.

P1

Pin a b c
1 D00 BBSY* D08
2 D01 BCLR* D09
3 D02 ACFAIL* D10
4 D03 BG0IN* D11
5 D04 BG0OUT* D12
6 D05 BG1IN* D13
7 D06 BG1OUT* D14
8 D07 BG2IN* D15
9 GND BG2OUT* GND
10 SYSCLK BG3IN* SYSFAIL*
11 GND BG3OUT* BERR*
12 DS1* BR0* SYSRESET*
13 DS0* BR1* LWORD*
14 WRITE* BR2* AM5
15 GND BR3* A23
16 DTACK* AM0 A22
17 GND AM1 A21
18 AS* AM2 A20
19 GND AM3 A19
20 IACK* GND A18
21 IACKIN* SERCLK A17
22 IACKOUT* SERDAT* A16
23 AM GND A15
24 A07 IRQ7* A14
25 A06 IRQ6* A13
26 A05 IRQ5* A12
27 A04 IRQ4* A11
28 A03 IRQ3* A10
29 A02 IRQ2* A09
30 A01 IRQ1* A08
31 −12V +5VSTDBY +12V
32 +5V +5V +5V

P2

Pin a b c
1 Usuario definido +5V Usuario definido
2 Usuario definido GND Usuario definido
3 Usuario definido RESERVA Usuario definido
4 Usuario definido A24 Usuario definido
5 Usuario definido A25 Usuario definido
6 Usuario definido A26 Usuario definido
7 Usuario definido A27 Usuario definido
8 Usuario definido A28 Usuario definido
9 Usuario definido A29 Usuario definido
10 Usuario definido A30 Usuario definido
11 Usuario definido A31 Usuario definido
12 Usuario definido GND Usuario definido
13 Usuario definido +5V Usuario definido
14 Usuario definido D16 Usuario definido
15 Usuario definido D17 Usuario definido
16 Usuario definido D18 Usuario definido
17 Usuario definido D19 Usuario definido
18 Usuario definido D20 Usuario definido
19 Usuario definido D21 Usuario definido
20 Usuario definido D22 Usuario definido
21 Usuario definido D23 Usuario definido
22 Usuario definido GND Usuario definido
23 Usuario definido D24 Usuario definido
24 Usuario definido D25 Usuario definido
25 Usuario definido D26 Usuario definido
26 Usuario definido D27 Usuario definido
27 Usuario definido D28 Usuario definido
28 Usuario definido D29 Usuario definido
29 Usuario definido D30 Usuario definido
30 Usuario definido D31 Usuario definido
31 Usuario definido GND Usuario definido
32 Usuario definido +5V Usuario definido

Las filas P2 ayc pueden ser utilizadas por un bus secundario, por ejemplo, el STEbus.

Contenido relacionado

Kermit (protocolo)

Historia de la ciencia y la tecnologia

Cookie (internet)

Las cookies HTTP son pequeños bloques de datos creados por un servidor web mientras un usuario navega por un sitio web y que el navegador web del usuario...
Más resultados...
Tamaño del texto:
Editar