Hi

Since we don't have a Wishbone maillist. I guess I will use this one instead.
After reading through the wishbone spec (latest), I have a few questions that someone might be able to answer. thanks.

... SETUP, EDGE 1: SLAVE decodes inputs, and responding SLAVE asserts [ACK_I]. SLAVE presents valid data on [DAT_I()] and [TGD_I()]. SLAVE asserts [ACK_I] in response to [STB_O] to indicate valid data. MASTER monitors [ACK_I], and prepares to latch data on [DAT_I()] and [TGD_I()]. CLOCK EDGE 1: MASTER latches data on [DAT_I()] and [TGD_I()]. MASTER negates [STB_O] and [CYC_O] to indicate the end of the cycle. SLAVE negates [ACK_I] in response to negated [STB_O]. This is a bit scary... on rising edge of a single clock, both sides are monitoring and presenting data and doing latching at the same rising clock? what happens to delays? Shouln't it take at least 3 rising edges? (assuming we don't use falling edges.) Like: 1. Rising of edge 1 SLAVE decodes inputs, and responding SLAVE asserts [ACK_I]. SLAVE presents valid data on [DAT_I()] and [TGD_I()]. SLAVE asserts [ACK_I] in response to [STB_O] to indicate valid data. 2. Rising of edge 2 MASTER monitors [ACK_I], and prepares to latch data on [DAT_I()] and [TGD_I()]. MASTER latches data on [DAT_I()] and [TGD_I()]. MASTER negates [STB_O] and [CYC_O] to indicate the end of the cycle. 3. Rising of edge3 SLAVE negates [ACK_I] in response to negated [STB_O]. The picture gets scarier when you read "block read/write" on page 51: SETUP, EDGE 1: SLAVE decodes inputs, and responding SLAVE asserts [ACK_I]. SLAVE presents valid data on [DAT_I()] and [TGD_I()]. MASTER monitors [ACK_I], and prepares to latch [DAT_I()] and[TGD_I()]. CLOCK EDGE 1: MASTER latches data on [DAT_I()] and [TGD_I()]. MASTER presents new [ADR_O()] and [TGA_O()]. MASTER presents new bank select [SEL_O()] to indicate where it expects data. The problem I have here is that, (besides the previous mentioned problems), MASTER presents new [ADR_O()] and [SEL_O()] without de-asserting STB and re-asserting STB (or some other indication that the first transfer is done.) How does the SLAVE know whether the MASTER is just taking its time de-asserting STB or already presenting new requests? --------------------------------- Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums/openrisc/attachments/20040106/0308cab2/attachment.htm

Hi Paul, OpenRisc mailing list isn't the place to discuss these issues. The opencores mailing list is more suited for that. But anyway I'll try to answer your questions. First of all you are talking about Wishbone Classic cycles. Let's say a master wants to perform a single transfer. At the initiation rising clock edge the master asserts: - CYC_O to signal it wants to initiate a transfer. - STB_O to signal it is ready to transmit or receive data - ADR_O, SEL_O, etc The slave decodes the inputs and responds (within the same clock cycle). Important here is that the slave asserts ACK_O The master receives the ACK from the slave and at the next clock cycle negates CYC_O, STB_O, etc. For a burst cycle the master simple keeps CYC_O and STB_O asserted, the slave responds every cycle until the burst is finished. Now as you see every action takes place between two rising clock edges, making this a synchronous transfer scheme. However due to the fact that the slave needs to respond in an asynchronous fashion, this is only suited for (relatively) low clock frequencies. Problem is that as the design gets bigger (more masters and slaves) the interconnect structure (with the asynchronous nature of the slave's response) becomes the critical path. Thus limiting the maximum operating frequency of the design. One way of boosting the frequency is to cut the path between the master and the slave. Meaning that the slave responds synchronous (i.e. its outputs are registered). But this adds a one cycle delay, as the slave responds in the next cycle after the master asserts its signals. In the worst case this means that only 50% of the total available bandwidth can be used. See Wishbone Registered Feedback Cycles for solutions to this problem. Cheers, Richard -----Original Message----- From: openrisc-bounces@opencores.org [mailto:openrisc-bounces@opencores.org] On Behalf Of paul w Sent: Wednesday, January 07, 2004 6:13 AM To: OpenRISC@opencores.org Subject: [openrisc] wishbone problem Hi Since we don't have a Wishbone maillist. I guess I will use this one instead. After reading through the wishbone spec (latest), I have a few questions that someone might be able to answer. thanks. ... SETUP, EDGE 1: SLAVE decodes inputs, and responding SLAVE asserts [ACK_I]. SLAVE presents valid data on [DAT_I()] and [TGD_I()]. SLAVE asserts [ACK_I] in response to [STB_O] to indicate valid data. MASTER monitors [ACK_I], and prepares to latch data on [DAT_I()] and [TGD_I()]. CLOCK EDGE 1: MASTER latches data on [DAT_I()] and [TGD_I()]. MASTER negates [STB_O] and [CYC_O] to indicate the end of the cycle. SLAVE negates [ACK_I] in response to negated [STB_O]. This is a bit scary... on rising edge of a single clock, both sides are monitoring and presenting data and doing latching at the same rising clock? what happens to delays? Shouln't it take at least 3 rising edges? (assuming we don't use falling edges.) Like: 1. Rising of edge 1 SLAVE decodes inputs, and responding SLAVE asserts [ACK_I]. SLAVE presents valid data on [DAT_I()] and [TGD_I()]. SLAVE asserts [ACK_I] in response to [STB_O] to indicate valid data. 2. Rising of edge 2 MASTER monitors [ACK_I], and prepares to latch data on [DAT_I()] and [TGD_I()]. MASTER latches data on [DAT_I()] and [TGD_I()]. MASTER negates [STB_O] and [CYC_O] to indicate the end of the cycle. 3. Rising of edge3 SLAVE negates [ACK_I] in response to negated [STB_O]. The picture gets scarier when you read "block read/write" on page 51: SETUP, EDGE 1: SLAVE decodes inputs, and responding SLAVE asserts [ACK_I]. SLAVE presents valid data on [DAT_I()] and [TGD_I()]. MASTER monitors [ACK_I], and prepares to latch [DAT_I()] and[TGD_I()]. CLOCK EDGE 1: MASTER latches data on [DAT_I()] and [TGD_I()]. MASTER presents new [ADR_O()] and [TGA_O()]. MASTER presents new bank select [SEL_O()] to indicate where it expects data. The problem I have here is that, (besides the previous mentioned problems), MASTER presents new [ADR_O()] and [SEL_O()] without de-asserting STB and re-asserting STB (or some other indication that the first transfer is done.) How does the SLAVE know whether the MASTER is just taking its time de-asserting STB or already presenting new requests? _____ Do you Yahoo!? Yahoo! Hotjobs: Enter http://pa.yahoo.com/*http:/us.rd.yahoo.com/hotjobs/mail_footer_email/ev t=21482/*http:/hotjobs.sweepstakes.yahoo.com/signingbonus> the "Signing Bonus" Sweepstakes -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums/openrisc/attachments/20040107/7ca6160e/attachment-0001.htm