Replies: 4 comments
-
Thanks for the link and suggestion! @mactcp was doing some work on timings too- @mactcp any thoughts? I'll review the doc and change later this week when I can get some free time :) |
Beta Was this translation helpful? Give feedback.
-
I don't think the SCSI specification requires a bus settle delay there. Bus settle delay seems to be required when MSG, C/D, I/O change, before the first assertion of REQ for a data transfer phase. After driving the DB signals, the initiator or target should wait at lest a cable skew delay (10ns) before asserting REQ or ACK. Nothing is as fast as 10ns on this chip so we are good in terms of that requirement. At the receiving end, no delay is required because the sending end has already inserted at least a cable skew delay. On the next page of that spec, https://www.staff.uni-mainz.de/tacke/scsi/SCSI2-06.html, section [6.1.5.1 Asynchronous information transfer], it says the initiator will insert at least one deskew delay between driving the DB signals and asserting ACK. As the BlueSCSI is the target, we don't need a delay there. I've also been using this old SCSI-1 spec, on page 26, it also says the initiator will wait a deskew delay. It would be good to check that anywhere the the information phase changes that at least a bus settle delay is occurring. That said, the fast optimized writeDataLoop implementation I've done still takes ~450ns for a single data transfer cycle. It does not take much code to get 400ns of delay on this chip. As I've found with the optimization work I have been doing, loop timing can be very sensitive. The loop may or may not take a 2 cycle cache fetch hit if it crosses over an 8 byte cache buffer. I had to force alignment of the functions, and pad with NOPs in some places to get consistent timing of small loops. I've been measuring everything with an oscilloscope to see how fast it actually is. @marcelv-3 I'm definitely curious if you have encountered a problem that is fixed by this change? |
Beta Was this translation helpful? Give feedback.
-
Looking at where there should be bus settle delays, in most cases there aren't appropriate delays. I am seeing some easy wins where this could be improved with no risk of any sort of negative performance impact. In writeDataPhaseSD, readDataPhaseSD, and verifyDataPhaseSD we could simply reorder the bus phase change to before the file seek, and the call to file.seek() is probably going to be more than 400ns. I'll run some tests and propose a change. There are a bunch of other places where adding a delay would make sense. |
Beta Was this translation helpful? Give feedback.
-
I've been taking a look at the delays in writeHandshake, which have references to the DTC-510B. The manual for the DTC-510B has examples for single byte transfers, and it looks like whoever originally wrote this incorporated the bus settle delay in to writeHandshake(). However that is being done for every byte in multi-byte transfers, not just on the phase change. Currently there don't seem to be any bus settle delays for anything involving readHandshake(), so I can see why this discussion has started with a proposal for adding an equivalent delay there. I've submitted a pull request where simply reordering some code so the phase change happens before file.seek() gets us a free bus settle delay of >400ns. It seemed like low hanging fruit where there is no risk of any sort of negative impact. One other thing I'm looking at is phase changes currently use 3 GPIO writes, which are 2 cycles each, so about 28ns each. Combining those to a single write could shave off 56ns for a phase change. Looks like there is plenty of room for cleanup and optimization around this. |
Beta Was this translation helpful? Give feedback.
-
Add a 400ns delay in readHandshake to wait until the signal line stabilizes.
delay_ns(SCSI_BUS_SETTLE_DELAY);
delay_ns function added.
maybe necessary in more places to be more in sync with SCSI timing specifications
SCSI Bus timings:
https://www.staff.uni-mainz.de/tacke/scsi/SCSI2-05.html
Beta Was this translation helpful? Give feedback.
All reactions