Hi Stefan, I think we are aligned in Request(2) and Request(3) based on ur input .. > "we protected this by making it write (and read?) only in supervisor mode?" > "(That it should be protected should be added to the spec either way)" [Pekon]: Please explicitly mention that READ(s) to above register should only be allowed only in supervisor mode.
What remains is Request(1).. > "Or by passing a parameter, although then it'd only be configurable at synthesis time." [Pekon]: Using parameter is better option, than having extra ports at boundary of OR1200.. having configurable during at synthesis time is okay, afterall we are just taking about "default-value after reset". Anyways you are providing a Software Register which can be programmed in supervisor mode to update the final value during boot. [Background]: configurability of exception_vector_base_addr "right from reset" was needed to take care of scenarios where exception happens before boot-software could update this register. [Example]: while booting from external interface, when source code is being downloaded the code from external memory, suddenly an exception is raised. [Limitation]: With current system, user has to put his default exception_vectors only at 0x0000. [Possible Solution]: Using parameter for reset-value of Register "exception_vector_base_addr". [Possible Advantages]: (a) Parameter gives user flexibility to put "default" exception_vectors at any other place also, say some different address of external_memory itself, from where code was getting downloaded. Thus user has complete control. (b) whole code (including default_exception_vectors) can lie in single external memory (under contiguous memory map). So following statement should suffice the requirement for OR1200 spec.. "default-value of exception_vector_base_addr (value after reset) can be modified by user during synthesis" And it would work for ork1sim also.. For implementation, default parameter value can put as 0x0000 for backward compatibility.. hope thats acceptable and closes Request(1) also.. with regards, pekon
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
