This message is from the T13 list server.
> The bridges I've designed and work with > have generally all had embedded uPs > to parse commands This sounds far short of if it works locally it will work behind the bridge too. Did you do any bridges to Atapi devices? What did you do with the unsupported commands? Reject them - or pass them thru as best you were able? Did you have the kind of IP relationship with the Atapi device people that you could get them to disclose in detail how to bridge each of their vendor-specific commands? > The bridges I've designed and work with > have generally all had embedded uPs > to parse commands - this just makes life so much easier. Yes we can make life easier by quietly swallowing the cost of a reprogrammable bridge and the cost of tweaking and requalifying code to support the especially creative design features, if any, of each new Atapi device which we wish to connect by bridge. We don't quietly swallow any costs. Surely you don't either? > an FPGA implementation wants to use a uP simpler When we have a microprocessor, we try to mask the rom so we can sell lots of copies of one bridge to work with a variety of devices we haven't yet seen, ... Fpga, reprogrammable uP, Asic, whatever, we still save money if we can figure out how to rev the design less often. > Today an embedded 8031 class uP > running at a high clock rate (say 48 MHz) is cheap > and can do the job quite well. > > You can embed that code in ROM, > and supply an external EEPROM capability > for updates. External EEPROM is money. Money talks. I remember in my first Atapi design we blew four weeks of two engineers in December to save US$0.60 per unit. > Given the pin counts you need anyway for the interfaces, > the resulting die is not the limiting factor > that drives bridge cost - instead it is the IO ring. Yes this is key when true, thank you ... but I have data I can't disclose in detail on rom-bound silicon. Might be worth keeping an eye on your bridge suppliers: in any generation, if they could shrink the rom, could they shrink the die? > some things ... affect hardware design And some things don't. Anybody tolerant enough of command overhead to let a uP in a bridge try to duplicate the command parsing in the Atapi device has a good chance of being able to tolerate two additional register reads after the status INTRQ. > Perhaps it would help if you had some more data > on the cases where the system was failing for this reason I agree. This data is difficult and expensive to gather ... no? Some people consider this highly pr*prietary, time-sensitive, market-edge stuff. Why should you help me avoid the problems you invested blood, sweat, and tears to avoid? Why shouldn't you leave the pitfalls unremarked in the spec for me to fall into? Rather than trying to argue wrong non-block residue will matter, I more often argue that it has mattered and it is cheap to eliminate. > Perhaps it would help if you had some more data > on the cases where the system was failing for this reason I don't think this data flows to me readily. Of all the plug 'n play troubles people experience, how many are reduced to a root cause that is relayed back to the designer of the host and the designer of the device? Maybe not many. Maybe the Pio traces I see only after all the people between me and the customer have given up in mystification are just the tip of the iceberg. Maybe not. "Rather than trying to argue wrong non-block residue will matter, I more often argue that it has mattered and it is cheap to eliminate." Free with AtapiPio, provided the device accurately reports residue. I've heard of Atapi devices that reply to, say, x 12 0 0 0 05 0 Inquiry for 5 bytes with a Pio DRQ of 6. Reporting residue separately from the sum of DRQ x1F5:1F4 ByteCount's would let such a device protect its legacy and yet still transfer the correct number of bytes to a host that cared about accuracy. Less free with AtapiDma. Getting the residue right is cheap, but passing none of back on in to the host requires a hardware change. > ... If accepting anything less than a transparent bridge is not a way of leaving enough money on the table for me to retire on, I want to hear that ... but I haven't yet. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org.
