delaying by half a clock cycle

Relatively inexperienced at sysntheseis so bear with me please

I have a module with a 32 bit input bus and every time a new value is
placed on it i want to wait half a clock cycle before i do anything.
Leonardo Spectrum is giving me some weird advice on the following code:

always@(input_bus)
begin
if(input_bus[31])
begin
@(negedge clk);
output_bus = input_bus;
end
else if(!input_bus[31])
begin
@(negedge clk);
output_bus = input_bus;
end
end


without the @(negedge clk) lines it synthesises fine but when i include
them it tells me that the always@(input_bus) needs to be edge
triggered. This makes no sense to me. How can I wait for the next
negedge of clk before doing anything after the contents of input_bus
have changed?

Any help would be most welcome!

Gud stuf outta youse.

Rob.

 

[Jonathan Bromley]

On 10 Jul 2006 08:43:59 -0700, robquigley@gmail.com wrote:

I have a module with a 32 bit input bus and every time a new value is
placed on it i want to wait half a clock cycle before i do anything.
Leonardo Spectrum is giving me some weird advice on the following code:

always@(input_bus)
begin
if(input_bus[31])
begin
@(negedge clk);
output_bus = input_bus;
end
else if(!input_bus[31])
begin
@(negedge clk);
output_bus = input_bus;
end
end


without the @(negedge clk) lines it synthesises fine but when i include
them it tells me that the always@(input_bus) needs to be edge
triggered. This makes no sense to me. How can I wait for the next
negedge of clk before doing anything after the contents of input_bus
have changed?

Lots of strange not-very-synthesisable stuff here.

First question: What sort of hardware do you imagine should be
built in order to detect "there is a new value on my 32-bit bus" ?
Remember that, in practice, each bit will change independently and
therefore you'll get LOTS of separate 1-bit changes whenever
a new value appears. I think it's a fairly safe bet that you have
some kind of strobe or clock signal somewhere that manages
or flags the arrival of a "new" value on this bus. (Subsidiary
question, for extra credit: What happens when the "new"
value is the same as the "old" value? Do you expect to
notice it?)

Second question: when you say "half clock cycle delay", does
this assume that input_bus was updated on the rising clock edge?

Generally when you write a Verilog or VHDL clocked-logic block
you need to specify the clock in the sensitivity list, and then
(in the body of the code) specify all the logic that will act
on each clock cycle. I strongly suspect that the following
will do what you need, and it's synthesisable:

always @(nedgedge clk) begin
if (input_bus[31]) begin
output_bus <= input_bus;
end else begin
output_bus <= [whatever];
end
end

Other stuff you need to think about:

(1) use of blocking (=) vs. nonblocking (<=) assignment
in clocked "always"
(2) if... else (in your case the two if conditions are mutually
exclusive, but what if they aren't???)
(3) for synthesis, you should have only exactly one event control
("@" event) at the very beginning of your always block

If you give us a bit more detail about your application we
can probably be more helpful in putting you on the right track.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

Jonathan Bromley wrote:

On 10 Jul 2006 08:43:59 -0700, robquigley@gmail.com wrote:

I have a module with a 32 bit input bus and every time a new value is
placed on it i want to wait half a clock cycle before i do anything.
Leonardo Spectrum is giving me some weird advice on the following code:

always@(input_bus)> >begin
if(input_bus[31])
begin
@(negedge clk);
output_bus = input_bus;
end
else if(!input_bus[31])
begin
@(negedge clk);
output_bus = input_bus;
end
end


without the @(negedge clk) lines it synthesises fine but when i include
them it tells me that the always@(input_bus) needs to be edge
triggered. This makes no sense to me. How can I wait for the next
negedge of clk before doing anything after the contents of input_bus
have changed?

Lots of strange not-very-synthesisable stuff here.

First question: What sort of hardware do you imagine should be
built in order to detect "there is a new value on my 32-bit bus" ?
Remember that, in practice, each bit will change independently and
therefore you'll get LOTS of separate 1-bit changes whenever
a new value appears. I think it's a fairly safe bet that you have
some kind of strobe or clock signal somewhere that manages
or flags the arrival of a "new" value on this bus. (Subsidiary
question, for extra credit: What happens when the "new"
value is the same as the "old" value? Do you expect to
notice it?)

Second question: when you say "half clock cycle delay", does
this assume that input_bus was updated on the rising clock edge?

Generally when you write a Verilog or VHDL clocked-logic block
you need to specify the clock in the sensitivity list, and then
(in the body of the code) specify all the logic that will act
on each clock cycle. I strongly suspect that the following
will do what you need, and it's synthesisable:

always @(nedgedge clk) begin
if (input_bus[31]) begin
output_bus <= input_bus;
end else begin
output_bus <= [whatever];
end
end

Other stuff you need to think about:

(1) use of blocking (=) vs. nonblocking (<=) assignment
in clocked "always"
(2) if... else (in your case the two if conditions are mutually
exclusive, but what if they aren't???)
(3) for synthesis, you should have only exactly one event control
("@" event) at the very beginning of your always block

If you give us a bit more detail about your application we
can probably be more helpful in putting you on the right track.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Hey jonathan thanx for the reply.

My input_bus is connected to a fifo that outputs on the rising clock
edge. It may not output every rising edge though so I only want to know
when the contents of the bus actually change.

If my always block is triggered by a clk edge i will have to somehow
determine whether there is a new value on the input bus or if the value
hasnt changed. This would mean storing the previous "old" value and
comparing it will the "new" value which will take up area, will it not?

The thing i dont get is that the always@(input_bus) synthesises fine
without the @(negedge clk) line.

So assuming input_bus is updated on the rising edge of clk (but not
every rising edge) how do i wait until the next negedge of clk, after a
change in input_bus, before doing anything?

Cheers for ur advice.....

 

[Jonathan Bromley]

On 11 Jul 2006 04:35:28 -0700,
robquigley@gmail.com wrote:

My input_bus is connected to a fifo that outputs on the rising clock
edge. It may not output every rising edge though so I only want to know
when the contents of the bus actually change.

If my always block is triggered by a clk edge i will have to somehow
determine whether there is a new value on the input bus or if the value
hasnt changed. This would mean storing the previous "old" value and
comparing it will the "new" value which will take up area, will it not?

Yes, but it's the only way to do it. Even if you use truly
asynchronous logic (and you REALLY don't want to do that!)
there must still be some kind of storage of old value to compare
with the new value.

The thing i dont get is that the always@(input_bus) synthesises fine
without the @(negedge clk) line.

That form of synthesisable logic block is used to create purely
COMBINATORIAL logic. The significance of "always @(inputs)" is
that the outputs are recalculated whenever the input changes.
This is NOT truly detection of input value changes; it's merely
a trick to make simulation behave correctly for combinational
logic. Basically the problem is this: A bunch of gates truly
CONTINUOUSLY re-calculates their output from their inputs.
Clearly this is not sensible for simulation; it would keep the
simulator unnecessarily busy. So we fake-over the problem
by noting that, in a combinational block, outputs can change
only as a result of input changes and it's pointless to re-calculate
the outputs at any other time. Synthesis is aware of
this dodge, and interprets the whole thing as combinational
logic which it then duly builds. There's no change detection
going on in the real hardware, but only in the simulation.

So assuming input_bus is updated on the rising edge of clk (but not
every rising edge) how do i wait until the next negedge of clk, after a
change in input_bus, before doing anything?

Example: This code asserts "change_flag" for exactly one
clock cycle (negedge to negedge) on detection of an input
change.

always @(negedge clk) begin
change_flag <= 0; // default, usual case
if (input_bus != old_input_bus) begin
// Just for this cycle, change your mind about change_flag:
change_flag <= 1;
end
old_input_bus <= input_bus;
end

Yes, it costs area, but that's unavoidable if you
really need the change detection. Note, too, that this code
assumes you've done something vaguely sensible about
initialisation of the old_input_bus register. Implementing
a reset sounds good.

I still ask the question: what happens if the FIFO delivers
a new value that happens to be the same as the previous
value? Surely you would miss it! Are you CERTAIN there
isn't an "output active" or somesuch strobe/flag available
from your FIFO? Are you CERTAIN that you want to do
something special when the input changes? Can't you
just do the same thing every clock, and let your outputs
stay the same (albeit recalculating on every clock) when
the input is stable?

Remember that hardware isn't like software. If there's
a piece of logic sitting there, it may as well earn its keep
by doing something on every clock cycle. In software you
definitely don't want to evaluate stuff unnecessarily,
because each evaluation costs some CPU time. In hardware
the evaluation logic is probably there, idle, already; so
you may as well leave it running. Making the decision to
leave that hardware idle if the input's unchanged will
probably cost you a pile MORE hardware, as you noticed
in connection with the change detector.

(Disclaimer: I know that some of the above paragraph is
not the whole truth, particularly if you're trying to design
for low power consumption or if youre trying to re-use
a complicated functional unit on multiple data streams.
But beginners in synthesis don't normally start by
worrying about that kind of stuff...)
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

Jonathan Bromley wrote:

On 11 Jul 2006 04:35:28 -0700,
robquigley@gmail.com wrote:

My input_bus is connected to a fifo that outputs on the rising clock
edge. It may not output every rising edge though so I only want to know
when the contents of the bus actually change.

If my always block is triggered by a clk edge i will have to somehow
determine whether there is a new value on the input bus or if the value
hasnt changed. This would mean storing the previous "old" value and
comparing it will the "new" value which will take up area, will it not?

Yes, but it's the only way to do it. Even if you use truly
asynchronous logic (and you REALLY don't want to do that!)
there must still be some kind of storage of old value to compare
with the new value.

The thing i dont get is that the always@(input_bus) synthesises fine
without the @(negedge clk) line.

That form of synthesisable logic block is used to create purely
COMBINATORIAL logic. The significance of "always @(inputs)" is
that the outputs are recalculated whenever the input changes.
This is NOT truly detection of input value changes; it's merely
a trick to make simulation behave correctly for combinational
logic. Basically the problem is this: A bunch of gates truly
CONTINUOUSLY re-calculates their output from their inputs.
Clearly this is not sensible for simulation; it would keep the
simulator unnecessarily busy. So we fake-over the problem
by noting that, in a combinational block, outputs can change
only as a result of input changes and it's pointless to re-calculate
the outputs at any other time. Synthesis is aware of
this dodge, and interprets the whole thing as combinational
logic which it then duly builds. There's no change detection
going on in the real hardware, but only in the simulation.

So assuming input_bus is updated on the rising edge of clk (but not
every rising edge) how do i wait until the next negedge of clk, after a
change in input_bus, before doing anything?

Example: This code asserts "change_flag" for exactly one
clock cycle (negedge to negedge) on detection of an input
change.

always @(negedge clk) begin
change_flag <= 0; // default, usual case
if (input_bus != old_input_bus) begin
// Just for this cycle, change your mind about change_flag:
change_flag <= 1;
end
old_input_bus <= input_bus;
end

Yes, it costs area, but that's unavoidable if you
really need the change detection. Note, too, that this code
assumes you've done something vaguely sensible about
initialisation of the old_input_bus register. Implementing
a reset sounds good.

I still ask the question: what happens if the FIFO delivers
a new value that happens to be the same as the previous
value? Surely you would miss it! Are you CERTAIN there
isn't an "output active" or somesuch strobe/flag available
from your FIFO? Are you CERTAIN that you want to do
something special when the input changes? Can't you
just do the same thing every clock, and let your outputs
stay the same (albeit recalculating on every clock) when
the input is stable?

Remember that hardware isn't like software. If there's
a piece of logic sitting there, it may as well earn its keep
by doing something on every clock cycle. In software you
definitely don't want to evaluate stuff unnecessarily,
because each evaluation costs some CPU time. In hardware
the evaluation logic is probably there, idle, already; so
you may as well leave it running. Making the decision to
leave that hardware idle if the input's unchanged will
probably cost you a pile MORE hardware, as you noticed
in connection with the change detector.

(Disclaimer: I know that some of the above paragraph is
not the whole truth, particularly if you're trying to design
for low power consumption or if youre trying to re-use
a complicated functional unit on multiple data streams.
But beginners in synthesis don't normally start by
worrying about that kind of stuff...)
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Thanx man,

I have a bit of thinking to do now and some redesign after some shady
assumptions on my part

Cheers for the help.

Rob.