Contexto
Tenía unos pocos días para implementar en el Zynq de la Parallella el forzador brutal de MD5 para proponerlo a un evento.
Como veía que se me venía difícil, intenté prepararme un [entorno de TDD] que no usé, pero me puso en sintonía.
(Nota: cada texto entre llaves indica un link que aún no está disponible, en algún momento actualizaré)
Sabía algo de VHDL, pero mi punto de entrada a esa plataforma es Verilog así que intenté aprender un poco [migrando ejemplos] e investigando y eso me dejó con soltura en el lenguaje y el entorno de desarrollo.
En lugar de respetar el plan que me había propuesto, fui más tipo blitzkrieg, tomé algunos componentes de la migración y los hice funcionar juntos, en una primera etapa un contador con botones de start, stop y reset, display de 7 segmentos y unos leds de estado, lo cual ocupa casi nada de la PL disponible:
 |
| Sin el pipeline |
Luego agregué el pipeline:
 |
| Diagrama de bloques simplificado |
Y lo fui implementando stage por stage, primero a mano y luego me cansé y programé un [generador en C]. Tambien hice una salida de referencia con los valores intermedios y conectando sucesivamente la entrada del selector de display a estos estados intermedios en el pipeline, verifiqué que funcionara ok.
 |
| 8 stages |
Y así hasta el stage63... puse lógica de detección de coincidencia y perdí un tiempo ridículo en conseguir que start/stop, reset, found, done y running hicieran lo que yo quería.
 |
| El pipeline completo |
Resultados
Tengo un circuito que calcula 4 GHashes en 40 segundos, esto es 100 MHashes por segundo, que es exactamente lo que había previsto.
 |
| Los IO no importan pues no harían falta en cada instancia, no? |
Para la demo y para github lo instancié ocho veces, se acerca a 1100 MHashes que había alcanzado con GPGPU. Tambien para probar la superficie instancié 10 pero sin la lógica necesaria para distribuir los rangos de exploración, las potencias de 2 son más fáciles.
Deuda técnica y aprendizajes
Como que esto fué tiro con arco zen, pero sin la sabiduría que implica, casi que manotazos de ahogado, entiendo que si funciona es por una acumulación inconsciente de conocimiento, hay partes que no puedo explicar responsablemente.
El tiempo de síntesis e implementación arrancó en cuatro minutos y se duplicó con el pipeline completo, yo aproveché para ir haciendo estas entradas en el blog o ir pensando el siguiente paso (sin salvar, que puede afectar el flujo actual o siguiente), no es bueno irse a colgar ropa o ponerse a pensar en otra cosa.
Cerca de cuarenta horas a lo largo de cuatro días me llevó esto.
Cuando aprenda a [simular] supongo que será todo más fluido.
Hay que mirar permanentemente los warnings, sobre todo los critical warnings, varias veces me avisaron de cables no conectados.
Sin embargo, en la etapa de debugging del pipeline ocurrió algo muy interesante: por desviar hacia el display etapas intermedias y no usar la salida de pipeline para nada, lo quita por optimización:
 |
| Efecto de conectar el display al stage00 en lugar del stage63 |
Seguí con la parte 6
