Dudas Verilog

257 views
Skip to first unread message

Jose Pico

unread,
Mar 15, 2017, 8:40:42 AM3/15/17
to FPGAwars: explorando el lado libre
Hola:

Abro este nuevo tema para poder presentaros mis dudas existenciales sobre verilog que me van surgiendo cuando me documento sobre verilog y no me quedan claras.
De esta forma si alguien me las resuelve estaré muy agradecido.

Como primera duda básica querría preguntar:

que diferencia habría al sintetizar:

o sintetizar:

en el primero se usa una asignación continua ( non-blocking) y en el segundo una asignación blocking ( creo).

Aquí , entiendo que sintetizan lo  mismo ya que icestudio me indica que en ambos caso ha utilizado  5 PIOs y 9 PLBs.

Al haber una uníca instrucción perteneciente al always entiendo que da igual que sea = o <= .

Qué herramienta libre podría usar para vér el circuito sintetizado pasándole el fichero verilog .v ?


Saludos y Gracias










Auto Generated Inline Image 1
Auto Generated Inline Image 2

Juan Gonzalez Gomez

unread,
Mar 15, 2017, 9:10:53 AM3/15/17
to FPGA-WARS: explorando el lado libre
Hola Jose,

En este ejemplo se sintetiza lo mismo usando <= que =

Por regla general, al implementar circuitos secuenciales, se usa <=,  y con los combinacionales =

El código correcto sería:

module led(input wire clk, output led);

reg led;

always @(posedge clk)
  led <= !led;

endmodule


Puedes obtener el gráfico de lo que ha sintetizado (antes del emplazado y rutado) usando yosys:

yosys -p 'proc; opt; show' test.v

Te sacará algo como esto:

Imágenes integradas 1

Saludos, Obijuan


--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el-lado-libre+unsubscribe@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-li...@googlegroups.com.
Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/a42b2625-f913-4300-98d8-e8597d8c868f%40googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

Jose Pico

unread,
Mar 15, 2017, 9:16:33 AM3/15/17
to fpga-wars-explora...@googlegroups.com
Muchas Gracias!
El tema es que al ir leyendo cosas me da la sensación de estar las cosas a medias y no utilizan simbolos correctos que me llegan a confundir con qué sería lo correcto.
Ahora como tengo icestudio lo voy probando y veo si hay errores graves o no, aunque en ocasiones como esta me lo sintetiza bien en ambos casos.
Es una maravilla tener icestudio y una fpga libre para ir aprendiendo con ambos de forma fácil.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.



Para publicar en este grupo, envía un correo electrónico a fpga-wars-explora...@googlegroups.com.








--


Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.


Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/qwYr1MX4hbI/unsubscribe.


Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.


Para publicar en este grupo, envía un correo electrónico a fpga-wars-explora...@googlegroups.com.

Jose Pico

unread,
Mar 15, 2017, 5:12:59 PM3/15/17
to FPGAwars: explorando el lado libre

Hola:

No me he atrevido a Sintetizar esto:

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el-lado-libre+unsubscribe@googlegroups.com.



Para publicar en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-li...@googlegroups.com.








--


Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.


Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/qwYr1MX4hbI/unsubscribe.


Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el-lado-libre+unsubscribe@googlegroups.com.


Para publicar en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-li...@googlegroups.com.
Auto Generated Inline Image 1

Jose Pico

unread,
Mar 15, 2017, 5:18:36 PM3/15/17
to FPGAwars: explorando el lado libre
Perdón!

Era este el circuito que quería poner como posible ejemplo de cortocircuito:

Una salida  a 1 y otra  salida con un cero.    0 con 1 --> cortocircuito

Auto Generated Inline Image 1

una...@gmail.com

unread,
Mar 15, 2017, 7:28:48 PM3/15/17
to FPGAwars: explorando el lado libre
Tranquilo, ese código:
  • No es válido y da error.
  • O, ignora una asignación y sólo tiene en cuenta la segunda.
Simplemente no puedes tener dos "drivers" para una sola señal. Físicamente no se puede, y cualquier sintetizador debe dar error.

