Help needed in delaying signals... in my design

R

Rootz Anabo

Guest
I have a design in which the total latency from input to output is about 60
clock cycles. This is a pipelined design in which one of my output signal is
the an input signal which also needs to go into another system. My problem
is that, how do I delay this input signal by 60 clock cycles so that this
input signal will be in sync with its corresponding signal.
So for example, I have input signals

data_in_a
data_in_b
data_in_value
clk

output signals are
data_out_a
data_out_b
data_out_value

It takes 60 clock cycles for data_out_value to be generated. I need to
somehow delay data_in_a and data_in_b by that amount of cycles so that I can
assign
data_out_a <= data_in_a
data_out_b <= data_in_b
data_out_value <= .....[value computed after 60 cycles]

I used this code below to delay the signals

delay: process (clk)
begin
if (rising_edge(clk)) then
delay_temp(0) <= data_in_a;
delay_temp(1) <= delay_temp(0);
and so on
delay_temp(59) <= delay_temp(58);
end if;
end process delay; <actually I used a for loop>

However, synplicity complains and does not like this even though it works
fine in simulation. Is there any better way to do this
thanks

kg2
 
"Rootz Anabo" <rootz_eye@yahoo.com> wrote in message
news:c50bsh$qp9$1@newsreader.wustl.edu...
I have a design in which the total latency from input to output is about
60
clock cycles. This is a pipelined design in which one of my output signal
is
the an input signal which also needs to go into another system. My problem
is that, how do I delay this input signal by 60 clock cycles so that this
input signal will be in sync with its corresponding signal.
So for example, I have input signals

data_in_a
data_in_b
data_in_value
clk

output signals are
data_out_a
data_out_b
data_out_value

It takes 60 clock cycles for data_out_value to be generated. I need to
somehow delay data_in_a and data_in_b by that amount of cycles so that I
can
assign
data_out_a <= data_in_a
data_out_b <= data_in_b
data_out_value <= .....[value computed after 60 cycles]

I used this code below to delay the signals

delay: process (clk)
begin
if (rising_edge(clk)) then
delay_temp(0) <= data_in_a;
delay_temp(1) <= delay_temp(0);
and so on
delay_temp(59) <= delay_temp(58);
end if;
end process delay; <actually I used a for loop

However, synplicity complains and does not like this even though it works
fine in simulation. Is there any better way to do this
thanks

I don't know the type of the data, assume it is of type X
Click to expand...
then you could write it as follows

architecture ...
type X_arr_tp is array (59 downto 0) of X;
signal X_arr : X_arr_tp;
..
begin

process(clk)
begin
if rising_edge (clk) then
X_arr<= X_arr(58 downto 0) & data_in_a;

Egbert Molenkamp
 
"Rootz Anabo" <rootz_eye@yahoo.com> wrote in message news:<c50bsh$qp9$1@newsreader.wustl.edu>...
I have a design in which the total latency from input to output is about 60
clock cycles. This is a pipelined design in which one of my output signal is
the an input signal which also needs to go into another system. My problem
is that, how do I delay this input signal by 60 clock cycles so that this
input signal will be in sync with its corresponding signal.
So for example, I have input signals

data_in_a
data_in_b
data_in_value
clk

output signals are
data_out_a
data_out_b
data_out_value

It takes 60 clock cycles for data_out_value to be generated. I need to
somehow delay data_in_a and data_in_b by that amount of cycles so that I can
assign
data_out_a <= data_in_a
data_out_b <= data_in_b
data_out_value <= .....[value computed after 60 cycles]

I used this code below to delay the signals

delay: process (clk)
begin
if (rising_edge(clk)) then
delay_temp(0) <= data_in_a;
delay_temp(1) <= delay_temp(0);
and so on
delay_temp(59) <= delay_temp(58);
end if;
end process delay; <actually I used a for loop

However, synplicity complains and does not like this even though it works
fine in simulation. Is there any better way to do this
thanks

