SRAM funciona con ciclos de lectura cortos, falla con ciclos más largos

3

Observo un comportamiento bastante extraño de un IS62WV51216BLL-55TLI chip SRAM conectado a un FPGA. Cuando lo ejecuto con los ciclos de lectura más cortos posibles, funciona como se esperaba:

(aquí,leíelvaloresperado0xCF9C3063.Untickes6.25ns)

Sinembargo,cuandointentousarciclosdelecturamáslargos,fallamisteriosamente: (aquí,leíelvalor0x136000D0enlugarde0x1360EC9F.Unamarcaes6.25ns)

Comopuedever,losdatoscorrectosaparecenenelbusdedatosenalgúnmomento,perosereemplazanrápidamenteporunvalorfalso.Estosucedeesporádicamenteenunadireccióndiferentecadavez,yvolveraleerlamismadirecciónporsegundavezfuncionabien:

(aquí,leíelvalor0x18E06439laprimeravezyelvaloresperado0x18E0E71Flasegundavez)

¿Alguientieneunaexplicaciónrazonableparaesto?¿Hayalgomalconmiciclodelectura?Aquíestáelciclodelecturadelahojadedatosanterior,parareferencia:

TodosmisdiagramassehicieronconSignalTap(analizadorlógicointegradoenFPGA)corriendoa160MHz.TodaslaspatillasdesalidadelcontroladorSRAMestánregistradas:

//**OutputPintcm_address_outregtcm_address_outen_reg;always@(posedgeclk)beginif(reset)begintcm_address_outen_reg<='b0;endelsebegintcm_address_outen_reg<='b1;endendreg[19:0]tcm_address_out_reg;always@(posedgeclk)begintcm_address_out_reg<=tcs_tcm_address_out[19:0];endassigntcm_address_out[19:0]=tcm_address_outen_reg?tcm_address_out_reg:'z;

Laseñaltcm_address_outseconectaalospinessram_addrquesevenenlosdiagramasanteriores,queasuvezestánconectadosalospinesA0-A18delICdeSRAM.Otrospinesestánconectadosdemanerasimilar.Lalongituddeloscables/rastrosentreunpinFPGAyunpinSRAMesdeaproximadamente10cm.ElSRAMICtienetapascerámicasde1uF+100nFentrelospinesGNDyVDDdeamboslados.

PS.Heintentadomantener\$\overline{CS}\$afirmadotodoeltiempo,loquenomejorólascosas.Tambiénprobéunamodificacióndonde\$\overline{OE}\$seafirma12.5nsdespuésde\$\overline{CS}\$ysedesactivadurante12.5nsentrelecturasconsecutivas(manteniendo\$\overline{CS}\PSEsonoayudó:

    
pregunta Dmitry Grigoryev

1 respuesta

2

Dmitry, para obtener la solución a su problema, deberá solucionarlo de manera sistemática. TonyM, Trevor, Dave, Michael y Gregory proporcionaron varias conjeturas, que deben ser calificadas sistémicamente dentro de su diseño. A continuación, le proporcionaré un resumen:

  • su tablero tiene algunos FPGA, con el chip IS62WV51216BLL-55TLI conectado a través de pistas de 10 centímetros de largo;
  • no hay información disponible sobre el enrutamiento de energía o el desacoplamiento de energía;
  • mostró el código que seleccionó la dirección, no hay información disponible sobre cómo muestrea los datos en el diseño de FPGA.
  • no hay imágenes del tablero disponibles, no podemos ver el diseño del tablero y cómo está hecho.

Veamos la configuración:

always@(posedge clk) begin
 if( reset ) begin

A las lecturas del analizador les falta la señal de reinicio. Deberá demostrar que la señal reset siempre es baja cuando se expone el problema.

Ahora veamos los diagramas. Como notó los cambios de valor E0A0 - > ECA0 - > EC9F - > 00D0, con el cambio a 00D0 dentro del ciclo de lectura y es un problema que informa. Esta SRAM no está registrada en sus pines de entrada y de E / S, por lo tanto, si comienza a emitir algunas señales erróneas, pueden surgir varios problemas:

  • problema de energía. Si hubiera un problema de alimentación intermitente, el chip RAM terminaría de todos modos con el valor correcto leído, ya que tiene entradas no registradas. Puede intentar aumentar el ciclo de lectura aún más, para ver si el valor cambia nuevamente de 00D0 a EC9F. Si el poder se estropeara por completo, habría corrupción de datos en el contenido de la RAM, ya que no sucede (y la segunda vez que puede leer los datos correctos) casi no creo que sea un problema de poder.
  • problema de señal de control o dirección. ¿Tienes pull-ups en las líneas de datos? Si los tiene, entonces la inactividad se leerá como FFFF, de lo contrario se puede leer cualquier cosa. Yo recomendaría encender los pull-ups débiles en el lado de FPGA. Es realmente difícil decir qué puede pasar con las líneas de control / dirección, ya que los comentaristas señalaron que lo que tienes es cómo FPGA ve la situación, y no lo que realmente sucede en la interconexión entre FPGA y SRAM.

Te recomendaría lo siguiente:

  • active los pull-ups débiles en las líneas de datos para asegurarse de que si tiene problemas para habilitar la selección / salida de chips, se vea como FFFF en el bus;
  • atrapa el ciclo de lectura del buggy y detiene el sistema, usando una sonda lógica para ver los niveles lógicos en los pines. Para esto, puede llenar la RAM con un contenido predefinido (por ejemplo, 0001 - 0203 - 0405 - ...) y leer las direcciones en bucle hasta que obtenga un valor inesperado, y detener el reloj cuando suceda. El uso del multímetro / sonda lógica mide los voltajes de todas las señales (control, datos y dirección) para averiguar cómo se ve desde fuera del FPGA.
  • como la gente ya dijo en los comentarios, verifique las conexiones físicas. Tome la lupa y mire cada junta de PCB, use una aguja que se coloca entre los pines del chip (si no es BGA sino TSOP) con algo de fuerza para asegurarse de que al aplicar los pines pequeños no se arranquen los pines (sea muy suave para no doblar las clavijas y las almohadillas de rasgado!).
respondido por el Anonymous

Lea otras preguntas en las etiquetas