On 05/03/2012 10:16 PM, Pekon Gupta wrote:
Hi,
Please see my responses embedded below..
On Thu, May 3, 2012 at 2:29 PM, Stefan Kristiansson
<[email protected] <mailto:[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.
In the implementation specification, I agree, in the arch spec I don't.
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.
Yeah sure, it could even be implemented by sw in on-chip ROM.
Or by passing a parameter, although then it'd only be configurable at synthesis
time.
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.
Again, I'm not opposed to having an implementation like this in or1200,
but I'm still not happy with having it defined like this in the arch spec, since
that means _all_ implementations that implements evba have to do it this way
(think or1ksim for example).
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..
Thanks to you for your input too!
Stefan
_______________________________________________
OpenRISC mailing list
[email protected]
http://lists.openrisc.net/listinfo/openrisc
