FPGA SDRAM SDR vs DDR. Consejos sobre la seleccion para una aplicacion especifica

Estimados,

En este post, les solicito consejos para tomar la mejor decision acerca de usar SDR o DDR en mi aplicacion.

Usando un FPGA, necesito grabar palabras de 16 bits en una memoria SDRAM (por capacidad).

La memoria MK9 (altera) es bastante pero no suficiente.

Las palabras de 16 bits van a estar ingresando al fpga a razon de 200mhz a tasa continua hasta llenar la memoria, sin pausas de ningun tipo. (planeo hacer una fifo con la memoria interna del fpga para suplir algunos problemas)

Dispongo de lo siguiente (un integrado, no modulos):

- Memoria DDR PC-2100. 133mhz (x2 ya que es ddr) de 16 bits de ancho de bus de datos
- Memora SDR 133mhz de 32 bits de ancho de bus de datos (de una gforce vieja)

Teniendo en cuenta:
- PCB hecha por mi, por lo que las altas frecuencias se van a complicar con los trazos.
- La memoria va a tener que estar un poco alejada del fpga, a 1 pulgada aprox
- Las demoras por refresco y por cambio de fila (me preocupa mas esta ultima).

Cual me convendria? Mi analisis es el siguiente:

- La memoria DDR me permite grabar en estado alto y bajo del clock, por lo que podria llegar a los 200mhz sin mayor problema PERO el bus de direccion (no estoy seguro si es asi en burst) y el de datos (ademas del clock) estarian cambiando de estado a 200mhz, son aproximadamente 30 trazos del PCB cambiando a esa frecuencia (n)

- En la memoria SDR, al ser de 32 bits, estaria "simulando" un DDR ya que juntaria 2 palabras de 16 bits en el fpga y las mandaria a la memoria a 133mhz. En este caso tendria unos 50 trazos del PCB cambiando, pero a 133mhz. Si fuera una SDR de 16 bits ya no me sirve porque no le da el ancho de banda.

Ademas,

En la memoria DDR, no sabria como manejar las pausas de cambio de fila o de refresco mientras tengo que grabar los datos a todo trapo.

En la SDR, al hacerla correr a 133mhz tendria 266mhz efectivos (por mandar 2 palabras a la vez) con lo cual la memoria "lee" la fifo interna del fpga mas rapido de lo que este la llena, haciendo la fifo de "buffer" para cuando la sdram tiene que cambiar de fila o refrescar.

Supongo que podria implementar la misma fifo para la ddr asi que supongamos que no es un problema pero lo queria mencionar.

Mi mayor preocupacion es la integridad de datos debido a los trazos del PCB.

Teniendo en cuenta estas opciones (o alguna otra que puedan sugerir), que me recomendarian usar para el proyecto?

Desde ya, muchisimas gracias

PD: Aclaro que no necesito acceso aleatorio al menos para grabacion. Se empieza a grabar en la direccion 0 y se graba continuo hasta que se llena.
 
Pienso que con la SDR vas a estar bien.

Una pregunta importante es que FPGA vas a usar, y verificar si para esa FPGA tenes controladores apropiados para la memoria en cuestion.

Yo trabajo con Altera en la que se implementa muy facilmente un procesador Nios con controlador para la DRAM.

Una aclaracion: Para DDR solo los datos funcionan a frecuencia doble, el bus de direcciones, no.
Y una pregunta. De donde vienen los datos a esa velocidad? Tendras que verificar que el FPGA pueda soportar esa interfaz tambien

Y una ultima nota: Hay tarjetas de evaluacion muy economicas, puede convenirte usar una en vez de ponerte a crear el PCB. Dependera de cuantas unidades quieras hacer, y aunque quieras hacer produccion masiva de la tarjeta, te convendra muchisimo como primer paso realizar la pequeña inversion (50 a 100 Obamas) de una tarjeta de evaluacion que ya seguro funciona con DRAM y todo.

Saludos
 
Última edición:
chclau,

Desde ya muchas gracias por responder.

La fpga es EP3C16Q240 grado 8 y la tarjetita que dispongo solo tiene fpga, flash y reguladores. Precisamente habia buscado esta para disponer de todos los IO aunque estoy tentado por esas que tienen SDRAM incluida. Pero en estos casos, la dram que traen es de 133mhz / 16 bits SDR. Creo que no podria llegar a 200mhz con eso.