Tienes riesgo de quemar cosas por un uso inadeacuado de periféricos externos que el sintetizador desconoce. Pero en lo que respecta al interior de la FPGA, nunca tendrás problemas de este tipo. De hecho, tienes limitaciones de diseño adicionales, como te comento en el otro hilo.

Jose Pico

unread,
Mar 15, 2017, 7:34:56 PM3/15/17
to fpga-wars-explora...@googlegroups.com
Ok Gracias

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/qwYr1MX4hbI/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el-lado-libre+unsubscribe@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-li...@googlegroups.com.
Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.

Jesús Arroyo

unread,
Mar 16, 2017, 2:46:10 PM3/16/17
to FPGAwars: explorando el lado libre
Buenas Jose,

Efectivamente en Icestudio no se premiten realizar conexiones en corto, sin embargo con verilog puedes crear "cortocircuitos" lógicos. El circuito que propones sintetiza correctamente, y lo que hace es asignar un "1" lógico al led.

Existe un proyecto muy interesante que permite visualizar los ficheros ASC, es decir el rutado de los circuitos dentro de la FPGA. Éste es el proyecto: https://knielsen.github.io/ice40_viewer/ice40_viewer.html, está escrito en JavaScript.

En el caso de tu circuito ésto es lo que muestra (asignación de un 1 a la salida). Con esto puedes ver cómo queda tu circuito en la FPGA:



En Icestudio los ficheros generados se encuentran en el directorio ~/.icestudio/.build. El fichero ASC se llama hardware.asc. Puedes sintetizar tu circuito con Icestudio y luego visualizar el ASC.

Un saludo.
Auto Generated Inline Image 1

Jose Pico

unread,
Mar 16, 2017, 3:39:07 PM3/16/17
to fpga-wars-explora...@googlegroups.com
Entiendo pues que si en mi código verilog por error no se controlase la posibilidad de un cortocircuito lógico ( posibilidad que dos salidas unidas se presente un 1 y un 0 ), el sintetizador genera una "wor", añade una or para evitar el cortocircuito real y la salida es un  1 lógico.

Voy a sintetizarlo y comprobar pues que el 1 con el 0 crea la or y sale un 1.

Saludos y Mil Gracias






El 16 de marzo de 2017, 19:46, Jesús Arroyo <jesus...@gmail.com> escribió:
Buenas Jose,

Efectivamente en Icestudio no se premiten realizar conexiones en corto, sin embargo con verilog puedes crear "cortocircuitos" lógicos. El circuito que propones sintetiza correctamente, y lo que hace es asignar un "1" lógico al led.

Existe un proyecto muy interesante que permite visualizar los ficheros ASC, es decir el rutado de los circuitos dentro de la FPGA. Éste es el proyecto: https://knielsen.github.io/ice40_viewer/ice40_viewer.html, está escrito en JavaScript.

En el caso de tu circuito ésto es lo que muestra (asignación de un 1 a la salida). Con esto puedes ver cómo queda tu circuito en la FPGA:



En Icestudio los ficheros generados se encuentran en el directorio ~/.icestudio/.build. El fichero ASC se llama hardware.asc. Puedes sintetizar tu circuito con Icestudio y luego visualizar el ASC.

Un saludo.



El jueves, 16 de marzo de 2017, 0:34:56 (UTC+1), Jose Pico escribió:
Ok Gracias

El 16 de marzo de 2017, 0:28, <una...@gmail.com> escribió:
Tranquilo, ese código:
  • No es válido y da error.
  • O, ignora una asignación y sólo tiene en cuenta la segunda.
Simplemente no puedes tener dos "drivers" para una sola señal. Físicamente no se puede, y cualquier sintetizador debe dar error.

Tienes riesgo de quemar cosas por un uso inadeacuado de periféricos externos que el sintetizador desconoce. Pero en lo que respecta al interior de la FPGA, nunca tendrás problemas de este tipo. De hecho, tienes limitaciones de diseño adicionales, como te comento en el otro hilo.

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/qwYr1MX4hbI/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el-lado-libre+unsubscribe@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-lib...@googlegroups.com.

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/qwYr1MX4hbI/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el-lado-libre+unsubscribe@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-li...@googlegroups.com.
Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.

