VHDL ayuda

[Jorge Luis Ramirez Torres]

Hola amigos, quisiera solicitar su ayuda, estoy ya tres días consecutivos envuelto en un problema que no logro resolver,

Me encuentro realizando una comunicación serial recibo los datos, y luego los presento en una salida de 9 leds, aparentemente tengo un retraso en la presentación de los datos

es decir:

1_ cargo el programa a la tarjeta, 

2_ envío 39 datos desde matlab

3_ los leds me muestran en el primer dato todo apagado ("1 1111 1111" unos porque la tarjeta trabaja en bajo)

4_al culminar ese envio de datos repito el proceso pero sin volver a  cargar el programa osea vuelvo a enviar datos desde matlab, 

5_ cuando debería presentarse el primer dato se presenta en su lugar el ultimo dato, 

6_ cuando debería presentarse el segundo dato se presenta en su lugar el primer dato

7_ y así sucesivamente hasta que cuando debería presentarse el ultimo dato se presenta el dato penúltimo, y ahí termina el proceso

Nota:en la lista sensitiva del process si coloque todas las señales a ser leidas dentro de dicho process.

Parece que se guardan los datos en el vector correspondiente pero me presenta el dato en el siguiente ciclo de process, y 

almacena el siguiente process, pero no lo presenta hasta la ejecucion del siguiente process. 

en otras palabras es como si en cada process hiciera la ejecucion en el siguiente orden:

1_ presenta - 2_almacena....

en lugar de hacer:

1_almacena- 2_presenta

De verdad desde ya agradezco mucho su colaboración y experiencia en este tema  

Saludos amigos...

[Renzo Bechler]

Podrias enviar alguna parte , significativa con el problema, del codigo? parece que tenes un buffer circular en el cual tenes un shift con respecto al primer lugar. puede estar en el orden en el cual recibis y mostras tambien. 

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Sebastián Escarza DCIC]

Hola, por lo que describís parecería como que tu implementación tiene un nivel de retardo adicional para presentar los datos. Puede que los datos estén llegando correctamente, pero que se demoren para llegar a los LEDs, como si tuvieras una etapa de latcheo entre el búfer de recepción y los LEDs. ¿Estás usando un registro para manejar la salida por los LEDs? Porque si es así, puede que al sistema le haga falta un flanco de reloj adicional para que estos registros emitan el dato por la salida (y los LEDs se actualicen). Obviamente, son todas conjeturas ya que estaría faltando información sobre cómo estructuraste tu sistema.
Saludos!

Sebastián

[Jorge Luis Ramirez Torres]

hola amigos, con respecto al código y la pregunta:

¿Estás usando un registro para manejar la salida por los LEDs?

Estoy usando simplemente esto:

signal Dato_aux: STD_LOGIC_VECTOR(9 downto 0);

signal Dato_aux_lsb: STD_LOGIC_VECTOR(6 downto 0);

signal Dato_aux_msb: STD_LOGIC_VECTOR(6 downto 0);

y los declaro después de la arquitectura y antes del process, 

y en la entidad tengo esto:

entity RecepSerial is

    Port ( baud : in  STD_LOGIC;

 clk_transfer : out  STD_LOGIC;

                          Rx : in  STD_LOGIC;

                      Dato_completo : out  STD_LOGIC_VECTOR (13 downto 0)

 );

end RecepSerial;

luego en el programa básicamente luego de varios ifs y demás cosas termino haciendo esta asignacion:

Dato_completo <= not (Dato_aux_lsb & Dato_aux_msb);

nada más. Se supone que ahi debería presentar pero sigo teniendo un tiempo de retardo,,

Nota: Ya hice la prueba de incluir dentro del process como variables std_logic_vector a:  

Dato_aux,  Dato_aux_lsb,  Dato_aux_msb, 

pero no dio resultado mas bien resulto peor porque se desfasan los datos no se une adecuadamente Dato_aux_lsb con el Dato_aux_msb del tiempo que le corresponde sino que se unen Dato_aux_lsb de un tiempo con el Dato_aux_msb del siguiente tiempo,

ademas estoy usando un generador de baudios donde basicamente hago un divisor de frecuencia, que me envia la señal baud y el if que abarca todo mi programa de recepción es este:

if (baud'event and baud='0') then

Gracias por su amable atención amigos

[Renzo Bechler]

perdón, por que es de 10 bits el signal Dato_aux? este lo utilizas para mostrar en los 9 LEDs? 

[Jorge Luis Ramirez Torres]

Dato_aux, es de 10 bits porque el dato que debo recibir es de 8 bits, según el protocolo,

viene 1 bit de arranque y 1 bit de parada, y asi suman 10;

 A Dato_aux lo utilizo pero para ir almacenando bit por bit, desde la posición 0 hasta la posición 9, 

pero la posición 0 junto con la posición 9 me sirven para comprobar que el dato se ha almacenado correctamente,

y por lo tanto para entrar a transferir los datos primero desde Dato_aux hacia Dato_aux_lsb, y en el siguiente ciclo (o siguiente dato a recibir) desde Dato_aux hacia Dato_aux_msb, esto debido a que necesito enviar un numero grande que no entra en 8 bits, entonces lo mando en dos paquetes(de los cuales solo utilizo 7 bits de cada uno porque tuve problemas con 8 bits) y luego tengo que unirlos,,, y los uno usando: 

Dato_completo <= not (Dato_aux_lsb & Dato_aux_msb);  (lo niego porque mi tarjeta trabaja en bajo y a Dato_completo le asigno los valores de las salidas(leds) )

claro que dato completo tiene 14 bits, sin embargo yo solo estoy visualizando 9 por que no consegui mas leds por lo pronto,, 

saludos,,,

[Sebastián Escarza DCIC]

Hola, quizás el retardo se introduzca al calcular Dato_completo. Lo que creo que hay que ver es si esta asignación:

Dato_completo <= not (Dato_aux_lsb & Dato_aux_msb);

...sintetiza lógica combinacional, o secuencial. Si es el segundo caso, la asignación se producirá sólo ante cambios de la señal de  clock. ¿La asignación está dentro o fuera de un process? ¿Está dentro de un if cuya condición sea un flanco de una señal como por ejemplo baud?
Haría falta tener más contexto del código donde está la asignación y así ver si la misma introduce el fatídico retardo adicional. Saludos!

Sebastián

Pd: perdón por la preguntas pero estoy mucho más acostumbrado a verilog que a vhdl

--

[Jorge Luis Ramirez Torres]

Hola, un buen día,,

Y con respecto a las dos preguntas:

¿La asignación está dentro o fuera de un process? 

La asignación si esta dentro de un process, de hecho todo mi programa esta dentro de un process, no tengo nada fuera.

¿Está dentro de un if cuya condición sea un flanco de una señal como por ejemplo baud?

Si esta dentro de un if de ese tipo, uso este if:

if (baud'event and baud='0') then

Y ademas toda la lógica de programación esta dentro de ese if.

En otras palabras ese if esta dentro del process, y dentro de ese if esta el resto de la programación,(nada fuera ni de ese if ni del process) por lo tanto con respecto a si es que sintetiza lógica combinacional o secuencial, la respuesta seria que sintetiza lógica secuencial.(por supuesto en ese bloque)

saludos

[Rodrigo Pardo]

Hola. No me imagino cómo funcionará la ejecución por pasos que estás haciendo, si es que entendí correctamente que lo hacés. Aun así te pregunto si quizás quieras probar hacer una asignación concurrente, fuera del process, de la señal dato_completo en otra señal y visualizar esta última en los LEDs a ver qué sucede.

Un saludo.

[Renzo Bechler]

Por ahi tiro una primera prueba, por las dudas no sea así, trata de realizar esta ultima asignación "Dato_completo <= not (Dato_aux_lsb & Dato_aux_msb);" fuera de un process cuya lista de sensibilidad (o funcionamiento interno) dependa de un reloj. debería ser un combinacional puro (a la salida de los secuenciales)

[Rodrigo Pardo]

Bueno, es lo mismo que decía yo, solo que por algún motivo inventé una variable innecesaria. Además yo probaría ver el lsb o el msb directamente en los LEDs, para asegurarme de que no haya algún retardo por la asignación, que no debería, ¿no?

[Jorge Luis Ramirez Torres]

Hola,, 

Respecto a: 

probar hacer una asignación concurrente, fuera del process, de la señal dato_completo en otra señal y visualizar esta última en los LEDs a ver qué sucede.

Gracias, tome el consejo sin embargo los resultados siguen siendo los mismos.

Y con respecto a  trata de realizar esta ultima asignación "Dato_completo <= not (Dato_aux_lsb & Dato_aux_msb); fuera del process,,

Me resulta un poco complicado debido a la logica de funcionamiento del programa que ya lo envió en el próximo comentario.

[Jorge Luis Ramirez Torres]

El código es el siguiente:

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

library IEEE;

use IEEE.STD_LOGIC_1164.ALL;

-- Uncomment the following library declaration if using

-- arithmetic functions with Signed or Unsigned values

use IEEE.NUMERIC_STD.ALL;

-- Uncomment the following library declaration if instantiating

-- any Xilinx primitives in this code.

--library UNISIM;

--use UNISIM.VComponents.all;

entity RecepSerial is

    Port ( baud : in  STD_LOGIC;

           Rx : in  STD_LOGIC;

 Dato_completo : out  STD_LOGIC_VECTOR (13 downto 0)

 );

end RecepSerial;

architecture Behavioral of RecepSerial is

signal Dato_aux: STD_LOGIC_VECTOR(9 downto 0) := "0000000000";

signal Dato_aux_lsb: STD_LOGIC_VECTOR(6 downto 0) := "0000000";

signal Dato_aux_msb: STD_LOGIC_VECTOR(6 downto 0) := "0000000";

begin

Adquisicion: process (baud, Rx, Dato_aux)

variable luz_RX:integer:=0;

variable indice: integer:=0;

variable conteo: integer:=0;

begin

if (baud'event and baud='0') then

if (Rx='0' and luz_RX=0) then 

luz_RX := 1;

indice :=0;

end if;

if luz_RX=1 then

      

Dato_aux(indice)<=Rx;

if indice > 8 then

luz_RX := 0;

if (Dato_aux(0)='0' and Dato_aux(9)='1') then

conteo:= conteo + 1;

--Entrando a recibir LSB

if conteo = 1 then

Dato_aux_lsb <= Dato_aux(7 downto 1);

end if;

--Entrando a recibir MSB

if conteo = 2 then

conteo:=0;

Dato_aux_msb <= Dato_aux(7 downto 1);

Dato_completo <= not (Dato_aux_lsb & Dato_aux_msb);

end if;

end if;

end if;

indice := indice + 1;

end if;

end if;

end process;

end Behavioral;

[Jorge Luis Ramirez Torres]

Con respecto a: ver el lsb o el msb directamente en los LEDs,:

NO HICE LO MISMO SIN EMBARGO A LA SIGUIENTE DECLARACIÓN:

signal Dato_aux_msb: STD_LOGIC_VECTOR(6 downto 0) := "0000000";

que como sabemos esta antes del del begin de la arquitectura

LA CAMBIE POR:

variable Dato_aux_msb: STD_LOGIC_VECTOR(6 downto 0) := "0000000";

que como sabemos esta antes del del begin del process

Y LOS RESULTADOS FUERON: que se presentaban los datos de Dato_aux_lsb, en el momento 

oportuno, sin embargo los datos de Dato_aux_msb seguian manteniendo el mismo retraso, 

por lo que resulto en una combinacion de un numero lsb de un tiempo con un numero msb de un tiempo atrasado.

[Jorge Luis Ramirez Torres]

Según lo anterior dicho resulta lógico llegar a la conclusión de cambiar la otra declaración: Dato_aux_lsb tambien, en incluirla antes del begin del process, y lo realice; luego también con Dato_aux,, pero los resultados fueron catastróficos, pues al parecer empezó a arrojar datos basura,, 

[Rodrigo Pardo]

¿En simulación te anda?

[Rodrigo Pardo]

Acá te hice algunos comentarios y cambios. Fijate qué te parece

Adquisicion: process (baud, Rx, Dato_aux)

variable luz_RX:integer:=0;

variable indice: integer:=0;

variable conteo: integer:=0;

begin

if (baud'event and baud='0') then

if (Rx='0' and luz_RX=0) then 

luz_RX := 1;

indice := 0;

end if;

if luz_RX=1 then

      

Dato_aux(indice) <= Rx;

if indice = 9 then

--if (Dato_aux(0)='0' and Dato_aux(9)='1') then --Dato_aux(9) todavía no vale 1. No hasta que salís del process y volves a entrar y el primer dato no te lo imprime.

   -- recién en la segunda vez que la evaluás está en 1 por el envío anterior. (Ver siguiente comentario) Podríamos sacar esto, para

-- probar, omitiendo el chequeo de esos bits.

if conteo = 0 then --Entrando a recibir LSB

Dato_aux_lsb <= Dato_aux(7 downto 1);

conteo:= conteo + 1; --Cambié un poco el if para entenderlo mejor, pero es la misma funcionalidad. Usá el que quieras.

elsif conteo = 1 then --Entrando a recibir MSB

-- Dato_aux_msb <= Dato_aux(7 downto 1); --La señal dato_aux_msb no se asigna hasta que no se sale del process,

  -- cuando la lees en la siguiente linea tiene otro valor. Así que lo reemplacé.

  -- http://stackoverflow.com/questions/5060635/how-does-signal-assignment-work-in-a-process

Dato_completo <= not (Dato_aux_lsb & Dato_aux(7 downto 1));

conteo := 0;

end if;

--end if;

luz_RX := 0;

end if;

indice := indice + 1;

end if;

end if;

end process;

[Sebastián Escarza DCIC]

Hola, no lo miré muy en detalle y estoy desde el celu, pero probá cambiar esto:

Dato_aux_msb <= Dato_aux(7 downto 1); Dato_completo <= not (Dato_aux_lsb & Dato_aux_msb);

Por esto:

Dato_completo <= not (Dato_aux_lsb & Dato_aux(7 downto 1) );

... evitando usar Dato_aux_msb como registro intermedio, y de esa manera eliminando el nivel de retardo intermedio.
Saludos!

Seba

[Rodrigo Pardo]

Personalmente esto que te planteé en el mail anterior de que todo te queda retrasado "medio" dato, lo solucionaría haciendo dos procesos concurrente y una asignación concurrente. Te paso mi código. No lo probé porque no tengo donde compilarlo y simularlo acá.

architecture Behavioral of RecepSerial is signal Dato_aux: STD_LOGIC_VECTOR(9 downto 0) := "0000000000"; signal Dato_aux_lsb: STD_LOGIC_VECTOR(6 downto 0) := "0000000"; signal Dato_aux_msb: STD_LOGIC_VECTOR(6 downto 0) := "0000000"; signal adquirido: STD_LOGIC := '0'; begin Adquisicion: process(Rx, baud) variable luz_RX:integer:=0; variable indice: integer:=0; begin if (baud'event and baud='0') then if (Rx='0' and luz_RX=0) then luz_RX := 1; indice := 0; end if; if luz_RX = 1 then Dato_aux(indice) <= Rx; if indice = 9 then adquirido <= '1'; luz_RX := 0; elsif adquirido <= '0'; end if; indice := indice + 1; end if; end if; end; Procesamiento: process (Dato_aux, adquirido) variable conteo: integer:=0; begin if (adquirido'event and adquirido='1') then if (Dato_aux(0)='0' and Dato_aux(9)='1') then if conteo = 0 then --Entrando a recibir LSB Dato_aux_lsb <= Dato_aux(7 downto 1); conteo:= conteo + 1; elsif conteo = 1 then --Entrando a recibir MSB Dato_aux_msb <= Dato_aux(7 downto 1); conteo := 0; end if; end if; end if; end process Procesamiento; Dato_completo <= not (Dato_aux_lsb & Dato_aux_msb ); end Behavioral;

[Jorge Luis Ramirez Torres]

Hola

 

Seba, con respecto a:

evitando usar Dato_aux_msb como registro intermedio,,

lo acabo de intentar, me dio el resultado que me daba cuando declaraba Dato_aux_msb dentro del process

o sea que se arregla Dato_aux_lsb, pero Dato_aux_msb, continua retrasado, parece que deberia arreglarse msb pero no es asi

no se porque pero el que se arregla es lsb.

Y una cosa mas aquello funcionó asi cuando mando por segunda vez los datos desde matlab, luego de haber programado la tarjeta,

mientras que cuando le envio los datos desde matlab justo después de cargar en la tarjeta, inicia presentando desde el segundo dato, 

Rodrigo, estoy probando tu código en este momento, veamos que pasa,, 

saludos,

[Rodrigo Pardo]

Claro, la segunda vez funciona porque queda como dato "basura" un 1 en el bit con subíndice 9 del arreglo.

--

[Jorge Luis Ramirez Torres]

Osea la segunda vez que envia los datos presenta todo un arreglo, no solo el subindice 9,

sino el ultimo arreglo lo presenta como primero, en msb, y en lsb ahi si presenta el primer dato en el primer lugar.

Acabo de probar el código que me envías pero también tiene un retraso entre msb y lsb, y justo cuando

se presenta un cambio en msb, comienza a presentar los datos como mas rapido de lo que esta presentando normalmente,

esto esta muy raro,, 

no se porque la tarjeta no presenta los datos a su debido tiempo

[Rodrigo Pardo]

¿Cuál de los dos códigos probaste?

[Jorge Luis Ramirez Torres]

Probe el ultimo que enviaste, ya estoy revisando el primero

[Alejandro Grosso]

Estimado Jorge:   te adjunto una versión de un transmisor receptor serie basado en el diseño que presenta Niklaus Wirth (Autor)

en el libro Digital Circuit Design for Computer Science Students: An Introductory Textbook 23 ago 1995.

El diseño lo hice funcionar para una fpga de actel con un clock de 40 MHz. El pre-escaler del diseño está pensado para dividir la frecuencia del clock de manera que puedas tomar 16 muestras de Rx cuando transmites a 9600 baudios.

Viendo tu especificación te comento algunos detalles:

Cuando especifiques hardware no pienses que es como programar.

Cuando ponés un if then else en VHDL tenés que imaginarte que la herramienta de síntesis lo va a implementar con un multiplexor.

Cuando ponés un if then sin else la herramienta de síntesis te va a sintetizar un flip-flop disparado por flancos si en la condición usas 'event, o te va a sintetizar uno sensible al nivel en caso contrario. Esto se debe a que cuando la condición no se cumple la señal debe mantener su valor y la forma de lograrlo es con un flip-flop.

La mayor parte de tu diseño deberiás poderlo especificar con sentencias concurrentes.

Los procesos en general deberías utilizarlos para especificar lógica combinacional de proximo estado y de salida de una máquina de estado. O en su defecto para escribir un nuevo estado en tu circuito.

Por ejemplo podés especificar todos los registros de tu circuito utilizando tres señales.

A_reg (que es la salida del registro). A_input (que es la entrada del registro) y A_write (que es la habilitación de escritura en el registro). Luego con sentencias concurrentes especificás la lógica combinacional de tu circuito para calcular todas las entradas a los distintos registros de tu circuito. Finalmente con un proceso que depende del clock escribís el nuevo estado de tu circuito.

cambio_estado: process (clk)

                        begin

                            if (clk='1' and clk'event) then

                                 If (A_write='1') then

                                    A_reg<=A_input;

                                 endif;

                                 if (B_write='1') then

                                    B_reg<=B_input;

                                 endif;

                                 etc....

                            endif;

Otra diferencia con programar es que cuando usás un loop en VHDL lo tenés que usar para describir la estructura del circuito y no para computar un valor como lo harías en programación.

Por supuesto que podés usar VHDL como un lenguaje de programación para tener una especificación behavoiral de tu circuito pero deberías usarla para validar tu especificación sintetizable usando un estilo data-flow.

Saludos. Alejandro.

[Sebastián Escarza DCIC]

Hola nuevamente,

Estuve mirando de nuevo y creo que el problema con ese medio dato de defase (que te llegaba bien antes de quitar la etapa de retardo intermedia) puede deberse también a un problema de big/little endianess en la transmisión de los mismos. ¿Desde Matlab transmitís primero la parte menos significativa? Porque algo que me llama mucho la atención es que al armar Dato_completo, ponés primero la parte más significativa...

Yo probaría modificar mi última sugerencia, de manera de realizar la asignación a Dato_completo de la siguiente manera:

Dato_completo <= not (Dato_aux(7 downto 1) & Dato_aux_lsb );

Aún no sinteticé tu código ya que estoy más familiarizado con Verilog y las herramientas de Altera, pero si lo analizamos desde un punto de vista temporal prestando atención a como evoluciona el sistema conforme van llegando los datos (la recepción de cada trama bit a bit parece correcta), se dan las siguientes situaciones:

Supongamos que desde matlab transmitís A B C D E F ... (cada letra representa medio dato) (X un valor arbitrario con el que se inicializa cada registro). Con esa secuencia estarías transmitiendo los datos BA, luego DC, luego FE (si lo hacés, como intuyo en little endian, confirmá eso).

Código original:

Dato_aux_msb <= Dato_aux(7 downto 1);

Dato_completo <= not (Dato_aux_lsb & Dato_aux_msb);

t1: se completa A en Dato_aux - Dato_aux_lsb latchea A - Dato_aux_msb tiene X - Dato_completo tiene XX
t2: se completa B en Dato_aux - Dato_aux_lsb tiene A - Dato_aux_msb latchea B - Dato_completo latchea AX

t3: se completa C en Dato_aux - Dato_aux_lsb latchea C - Dato_aux_msb tiene B - Dato_completo tiene AX

t4: se completa D en Dato_aux - Dato_aux_lsb tiene C - Dato_aux_msb latchea D - Dato_completo latchea CB
t5: se completa E en Dato_aux - Dato_aux_lsb latchea E - Dato_aux_msb tiene D - Dato_completo tiene CB
t6: se completa F en Dato_aux - Dato_aux_lsb tiene E - Dato_aux_msb latchea F - Dato_completo latchea ED
...

Acá los datos se muestran correctos pero retrasados: AX sería "correcto" en t2, CB en t4, ED en t6, etc.

Se está mostrando una X, un valor de inicialización del regsitro, ¿puede que eso coincida con una mitad del primer dato que haga que lo que se ve parezca correcto? Según esto, CB y ED serían correctos. ¿Puede que justo las partes altas de estos datos transmitidos desde matlab coincidan y hagan parecer correctos datos que no lo son?

Código con la modificación de eliminar el registro intermedio de Dato_aux_msb:

Dato_completo <= not (Dato_aux_lsb & Dato_aux(7 downto 1) );

t1: se completa A en Dato_aux - Dato_aux_lsb latchea A - Dato_completo tiene XX
t2: se completa B en Dato_aux - Dato_aux_lsb tiene A - Dato_completo latchea AB

t3: se completa C en Dato_aux - Dato_aux_lsb latchea C - Dato_completo tiene AB

t4: se completa D en Dato_aux - Dato_aux_lsb tiene C - Dato_completo latchea CD

t5: se completa E en Dato_aux - Dato_aux_lsb latchea E - Dato_completo tiene CD
t6: se completa F en Dato_aux - Dato_aux_lsb tiene E - Dato_completo latchea EF

...

Acá los datos se muestran cortados y sólo parece funcionar el LSB: se mostraría AB en t2, CD en t4, EF en t6, etc. Si comparamos con el caso anterior la B pasó a mostrarse de t4 a t2, la D de t6 a t4, y (aunque no se aprecia) la F de t8 a t6... dando la "sensación" de que el LSB se adelantó un dato (y se arregló), pero mostrándose la B con la A en lugar de con la C, y la D con la C en lugar de con la E, induciendo a pensar que los datos están fraccionados (se muestra la mitad del dato, con la otra mitad del siguiente).

Código sin retardo extra ajustando el armado de la salida a little endian:

Dato_completo <= not (Dato_aux(7 downto 1) & Dato_aux_lsb );

t1: se completa A en Dato_aux - Dato_aux_lsb latchea A - Dato_completo tiene XX
t2: se completa B en Dato_aux - Dato_aux_lsb tiene A - Dato_completo latchea BA

t3: se completa C en Dato_aux - Dato_aux_lsb latchea C - Dato_completo tiene BA

t4: se completa D en Dato_aux - Dato_aux_lsb tiene C - Dato_completo latchea DC

t5: se completa E en Dato_aux - Dato_aux_lsb latchea E - Dato_completo tiene DC
t6: se completa F en Dato_aux - Dato_aux_lsb tiene E - Dato_completo latchea FE

...
Acá se mostraría BA en t2, DC en t4, FE en t6, etc. que creo que sería lo correcto (salvo que justo tengas cruzados los cables en los leds, o alguna cosa por el estilo)

No se si estaré muy errado, pero te recomiendo revisar esta cuestión. Si este no es el problema, estaría bueno que nos envíes los datos que transmitís (los primeros 3 o 4 nomás) y cómo se muestran con cada código que has probado y en la primer pasada (i.e. luego de descargar el bitstream) y la segunda, como para descartar cualquier problema con el little/big endianess, o la existencia de mitades iguales en datos consecutivos que induzcan a pensar que un dato se muestra correctamente cuando no es así).

Algo que también está bueno es visualizar la netlist generada por la herramienta de síntesis a nivel RTL. Supongo que la herramienta (de xilinx?) que estás usando, debe tener una manera de ver el circuito generado como para echar un vistazo si la síntesis se corresponde con lo que esperás del código HDL.

También, las otras recomendaciones realizadas por las demás personas en el hilo son para tener en cuenta. Espero que el bug aparezca pronto y soluciones el problema.
Saludos!

Seba

--

[Jorge Luis Ramirez Torres]

Hola,,

Alejandro muy útil la información que me enviaste estoy muy agradecido,, muchas cosas que desconocía, gracias,,

Seba, este momento procedo a analizar la información que me enviaste, por lo pronto respondo brevemente a tus preguntas, 

¿Desde matlab transmitís primero la parte menos significativa?

Si, primero la parte menos significativa y después de un pause(0,4) transmito la mas significativa.

Probar invertir esto: Dato_completo <= not (Dato_aux_lsb & Dato_aux(7 downto 1));

ya lo hice pero solo presento los dato en sentido cambiado.

Si estaría transmitiendo en little endian, pues como dije primero el byte menos significativo y desde el bit menos significativo, sin embargo solo tomo los 7 primeros bits de cada byte, al unirlos en xilinx, ¿Por que? pues maltab no estaba enviando correctamente números que incluían el 1 en el bit mas significativo de cada byte, y lo solucione dividiendo el numero en matab de tal forma que el numero se divida en dos paquetes de 7 bits cada uno, pero por el protocolo matlab sigue enviando 8 bits pero al hacer lo que acabo de indicar aseguré que matlab no tenga 1 en el 8vo bit, y por lo tanto siempre envíe los datos, cuestion que esta comprobada esta enviando bien. 

Si efectivamente hay datos que son aparentemente correctos, pero al llegar al decimo dato puedo determinar que estan retrasados,

debido a un cambio en octavo bit de los datos del archivo adjunto, es decir el octavo bit al unir en xilinx viene a ser el bit menos significativo de Dato_aux_msb, por lo que los 7 primeros corresponden a Dato_aux_lsb.

Lo de descartar el problema del little/big endianes, y lo de los cables cruzados pues si esta descartado ¿Por que?, pues porque cuando envío los datos usando mi código original, resulta que los datos son correctos y sin ningún desfase ENTRE ELLOS lo he comprobado, sin embargo el problema ahi radica en una sola cosa, y es que existe un desfase del paquete completo(14 bits) con respecto a los tiempos, en otras palabras, desde la segunda carga de datos desde matlab, la presentacion de datos,

va en este orden:

ultimo, primero, segundo, tercero,.........., penultimo, y fin de la presentacion de datos en los leds

y cuando envio desde matlab justo despues de haber cargado el programa a la tarjeta los datos se presentan asi:

"00000000000000"(siempre todo apagado), segundo, tercero,.........., penultimo, y fin de la presentacion de datos en los leds

saludos,,

[Jorge Luis Ramirez Torres]

Archivo adjunto de los datos esperados