Me preocupa que cuando implemento un IP para sdram usando un megawizard, me advierte bien clarito que la maxima F de interfaz para esta fpga es 133mhz, a pesar de que en el datasheet veo que la fmax de IO es mayor y que efectivamente he probado hacerla correr internamente a 400mhz (no digo que los IO puedan llegar a eso pero si supongo que llegan a 200mhz en "lectura")

Controlador NIOS para esta parte lo descarto porque *creo* (para nada seguro) que si voy a manejar la ram desde el, supongo que implementando un PIO para la entrada de datos al fpga, cada transferencia desde su PIO a la ram serian varios ciclos de reloj lo que tiraria abajo la fmax.

Los datos vienen desde dos adc de 8 bits funcionando a 200mhz.

El fpga que dispongo es este http://www.ebay.com/itm/261508226107 y una de mis grandes preocupaciones es tener que ponerlo en zocalo a estas frecuencias.

Algo con memoria incluida seria esto http://www.ebay.com/itm/271434726780 pero tiene los problemas mencionados antes con la ram (ancho de banda total), amen de que tendria el mismo problema de tener que conectar los adc a 200mhz a traves de zocalo.

Estaba pensando en intentar hacerme una pcb para tener un prototipo funcional "con zocalo" y una vez bien definido todo, mandar a hacer 5 placas a china diseñadas por mi, donde tenga el fpga bien pegado a la memoria y los adc. El tema es que no se si dicho prototipo funcionaria a 200mhz debido a la conexion de las tiras de pines.

Edito y agrego: Ya que mencionaste Nios, se me acaba de ocurrir que podria hacer algo asi:

adc externo > pines fpga > fifo memoria interna (grande) > PIO de un nios > interfaz sdram

El tema es que por mas que hiciese correr el nios a 400mhz o lo maximo que se pudiera, igualmente no podria obtener una velocidad > 200mhz en la transferencia a la sdram con lo que se me llenaria el buffer fifo antes de poder descargarlo en la memoria.
 
Última edición:
Una Cyclone III...

Bueno, reviso lo que te dije y quiza lo mejor sea DDR, incluso en versiones muy viejas de Quartus no veo soporte para el SDR.

Pensa que aunque alguna tarjeta de evaluacion existente te limite y no soporte todos los requisitos de tu aplicacion final podes verificar aunque sea la mitad de tu aplicacion, por ejemplo uno solo de los dos ADCs, ver que te anda y despues escalar la logica a la aplicacion final en tu tarjeta.

Creo que te confundi con el Nios. La idea no es meterlo en el medio del flujo de datos, lo logico es utilizar un bus propio o estandar de Altera (Avalon) para conectar directamente desde el ADC hasta la memoria.

El Nios esta ahi nomas como algo util para hacer debugging, no para interponerse en el flujo de datos.

Enviar los datos del ADC a 200MHz a traves de conectores va a ser bastante complicadito.
La mayoria de las tarjetas estandar para ADC que usan las tarjetas de evaluacion de Altera usan los conectores HSMC que tienen tanto buses paralelos como seriales de alta velocidad(LVDS), pero para las velocidades que estas comentando me parece que usan unicamente LVDS.

No digo que sea imposible hacerlo, PCI-X era un bus paralelo que superaba con mucho esas velocidades, pero el layout tiene que ser realizado con mucho cuidado y los conectores tambien son importantes.

El Cyclone III starter board tiene DDR y HSMC, fijate que tarjetas ADC estan disponibles para el. No te digo que te lo compres, pero como referencia. Aparte de Altera, fijate otros proveedores como Terasic y Arrow que a veces hacen tarjetitas muy economicas. Yo tengo una Cyclone V BeMicro de Arrow que me salio solo 49 Obamas.

Suerte y saludos
 
Última edición:
Gracias por tus datos. En cuanto a tarjetas estoy atado a china me parece porque los envios a mi pais desde cualquier otro lado que no sean el correo oficial suelen quedar retenidos en aduana.

El soporte SDR no lo tiene quartus en los IP cores, lo haria en puro vhdl como aqui http://hamsterworks.co.nz/mediawiki/index.php/Simple_SDRAM_Controller

