Representación esquemática de AGND y DGND en un diseño de plano de tierra compartido

He visto muchas preguntas sobre cómo conectar AGND y DGND en un esquema, y ​​la respuesta habitual es usar algún tipo de componente de enlace de red con una huella física (y aprobar la violación DRC de superposición resultante). Si bien es bastante complicado, esto parece estar bien para un diseño de suelo en estrella o segregado con una conexión de un solo punto.

Sin embargo, esto realmente no ayuda en un diseño de plano de tierra "compartido", en el que no hay un único punto de conexión entre planos de tierra distintos y, en cambio, se basa en la distribución física de dispositivos y trazas para mantener separadas las rutas de retorno AGND y DGND en un único plano de tierra indiferenciado.

Mi pregunta es, ¿hay alguna manera de representar esto en el esquema, que no sea usar una sola red GND no diferenciada y confiar, por ejemplo, en anotaciones ad hoc, hojas separadas, etc. para identificar los distintos dominios de ubicación/enrutamiento?

Estoy preguntando específicamente sobre Eagle, pero también sería interesante saber qué tipo de soporte brindan las herramientas de gama alta en este sentido.

EDITAR: Para aclarar, estoy preguntando específicamente sobre un diseño que siga los principios establecidos, por ejemplo, en este artículo de Henry Ott .

¿Por qué este método perfectamente aceptable (que usted llama hacky) debería ser diferente para el tipo de diseño que propone?
Es posible que esté buscando un comando corto de red.
Lo llamo hacky (quizás injustamente) porque, a menos que haya un componente de enlace de red que no haya encontrado que resuelva este problema, causa una violación de DRC que debe aprobarse manualmente.
Este método no funciona para el tipo de diseño que propongo (y que he visto defendido por muchas fuentes acreditadas) porque da como resultado una conexión entre dos redes de tierra distintas en un solo punto, que es precisamente lo que este diseño pretende evitar. .
¿Está tratando de hacer cumplir las reglas en el momento del diseño o la documentación en el esquema? Estoy bastante seguro de que si estuviera leyendo su esquema, no querría que una red tuviera dos nombres diferentes. Pero tal vez esa sea una preferencia personal. Si hay un GND monolítico, preferiría que se llamara GND y lo dejara así.
Al volver a leer ese artículo de Henry Ott, dice que solo debe haber un plano de tierra y que el aislamiento del ruido debe lograrse mediante la ubicación y el enrutamiento. No hay una buena manera de documentar los requisitos de ubicación y enrutamiento en el esquema que no sea agregar notas y diagramas, a los que parece referirse como ad-hoc. Tal vez algunas empresas tendrían pautas sobre cómo se debe registrar esa información en el esquema. Cuando trabajaba en motorola, escribíamos un documento de requisitos de enrutamiento totalmente separado del esquema. El tipo de diseño lo usaría para apilar, colocar, etc.
@mkeith: diría que vale la pena escribir esto como respuesta.

Respuestas (2)

Al volver a leer ese artículo de Henry Ott, que es excelente y que he leído antes, dice que solo debe haber un plano de tierra y que el aislamiento de ruido digital debe lograrse mediante la ubicación y el enrutamiento. Todavía no he visto una herramienta de entrada de esquemas que proporcione una buena manera de documentar ese tipo de cosas. A pesar de que se invierte mucho pensamiento y diseño en una ubicación para satisfacer los requisitos establecidos por Ott, no se ve muy diferente a simple vista de cualquier otra placa con un plano de tierra monolítico y una red.

Personalmente, si estuviera revisando un esquema para una placa como esa, no me gustaría que hubiera múltiples alias de red asignados a tierra. Eso es simplemente confuso. Preferiría que el esquema use una sola red GND y un nombre de red. Esto podría ser una cuestión de preferencia, así que tenlo en cuenta.

Algunas empresas pueden tener pautas sobre cómo se debe registrar esa información en el esquema. Cuando trabajé en motorola hace 20 años (Motorola Computer Group... computadoras CompacktPCI de placa única), los EE escribían un documento de requisitos de enrutamiento totalmente separado del esquema. El ingeniero de diseño lo usaría como referencia para el apilamiento, la ubicación, etc. La información sobre las divisiones o rellenos del plano de potencia o el tratamiento especial para los convertidores de CC-CC y las trazas de impedancia controlada estarían en el documento.

La ubicación se revisaría y aprobaría antes de colocar las vías para evitar trabajo innecesario. Hoy en día, dependiendo de la cadena de herramientas que se utilice, se pueden controlar muchas propiedades desde el esquema (como pares de diferencias, coincidencia de longitudes, etc.). Creo que es una mejor manera de hacerlo. Pero hasta donde yo sé, no hay forma de transmitir las complejas restricciones de ubicación necesarias para seguir las recomendaciones de Ott. Si cree que es necesario, puede intentar instituir un procedimiento operativo estándar en su empresa para ayudar a documentar ese tipo de cosas de manera estándar. A veces los jefes aprecian ese tipo de cosas. Pero puede que no tenga sentido para empresas muy pequeñas que no hacen diseños con frecuencia.

Otra cosa que he visto ocasionalmente es un diagrama de planta. Esto a menudo se dibuja con algún tipo de herramienta de diagrama de bloques y no es muy preciso dimensionalmente hablando, pero proporciona una indicación de las ubicaciones relativas de los componentes clave. Esto podría ser un documento separado o podría agregarse al esquema en la página 2 o la página 3.

Para la mayoría de los diseños, un concepto de suelo en estrella es el mejor camino a seguir. Los lazos netos no conducen a violaciones de DRC, sino que inhiben las violaciones de DRC, por ejemplo, para un terreno estelar.

Eso es lo que puede ser (aunque encontrará muchos que no estarían de acuerdo), pero (a) todavía tengo que encontrar una solución de empate neto que no produzca una violación de DRC en Eagle (me encantaría que me señalaran uno) y (b) no aborda el enfoque de diseño específico sobre el que estoy preguntando.
"Estoy preguntando específicamente sobre Eagle, pero también sería interesante saber qué tipo de soporte brindan las herramientas de gama alta en este sentido". El Hackiness se debe a Eagle. Esperaría que cualquier entorno cad decente maneje esto bien. Entonces, el problema no es el método, el problema en este caso parece ser la herramienta.
Altium Designer y Mentor no generan violaciones de DRC cuando se utilizan vínculos netos. No hay nada en desacuerdo con respecto a la puesta a tierra en estrella: o necesita separar las tierras para reducir el acoplamiento y unir estas tierras con un punto de estrella en algún lugar o proporcionar una tierra compartida que minimice las áreas de bucle a costa de un mayor acoplamiento.
Representación esquemática de AGND y DGND en un diseño de plano de tierra compartido
RespuestasAquíPolítica de privacidad1y, 0v