Jose Pico

unread,
Mar 16, 2017, 3:54:04 PM3/16/17
to fpga-wars-explora...@googlegroups.com
Correcto!
Tras sintetizar el código verilog con  una salida  1 y 0 juntas, no produce ningún desastre y genera un 1 lógico de salida encendiendo el led asignado.

Saludos

una...@gmail.com

unread,
Mar 17, 2017, 12:00:29 AM3/17/17
to FPGAwars: explorando el lado libre
En ese caso concreto sí. Pero no lo tomes como norma, ya que no sabes qué sucederá en otros. Este es un ejemplo en que, aunque la síntesis no de error, no se puede decir que la solución sea correcta. No por un fallo de las herramientas, sino por falta de especificación del diseñador. Tu intención no era modelar una puerta OR.

The wire and tri nets connect elements. The net types wire and tri are identical in their syntax and functions; two names are provided so that the name of a net can  indicate the purpose of the net in that model. A wire net is typically used for nets that are driven by a single gate or continuous assignment. The tri net type might be used where multiple drivers drive a net.

Logical conflicts from multiple sources on a wire or a tri net result in unknown values unless the net is controlled by logic strength.

Wired nets are of type wor, wand, trior, and triand, and are used to model wired logic configurations. Wired nets resolve the conflicts that result when multiple drivers drive the same net. The wor and trior nets create wired or configurations, such that when any of the drivers is 1, the net is 1. The wand and triand nets create wired and configurations, such that if any driver is 0, the net is 0.

Copiado de https://www.eecis.udel.edu/~elias/verilog/verilog_manuals/chap_3.pdf . El tema del strengh está en https://www.eecis.udel.edu/~elias/verilog/verilog_manuals/chap_6.pdf.

Lo que Jesús ha denominado 'cortocircuitos lógicos' es un recurso para modelar "wired logic", y tiene que ver más con la corriente/impedancia de un buffer que con la tensión o nivel lógico (aunque evidentemente están relacionados por Ohm): asumiendo que un 1 lógico implica emitir corriente por un pin, "wired logic" permite "calcular" cuál será el resultado si hay varios buffers emitiendo y cogiendo corriente del mismo pin. Digamos que un master con "nivel lógico alto débil" emite 1 mA, y otro con "nivel lógico bajo fuerte" coge 2mA del bus. Sí el resto de dispositivos del bus está en alta impedancia, tendremos un valor lógico bajo, porque el resultado es que se chupa más corriente de la que se genera.

Entenderás que nada de eso es aplicable al interior de una FPGA, porque no existe nada parecido a "niveles débiles". Están diseñadas específicamente para evitarlo.

En tu ejemplo, el sintetizador ha creado una wor, pero podría haber sido una wand, una trior o una triand. Y no tiene nada que ver con el hecho de que "controles la posibilidad de un cortocircuito lógico". Esta decisión se toma antes de evaluar el contenido que hay a la derecha de los "=". El hecho de que sea una "or" puede ser porque a quien diseñó el sintetizador le pareció lo más "natural".

Para garantizar que se implementará siempre así, deberías utilizar: https://www.youtube.com/watch?v=lys9e3AODbU

wor iout
assign iout
= Error & Wait;
assign iout
= Valid | Clear;
assign
out = iout;

A diferencia del software, en el hardware más código no implica la utilización de más recursos. De hecho, a partir de un nivel de diseño, se añaden muchísimas líneas de código que justamente optimizan el tamaño final del circuito. Aunque es un poco contra-intuitivo, ser verbose con los HDL es bueno.

Pero, personalmente, para este caso me parece más legible:

assign out = (Error & Wait) | (Valid | Clear);

o

assign out = (Error & Wait) | Valid | Clear;

En general, deberías evitar cualquier señal diferente de wire. No las necesitas, y tratar de utilizarlas sólo te llevará a código más difícil de depurar. Siempre hablando de FPGAs. Si quieres utilizar icestudio para modelar otros circuitos, no aplica nada de lo anterior.