Y estoy de acuerdo con vos en que veo complicado pasar señales a esa velocidad por conectores. Como poder se puede pero que salga bien, con mis conocimientos actuales o tecnicas posibles en casa, es un poco una loteria.
 
Si queres mi recomendacion... pudiendo usar un controlador probado de Altera, no me arriesgaria con algo que no se quien hizo.
Mira que un controlador DRAM no es moco de pavo. Yo optaria por la memoria DDR.
 
Estoy analizando el dimm ddr de notebook del cual voy a sacar el chip y veo que tiene resistores de 22 ohms justo luego del peine de conectores.

Creo que voy a implementar lo mismo ya que es una buena forma de evitar reflexiones, aunque me resulta raro que estan en serie y no a masa.

Por otro lado, veo que la plaquita tiene las pistas compensadas en longitud, habra que hacer algo similar.

------------------------------

Edito: Luego de leer algunos PDF tecnicos, ahora entiendo cual es la funcion de las resistencias en serie en este caso.

Las tarjetas de Arrow estan muy buenas! pero lamentablemente no tienen stock de nada de lo que es barato e interesante.
 
Última edición:
Uyyy me hiciste acordar.

Mira hace unos años (unos cuantos) cuando salieron las DDR2 una empresa para la que trabajaba me encargo analizar varias configuraciones de conexion. Que si terminacion serie para los datos, paralelo para las direcciones, terminacion activa...

La conclusion? No copies para una tarjeta chiquita lo que se hace para un DIMM. El DIMM esta bastante alejado del controlador y los fenomenos de linea de transmision son mas palpables.

Pero si el componente DRAM esta al lado del FPGA lo mejor... es no poner nada.

Fijate una cosa, suponete una linea de datos. Salis del FPGA con encapsulado BGA probablemente a traves de una via, vas por una capa interna del PCB y te conectas a una via al lado del DRAM.
Si pones terminacion serie, primero que todas esas resistencias por chicas que sean ocupan lugar (te vas a llevar la sorpresa de que, todas juntas, ocupan mas ancho fisico que la memoria). Ademas, esa pista que iba muy comoda por adentro del PCB ahora le tenes que agregar dos vias mas poder conectarte con la resistencia en el medio... no te conviene.

Fijate los esquemas de referencia de los FPGA, en casi ninguno veras terminaciones por dos causas
1. Las conexiones suelen ser punto a punto (o sea, no son buses con varias memorias, sobre todo para datos, la conexion es punto a punto, y el bus de datos es el que anda a doble velocidad), y
2. Muy cortitas las conexiones, el efecto de linea de transmision es menos dominante.
 
Última edición:
Excelente dato. Coincido en que si hago la placa poniendo la memoria a menos de 1 cm del fpga es muy posible que no tengan sentido los terminadores.

Yo los pensaba poner por el siguiente razonamiento logico:

Salvando las grandes distancias entre un zocalo dimm y el zocalo de pines 2mm que tiene mi placa, la situacion era algo similar:

- Una distancia "considerable" entre el fpga y el chip de memoria (aprox unos 3-4cm) Pensalo asi: Salgo del fpga > hacia los pines de la placa > conector > ruta en la "motherboard" desde el conector > 1cm hasta la memoria.

- Al tener un conector en el medio, la señal se degrada y estoy seguro que hay reflexiones.

Nada de esto pasa en un punto a punto muy cercano como tienen las placas de evaluacion por lo que en una supuesta placa final no haria falta en teoria, pero para el prototipo de experimentacion creo que si, aunque sea minimamente en las lineas de datos y clock.

Por otro lado, te cuento que estuve experimentando un poco mas con el Qsys y disponemos (Quartus v13) de controladores DDR como tambien SDR.

Ahora la idea que manejo es tener (en Qsys):

- Clock
- Controlador SDRAM
- Componente personalizado que incluye: Captura y control de los ADC + una fifo actuando de buffer
- Nios II como controlador general de funcionamiento. No para estar en el medio de los datos, sino para activar la grabacion y una vez finalizada, leer la sdram y transferir por algun bus: RS232, USB, veremos.

Mi componente personalizado implementaria un bus Avalon Master con el cual la conexion al resto de los componentes se hace mas trivial.

Adjunto un link (en ingles) con informacion de como crear componentes propios que implementen los buses Avalon, por si a alguien mas le sirve.

http://www.alteraforum.com/forum/showthread.php?t=19053