kg2
Click to expand...

signal counter : integer range 0 to 60;

-----------------------------------------------
-----------------------------------------------
process(Reset, Clk)
begin
if Reset='1' then
l_data_out_a <= '0'; -- other dimensions of course also
possible!
l_data_in_a <= '0';
counter <= 0;

elsif Clk'event and Clk='1' then

l_data_out_a <= l_data_out_a;
l_data_in_a <= l_data_in_a;

if Valid_in='1' then
l_data_in_a <= Data_in_a; -- sample input (input Valid_in
is one
-- clock high
end if;

if counter=60 then
counter <= 0;
else
counter <= counter + 1;
end if;

if counter=60 then
l_data_out_a <= l_data_in_a
end if;

end if;
end process;
-----------------------------------------------
-----------------------------------------------


Data_out_a <= l_data_out_a;
 
ALuPin a écrit:
signal counter : integer range 0 to 60;
Click to expand...
Your method doesn't work if there's a new value on every clock cycle.


--
____ _ __ ___
| _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le -
| | | | | (_| |_| | Invalid return address: remove the -
|_| |_|_|\__|\___/
 
I don't know the type of the data, assume it is of type X
then you could write it as follows

architecture ...
type X_arr_tp is array (59 downto 0) of X;
signal X_arr : X_arr_tp;
..
begin

process(clk)
begin
if rising_edge (clk) then
X_arr<= X_arr(58 downto 0) & data_in_a;

Egbert Molenkamp
Click to expand...
or if you prefer local variables (2 possibilities):

For NPIPE > 1 :

process(rst_an, clk)
constant C_NPIPE : integer := 60; -- must be > 1
type t_pipe is array(1 to C_NPIPE) of X;
variable v_pipe_q : t_pipe;
begin
if rst_an = '0' then
v_pipe_q := ...; -- depend of type X
elsif rising_edge(clk) then
v_pipe_q := v_pipe_q(2 to C_NPIPE) & data_in_a;
end if;
data_in_a_delayed_q <= v_pipe_q(1);
end process;


For NPIPE > 0 :

process(rst_an, clk)
constant C_NPIPE : integer := 60; -- must be > 0
type t_pipe is array(0 to C_NPIPE) of X;
variable v_pipe_q : t_pipe;
begin
if rst_an = '0' then
v_pipe_q := ...; -- depend of type X
elsif rising_edge(clk) then
v_pipe_q(C_NPIPE) := data_in_a;
v_pipe_q(0 to C_NPIPE-1) := v_pipe_q(1 to C_NPIPE);
end if;
s_data_in_a_delayed_q <= v_pipe_q(0);
end process;

regards
fe
 
"ALuPin" <ALuPin@web.de> escribió en el mensaje
news:b8a9a7b0.0404070558.4d4383ad@posting.google.com...
"Rootz Anabo" <rootz_eye@yahoo.com> wrote in message
news:<c50bsh$qp9$1@newsreader.wustl.edu>...
I have a design in which the total latency from input to output is about
60
clock cycles. This is a pipelined design in which one of my output
signal is
the an input signal which also needs to go into another system. My
problem
is that, how do I delay this input signal by 60 clock cycles so that
this
input signal will be in sync with its corresponding signal.
So for example, I have input signals

data_in_a
data_in_b
data_in_value
clk

output signals are
data_out_a
data_out_b
data_out_value

It takes 60 clock cycles for data_out_value to be generated. I need to
somehow delay data_in_a and data_in_b by that amount of cycles so that I
can
assign
data_out_a <= data_in_a
data_out_b <= data_in_b
data_out_value <= .....[value computed after 60 cycles]

I used this code below to delay the signals

delay: process (clk)
begin
if (rising_edge(clk)) then
delay_temp(0) <= data_in_a;
delay_temp(1) <= delay_temp(0);
and so on
delay_temp(59) <= delay_temp(58);
end if;
end process delay; <actually I used a for loop

However, synplicity complains and does not like this even though it
works
fine in simulation. Is there any better way to do this
thanks

kg2


signal counter : integer range 0 to 60;

-----------------------------------------------
-----------------------------------------------
process(Reset, Clk)
begin
if Reset='1' then
l_data_out_a <= '0'; -- other dimensions of course also
possible!
l_data_in_a <= '0';
counter <= 0;

elsif Clk'event and Clk='1' then

l_data_out_a <= l_data_out_a;
l_data_in_a <= l_data_in_a;
Click to expand...
why are you doing those assignations?

if Valid_in='1' then
l_data_in_a <= Data_in_a; -- sample input (input Valid_in
is one
-- clock high
end if;

if counter=60 then
counter <= 0;
else
counter <= counter + 1;
end if;

if counter=60 then
l_data_out_a <= l_data_in_a
end if;

end if;
end process;
-----------------------------------------------
-----------------------------------------------


Data_out_a <= l_data_out_a;
Click to expand...
what is this anyway?

you can use a FIFO or a shift-register as wide as your data is and as deep
as you need the delay, the shift register will be clocked by your "clk"
signal
 
signal counter : integer range 0 to 60;

-----------------------------------------------
-----------------------------------------------
process(Reset, Clk)
begin
if Reset='1' then
l_data_out_a <= '0'; -- other dimensions of course also
possible!
l_data_in_a <= '0';
counter <= 0;

elsif Clk'event and Clk='1' then

l_data_out_a <= l_data_out_a;
l_data_in_a <= l_data_in_a;


why are you doing those assignations?
Click to expand...
Hi,

This assignations are the ELSE-tree of
"if counter=60 then"

Rgds
Andrés V.
 
ALuPin a écrit:

This assignations are the ELSE-tree of
"if counter=60 then"
Click to expand...
Since these are inside a clock processed, which will infer flip-flops,
you don't need them.

--
____ _ __ ___
| _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le -
| | | | | (_| |_| | Invalid return address: remove the -
|_| |_|_|\__|\___/
 
"Nicolas Matringe" <matringe.nicolas@numeri-cable.fr> escribió en el mensaje
news:4074FC35.1020603@numeri-cable.fr...
ALuPin a écrit:

This assignations are the ELSE-tree of
"if counter=60 then"

Since these are inside a clock processed, which will infer flip-flops,
you don't need them.
Click to expand...
exactly.

but still, i dont understand why were you assigning a signal to itself (the
following piece of code), what exactly did you wanted to do?
i've never seen that, or maybe i've never had to code something like that
before! for me it looks like a loop (though i know that it wont work like a
loop, fortunately)

if it were outside the process, what would be the effect?, maybe i'll check
tomorrow on modelsim :)

elsif Clk'event and Clk='1' then

l_data_out_a <= l_data_out_a;
l_data_in_a <= l_data_in_a;
Click to expand...
 
"Nicolas Matringe" <matringe.nicolas@numeri-cable.fr> escribió en el mensaje
news:4074FC35.1020603@numeri-cable.fr...
ALuPin a écrit:

This assignations are the ELSE-tree of
"if counter=60 then"

Since these are inside a clock processed, which will infer flip-flops,
you don't need them.
Click to expand...
exactly.

but still, i dont understand why were you assigning a signal to itself (the
following piece of code), what exactly did you wanted to do?
i've never seen that, or maybe i've never had to code something like that
before! for me it looks like a loop (though i know that it wont work like a
loop, fortunately)

if it were outside the process, what would be the effect?, maybe i'll check
tomorrow on modelsim :)

elsif Clk'event and Clk='1' then

l_data_out_a <= l_data_out_a;
l_data_in_a <= l_data_in_a;
Click to expand...
 
but still, i dont understand why were you assigning a signal to itself
(the
following piece of code), what exactly did you wanted to do?
Click to expand...
keep it's last value.

i've never seen that, or maybe i've never had to code something like that
before! for me it looks like a loop (though i know that it wont work like
a
loop, fortunately)
Click to expand...
Inside the rising_edge statement,
Writing:
l_data_out_a <= l_data_out_a; -- this is the default value for all
unassigned conditions
if counter=60 then
l_data_out_a <= l_data_in_a;
end if;

it's equivalent to writing:
if counter=60 then
l_data_out_a <= l_data_in_a;
else
l_data_out_a <= l_data_out_a;
end if;

and also to writing:
if counter=60 then
l_data_out_a <= l_data_in_a;
end if;
because in VHDL, keep the last value is automaticaly implemented for
unassigned condition.

And those codes will produce this hardware :
(Please view in fixed-width font, e.g. Courier)

+--------------------+
| . |
| |\ |
| | \ |
+----|0 | .---. |
| |-----|D Q|--+-- l_data_out_a
l_data_in_a -----|1 | +-|> |
| / | '---'
|/| |
' | |
.-----. | |
counter--| =60 |---+ |
'-----' |
clk --------------------+

regards
fe
 
"fe" <notvalid@nowhere.com> escribió en el mensaje
news:wFgdc.19161$ih4.196046@wagner.videotron.net...
but still, i dont understand why were you assigning a signal to itself
(the
following piece of code), what exactly did you wanted to do?

keep it's last value.
Click to expand...

ok, thanks!, i guess that when i see a process(clk...) i see flipflops and i
dont think in it being necesary in real logic :) i guess that's the problem
when you learn hardware first and then vhdl :)

