When are two clock domains actually considered asynchronous?

Tue Dec 14, 2010 5:56 am   

On Dec 12, 3:37 pm, Alessandro Basili <alessandro.bas...@cern.ch>
wrote:

I never said testing isn't useful. I said that testing can't assure
that something works unless you test every possible condition and that
is not possible in an absolute sense.

Besides, you snipped the OP's comment I was responding to...

"the design seems to be working fine in hardware although I haven’t
made any extensive tests yet."

The problem we are discussing is ***exactly*** the sort of thing you
may not find in testing. The way the OP has constructed the circuit
it may work in 99.99% of the systems he builds. Or it may work 99.99%
of the time in all of the systems. But testing can't validate timing
since you can't control all of the variables.

The only thing testing can really do is to verify that your design
meets your requirements... if your requirements are testable! I've
been trained in quality process development and after seeing it in
action, I realize that much of it is not a better than intelligent
thinking. Just like many of the tools provided in engineering, this
is one that seems to provide benefit when used by the "masses" rather
than by the skilled.



"a huge difference"... I understand there are lots of ways to improve
testing, but that doesn't change the fundamental limitation of
testing.



I'm not sure what to say about this article. It is actually a bit
shallow in my opinion. But it also contains errors! Much of it is
really just the opinion of the author.



I think that terms like "good practices" are some of the least useful
concepts I've ever seen. First, where are "good practices" defined?
Without a clear, detailed definition of the term, it doesn't
communicate anything. Usually it is used to mean "what I do". It may
be defined within a company, in some limited ways it may be defined
within a sector. But in general this is a term that has little
meaning as used by most people. This is much like recommending to
design "carefully". I can't say how many times I have seen that word
used in engineering without actually saying anything.



What alternative would that be??? Is that different than the solution
I recommended?

Rick

Tue Dec 14, 2010 6:25 am   

On Dec 12, 4:17 pm, Beppe <beppe.e...@gmail.com> wrote:


I don't have time to draw a diagram, but here is some code. I've had
to edit out a lot of support circuitry which is not related, I hope I
didn't screw this up.

Scfg_Sync : process (SysClk, SysRst) begin
if (SysRst = '1') then
Scfg_SysClk <= '0';
elsif (falling_edge(SysClk)) then
if (Clk_en = '1') then
Scfg_SysClk <= not Scfg_StbLatch; -- Sync across clock domains
end if;
end if;
end process Scfg_Sync;

-- Control register interface
-- Clock interface and synchronize to system clock
CntrlReg : process (Scfg_Str, IF_EN) begin
if (IF_EN = '1') then
Scfg_StbLatch <= '0';
Scfg_StbLatch_D <= '0';
elsif (rising_edge(Scfg_Str)) then
Scfg_StbLatch <= Scfg_SysClk; -- Sync across clock domains
Scfg_StbLatch_D <= Scfg_StbLatch;
end if;
end process CntrlReg;

Scfg_clk_en <= Scfg_StbLatch xor Scfg_StbLatch_D;

Every time the clock enable in the SysClk domain is asserted, the loop
signal Scfg_SysClk toggles generating an edge which is detected by the
concurrent statement at the end. That logic can also be registered to
help with metastability issues since Scfg_StbLatch will go
metastable.

To convey the clock SysClk to the other domain, just remove the if
(Clk_en = '1') and let every rising edge send an transition to the
other domain. The Scfg_Str domain has to be clocked at least as fast
as the edge rate of Scfg_SysClk for an enable or twice as fast for a
clock.

Getting data across just requires that the data be held stable until
it is clocked into the receiving domain. Sometimes this does not
require an interface register at all depending on the particulars of
the interface timing, etc.

Rick

Wed Dec 15, 2010 11:55 am   

That makes it easier. Here’s the XST RTL schematic of the circuit:

http://www.mypicx.com/uploadimg/1078299247_12152010_1.jpg

And a wave diagram:

http://www.mypicx.com/uploadimg/694346392_12152010_2.jpg

Any particular reason for using the negative edge in the Scfg_Sync
process? I used the positive edge. data_in is clocked on the positive
sysclk edge without enable. data_out is clocked on the positive
scfg_str edge when scfg_clk_en is high.

Am I using this in a way you recognize?

/B

Wed Dec 15, 2010 4:22 pm   

On Dec 15, 4:55 am, Beppe <beppe.e...@gmail.com> wrote:

This is why I hate these machine drawn schematics. The machine has no
clue about the logical flow. Scfg_StbLatch should be in the same line
with the other blocks clearly showing the flow with the feedback loop
back to the other clock domain. The feedback loop is what makes it
work (each side is not armed until the other acknowledges) and the
following logic is just to reconstruct the enable or clock.



Yes, Scfg_Sync was required to use the falling edge in my design as it
is an external interface. This looks exactly as it should look for a
clock enable circuit. Metastability precautions are required for the
signal Scfg_StbLatch. The only other note is to make sure the data is
held stable long enough for it to be registered in the destination
domain. This may require a register in the data path driven by
SysClk. There are a lot of details dependent on the relative clock
speeds.

If you need to convey a clock enable just add that to the Scfg_SysClk
register.

Rick

Wed Dec 15, 2010 8:50 pm   

On 12/14/2010 4:56 AM, rickman wrote:
[snip]

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...).


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


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.


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.


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


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.


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).

> Rick

Wed Dec 15, 2010 11:35 pm   

On Dec 15, 2:50 pm, Alessandro Basili <alessandro.bas...@cern.ch>
wrote:

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.



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



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



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.



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.



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

Thu Dec 16, 2010 12:36 am   

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

Fri Dec 17, 2010 1:36 pm   

On 12/15/2010 11:36 PM, Beppe wrote:

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.

> /B

Fri Dec 17, 2010 3:43 pm   

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.


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

Fri Dec 17, 2010 3:52 pm   

On Dec 15, 5:36 pm, Beppe <beppe.e...@gmail.com> wrote:

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