race conditions in huge project

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

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

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.

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