PD: Aun le tengo miedo a DDR jaja

------------------------------------------------

Edito y agrego:

No solo el efecto "tamaño" de las resistencias se hace incomodo, sino que tambien sus terminales por mas smd que sean agregan capacitancia :(

Por casualidad tendras / alguien mas tiene un esquematico de tarjeta fpga que contenga DDR? Voy a mirar por el lado de las Xula que son open source a ver que hay para ver que puedo copiar cuando diseñe una placa final.
 
Última edición:
Queria agregar datos a este tema por mas que paso mucho tiempo.

Al final hice la siguiente configuracion: (placa mandada a hacer a china).

FPGA > zocalo > trazos igualados en longitud > resistencias en pack como tienen los dimm > memoria.

Los resistores estan solamente en las lineas de datos y clock. El bus de direcciones es directo.

La configuracion es 2 memorias SDR @ 166mhz x 16 bits. Si bien las pude hacer andar individualmente a 166mhz, estando juntas tuve que bajarme a 133mhz porque me canse de probar distintos desplazamientos de clock.

Como totalizan 32 bits y yo grabo en paquetes de 16 bits, con esos 133mhz tengo un equivalente a 266mhz.

Use el controlador SDR provisto por Quartus pero metido dentro de un componente personalizado con bus Avalon.

El componente personalizado tiene implementado un FIFO que se alimenta de la conexion a los ADC a 200mhz x 16 bits y de el salen 32 bits @ 133mhz. Esto hace que la fifo este siempre vacia a menos que el controlador sram este cambiando de filas o refrescando. Para el controlador SDRAM, la memoria es 1 chip de 32 bits aunque fisicamente sean 2 x 16 bits.

Tambien implemente un buffer circular con este componente, que captura constantemente y cuando hay un trigger marca ese punto y arranca un timer que detiene la captura cuando haya pasado 1/2 memoria desde el punto de trigger.

A partir de ese momento, se implemento un controlador DMA que transfiere los datos de la SDRAM a la memoria interna del FPGA usada por el controlador de video (para generar señal vga). Esto es controlado por NIOS.

En fin, este texto era para comentarles que si, se puede hacer una placa a 133mhz que termina capturando a 266mhz sin nada demasiado especial. Simplemente el engorro de tener que ponerle 2 memorias SDR para duplicar el ancho de banda.
 
¡Justo encontré el hilo que buscaba!... así que revivo un muerto. :D

Tengo varias consultas y veo que ando rumbeando más o menos por donde apuntaba seaarg.

Estoy haciendo un proyecto donde si o si tengo que caer en una FPGA con una/dos memorias, de momento por un tema tecnológico (evitar BGA y al mismo tiempo tener la máxima cantidad de puertos disponibles), terminé eligiendo exáctamente la misma FPGA que seaarg (casualidad o causalidad :D) y me decidí por memorias DDR (específicamente de la empresa micron "256Mb: x4, x8, x16 DDR SDRAM" que trabajan a 200MHz).

Mis condición de diseño es alcanzar una tasa de transferencia de 240MBytes/s y mis dudas son:

1- Si yo trabajo con una memoria DDR, ¿es correcto este cálculo?:

fclk=200MHz; Word=16 bits => Tasa=200MHz*16bits*2=6400 Mbit/s * 1Byte/8bits = 800 MBytes/s
fclk=200MHz; Word=8 bits => Tasa=200MHz*8bits*2=3200 Mbit/s * 1Byte/8bits = 400 MBytes/s

2- Como mi tasa de transferencia es de solo 240MBytes/s, ¿puedo hacer un underclock y trabajar con una fclk mucho menor y que las memorias no tengan inconvenientes? en este caso al cerca de 120MHz y 60MHz respectivamente (Word=16 bits, Word=8bits).

3- Suponiendo que "2-" se puediera hacer, ¿qué es más recomendable, trabajar con 16 bits o con 8 bits?
Con 8 bits el PCB se facilita un montón, pero mi fclk aumenta el doble, por ende mi diseño tiene que ser mucho mejor.

4- ¿Conviene trabajar con dos memorias, una para capturar y otra para procesar (procesamiento de video)? o ¿con una sola podría resolver todo?

Lo que más me asusta son las frecuencias con las que tengo que trabajar en PCB y por lo poco que sé de FPGA, en la familia que quiero usar (por el encapsulado), trabajar con 16bits implica usar 2 bancos en lados distintos del integrado (o sea, el PCB quedará bastante rebuscado con líneas de alta frecuencia).
 
Hola!

Bueno, el calculo es un poco mas complicado por varias razones.

Primero, que la memoria no puede estar en un burst infinito. Segundo, que tenes que enviar la informacion de fila y columna (direccion), tiempo durante el cual no se envian datos. Tercero, tenes que tener en cuenta si hay CAS latency, etc. Cuarto, esta el refresco que aunque poco frecuente, "roba" un poco de capacidad de datos de la memoria.

De todos modos y para los efectos practicos el ancho de banda obtenible es muy cercano al teorico.

Si realmente tenes el problema de que los datos estan en lados opuestos, yo optaria por 8 bits. Pero... estas realmente seguro que es asi? A mi me resulta raro...
 
Hola!

Bueno, el calculo es un poco mas complicado por varias razones.

Primero, que la memoria no puede estar en un burst infinito. Segundo, que tenes que enviar la informacion de fila y columna (direccion), tiempo durante el cual no se envian datos. Tercero, tenes que tener en cuenta si hay CAS latency, etc. Cuarto, esta el refresco que aunque poco frecuente, "roba" un poco de capacidad de datos de la memoria.

De todos modos y para los efectos practicos el ancho de banda obtenible es muy cercano al teorico.

Si, es cierto eso (según lo que se puede ver de los diagramas de tiempo), pero el ideal es más o menos lo que calculé ¿no?

Si realmente tenes el problema de que los datos estan en lados opuestos, yo optaria por 8 bits. Pero... estas realmente seguro que es asi? A mi me resulta raro...

Ese es el tema, a mi también me pareció bastante raro, pero al parecer es lo malo del encapsulado que uso, por ej. con algunas BGA eso no sucede. Subo un pdf de altera sobre memorias externas para la cyclone 3, en la tabla de la página 4 en familia "EP3C16" con encapsulado 240-pin PQFP se puede ver que solo tiene un bus de datos por c/lado del integrado (left, right, top y bottom) con su data strobe.

La verdad que si tuviera que hacer el control de 16 bits, el PCB queda bastante rebuscado, ya que tendría que unir top/left o top/right.

Sobre el tema del underclock, ¿lo puedo hacer? ¿no afecta en nada en el refresco de la memoria?.

Perdoná si te mato a preguntas, pero es que soy bastante nuevo en el tema. :D

Saludos y gracias.
 

Adjuntos

  • cyc3_ciii51009.pdf
    468.8 KB · Visitas: 15
Cosme,

Me encanta cuando coincidimos en threads :)

