Couple of questions about the wishbone registered feedback cycles. The specification is very specific in describing the behavior of sel() during burst cycles. It is vague when describing the behavior of sel() during end of burst cycles. This implies that it is possible to finish a burst with an odd number of bytes. Usually, the spec is very clear using words like MAY or MUST. Any reason its not clear here? Also, why not allow the first cycle of a burst (or any cycle, for that matter) to begin with an odd number of bytes? I can think of a not too contrived case where I might want to do it. Lastly, given that during constant cycles and incrementing cycles that the address has to either stay the same or change, why bother with differentiating these cycles from each other, and why do we need the burst wrap type at all? I suppose another way to phrase this would be, is it a good idea to have this redundancy in the interface and what happens if they don't agree? thanks, scott murphy p.s. is there a way to search the archives for discussion threads? --------------------------------- Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/cores/attachments/20040107/018beff4/attachment.htm

Couple of questions about the wishbone registered feedback cycles. The specification is very specific in describing the behavior of sel() during burst cycles. It is vague when describing the behavior of sel() during end of burst cycles. This implies that it is possible to finish a burst with an odd number of bytes. Odd number of bytes? You mean with some of SEL_O's bits negated? Sure, why shouldn't that be legal? Although it might be legal by the spec, it depends on the slave whether or not this is a legal transfer. Meaning whether or not it makes sense to the slave to have some of the SEL bits negated, for example some slaves are pure 32bit cores. They will assert ERR_O when any of the SEL_I bits are negated. Other slaves, like memory controllers, better should support these (byte / multi-byte accesses). Usually, the spec is very clear using words like MAY or MUST. Any reason its not clear here? Nah, it's just not mentioned. I added the following line (in the right place) to the End-of-Cycle example: "MASTER presents [SEL_O()] to indicate where it expects data." I fixed a couple of typos and added some clarifications to the spec. I will probably release a new spec soon. After thinking about it, I really believe the revB.3 spec should have been called revC.1 as it is a major rework from the revB.2 spec. As the next release is only be a minor revision of the current spec it should (and probably will) be called revC.2 Also, why not allow the first cycle of a burst (or any cycle, for that matter) to begin with an odd number of bytes? I can think of a not too contrived case where I might want to do it. I don't see why this isn't possible. The spec says that the master should set SEL_O during a transfer. A burst is simply 1+ transfers. See my first comment on SEL_O signals. Lastly, given that during constant cycles and incrementing cycles that the address has to either stay the same or change, why bother with differentiating these cycles from each other, Well because in one case (constant cycle) the address stays the same and in the other case the address increments, duh. Constant burst cycles can be used by streaming data to a FIFO for example. and why do we need the burst wrap type at all? Wrap bursts are commonly used by caches (cache line fills/writes). For example the OR1K uses wrap bursts for its caches. Masters that work on linear data (e.g. a video memory) use linear bursts. For example the vga/lcd controller uses linear bursts. I suppose another way to phrase this would be, is it a good idea to have this redundancy I don't see it as redundancy. A static memory controller could use these signals to prefetch the correct data at full speed and support both a CPU cache and linear memory blocks (to use the above examples). in the interface and what happens if they don't agree? Well, if something breaks in a handshaked communication than it breaks. There's no hardware fault recovery system. The ERR_O, ERR_I signals are supposed to trap these events. When a slave asserts ERR_O than something went wrong during the transfer (read/write to illegal address??). It's left up to the master to decide what to do with it. It will probably trigger an interrupt and leave it up to the software to clean up the mess. Cheers, Richard thanks, scott murphy p.s. is there a way to search the archives for discussion threads? _____ 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.cgi/cores/attachments/20040108/2771c8bc/attachment.htm

Richard, I'm looking forward to the updated spec. Please see my responses below. thanks Richard Herveille richard at asics.ws> wrote: v\:* {behavior:url(#default#VML);}o\:* {behavior:url(#default#VML);}w\:* {behavior:url(#default#VML);}.shape {behavior:url(#default#VML);} Also, why not allow the first cycle of a burst (or any cycle, for that matter) to begin with an odd number of bytes? I can think of a not too contrived case where I might want to do it. I donÂ’t see why this isnÂ’t possible. The spec says that the master should set SEL_O during a transfer. A burst is simply 1+ transfers. See my first comment on SEL_O signals. rules 4.35 and 4.40 prohibit this because the master is not allowed to change the value of SEL_O signals during constant or incrementing bursts. Thus it is illegal to begin a burst on an odd byte boundry. Though as you pointed out, not to end it that way if the slave supports it. I suppose another way to phrase this would be, is it a good idea to have this redundancy I donÂ’t see it as redundancy. A static memory controller could use these signals to prefetch the correct data at full speed and support both a CPU cache and linear memory blocks (to use the above examples). Of course, a slave could use the information, but if I didn't mind the performance hit, I could design a slave that didn't use the cycle tags at all. Or I could design a slave that looked at the burst type and the address. In this case, the byte wrap is redundant. Or I could design a slave that used the burst type and wrap type and the address from the first cycle. In this case, the address in the subsequent cycles is redundant. Now, I'm not trying to say this is good or bad. I'm just tryping to get more of a feel for the interface. Or perhaps its been too long since I had a good, nit-picky technical discussion. cheers --------------------------------- Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/cores/attachments/20040108/d5ec2a3b/attachment.htm

Richard, I'm looking forward to the updated spec. Please see my responses below. Don't get your hopes to high. It's only a minor update. Some fixes and clarifications, nothing special. Of course, a slave could use the information, but if I didn't mind the performance hit, I could design a slave that didn't use the cycle tags at all. So you design a Wishbone Classic slave. Or I could design a slave that looked at the burst type and the address. In this case, the byte wrap is redundant. The CTI and BTE signals are added to the specs to improve bandwidth. Using only one of the signals doesn't help; you still need to decode the address before you can fetch data. Using the CTI and BTE signals you can prefetch data. Don't try to discover new implementations; either use the Wishbone Registered Feedback cycles or don't. You are, of course, free to determine what transfers you support. Or I could design a slave that used the burst type and wrap type and the address from the first cycle. In this case, the address in the subsequent cycles is redundant. True, and that's probably how you must design the slave if you want to prefetch data. Now, I'm not trying to say this is good or bad. I'm just tryping to get more of a feel for the interface. Or perhaps its been too long since I had a good, nit-picky technical discussion. I can answer all your issues with one word: COMPATIBILITY A Wishbone Master that uses Registered Feedback cycles needs to support Wishbone Classic cycles as well. If you design a high-bandwidth slave you'll probably go for the Registered Feedback cycles as they provide the highest bandwidth (using bursts). If you design a simple slave, say some GPIOs, it doesn't make sense to support the more complex Registered Feedback transfers. You'll design a Wishbone Classic slave instead. Now as the Master doesn't know whether the attached slaves are Classic or Registered Feedback compatible slaves, it must provide enough information to support both. And that's the redundancy you're talking about. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/cores/attachments/20040109/e65b17b4/attachment.htm