Help needed in delaying signals... in my design

[Rootz Anabo]

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

 

[Egbert Molenkamp]

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
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

 

[ALuPin]

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;

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;

 

[Nicolas Matringe]

ALuPin a écrit:

signal counter : integer range 0 to 60;

Your method doesn't work if there's a new value on every clock cycle.

 

[fe]

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

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

 

[paris]

"Rootz Anabo" <[email protected]> wrote in message

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;

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;
-----------------------------------------------

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

 

[ALuPin]

Hi,

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

Rgds
Andrés V.

 

[Nicolas Matringe]

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.

 

[paris]

ALuPin a écrit:


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

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

 

[paris]

ALuPin a écrit:


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

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

 

[Tuukka Toivonen]

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?

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.

 

[fe]

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.

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

 

[paris]

keep it's last value.

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.

like

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

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)

 

[Nicolas Matringe]

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)

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 ) instead of bigger clock enable logic.