Hi I do not work on OR1200 right now, but I have experience with it and other embedded processors.
Here is what I see as a sensible solution: 1. default exception address: - configurable at compile time with a parameter in Verilog - power up value same as before 0x0 (default value for the parameter) - there is no need for a runtime configuration signal (all configuration can be done in software) 2. programmable register - can be accessed (reads/writes) only in supervisor mode - there could be a write lock bit for this register, it could be useful for example on a no MMU system (I am not an expert here), the lock would only be cleared by a hardware reset - the programmable register can be made optional (to save some logic) with a compile time Verilog parameter, one way to achieve this is to set the lock bit to 1 after reset (Verilog parameter) - another way to restrict this register is to provide a mask (parameter) for bits that can be written to, a sensible default for such a mask would be 0xfffff000, this is assuming the space reserved for exceptions is 0x1000 (again, I do not remember the OR1200 details) Explanation: The most common scenario for this feature is booting the system from ROM (or Flash), extracting the Linux image into RAM and moving exception vectors to RAM. After power-on reset the reset address should point to 0x0 (again, I do not remember the OR1200 details). At this address there should be a ROM (of Parallel Flash or SPI Flash with an XIP controller). In this ROM there should be a small boot-loader which is able to determine the correct exception address and write it into the register. There is no need for configuration signals going into the CPU, since the boot-loader is able to read GPIO. Another use-case for configurable exception address is an ASIC with all code in ROM. The exception address can be moved to RAM for debugging purposes, or to patch an issue in the exception handling code in ROM. Regarding the documentation it might make sense to only document the parameter defaults and software accessible options, and leave the available parameterization options to people who read the Verilog source. Regards, Iztok Jeras _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