No puedo contestar mucho de tus preguntas porque me falta teoria, asi que tomalo como de quien viene:

Si yo estuviera haciendo algo asi, preferiria trabajar a 16 bits y a mitad de clock. Es preferible complicar la pcb a que no ande por problemas de alta frecuencia. Por supuesto que si tu entrada de datos corre a muchos mhz tenes el problema de todas maneras.

En mi experiencia, puse las resistencias serie pero luego de armar y probar me parece que no hacen falta. Definitivamente en el bus de datos de mi ADC perjudicaron la señal. En la memoria no estoy seguro porque funciona OK.

Te recomiendo que leas sobre ajustar el skew entre clock y datos en la memoria. Esto es un parametro que lo logras con el PLL interno del FPGA.

Te adjunto aqui la PCB y esquematico en kicad que termine haciendo, para que veas la distribucion de las lineas de datos y direccion. Tambien tuve dudas con lo que mencionas de los bancos del FPGA.

Y por ultimo, cuidado con el banco (fisicamente, el "de arriba" viendo la FPGA al derecho) ya que algunos pines tienen una resistencia baja (~750 ohms) entre ellas. Sugiero que antes de diseñar la PCB agarres el tester y midas entre las que pensas usar.

Te lo digo porque, vas a ver que en mi PCB los adc estan ahi arriba y, entre tener las resistencias serie y la alta velocidad, sumado a la posible no-tan-baja impedancia de salida del ADC, se me terminaron "mezclando bits" debido a esa relativamente baja impedancia de entrada del FPGA en ese banco.

