|
Message
From: matt at ettus.com<matt@e...>
Date: Thu Apr 12 12:08:54 CEST 2007
Subject: [oc] Wishbone spec clarification
----- Original Message -----
From: Richard Herveille<richard@h...>
To:
Date: Thu Apr 12 08:28:44 CEST 2007
Subject: [oc] Wishbone spec clarification
> =====================================
> The wishbone spec, Rule 3.30, on page 41 states:
> SLAVE interfaces MAY NOT respond to any SLAVE signals when [CYC_I]
> is negated.
> However, in figure A-11 on page 110, it is clear that the CYC_I
> signal
> is completely ignored by the simple register. It also similarly
> violates Rule 3.35 on page 41,
> The cycle termination signals [ACK_O], [ERR_O], and [RTY_O] must
> be
> generated in response to the logical AND of [CYC_I] and [STB_I].
> I'm new to wishbone, so I'm not sure if this is a big deal or not,
> but I
> could imagine problems if the INTERCON assumes the slaves follow
> these 2
> rules and they don't.
> [rih] It does not violate the specs.
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.
> 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.
> ======================================
> 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.
Thanks,
Matt
|
 |
Browse