Como observación final, "wait" es una palabra reservada en Verilog. Aunque no hay conflicto en este contexo, es prudente no utilizarla para nombrar puertos/señales.

Saludos

una...@gmail.com

unread,
Mar 17, 2017, 12:12:41 AM3/17/17
to FPGAwars: explorando el lado libre
Aquí una explicación bastante directa de por qué una sintetis sin errores no es una síntesis correcta (desde el punto de vista del diseño lógico): https://forums.xilinx.com/t5/Synthesis/Input-outputs-ports-in-Vivado-direction-mistakes-do-not-generate/td-p/466694/page/2

Synthesis tools have the requirement that the resulting gates match the functionality of the RTL description. This means that it will reproduce the functionality you described - in spite of the fact that the functionality is wrong... It is being nice by giving you the warning that "Hmmm, something doesn't look right here", but it still goes ahead and duplicates the functionality described.

Por otro lado, hay un contexto en el qué si puede ser útil el uso de "wor" y "wand": la descripción parametrizada de sistemas. Si un módulo tiene un parámetro para decidir si se sintetiza o no una parte del mismo, y su salida, cuando existe, se une mediante una puerta "or" o "and" a otra salida de otra parte del circuito, tiene sentido que la puerta no se sintetice cuando el parámetro no está activo. Por ejemplo: el bit de interrupción general de un microcontrolador. Si sólo hay una fuente de interrupción, no es necesaria ninguna puerta lógica. Si hay más de una, es interesante que se añada una or.

Aún así, se puede describir la misma funcionalidad sólo con wire. En la mayoría de sintetizadores para FPGA, si ponemos siempre la puerta, se eliminará en la fase de optimización de la síntesis si sólo tiene una entrada.

Jose Pico

unread,
Mar 17, 2017, 6:51:21 AM3/17/17
to fpga-wars-explora...@googlegroups.com
Gracias por todo, me miraré bien la documentación adjuntada.

Saludos 

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/qwYr1MX4hbI/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el-lado-libre+unsubscribe@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-li...@googlegroups.com.

1138-4EB

unread,
Mar 26, 2017, 5:54:06 PM3/26/17
to FPGAwars: explorando el lado libre

Unsupported Verilog-2005 Features


The following Verilog-2005 features are not supported by yosys and there are currently no plans to add support for them:

  • The tri, triand, trior, wand and wor net types


https://github.com/cliffordwolf/yosys

Jose Pico

unread,
Mar 28, 2017, 5:28:37 PM3/28/17
to FPGAwars: explorando el lado libre
Gracias

Jose Pico

unread,
Apr 2, 2017, 12:29:14 PM4/2/17
to FPGAwars: explorando el lado libre
Hola:

Porqué no me sintetiza bien esto?

Ver imagen adjuntada.

Saludos
Posedge-NegEdge.png

1138-4EB

unread,
Apr 2, 2017, 1:27:02 PM4/2/17
to FPGAwars: explorando el lado libre
Un registro no puede reaccionar a dos señales de reloj. Funciona por flanco ascendente o descendente, dependiendo de si está negada la entrada o no. Pero físicamente no existe circuito para Double Data Rate.

Detectar los flancos ascendentes y descendentes requiere, por tanto, dos registros: https://www.google.ch/patents/US7317773

1138-4EB

unread,
Apr 2, 2017, 1:37:32 PM4/2/17
to FPGAwars: explorando el lado libre
En la datasheet de la iCE40 se indica, que, como en el caso de los triestado, hay pines I/O que soportan DDR:

Input Register Block
The input register blocks for the PIOs on all edges contain registers that can be used to condition high-speed inter-
face signals before they are passed to the device core. In Generic DDR mode, two registers are used to sample the
data on the positive and negative edges of the system clock signal, creating two data streams
.
 
Output Register Block
The output register block can optionally register signals from the core of the device before they are passed to the
sysIO buffers. In Generic DDR mode, two registers are used to capture the data on the positive and negative edge
of the system clock and then muxed creating one data stream
.

