1/1 
|
Re: Possible Error in WB Slave unit
by Unknown on Nov 18, 2005 |
Not available! | ||
|
dsp at mail2.qortek.com wrote:
This is what I’m observing in hardware. I start a cycle by asserting
[CYC_O], [STB_O] and[ WE_O] and qualify [ADR_O]. The slave unit responds after a few clock cycles with an [ACK_O] that looks to be sync with [CLK_I]. Since the WB Master samples [ACK_I] on the rising edge of [CLK_I] the signal [ACK_I] (due to delay) is not qualified until the following cycle. It sounds to make like you've got a classic timing problem.
The problem is that the Slave unit negates the [ACK_O] signal at the
end of the current clock cycle even though the Master is still asserting [CYC_O] and [STB_O]. My understanding of the WB B3 spec, the slave should continue to assert [ACK_O] until [CYC_O] or [STB_O] are negated. This is incorrect. The slave asserts [ACK_O] for one cycle. If on the next cycle [CYC_O] and [STB_O] are high, this indicates a new cycle.
Is this a correct observation of the [ACK_O] signal from the slave?
Yes.
Further more, the slave enters a second read cycle which is the
terminated from the previos master read cycle. Of course.
The problem here is
that [ACK_O] remains asserted. Not a problem for the Master, but the slave is not ready and the cycle is terminated too early. Timing.
I'm going to look into correcting this by these methods
1) the slave unit continues to assert [ACK_O] untill [STB_I] is nagated. That would not be within spec, AFAIK.
2) the slave unit asserts ack before rising edge of the qualifiing
edge of [CLK_I] It just sound like you have some serious timing constraint problems. You dave the entire design on one clock, and are not seperating them into seperate domains, are you? WISHBONE is a fully synchronous spec (i.e. same frequency AND phase). In a standard classic cycle with a registered slave output (ignoring CYC_O, etc. for brevity) you'll see the following. I'll insert three wait states. 1.1 Master asserts STB_O. -- next clock edge -- 2.1 Slave samples STB_I as asserted and outputs nothing 2.2 Master samples ACK_I as deasserted (still) -- next clock edge -- 3.1 Slave asserts ACK_O 3.2 Master samples ACK_I as deasserted (still) -- next clock edge -- 4.1 Slave deasserts ACK_O 4.2 Master samples ACK_I as asserted 4.3 Master deasserts STB_O -- next clock edge -- 5.1 Slave samples STB_I as deasserted and all is right with the world You don't mention your level of education or experience, and without further detail, it sounds like your having trouble with a standard synchronous handshaking idiom. I would recommend drawing the circuit up and representing the control signal outputs driven by registers, and make yourself a timing diagram complete with setup and hold times (i.e. don't have any output change on a clock edge). Kinda like the ones in the spec. But you'll understand it better if you work out the timing for yourself.
Paragraphs from WB B3 spec:
3.1.3 Handshaking Protocol All bus cycles use a handshaking protocol between the MASTER and SLAVE interfaces. As shown in Figure 3-2, the MASTER asserts [STB_O] when it is ready to transfer data. [STB_O] remains asserted until the SLAVE asserts one of the cycle terminating signals [ACK_I], [ERR_I] or [RTY_I]. At every rising edge of [CLK_I] the terminating signal is sampled. If it is asserted, then [STB_O] is negated. This gives both MASTER and SLAVE interfaces the possibility to control the rate at which data is transferred. Yes, the above is correct. I'm not sure how your interpreting it such that your missing things. The only thing I can think of is that you dan't have a phase aligned clock for both master and slave. - hoffer |
|||
|
Re: Possible Error in WB Slave unit
by dsp on Nov 20, 2005 |
dsp
Posts: 8 Joined: Jan 23, 2011 Last seen: Jan 27, 2025 |
||
|
Education BS in electronics, 15+yrs Programming, 4yrs+ job experience
(FPGAs/DSP/Systems). I have about 6yrs in industrial control systems
(jobs during college and high school). I'm working on masters (but
that will be in optics engineering). Always educating myself (ANY good
book recommendations?)
Please see the TI DSP and Xilinx FPGA Dev Board project on opencores.
Indeed i did miss this STB_O and ACK_I signaling, and fixed it so that
STB_O is negated when ACK_I is qualified on the rising edge of CLK_I.
One clock for WB!! One clock for EMIF and signals are Syncronized
between the domains. There is clock for the PCI which has a rolling
phase alignment because 40M and 33M are not direct multiples. There
are FIFOs between PCI and WB so this should not be an issue. And i
didnt see any restrictions on the two clocks in the manual. But i may
have missed that if one does exist.
I use BUFG for clocks, and DCM to generate all the clocks for WB, PCI
and Chipscope pro.
100Mhz in
33Mhz out for PCI
40Mhz out for WB
240Mhz out for ChipScope.
Emif clock comes for DSP. Emif clock has nothing to do with my master
output signals since there are syncronizers in place.
Also, I'm running this in host mode.
I'm looking at the ACK_O generation and only see one instance that
[ACK_O] might be generated async with WB Clock and that is from
del_error_in which appears to be latched on the rising edge of PCI
Clock in the the module pci_delayed_sync on line 439?
Otherwise, the STB_O negation fix worked. But I'm still seeing odd
issues with the ACK_O signal.
You are probably correct there is a timing issue somewhere, and i many
need to refine some constraintsmor lower the WB clock frequency.
This is the first design that's i've done with more than 2 clock
domains. And the second attempt at WB interface first was a slave
device on a different project.
I'm going to continue to work through this, please bare with me.
----- Original Message -----
From: Michael Hordijkhoffbrinkle at h...>
To:
Date: Fri Nov 18 23:30:45 CET 2005
Subject: [pci] Re: Possible Error in WB Slave unit
dsp at mail2.qortek.com wrote:
> This is what IÂ’m observing in hardware. I start a cycle
by asserting
> [CYC_O], [STB_O] and[ WE_O] and qualify [ADR_O]. The slave
unit
> responds after a few clock cycles with an [ACK_O] that looks
to be
> sync with [CLK_I]. Since the WB Master samples [ACK_I] on the
rising
> edge of [CLK_I] the signal [ACK_I] (due to delay) is not
qualified
> until the following cycle.
It sounds to make like you've got a classic timing problem.
> The problem is that the Slave unit negates the [ACK_O] signal
at the
> end of the current clock cycle even though the Master is still
> asserting [CYC_O] and [STB_O]. My understanding of the WB B3 spec,
> the slave should continue to assert [ACK_O] until [CYC_O] or
[STB_O]
> are negated.
This is incorrect. The slave asserts [ACK_O] for one cycle. If on the next cycle [CYC_O] and [STB_O] are high, this indicates a new cycle.
> Is this a correct observation of the [ACK_O] signal from the
slave? Yes.
> Further more, the slave enters a second read cycle which is
the
> terminated from the previos master read cycle.
Of course.
> The problem here is
> that [ACK_O] remains asserted. Not a problem for the Master, but the
> slave is not ready and the cycle is terminated too early.
Timing.
> I'm going to look into correcting this by these methods
> 1) the slave unit continues to assert [ACK_O] untill [STB_I] is nagated. That would not be within spec, AFAIK.
> 2) the slave unit asserts ack before rising edge of the
qualifiing
> edge of [CLK_I]
It just sound like you have some serious timing constraint problems. You dave the entire design on one clock, and are not seperating them into seperate domains, are you? WISHBONE is a fully synchronous spec (i.e. same frequency AND phase). In a standard classic cycle with a registered slave output (ignoring CYC_O, etc. for brevity) you'll see the following. I'll insert three wait states. 1.1 Master asserts STB_O. -- next clock edge -- 2.1 Slave samples STB_I as asserted and outputs nothing 2.2 Master samples ACK_I as deasserted (still) -- next clock edge -- 3.1 Slave asserts ACK_O 3.2 Master samples ACK_I as deasserted (still) -- next clock edge -- 4.1 Slave deasserts ACK_O 4.2 Master samples ACK_I as asserted 4.3 Master deasserts STB_O -- next clock edge -- 5.1 Slave samples STB_I as deasserted and all is right with the world You don't mention your level of education or experience, and without further detail, it sounds like your having trouble with a standard synchronous handshaking idiom. I would recommend drawing the circuit up and representing the control signal outputs driven by registers, and make yourself a timing diagram complete with setup and hold times (i.e. don't have any output change on a clock edge). Kinda like the ones in the spec. But you'll understand it better if you work out the timing for yourself.
> Paragraphs from WB B3 spec:
> > 3.1.3 Handshaking Protocol > All bus cycles use a handshaking protocol between the MASTER and SLAVE
> interfaces. As
> shown in Figure 3-2, the MASTER asserts [STB_O] when it is ready to
> transfer data. [STB_O]
> remains asserted until the SLAVE asserts one of the cycle terminating
> signals [ACK_I], [ERR_I]
> or [RTY_I]. At every rising edge of [CLK_I] the terminating signal is
> sampled. If it is asserted,
> then [STB_O] is negated. This gives both MASTER and SLAVE interfaces
> the possibility to
> control the rate at which data is transferred. Yes, the above is correct. I'm not sure how your interpreting it such that your missing things. The only thing I can think of is that you dan't have a phase aligned clock for both master and slave. - hoffer |
|||
1/1