Mixed clocked/combinatorial coding styles (another thread)

Andy wrote:
> One major reason to avoid multiple clock domains when possible is that
> simulation (RTL or full-timing) rarely reveals the problems inherent
> in crossing clock domains. Static timing analysis does not reveal them
> either. Experienced designers know to avoid problems they don't need.
> If you think complex code is hard to debug, you should try debugging
> behavior that is not repeatable in simulation at all.

You are right on the points you raise. Additional clock domains should
be always avoided if possible. And if they are needed they should be
separated from the code with coding conventions, so they will be easy to
check in code reviews etc.

There are tools to check the clock domain crossings statically, but
those tools are not cheap. They are meant for ASIC designs where the
respin cost is high enough to justify the price of the tool. I have
used Mentor 0-In CDC, and that tool is very good in finding clock domain
crossing problems. But it is additional tool that needs setup, and
someone who really understands what asynchronous clock domain crossing
means, and what can be a problem and what is not.


--Kim

On Aug 26, 1:09*am, Kim Enkovaara <kim.enkova...@iki.fi> wrote:

> There are tools to check the clock domain crossings statically, but
> those tools are not cheap.

On the low end $$ side, Quartus will report the clock domain crossings
in their standard timing analysis. There is an option called 'Cut
paths between unrelated clock domains' which defaults to 'On'. Change
that to 'Off' and it will include in the report timing that crosses
clock domains.

KJ

KJ wrote:
> On Aug 26, 1:09 am, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
>
>> There are tools to check the clock domain crossings statically, but
>> those tools are not cheap.
>
> On the low end $$ side, Quartus will report the clock domain crossings
> in their standard timing analysis. There is an option called 'Cut
> paths between unrelated clock domains' which defaults to 'On'. Change
> that to 'Off' and it will include in the report timing that crosses
> clock domains.

It's not problematic to get list of all clock domain crossing, its easy
also in primetime etc., but checking them is a big task, and to keep up
with the design changes. STA can not analyze if the crossings are
correct.

The formal tools do for vhdl/verilog code preliminary synthesis,
or read in netlist from synthesis. After that they look for clock
domain crossings, and formally proof that the crossing are either
correct or incorrect. The tools know quite big amount of different
synchronizer structures and where they should/can be used. Also own
structures can be defined. The tools have also methods to inject
metastability to the designs during simulation etc.

--Kim

Kim Enkovaara wrote:

> It's not problematic to get list of all clock domain crossing, its easy
> also in primetime etc.,

I think Kevin mentioned low cost.

> STA can not analyze if the crossings are
> correct.

True, but I can, so a warning has significant value.
This is a rare feature in fpga vendor tools.

-- Mike Treseler