Resumiendo, de mi osciloscopio uno de los canales andaba bien, y en el otro una senoidal se distorsionaba por todos lados debido a esto (hasta la entrada del ADC la señal estaba perfecta).

Finalmente, si te interesa avisame y te adjunto el proyecto de Quartus por si queres sacar idas de componentes custom, con bus avalon, la implementacion del controlador RAM, etc.
 

Adjuntos

  • motherboard.zip
    467.5 KB · Visitas: 9
Gracias seaarg por el proyecto, voy mirarlo bien y cualquier cosa te comento.

Por lo que ví del PCB hasta ahora, es más o menos lo que había averiguado (te quedó bastante bueno con el Kicad, la verdad nunca le dí mucha bola a ese programa, pero veo que es bastante potente).

¿Qué memorias son esas (vt3612164)?

Dejo la nota de aplicación AN-348, habla sobre las recomendaciones que debe tener el PCB a la hora de conectar una memoria DDR, que si bien está pensada para una Cyclone I, supongo que el principio se aplica a la familia de la III.

Lo tips que menciona (más allá de las pistas), son:

- Resistencias en serie tanto Datos, Data Strobe y Data mask lo más cerca posible de la memoria.
- Resistencias en serie tanto Address como señal de control lo más cerca posible de la FPGA.
- Resistencias de pull-up a VTT (1,25v) al final de las líneas (memoria).

Por lo que mencionó chclau al parecer no son tan necesarias esas resistencias.

Adjunto como irían esas resistencias según esa nota de aplicación:

Resistencias.jpeg
 

Adjuntos

  • an348.pdf
    441.2 KB · Visitas: 4
Última edición:
Cosme, la memoria esa no recuerdo, creo que fue una adaptacion custom de algun chip por ahi :)

Las que tengo soldadas son VT3612164T-6 que las saque de una plaquita de video gForce2MX de las viejitas AGP. Son SDR

Acordate tambien de averiguar, si mal no recuerdo en las DDR necesitas el regulador del voltaje de referencia (o esto era en las mas modernas? ya me confundi). Dicho regulador deberia andar cerca de los slots de memoria de una motherboard, lo podes pedir prestado de ahi.

En este regulador, lo importante es que tenga capacidad de corriente en ambos sentidos, sink y source.

PD: Probablemente es mucho esfuerzo, pero yo intentaria primero SIN las resistencias. Como te dije antes, para la memoria me funcionaron pero tuve que bajar de 166mhz a 133mhz para poder ajustar el skew de clock de ambos chips. Ojo que es posible que las resistencias (10 ohms) no fueran las culpables.

Porque digo sin resistencias? porque estan pensadas para evitar reflexiones en lineas largas como una motherboard. Si vos tenes el chip de ram pegado al fpga quiza no sirvan. De todos modos, vos tambien tenes un socket igual que yo asi que.... no se que recomendar mejor jaja

Hay un programita NIOS de ejemplo que es un memtest. Se usa para determinar a prueba y error (metodo divide y reinaras) cual es el skew correcto en nanosegundos.

AH! por ultimo, averigua bien, si mal no recuerdo en la Cyclone III estas limitado a 133mhz en sus ports. Internamente corre a velocidades mucho mayores. El IP core de ram te va a tirar esa advertencia y tambien te va a protestar por la seleccion de bancos.
 
Última edición:
Cosme, la memoria esa no recuerdo, creo que fue una adaptacion custom de algun chip por ahi :)

Las que tengo soldadas son VT3612164T-6 que las saque de una plaquita de video gForce2MX de las viejitas AGP. Son SDR

Ok, voy a buscarlas a ver que me dicen. Lo que ví es que pusiste un único bus de Address para las dos y lo controlas con el CS, ¿es así no? En esa situación, solo podrías controlar una memoria a la vez.

Acordate tambien de averiguar, si mal no recuerdo en las DDR necesitas el regulador del voltaje de referencia (o esto era en las mas modernas? ya me confundi). Dicho regulador deberia andar cerca de los slots de memoria de una motherboard, lo podes pedir prestado de ahi.

En este regulador, lo importante es que tenga capacidad de corriente en ambos sentidos, sink y source.

Ok.

PD: Probablemente es mucho esfuerzo, pero yo intentaria primero SIN las resistencias. Como te dije antes, para la memoria me funcionaron pero tuve que bajar de 166mhz a 133mhz para poder ajustar el skew de clock de ambos chips. Ojo que es posible que las resistencias (10 ohms) no fueran las culpables.