in anycase, that kind of syntax, it's like "bad practice" or something??,
cause i had never seen it before.

i've never seen that, or maybe i've never had to code something like
that
before! for me it looks like a loop (though i know that it wont work
like
a
loop, fortunately)


Inside the rising_edge statement,
Writing:
l_data_out_a <= l_data_out_a; -- this is the default value for all
unassigned conditions
if counter=60 then
l_data_out_a <= l_data_in_a;
end if;

it's equivalent to writing:
if counter=60 then
l_data_out_a <= l_data_in_a;
else
l_data_out_a <= l_data_out_a;
end if;

and also to writing:
if counter=60 then
l_data_out_a <= l_data_in_a;
end if;
because in VHDL, keep the last value is automaticaly implemented for
unassigned condition.

And those codes will produce this hardware :
(Please view in fixed-width font, e.g. Courier)

+--------------------+
| . |
| |\ |
| | \ |
+----|0 | .---. |
| |-----|D Q|--+-- l_data_out_a
l_data_in_a -----|1 | +-|> |
| / | '---'
|/| |
' | |
.-----. | |
counter--| =60 |---+ |
'-----' |
clk --------------------+

regards
fe
Click to expand...
thanks for the schematic,
though, i dont see any use for the multiplexer, you could just clock the DFF
with the output of the counter (dont worry, in anycase it's not what the
original post wanted anyway)
 
In article <c53u99$kfo$1@avanie.enst.fr>, paris wrote:
but still, i dont understand why were you assigning a signal to itself (the
following piece of code), what exactly did you wanted to do?
elsif Clk'event and Clk='1' then

l_data_out_a <= l_data_out_a;
l_data_in_a <= l_data_in_a;
Click to expand...
The assignment is done only at rising clock edge, and therefore
the above models two flip-flops which retain their value. The
assignments could be removed without functional change, but the
above shows the loop from flipflop output back to its input explicitly.
 
paris a écrit:

thanks for the schematic,
though, i dont see any use for the multiplexer, you could just clock the DFF
with the output of the counter (dont worry, in anycase it's not what the
original post wanted anyway)
Click to expand...
This case is rather straightforward but with some complex clock enable
schemes, the synthesis tool produces such a loopback (with more than
just a mux :eek:) instead of bigger clock enable logic.

--
____ _ __ ___
| _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le -
| | | | | (_| |_| | Invalid return address: remove the -
|_| |_|_|\__|\___/
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top