I have a few questions about the Wishbone specs:

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

======================================

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?

========================================

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.

========================================

Thanks,
Matt

===================================== 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. 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. ====================================== 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. ======================================== 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 ======================================== Thanks, Matt _______________________________________________ http://www.opencores.org/mailman/listinfo/cores

Richard Herveille wrote:

And of course if you qualify it with per-slave address-decode logic, it becomes a chip-select. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266

And of course if you qualify it with per-slave address-decode logic, it
becomes a chip-select.

[rih] True, which is why simple slaves really don't need CYC_I as they
should only qualify STB, however all cores I have seen so far (including
mine) use both CYC_I and STB_I.

Typical ACK_o generation is then like this: ACK_O = CYC_I & STB_I;

If an external address decoder is used, it should validate the address based
on CYC_I. In that case the generated STB_O signals (i.e. chip-selects) are
already validated against CYC_I.
The slave's CYC_I inputs can then be tied to '1'.

Richard

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.




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.




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.



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

----- Original Message ----- From: Richard Herveillerichard at h...> To: Date: Thu Apr 12 08:28:44 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.



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.



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.



OK. I don't see those in the spec either, so I'll assume they aren't
used.

Thanks,
Matt