race conditions in huge project

[Moritz Schmid]

Hi,

I was recently assigned a huge unfinished vhdl project. Now that I have
had a first glance at my predecessor's code, I suspect there to be
quite a few race conditions.

Does any one have experience with a good and solid method to identify these?

My idea would be to insert flags, whether a value was already set in a
cycle, and to check for these (maybe with something like an assertion),
before using the value to determine new values.

Any help would be really appreciated!

Thanks,

Moritz

 

[rickman]

On Jul 31, 11:52 am, Moritz Schmid <hansda...@gmx.de> wrote:

Hi,

I was recently assigned a huge unfinished vhdl project. Now that I have
had a first glance at my predecessor's code, I suspect there to be
quite a few race conditions.

Does any one have experience with a good and solid method to identify these?

My idea would be to insert flags, whether a value was already set in a
cycle, and to check for these (maybe with something like an assertion),
before using the value to determine new values.

Any help would be really appreciated!

I can't say I am familiar with problems from race conditions other
than in async logic. If you have async logic in a cycle (a loop) then
you have potential latches. I suspect I am not really grasping what
you are describing.

When you say "cycle" what are you referring to exactly? Is this a
synchronous design? Is there async feedback?

The more important design technique for properly implementing a large
design is partitioning it into smaller designs, each with a clear and
well defined interface to the rest of the design. It is good to adopt
a standard way of interfacing these smaller blocks so that you don't
have to keep track of a lot of complicated details at each
interface.

Does any of that help? Can you give more info on your problem?

Rick

 

[Moritz Schmid]

On 2008-07-31 18:33:22 +0200, rickman <gnuarm@gmail.com> said:

On Jul 31, 11:52 am, Moritz Schmid <hansda...@gmx.de> wrote:
Hi,

I was recently assigned a huge unfinished vhdl project. Now that I have
had a first glance at my predecessor's code, I suspect there to be
quite a few race conditions.

Does any one have experience with a good and solid method to identify these?

My idea would be to insert flags, whether a value was already set in a
cycle, and to check for these (maybe with something like an assertion),
before using the value to determine new values.

Any help would be really appreciated!

I can't say I am familiar with problems from race conditions other
than in async logic. If you have async logic in a cycle (a loop) then
you have potential latches. I suspect I am not really grasping what
you are describing.

When you say "cycle" what are you referring to exactly? Is this a
synchronous design? Is there async feedback?

The more important design technique for properly implementing a large
design is partitioning it into smaller designs, each with a clear and
well defined interface to the rest of the design. It is good to adopt
a standard way of interfacing these smaller blocks so that you don't
have to keep track of a lot of complicated details at each
interface.

Does any of that help? Can you give more info on your problem?

Rick

@ Rick: By a cycle, I meant a clock cycle. Sorry for not being specific
in that point.

@ Rick and Jens: Thanks for the help! I will try these steps, and come
back for more help as soon as I have gotten things together!

Moritz

 

[jens]

Here's what I would start with:

1. Is every flip-flop using the same clock? If so, that's good, skip
ahead to step #4.

2. Every flip-flop isn't using the same clock: can the design be
changed to make them all use the same clock? Are any clocks derived
from a base clock? If so, use only the base clock and create a clock
enable to replace the derived clocks. If there's only one clock left,
that's good, skip ahead to step #4.

3. The design absolutely needs multiple clocks or it would be more
effort than it's worth to use only one clock: find all signals that
cross clock domains and fix them if necessary. A signal that's not
related to other signals can use a simple synchronizer (two flip-flops
clocked by the destination clock), but multiple related signals (like
a bus or state machine output, even if it's just two signals) need
something else like a FIFO or handshaking. If you get that far (FIFO
or handshaking required), it may be a good time to go back to step #2.

4. Verify that all IC inputs that go to flip-flops (other than the
clock, of course) are properly synchronized (see step #3).

That should take care of asynchronous timing issues, of course there's
still the simulation/getting it to work phase, not adding any timing
issues, performing static timing analysis, etc.