OPENCORES.ORG

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