Jose Pico

unread,
Apr 2, 2017, 5:59:21 PM4/2/17
to FPGAwars: explorando el lado libre
Hola!

Muchas Gracias de nuevo.

La idea es que estaba intentando medir el ancho de un pulso de forma que cuando detectara el pulso ascendiente iniciara un contador cuentas y que cuando detectará 
flanco descendiente parara la cuenta. 
tomando esta cuenta sabría el ancho del pulso introducido.
Esto me valdría por ejemplo para de una forma sencilla sabiendo el ancho del pulso podría establecer la velocidad de giro de un motor si este pulso me lo generase un 
encoder tipo effecto hall o un encoder de cuadratura que además tiene un orificio de home como el HDES 9140 ( este es el que tengo yo y sobre el cual estaba midiendo
los pulsos que generaba a cada vuelta ).

Entiendo que tengo que crear dos registros con relojes desfasados 180 entre ellos, que ambos detecten flanco ascendente  y a su salida usar un multiplexor.

Saludos y Mil gracias

El domingo, 2 de abril de 2017, 19:27:02 (UTC+2), 1138-4EB escribió:

Jose Pico

unread,
Apr 2, 2017, 6:31:06 PM4/2/17
to FPGAwars: explorando el lado libre
Hola:

He implementado el DDRFlip Flop conforme fichero adjunto.
Gracias
DDRFlipFlop.png

1138-4EB

unread,
Apr 2, 2017, 7:45:11 PM4/2/17
to FPGAwars: explorando el lado libre
Hola Jose,

Ten en cuenta que, como comenté en el hilo de Lorea, la señal de reloj es sagrada. Al introducir una puerta NOT, estás generando un retardo en la señal de reloj que va al registro de arriba. Por lo tanto, el desfase no será de 180º, sino mayor. Cuánto mayor, depende del periodo de tu reloj. Supongamos que estás trabajando a 10MHz, por lo que el periodo de tu reloj es 100ns; y que la puerta tiene un retardo de 2ns: el registro de abajo actuará en los instantes 0, 100, 200, etc. El de arriba lo hará en el 52, 152, 252, etc. Es decir, el duty-cycle en ambos casos es del 50% y la frecuencia de 10MHz, pero el desfase es de (52/100)*360=187,2º. En otras palabra, el registro de arriba no va a muestrear cuando haya un flanco descendente en el de abajo, que es lo esperado, sino un poco después.

Esto puede ser irrevelante para esta aplicación, y especialmente para estas frecuencias de trabajo, pero verás que puede ser un problema si el circuito funciona más rápido, o si el retardo introducido por la lógica es mayor. Por lo tanto, te recomendaría que quitaras esa puerta, y utilices verilog para especificar qué flanco de reloj quieres detectar. A mayores, evita pasar el reloj por cuaquier lógica, ya que de lo contrario es fácil ir acumulando etapas sin ser consciente. Quizá quieras contribuir a icestudio proponiendo una modificación del bloque DFF para que el flanco sea seleccionable.

