Ir al contenido principal

Placa de desarrollo Altera Cyclone II EP2C5T144 FPGA Mini

En un artículo anterior ya analizamos una placa de desarrollo FPGA con un precio muy interesante. Hoy os traigo otra, que aunque es de gama baja, es algo más potente (es una Cyclone II, concretamente una EP2C5T144C8N).  La placa de desarrollo Altera Cyclone II EP2C5T144 FPGA Mini puede encontrarse en Internet a unos 20 Euros o incluso menos.

Placa EP2C5T144C8N

Esta FPGA tiene 4068 elementos lógicos, así que con ella podremos acometer proyectos de una envergadura media (no está nada mal para el precio).

Algunas características reseñables son:

  • Dispone de un regulador de tensión de 1,2V para el core de la FPGA y otro de 3,3V para los puertos de entrada/salida. La placa se alimenta con 5V.
  • Oscilador a 50Mhz (la FPGA soporta hasta 300Mhz). Dispone de dos PLLs.
  • Varios bloques de RAM de 4Ks (total: 119.898 bits).
  • Una EEPROM EPCS4 de 4Mbit (sólo programable a través del puerto AS).
  • Todos los pines de E/S están conectados a las cabeceras y están bien identificados en el PCB.
  • En la placa hay 4 leds (uno conectado a VCC y no programable) y un botón de reset.
  • Soporta desarrollo basado en Nios II.
El esquemático de la placa es el siguiente.

Cyclone-II-FPGA-Board-FZ0697-4

En la página oficial de Altera está disponible todas la información sobre la serie Cyclone II:

https://www.intel.la/content/www/xl/es/support/programmable/support-resources/devices/cyclone-ii-support.html

He usado el mismo montaje para el sumador de dos bits con el que probamos la placa basada en EP1C3T144.

Esquema

Sólo he tenido que cargar el proyecto en Quartus v.11 y cambiar el modelo de FPGA. Obviamente he tenido que cambiar los pines en el pinplanner. He usado los pines 142 y 143 para salida, y 139 y 141 como entradas. Afortunadamente, en esta placa es fácil localizar los pines, ya que vienen bien indicados en el PCB.

pinplanner

Tras volver a sintetizar el circuito, como digo, sin ningún cambio, todo ha funcionado a la primera tal y como se ve en el siguiente vídeo.

Comentarios

Entradas populares de este blog

Creando firmas de virus para ClamAV

ClamAv es un antivirus opensource y multiplataforma creado por Tomasz Kojm muy utilizado en los servidores de correo Linux. Este antivirus es desarrollado por la comunidad, y su utilidad práctica depende de que su base de datos de firmas sea lo suficientemente grande y actualizado. Para ello es necesario que voluntarios contribuyan activamente aportando firmas. El presente artículo pretende describir de manera sencilla cómo crear firmas de virus para ClamAV y contribuir con ellas a la comunidad.

Manejo de grafos con NetworkX en Python

El aprendizaje computacional es un área de investigación que en los últimos años ha tenido un auge importante, sobre todo gracias al aprendizaje profundo (Deep Learning). Pero no todo son redes neuronales. Paralelamente a estas técnicas, más bien basadas en el aprendizaje de patrones, también hay un auge de otras técnicas, digamos, más basadas en el aprendizaje simbólico. Si echamos la vista algunos años atrás, podemos considerar que quizá, la promesa de la web semántica como gran base de conocimiento ha fracasado, pero no es tan así. Ha ido transmutándose y evolucionando hacia bases de conocimiento basadas en ontologías a partir de las cuales es posible obtener nuevo conocimiento. Es lo que llamamos razonamiento automático y empresas como Google ya lo utilizan para ofrecerte información adicional sobre tus búsquedas. Ellos lo llaman Grafos de Conocimiento o Knowledge Graphs . Gracias a estos grafos de conocimiento, Google puede ofrecerte información adicional sobre tu búsqueda, ad...

Ingeniería inversa de un parche de Microsoft Windows

A estas alturas ya hemos asumido que la seguridad total en Internet es, cuanto menos, un mito. Ningún software está libre de vulnerabilidades, y por mucha auditoría, test de intrusión o pruebas de fuzzing que nos empeñemos en hacer, ninguna metodología puede demostrar sin lugar a dudas que un software es 100% seguro. Ante este panorama, hay dos tendencias mayoritarias a la hora de hacer públicas las vulnerabilidades. Por un lado, están los que piensan que cuando se descubre un fallo ha de hacerse público de forma inmediata. En este escenario, la publicación de una vulnerabilidad es el pistoletazo de salida para una carrera entre el desarrollador para sacar el parche y los "malos" para lograr explotarla. Esta política es conocida como full disclosure . Por otro lado, tenemos a los siguen una política responsible disclosure , que abogan por mantener la vulnerabilidad en secreto hasta la salida del parche por parte del desarrollador. Sin entrar en cuestiones filosóficas que no...