|
Message
From: Richard Herveille<richard@h...>
Date: Thu Apr 12 09:26:24 CEST 2007
Subject: [oc] Wishbone spec clarification
The spec says that "cycle termination signals MUST be generated in
response to the logical AND of CYC and STB. That seems pretty clear
to me, and it also seems pretty clear that the example doesn't do
that. I certainly agree with your assertion that it may not matter,
but that doesn't mean that it doesn't violate the spec.
[rih] I'll keep my claim that it does not violate the spec, but I see your
point.
Imagine the bigger picture; CYC is a bus-request signal. A requesting master
asserts CYC_O and (at some point) STB_O. The bus arbiter generates its STB_O
in response to select the called slave. In this respect the bus arbiter
already had to validate its STB_I versus CYC_I (in order to generate the
slave's STB). So physically the slave generates ACK from the AND of the
master's CYC and STB, but this is really taken care of the by bus arbiter.
> CYC can be considered a bus-request signal
> STB can be considered a transfer-valid signal
> Most (all??) cores simply output CYC and STB at the same time;
> basically
> making them the same signal. However the spec allows CYC to be
> asserted
> without asserting STB.
That most cores do something doesn't matter. The spec says "MUST" and
it capitalizes it. Then it goes on to contradict itself. I'm not
trying to be pedantic here, but this is the whole reason you define
terms like "MUST" and "SHOULD" at the beginning of the spec.
[rih] Yes I agree. I am just stating that currently most cores output the
same signal for CYC and STB. However the spec allows STB to be negated while
CYC is asserted. So slave's should not assume that CYC and STB are the same
signal.
> ======================================
> What is the purpose of the LOCK_O signal? From the description it
> says
> that it indicates that the bus cycle is uninterruptible. However,
> the
> statement:
> Once the transfer has started, the INTERCON does not grant the bus
> to any other MASTER, until the current MASTER negates [LOCK_O] or
> [CYC_O].
> If deasserting CYC_O causes the lock to end, then this signal
> doesn't
> really do anything more than asserting CYC_O by itself, does it?
> [rih] Not really
> CYC is a bus-request signal. If it's asserted it validates all
> other
> signals. So if CYC is negated, LOCK is invalid.
> If a higher priority bus master asserts CYC then the bus arbiter
> might grant
> that master the bus. Asserting LOCK prevents this.
> So far nobody uses LOCK.
I see. So if you don't assert lock, the arbiter can take away access
even if the CYC signal remains asserted. That makes sense, thanks for
the clarification.
> ========================================
> What is the cab_i signal on slaves and cab_o on masters which the
> wb_conbus uses? I don't see it mentioned anywhere in the specs, and
> the
> conbus just seems to pass it on without acting on it.
> [rih] CAB is obsolete and has been superseded by CTI and CTE
OK. I don't see those in the spec either, so I'll assume they aren't
used.
[rih] CTI and BTE are explained in the 'registered feedback cycle' section4.
Richard
|
 |
Browse