Si lo haces con verilog, el sintetizador utilizará recursos propios de la FPGA con bajo skew (https://en.wikipedia.org/wiki/Clock_skew) y, probablemente, corrección de fase. Lo habitual es que haga la operación not en un solo punto de la FPGA y después lleve en paralelo el reloj positivo y su inversa utilizando dos líneas diferentes de entre las especiales para estas tareas. Si utilizas una de las PLL para ello, además lo que hace es mantener en reset la FPGA hasta garantizar que el desfase entre los dos relojes es exactamente el deseado, y después los distribuye.

----

En cualquier caso, para la aplicación que planteas no es necesario un circuito de este tipo. Cuando trabajas con FPGAs tienes que tener siempre en cuenta las frecuencias de trabajo naturales de los sistemas. Cualquier uC es normalmente igual o más lento que las plantas que se quieren controlar. Pero las FPGAs son, por lo general, mucho más rápidas. Por lo tanto, ¿por qué complicarte para hacerlo todo justo a la velocidad del motor en lugar de aprovechar tu superioridad para "ir sobrado"? Sígueme:

Digamos que el motor gira como máximo a 15k rpm, tenemos un encoder de 120 aspas y utilizamos dos fototransistores (o hall) en modo X4. Así: (15k/60)*120*4=120KHz, que es 100 veces más lento que los 12MHz de la icestick. Por lo tanto, puedes utilizar únicamente los flanjos positivos, y en el peor de los casos (cuando el motor gira a máxima velocidad) tu error temporal de lectura será de menos del 1%.

Esto cambia la perspectiva del ejercicio, ya que el objetivo no es utilizar ni imitar DDR, sino un circuito típico para sincronizar dominios de relojs: https://en.wikipedia.org/wiki/Clock_domain_crossing
Efectivamente, lo que tenemos delante es la necesidad de sincronizar dos señales "de reloj" "lentas" mesosíncronas (previsiblemente desfasadas 90º), con otra señal "rápida" asíncrona periódica: http://www.dacya.ucm.es/horten/dci/Tema2_6.PDF

Una implementación muy rápida es utilizar un solo registro, "reg", para una señal que llega de fuera, "sig", y utilizar una xor junto con el valor de "reg" para decidir si lo que ha llegado es un pulso de subida, de bajada o no ha habido cambio:

// flanco de subida: (sig ^ reg) & ~reg
// flanco de bajada: (sig ^ reg) & reg

if (rst)       begin c_en = 0;   end
else begin
if (sig ^ reg) begin c_en = ~reg; end
end

En ese caso c_en será una señal que tendrá exactamente la misma frecuencia y forma que la original, pero debidamente adaptada al dominio de reloj interno de la FPGA. Por lo tanto, puede ser usada como habilitador de un contador. Nótese que, cuando el motor gire despacio ela cuenta se incrementará notablemente: a 150rpm son 10k pulsos. Por lo tanto, puede ser interesante utilizar al menos dos contadores encadenamos (por ejemplo dos de 8 bits), en vez de uno de 16. Para más detalles, ver el hilo de Lorea.

Dicho todo lo anterior, no utilices ese código que he puesto. Es sólo didáctico, para que se entienda la idea que hay detrás. En la práctica es poco útil porque no filtra los rebotes, por lo que es muy probable que detecte más flancos de los que debiera. La solución "buena", "sencilla" y "directa" para esta aplicación es que analices detalladamente y casi estudies las diapostivas 5-10 de este enlace: http://www.eng.utah.edu/~cs3710/xilinx-docs/examples/s3esk_rotary_encoder_interface.pdf Créeme que te ahorrará muchos dolores de cabeza.

Saludos

Jose Pico

unread,
Apr 3, 2017, 10:07:57 AM4/3/17
to fpga-wars-explora...@googlegroups.com
Hola unai!

Eres mejor que Google...
Eres como el espejo espejiito mágico que todo lo sabe.
Es un placer recibir todos tus feedbacks, es todo una fuente de aprendizaje.
Ahora me pongo en modo asimilación de mail... jejjejejeje
Mil gracias!

--


Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.


Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/qwYr1MX4hbI/unsubscribe.


Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.


Para publicar en este grupo, envía un correo electrónico a fpga-wars-explora...@googlegroups.com.

Jose Pico

unread,
Apr 4, 2017, 6:53:38 PM4/4/17
to FPGAwars: explorando el lado libre
Hola:

Adjunto un Flip-Flop activado tanto por flanco positivo como por negativo, lo  que no sé muy bien la utildad ahora mismo, pero ahi lo dejo.
 
Auto Generated Inline Image 1

Jose Pico

unread,
Apr 4, 2017, 7:05:32 PM4/4/17
to FPGAwars: explorando el lado libre
Hola:

Esta sería otra forma:

Auto Generated Inline Image 1

Jose Pico

unread,
Apr 4, 2017, 7:27:10 PM4/4/17
to FPGAwars: explorando el lado libre
Hola:

Aquí una aplicación un poco más elaborada usando un flip flop de detección doble de flanco que podría valer para medir de forma bastante estimada el ancho de  un pulso introducido por la señal de reloj clk

Auto Generated Inline Image 1

Democrito

unread,
Apr 4, 2017, 8:12:12 PM4/4/17
to FPGAwars: explorando el lado libre
Hola José,

Te comento algo que hace algunos meses me dio muchos quebraderos de cabeza, y era conectar una salida y unirlo a una entrada dentro del mismo bloque. Me parece que no se debe de hacer y la manera correcta sería asignarlo como "código" verilog, en este caso sería añadir al final: assign d = qn;


Jose Pico

unread,
Apr 5, 2017, 3:01:41 AM4/5/17
to FPGAwars: explorando el lado libre

Hola!

Gracias por la sugerencia, lo tendré en cuenta.

De todas formas en esto del diseño de FPGAs gráfico la idea es que se pueda crear un módulo y este reutilizar.
En verdad el módulo no llevaría la señal de realimentación de origen y es en función de lo que quiera el diseñador realizar que la añada o no a posteriori. Esto debería de funcionar si no pierde todo el sentido del disseño gráfico.

El esquema añadiendo el bloque como un módulo y dibujándole el exterior sería:

En este cado a mi me parece que funciona correctamente.
Subo el  *.ice también

Saludos
Ex DDR FF v1.ice
Auto Generated Inline Image 1

Jose Pico

unread,
Apr 5, 2017, 3:04:57 AM4/5/17
to FPGAwars: explorando el lado libre
Hola!
 subo el *.ice por si alguien lo quiere ver o ejecutar para probarlo.

Saludos
Ex DDR FlipFlop v3 01.ice

Juan Gonzalez Gomez

unread,
Apr 5, 2017, 5:43:55 AM4/5/17
to FPGA-WARS: explorando el lado libre
En versiones anteriores de icestudio había un bug que no permitía conectar una señal de salida a una de entrada en el propio bloque
(a lo mejor demócrito se refería a eso)

En la 0.3-RC está solucionado, y este tipo de conexiones se pueden hacer sin problemas (a gusto del diseñador)

Saludos, Obijuan

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el-lado-libre+unsubscribe@googlegroups.com.

Para publicar en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-li...@googlegroups.com.
Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.

Democrito

unread,
Apr 5, 2017, 5:57:44 AM4/5/17
to FPGAwars: explorando el lado libre
Tomo nota!

Jose Pico

unread,
Apr 5, 2017, 6:16:28 AM4/5/17
to FPGAwars: explorando el lado libre
Ok

1138-4EB

unread,
Apr 5, 2017, 7:27:04 AM4/5/17
to FPGAwars: explorando el lado libre
Hola José, Democrito y cia,

En principio, el primer diseño de José, el que tiene una única entrada 'd' y la realimentación, no debería funcionar. Si lo hace correctamente es porque Icestudio o el sintetizador están añadiendo información no especificada: el valor inicial. Si, por lo que sea, 'd' empieza con U, todas las señales serán U durante toda la ejecución, puesto que "not U = U". Si 'q1' y 'q2' empiezan con un valor lógico válido, sea cual sea, funcionará. Aunque puede haber un glitch inicial. La solución es tan sencilla como añadir un reset. Práctica que te recomiendo tomar como norma para cualquier registro. Que sea un reset síncrono o asíncrono es menos importante.

Por otro lado, en cuanto a la realimentación en sí, no es problemática en este caso porque hay un registro en medio. En otro caso, cuidado con los loops lógicos, que suelen dar errores poco intuitivos. Otro "fenómeno" que puede aparecer son los latches: https://www.doulos.com/knowhow/fpga/latches/

En el segundo circuito no creo que haya ningún "peligro". Lo único ¿por qué utilizas dos entradas de reloj?

Saludos

1138-4EB

unread,
Apr 5, 2017, 7:29:07 AM4/5/17
to FPGAwars: explorando el lado libre

Jose Pico

unread,
Apr 5, 2017, 7:40:04 AM4/5/17
to FPGAwars: explorando el lado libre


El miércoles, 5 de abril de 2017, 13:27:04 (UTC+2), 1138-4EB escribió:
Hola José, Democrito y cia,

En principio, el primer diseño de José, el que tiene una única entrada 'd' y la realimentación, no debería funcionar. Si lo hace correctamente es porque Icestudio o el sintetizador están añadiendo información no especificada: el valor inicial. Si, por lo que sea, 'd' empieza con U, todas las señales serán U durante toda la ejecución, puesto que "not U = U". Si 'q1' y 'q2' empiezan con un valor lógico válido, sea cual sea, funcionará. Aunque puede haber un glitch inicial. La solución es tan sencilla como añadir un reset. Práctica que te recomiendo tomar como norma para cualquier registro. Que sea un reset síncrono o asíncrono es menos importante.

   R: Menos mal que el sintetizador es listo! Tomo nota! intentaremos depurarnos....jejej 
       Si se inicia el valor del registro con un valor inicial 0 o 1 entiendo que debería funcionar siempre lo único que empezaría de con un 1 o un 0.
       El ejemplo es un simple ejemplo didáctico. 
  

Por otro lado, en cuanto a la realimentación en sí, no es problemática en este caso porque hay un registro en medio. En otro caso, cuidado con los loops lógicos, que suelen dar errores poco intuitivos. Otro "fenómeno" que puede aparecer son los latches: https://www.doulos.com/knowhow/fpga/latches/

   R: Entiendo que siempre hay que intentar evitar que se creen latches, por que no es recomendable mezclar latches con Flip Flops. Se puede perder un poco el control de  
       las cosas. 


En el segundo circuito no creo que haya ningún "peligro". Lo único ¿por qué utilizas dos entradas de reloj?

  R: los de los dos relojes no sirven para nada, fue un flash, luego lo hice con un único reloj.  Un flash de la nocturnidad ....  
 

Saludos

Unai Martinez

unread,
Apr 5, 2017, 7:57:20 AM4/5/17
to FPGA-WARS: explorando el lado libre
Si se inicia el valor del registro con un valor inicial 0 o 1 entiendo que debería funcionar siempre lo único que empezaría de con un 1 o un 0.
El ejemplo es un simple ejemplo didáctico. 

Efectivamente. A eso me refería con "glich". Igual quieres contar los pulsos positivos y ¡resulta que el circuito cuenta los negativos! Si es una señal con un 50% de duty-cycle, da igual. Pero este tipo de circuito es para medir pulsos irregulares
 
R: Entiendo que siempre hay que intentar evitar que se creen latches, por que no es recomendable mezclar latches con Flip Flops. Se puede perder un poco el control de  
       las cosas.

Efectivamente. Básicamente un latch no es síncrono, porque mientras el enable esté activo la salida toma el valor de la entrada independientemente del reloj. Esto complica el análisis temporal del circuito. Prácticamente siempre se podrá añadir un reloj, obteniendo un FF, y la funcionalidad no se verá afectada.
 
Aclarado lo de los relojes.

Saludos

Miquel Servera

unread,
Apr 5, 2017, 5:00:48 PM4/5/17
to FPGAwars: explorando el lado libre
Mier.... cada vez que os leo me doy mas cuenta de lo tonto que soy. :(

El miércoles, 15 de marzo de 2017, 13:40:42 (UTC+1), Jose Pico escribió:
Hola:

Abro este nuevo tema para poder presentaros mis dudas existenciales sobre verilog que me van surgiendo cuando me documento sobre verilog y no me quedan claras.
De esta forma si alguien me las resuelve estaré muy agradecido.

Como primera duda básica querría preguntar:

que diferencia habría al sintetizar:

o sintetizar:

en el primero se usa una asignación continua ( non-blocking) y en el segundo una asignación blocking ( creo).

Aquí , entiendo que sintetizan lo  mismo ya que icestudio me indica que en ambos caso ha utilizado  5 PIOs y 9 PLBs.

Al haber una uníca instrucción perteneciente al always entiendo que da igual que sea = o <= .

Qué herramienta libre podría usar para vér el circuito sintetizado pasándole el fichero verilog .v ?


Saludos y Gracias










Reply all
Reply to author
Forward
0 new messages