Porque digo sin resistencias? porque estan pensadas para evitar reflexiones en lineas largas como una motherboard. Si vos tenes el chip de ram pegado al fpga quiza no sirvan. De todos modos, vos tambien tenes un socket igual que yo asi que.... no se que recomendar mejor jaja

Supongo que viene por ahí (evitar reflexión y según donde las ponés, tirás reflexión en la pista más corta), por eso el dato que tiró chclau me pareció interesante.

Hay un programita NIOS de ejemplo que es un memtest. Se usa para determinar a prueba y error (metodo divide y reinaras) cual es el skew correcto en nanosegundos.

Ok.

AH! por ultimo, averigua bien, si mal no recuerdo en la Cyclone III estas limitado a 133mhz en sus ports. Internamente corre a velocidades mucho mayores. El IP core de ram te va a tirar esa advertencia y tambien te va a protestar por la seleccion de bancos.

Ahí me mataste, tal vez por ser nuevito en el tema. :D

Por lo que sé, se supone que la familia Cyclone 3 puede trabajar con DDR2 (no recuerdo si DDR3), por lo tanto a 200MHz debería llegar.

Me imagino (a tomarlo con pinzas, porque acá es donde peco de novato), que al usar esos pines reservados para las memorias (DQ, etc), estás usando los puertos más rápidos que tiene la FPGA y podés alcanzar esas velocidades máximas. En cambio si se usara un puerto de menor velocidad, esa frecuencia queda limitada y tal vez por eso el Warning que te tiro.

De lo que ví de tú esquemático, vos tiraste algunas líneas de datos en pines comunes, por eso tal vez qeudó limitado a esa frecuencia de 133MHz (más allá del tipo de memoria que uses).

Ojo, como mencioné antes, con 120MHz ya soy Gardel de hecho si puedo trabajar con el clock más bajo, mejor.

Editado:

Creo que esas resistencia en serie tienen dos objetivos principales:

1- Ecualizar la impedancia de las pistas por diferencia de longitud.
2- Reducir los picos de overshoot, amortiguandolos mediante la capacidad propia del puerto haciendo un mini R-C.

Entonces, como hay una nueva impedancia en la línea (la pista), si o si se generarán reflexiones que pueden ser mayor o menores según el largo de las pistas, por lo tanto tal vez a veces convenga ponerlas de un lado (memoria) o en el otro (FPGA) según donde afecte más esa reflexión.
 
Última edición:
En mi caso, simplemente puse dos memorias de 16 bits "en paralelo" en todas sus lineas excepto las de datos, para trabajarlas como un unico chip de 32 bits.

No recuerdo el esquematico ahora pero puede que haya puesto lineas diferentes para CS (por las dudas), que despues en software las maneje juntas.

Ah si! el clock tambien son 2 lineas diferentes, pero mas que nada para no cargar la salida del fpga. Internamente van casi juntos tambien (con un skew de unos nanos).

Mi origen de datos es de 16 bits (2 ADC) y la razon de usar 1 memoria (2 chips) de 32 bits fue simplemente duplicar el ancho de banda por lo que mis 133mhz se hicieron 266mhz @ 16 bits :)

El bonus fue que tambien duplique la cantidad de memoria. Para tu caso, yo no me haria tanto lio y simplemente elegiria con mucho cuidado que pines del fpga usar. Estas en lo correcto en que *creo* que tuve el problema de tener que elegir pines standard.

Lo mejor que podrias hacer es conseguirte un esquematico de una placa de desarrollo con DDR y usar los pines que ellos usen

Por ultimo: si tenes ganas, fijate de usar Kicad. En modo OpenGL tiene una herramienta fantastica para ecualizar el largo de pistas. Fijate que en mi diseño estan las tipicas vivoritas... En DDR esto se vuelve critico!!!
 
Última edición:
Ojo al piojo, muchachos, que mientras que SDR DRAM usa 3.3V "normalitos" LVCMOS o LVTTL, DDR ya usa otra tecnologia denominada SSTL, a 2.5V para DDR y a 1.8V para DDR2. A lo que voy es que si usan DDR no es tan simple 'usar cualquier pin' de la FPGA
 
Última edición:
Atrás
Arriba