When are two clock domains actually considered asynchronous?

[rickman]

I don't get that. What you call as "every possible condition" is
intended as every possible state of a particular set of logic. If your
logic cannot be described as a well defined number of states then I
agree that testing will never be enough (but in this case I suggest a
rework of the design).
If your states are not controllable (i.e. by an external control signal)
then there's little you can do in testing. If your states are even not
observable then I believe you are "doomed" (as somebody said earlier...).

If you are only talking about testing logic, yes, you can do that
exhaustively assuming a few conditions. But testing in general takes
on a lot more than that and the condition the OP was not a logic
issue, rather it would depend on uncontrolled variables and
potentially very intermittent.

I snipped the OP's comment because didn't add anything that wasn't
already said in your sentence.

It gave the context. Without the relevant context, which seems to be
the issue we are not communicating on, the points mean nothing.

This is why the way OP constructed the circuit was suboptimal and that
is why it was suggested not to use a generated clock, but an enable
signal (or even clock the UART with the original 25MHz clock).


If something cannot be testable, how would you accept those
requirements? And how can than be said the system doesn't work?
according to which requirement violation?





The fundamental limitation of testing are most probably due to a very
poor description of the device under test. That is why documentation
should be the first step in a work flow, rather then the last one where
the designer tend to leave out all the "unnecessary" details which
eventually lead to misunderstanding. How hard is to test one single
flip-flop? Not much, only because if fully described.





Could you please post the errors? Since I haven't found them, most
probably your reading was deeper than mine and it would be very helpful
to me.
The author not only gives an opinion, it lays down an approach which is
at a higher level of abstraction than the flops and gates.

I don't have time to do that now. Maybe I can come back to this over
the weekend.

In many books, standards, proceedings, articles and you may be lucky
that your company has already defined a set of them.

My experience is that most "good practices" are really just
experience. When they are "codified" they often loose their impact
because of being applied poorly. Yes, "good practices" is clearly
good. But it is a term that has no real definition except within some
specific context and so is not really useful in a conversation about a
concrete issue.

Usually it means "what most of the people do" as opposed of what you
suggested. Of course circumstances and requirements maybe some how very
demanding but an alternative architectural approach will surely have an
higher impact.

I see no value in doing "what most people do". I have seen the same
mistakes made over and over with people reciting their mantras.
Mostly these mistakes are just time wasters, but they are mistakes
none the less. I expect you will ask me for an example. One I see
often is the poor application of decoupling caps on devices. Many
people use all sorts of rules of thumb and claim that their rule must
not be violated or you aren't using "good practices". Meanwhile the
electric fields ignore their good practices and instead obey the laws
of physics.

As in the OP example, instead of suggesting how to control the timing of
the clk_250k I would recommend not to use it at all (that means one
clock less).

I'm not sure we are communicating on this one. That is what I told my
customer, use one clock on the inside and cross the clock domain at
the interface. This often makes the design much simpler and in the
customer's design allows the tools to figure out much simpler timing
and routing constraints.

Rick

 

[Beppe]

As in the OP example, instead of suggesting how to control the timing of

the clk_250k I would recommend not to use it at all (that means one > clock less).

What are you're arguments against using the clk_250k apart from having
one clock less? clk_25 is only used for generating the clk_250k. No
data is passing from the clk_25 domain to the clk_250k domain and
clk_250k is put on a low skew global clock net.

/B

 

[Alessandro Basili]

What are you're arguments against using the clk_250k apart from having
one clock less? clk_25 is only used for generating the clk_250k. No
data is passing from the clk_25 domain to the clk_250k domain and
clk_250k is put on a low skew global clock net.

I believe the reason of having an additional clock should be motivated.
All what I see reduces portability and invalidates a simple behavioral
description, since you need to instance the low skew clock directly in
your description. What would be your gain instead? The direct use of
clk_25 in your uart suits perfectly and the argument to reduce the
amount of power consumption on a bunch of flops (what, like 50???) is
not worth the effort.

 

[Beppe]

Well, I can see the point of using an enable instead of a divided
clock even if this clock is on a low skew clock net. It’s good design
practice and you don’t introduce an additional clock. Fine. However, I
think you should always question good design practice and understand
why it’s better to do it the “good” way rather than the unknown,
unexplored, uncommon, etc. way. At least if you want to get some
deeper understanding of the subject. Also, what was good design
practice yesterday is not always good design practice today. E.g.
Xilinx have changed their recommended coding styles quite a lot since
the introduction of the 6-input LUTs.

I believe the reason of having an additional clock should be motivated.
All what I see reduces portability and invalidates a simple behavioral
description, since you need to instance the low skew clock directly in
your description. What would be your gain instead? The direct use of
clk_25 in your uart suits perfectly and the argument to reduce the
amount of power consumption on a bunch of flops (what, like 50???) is
not worth the effort.

How would it reduce portability? The DCM has already reduced the
portability and I don’t see how the clock divider would reduce it even
more. Well, I can agree that instantiating a design element somehow
invalidates a behavioral description (if that’s what you meant), but
how do you go through a design without instantiating a single vendor
specific component? BTW, I didn’t have to instantiate the BUFG, the
tool inferred it!

/B

 

[rickman]

What are you're arguments against using the clk_250k apart from having
one clock less? clk_25 is only used for generating the clk_250k. No
data is passing from the clk_25 domain to the clk_250k domain and
clk_250k is put on a low skew global clock net.

I'm not trying to argue or convince you, so I don't have an argument.
You asked for opinions, I am offering mine. I don't know how much
logic you have in the various clock domains or if there are others. I
think you have said there is very little in the 28 MHz domain, but I'm
not at all clear on what is in the 25 MHz and 250 kHz domains.

I know little about letting the timing tools figure out how to handle
dual outputs from a DCM. Unless there is some compelling reason, I
would use clock crossing logic going between any of these clock
domains.

On the other hand, it is entirely possible to use a single clock
domain for the entire design. You have a 125 MHz clock domain which
is a super set of each of the slower clocks. A clock does not need to
be an integer multiple to use a clock enable. For that matter, it
doesn't even need to be 2x. In this design if the Midi code uses a
clock enable to set the rate, you could easily use the 28 MHz clock
with a 25 MHz enable.

But a lot depends on how much interface you have vs. the hassle of
converting code to work with enabled clocks. Clock crossing logic is
not large or complex. I mainly find it unpleasant in that it clutters
up a design somewhat. A recent design I did had expanded an existing
design running on a 12.288 MHz clock from off board PLL controlled
based on an interface FIFO. So this clock had to be used to establish
interface timing, both sides in fact. The code I was adding had to
have a section that ran on a 32 MHz clock to operate a digital PLL for
a third interface. I had planned to provide a clock crossing
interface between the two new sections of logic. But at some point
this became a PITA and I ended up making the entire new design run on
the 32 MHz clock and turned the 12.288 into an enable for the two
exiting interfaces. OTOH, the previous circuit was working fine and
had little to do with the new circuit (different modes of operation)
so it was left alone clocking off the 12.288. Yet another interface
for configuration was clocked off the interface clock (sort of a
bastard SPI) and was also not changed for the new section. So
multiple clocks are not bad, but I find it easier to live with if I
convert at the external interface and run on one clock as much as
possible.

Rick