On 6/6/05, Jack Carroll <[EMAIL PROTECTED]> wrote: > On Sun, Jun 05, 2005 at 09:56:14PM -0400, Timothy Miller wrote: > > > > Yes, of course. We'll have fifos that cross clock domains. In fact, > > that's pretty much the primary way to get data across clock domains. > > That puts the purpose into context. When you say "cross clock > domains", are you talking about completely independent clock domains, or > about different clocks that ultimately derive from the same master > oscillator?
Completely independent. > In other words, do we have to plan for a handshake that can > cope with metastability as in a hard disk interface, or can we design things > so that the receiving register's setup time will always be met? Yes, we do have to cope with metastability. We have one that should deal with any two domains, regardless of their relative periods and phases. It's very generalized, but it also introduces more latency than some alternatives. I'll post it soon. > And with that, I'll hold off taking up any more time in this > discussion until I get further along studying, and have a reasonable chance > of doing some useful work on the project. > > On another subject, I did a little preliminary follow-up on the > interest you expressed in having a plug-in option for the memory that holds > the FPGA load image. > Out of half a dozen common flash memory cartridges made for digital > cameras, the only one with a reasonably simple protocol seems to be Memory > Stick. The others emulate ATA interfaces, or floppy disks, or worse. It > has a serial protocol, but not one as simple as the usual serial flash chips > used in embedded systems. It requires a command stream to make it read data > out. A lot is left out of the protocol document I found on line, and there > are hints that an NDA might be required to get the details of the command > syntax. > The other thing to be determined is whether PC-compatible cartridge > reader/writers are readily available, and not just cartridge readers. > Depending on the FPGA card to write the cartridge could very easily create > chicken-and-egg paradoxes, and might well require more hardware. We need something very simple, so I think we'll just use a basic flash chip directly. However, we may be able to socket it. Not sure. > The sort of implementation I envision is to always install the > regular FPGA image memory EEPROM with hardwired write protection, to > guarantee recovery from an operator goof-up. It would include logic to read > the cartridge, and would automatically load the optional image from there if > the cartridge responded to probing. > Think this is worth further research? I don't know. The thing is, the PCI controller will be its own flash-based FPGA, and we're not going to provide a software path to reprogram it. Unless you have the right equipment, you can't update the PCI controller. If the flash that holds the BIOS and Xilinx bitfile gets corrupted, you can just reprogram it. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
