Hi, Please see my responses embedded below..
On Thu, May 3, 2012 at 2:29 PM, Stefan Kristiansson < [email protected]> wrote: > On Thu, May 03, 2012 at 01:10:57PM +0530, Pekon Gupta wrote: > > All, > > > > I think this is nice flexibility to be added, but with some caution.. > > May I ask for some updates here..? > > > > > > Request (1): reset-value of all the bits in this register should come > from > > some config-pins, which are sampled just at next edge of reset > de-assertion > > (similar to what John Eaton requested earlier). > > > > [Reason]: Suppose a exception occurs just after boot before, before > > software could update these register. so flexibility should come with > some > > concrete backup. > > As OR1200 is becoming popular, it may go into number of systems ranging > > from "consumer electronics" to "safety" or "health (medical) critical" > > equipments. Some safety/medical systems have to meet strong guidelines to > > get certifications from international organizations. At times these > > standards test some very corner scenarios, where your system should be > > fail-safe or system-recovery should be deterministic in all conditions. > > Having some loopholes, where Software can go hay-wire may be discouraging > > to use OR1200 in such cases. > > Though i agree, there are lot of other checks, which need to be > > incorporated in system (as a whole), but at-least we should not introduce > > new holes in our system (OR1200). > > > > Do you really think that's necessary to put in the spec? > It seems like an odd requirement to put on implementations: > "The reset value has to be configurable by config pins" > [Pekon]: Yes, it would be good to document it in spec, as it helps to understand few years later why anyone put such logic. (i feel having bit elaborate spec definition usually helps later) you may put it like this .. "default value of this register is latched from xx_yy[m:n] input pin during reset de-assertion". This way you let the user to choose his implementation but make sure that desired flexibility is met. Anyways "flop(registers) cannot have non-constant reset-values". This is because flops(registers) have only CLEAR and PRESET pins. So you need to specify "constants" only as reset-values(0 or 1) in RTL code. You cannot have reset-value driven from any external signal (like xx_yy[m:n] pins here). To meet such requirement, you need to add some logic around the flop, to get desired functionality.. So, "default-value" would be more precise here, instead of "reset-value". Also, RTL implementation for these bits needs to be bit customized to meet above requirement. > The reason I'd like to define the reset value to zero is that > it makes for backwards compability. > If someone really wants to do an implementation that configures > the value in hardware right after reset, that's probably fine. > > [Pekon]: for backward compatibility, you may explicitely ask the OR1200 integrator to tieof "xx_yy[m:n] at boundary of OR1200. This can also be mentioned in IPXACT, if you plan to provide one along with RTL release. I personally would not want users to hack the RTL much, because it becomes difficult to maintain it as separate branch. And then proving the "logic equivalence" (using tools like LEC) with main trunk, becomes difficult. Adding a separate pin at OR1200 boundary, provides flexibility without asking the user to hack the RTL, And maintains "logic-equivalence" at OR1200 block-level. > > > Request (2): these bits should be just once-writable after > Power-On-Reset. > > > > [Reason]: This is critical for some security features, which may > > maliciously try to update this register, and try to insert its own code > in > > between by raising exception. > > Note: Make it mandatory for software to write this register at-least once > > on boot. even with same value as already present. > > > > Would it be enough if 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]: yes i agree, that should be good way also.. This is okay for "security".. But, I don't know how much it is good for "safety", because a software run-away might happen in supervisor mode also.. and if that run-away changes these bits, then whole system is at toss.. because now system would not know where its exception vectors are .. however, we should not complicate things too much for unforeseen future, so just putting this under supervisor mode should be good. > > > Request (3): Also, it would be good, if we can group all such boot-time > > specific registers in some specific memory-map which can be fire-walled. > > > > [Reason]: For security reasons, people might not like top-level > > applications to see where the actual exception-vectors lie in memory-map. > > > > Hey, by adding the modifiable exception base vector alone, > we're already one step closer to hiding where the exception-vectors are ;) > > [Pekon]: yes, I agree.. if you make this R/W in supervisor mode only, then that solves the purpose. (Reads to this register should also be available only in supervisor mode) Thanks Stefan for your inputs.. However, does anyone else in the community see any issues or conflict with these updates ? more feedbacks and refinements are welcomed.. with regards, pekon
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
