This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Component Design

Component Design

Module Detailled Design

Component Documentation

1 - CM109A_ClkCfgAndMon

Clock Configuration and Monitoring RH850

(ClkCfgAndMon)

FDD #CM109A

1. Function In This Document 5

2. Critical Registers 5

3. Sub-functions 6

3.1. NTCs 6

3.2. SAN Linkage 6

3.3. Description 6

3.4. Rationale 6

3.5. Implementation 6

3.6. Reference 8

3.7. Verification Method 12

4. Revision Record & Change Approval 12

Renesas Document References:

Hardware User’s Manual (HWUM) version 1.00 dated July 2015

Safety Application Note (SAN) R01AN2118EJ0120 Rev. 1.20 Release December 1, 2015

Function In This Document

N/A

NTCs

N/A

SAN Linkage

N/A

Description

This function configures and starts the PE’s clock monitor logic. This logic will cause a signal to the ECM if the monitored clocks exceed their low or high limit thresholds over their sample intervals.

Each of four clock monitor circuits compares the number of rising clock edges which occur on two clock signals. In the time required for each “sampling clock” to produce 16 rising edges (after each reference rising edge) the rising edges of the corresponding “monitored clock” are counted and compared to programmed low and high limits for that monitor circuit. A comparison outside the range defined by the limits causes a signal to the ECM.

Per HWUM 31.5.3.2 and 31.5.3.3, each clock monitor channel’s enable bit, when set to one, locks that channel’s low and high limit registers until any reset occurs. Each clock monitor channel’s enable bit can be controlled by writing to the respective control register CLMAnCTL0.

Rationale

The sample and monitor clocks of CLMA1 and CLMA3 are both derived from the same basic oscillator. For this reason, variation in these sources will occur in both sample and monitor clock circuit inputs and the resulting counts will not show the variation that will occur with CLMA0 and CLMA2 where the two oscillator inputs have independent variations. Instead of adding the two tolerances which is appropriate with independent error sources, a fraction of the total tolerance should be used by MCAL with the positively correlated errors of CLMA1 and CLMA3. Unless Renesas describes new sources of frequency error it may be desirable to tighten the tolerances of CLMA1 and CLMA3.

Assumption:

A programmable “option byte” OPBT0 value affects the values used with the Renesas formulae here. The assumption used here are that OPBT0[21:20] is either 0b00 or 0b11. These two values yield identical upper and lower limit values for the clock monitor circuits. Currently CM106A documents the use of OPBT0[21:20] = 0b00.

All four monitor circuits will be initialized and armed since, in addition to the existence of a reasonable frequency pulse stream from the two oscillators, the additional channels each verifies that some distinct frequency divider flip-flops are functioning.

Implementation

The following table lists the values available from different sources which may be used to initialize the clock monitor circuits.

Clock monitorOPBT0 [21:20]monitored clocksampling clock

Renesas formula min hex

(%tol.)

Renesas formula max hex

(%tol.)

Derived Tolerance for MCAL (+/-%)
CLMA0Don’t CareMain OscHS intOsc / 4

73

(-10.16)

8F

(11.72)

(10, -10), (1, -1)
CLMA1Don’t CarePeripheral clk /2Main Osc / 8

9E

(-1.25)

A1

(0.625)

(1, -1) (1, -1)
CLMA200WDTCLKI = 8MhzMain Osc / 16

72

(-10.94)

8D

(10.16)

(10, -10), (1, -1)
CLMA3Don’t CareClk CPUMain Osc / 2

13E

(-0.625)

141

(0.313)

(1, -1) (1, -1)

Note: Renesas also documents a hardware requirement that each clock monitor lower limit be larger than zero and that each upper limit must be greater than or equal to the corresponding lower limit plus three.

The use of “Don’t Care“ in this table means that the value has no impact on the circuit behavior.

The Renesas formulae compute clock monitor limit values assuming that the two clocks of each monitor have independent variation from nominal. While this is completely true for CLMA0 and CLMA2, it is wrong for CLMA1 and CLMA3 which use the same oscillator as the source of both inputs. Those channels’ limits are likely wider than they need to be but the digital hardware design limits on how close the two limit values of each monitor can be to each other prevents those tolerances from being very much tighter.

Renesas’ MCAL provides an input tolerance for each of the clocks involved with each monitor circuit. MCAL accepts input tolerance quantized to whole percentage so the minimum non-zero tolerance of one percent is used for CLMA1 and CLMA3 inputs. The minimum crystal oscillator tolerance (one percent) is used with the ten percent tolerance of the “high-frequency” oscillator for CLMA0 and CLMA2.

A snapshot of the spreadsheet used to evaluate clock monitor limit values has been included in the “reference data” section below.

MCAL Input:

In the McuGeneralConfiguration container

McuClm0Operation true

McuClm0MonitoringClockAccuracy 1

McuClm0SamplingClockAccuracy 10

McuClm1Operation true

McuClm1MonitoringClockAccuracy 1

McuClm1SamplingClockAccuracy 1

McuClm2Operation true

McuClm2MonitoringClockAccuracy 1

McuClm2SamplingClockAccuracy 10

McuClm3Operation true

McuClm3MonitoringClockAccuracy 1

McuClm3SamplingClockAccuracy 1

Reference

Verification Method

N/A

Revision Record & Change Approval

RevDateChange Control #DrwChange Description
01.00.0003/02/20162475ECInitial release

2 - CM109A Review Checklist

Nexteer_Template_V1.0

Overview

Peer Review Instructions
Technical Review Checklist
Template Change Log


Sheet 1: Peer Review Instructions

Instructions for Functional Design Package Peer Review




PRE-MEETING


Function OwnerConfirm that requirements are reviewed and approved PRIOR to the FDP peer review

Function OwnerStart with latest version of the template for any "first reviews" - Continue to use existing temmplate for re-reviews

Function OwnerProvide the functional design package (changed documents) to the invited attendees 1-2 working days in advance of review

Function OwnerNotify the assigned peer reviewer and make sure they are prepared to do their function in the meeting

Function OwnerIdentify necessary attendance and invite to meeting

Function OwnerComplete the "Author" column information for sections 1 through 3 prior to the review

Function OwnerComplete the attendance invitation list in section 5

Function OwnerFor Re-reviews only: Complete the column "remarks by author" to identify actions taken to address items found in earlier reviews.



DURING MEETING


Function OwnerPresent document changes to the review team

Peer ReviewerCapture attendance of the review

Peer ReviewerCapture actions and issues in section 4. Identify issue summary, Document type, Reference (Requirement ID, section number, etc), Defect Type and indicate status as "OPEN"



POST MEETING


Function OwnerFollow up on all "open" items. Update "Summary of Resolution" to indicate what was done or decided.

Function OwnerSchedule follow up review OR review open items with peer reviewer and obtain agreement to close

Peer ReviewerClose change request in system and confirm all associated tasks are complete. Upload peer review checklist (this document) with any FDP updates

Sheet 2: Technical Review Checklist

Technical Review Checklist - Template Version 01.00.09







Product NameElectric Power SteeringElectrical Arch.4Review ScopeDefect TypeNumbers




YesClosedFR
Function NameCM109A_ClkCfgAndMonVersion
<Discuss scope - which documents of an FDP are being specifically reviewed.>Requirement0




NoRejectedFDD
AuthorEd Cory

Interface1




NAOpenModel


EffortDesign3






FMEA


Review Effort(Hrs.)1.00Standards4






*.m File


Corr+Verf effort(Hrs.)2.00Documentation4






Cal Process


Total Effort (Hrs.)3.00Others5













Total17







Checklist No.Description of CheckAuthor: This column is for Self review. Author shall fill Yes/No/NA against each point in checklist. AuthorAuthor: This column is for reviewer. Reviewer shall fill Yes/No/NA against each point in checklist. ReviewerAuthor: Detailed Description of the finding shall be provided by the reviewer. Description of finding by reviewerAuthor: Defect type to be selected. Defect TypeAuthor: What action is taken to fix the comment & other remarks need to be filled by author. Remarks By AuthorAuthor: Data in this column shall be filled by reviewer after checking whether the rework is completed. Status







1Section 1: TECHNICAL CHECK













1.1Confirm that all signal inputs into the FDP (Functional Design Package) are contained within and exactly named as the "Available_Nexteer_Signals.m" states.













1.2Confirm any removed signal inputs from the design have been removed from the "Available_Nexteer_Signals.m" file.













1.3Confirm all signals and parameters (outputs, calibrations, constants, non-volatile memory) used in the *.m file and the design conform to the AutoSAR naming convention documentation.













1.4Confirm *.m file has been provided to the "Available_Signal_Names" Author.













1.5Confirm Electrical Systems interface map is updated to reflect the FDP (signal IO)













1.6Confirm that Static Register evaluation has been completed and updated for any register data that is written to.













1.7Have calibration default values been reviewed for correctness?













2Section 2: Safety CHECKAuthor: This column is for Self review. Author shall fill Yes/No/NA against each point in checklist. AuthorAuthor: This column is for reviewer. Reviewer shall fill Yes/No/NA against each point in checklist. ReviewerAuthor: Detailed Description of the finding shall be provided by the reviewer. Description of finding by reviewerAuthor: Defect type to be selected. Defect TypeAuthor: What action is taken to fix the comment & other remarks need to be filled by author. Remarks By AuthorAuthor: Data in this column shall be filled by reviewer after checking whether the rework is completed. Status







2.1Confirm that the functional DFMEA is up to date based on the design in the current package.













2.2Confirm that Safety requirements (ASIL A - D) are referenced in the design documents.













3Section 3: Lessons LearnedAuthor: This column is for Self review. Author shall fill Yes/No/NA against each point in checklist. AuthorAuthor: This column is for reviewer. Reviewer shall fill Yes/No/NA against each point in checklist. ReviewerAuthor: Detailed Description of the finding shall be provided by the reviewer. Description of finding by reviewerAuthor: Defect type to be selected. Defect TypeAuthor: What action is taken to fix the comment & other remarks need to be filled by author. Remarks By AuthorAuthor: Data in this column shall be filled by reviewer after checking whether the rework is completed. Status







3.01Have functions depending upon system state been reviewed for need to be executed at the 2ms rate to avoid system lag issues?













3.02Have all diagnostics (NTCs) been confirmed to show logic to invoke a diagnostic "PASS" for control of the status byte at the customer level.













3.03Has the requirements traceability steps used the RMI steps as defined in the FDD authoring spec to generate the traceability report?













3.04Has the requirements traceability report been verified to only contain ONLY requirements from the FR.













3.05Confirm that all PIM that does NOT have an initialization value of zero is initialized in an INIT function.













3.06Confirm if NVM is used, the NVM is defined in structures













3.07If the function uses NVM, confirm that the m file uses the SetBlockStatus to indicate a write at powerdown













3.08Confirm NTCs are not set within an IRQ (not related to the typical periodic OS)













3.09Confirm NTCs are not set or read in a periodic rate faster than 2 ms (ex. Motor Control Loop)













3.10Constants check: Do all constants have the correct scope (local, global) and are they defined in the correct location (this FDD, ES/SF/AR999)?













3.11Confirm all calibrations are required (ie they cannot be constants)













4Section 4: Issues / Actions IdentifiedDocumentReferenceSummary of resolutionAuthor: Defect type to be selected. Defect TypeAuthor: What action is taken to fix the comment & other remarks need to be filled by author. Remarks By AuthorAuthor: Data in this column shall be filled by reviewer after checking whether the rework is completed. Status







4.1Rename file - should be named with module short nameFDD
rename file using short nameStandards









4.2Remove all of section 3 in FDD. Once static register verification strategy is better defined, we will have to come back into this FDD and update accordingly.FDD
removed high and low limits from section 3, left CTL regs to comply with SAN's "The
control register shall be also read back once after configuration to ensure the CLM is enable."
Standards









4.3Remove setAndVerify function/logic and replace with just standard writes.FDD
Removed setAndVerify function/logic and replaced with just standard writes.Design









4.4Remove setProtectedRegister8andVerify and replace with direct call to WrProtdReg functionFDD
Removed setProtectedRegister8andVerify and replaced with direct calls to WrProtdReg functionDesign









4.5If you call out in rationale sections in another document, make sure to call out the version of the document somehow being referencedFDD
added references to HWUM & SAN, versions and datesDocumentation









4.6Re-review as a team all Cautions listed in FDDFDD
re-reviewed with entire team 2/3/2016Others









4.7Maybe embed spreadsheet with logic used for determining tolerances on clock monitoring. Review this with the larger team for agreement (including Renesas)FDD
embedded spreadsheet.Documentation









4.8See about updating and running latest data dictionary creation and verification tools.*.m File
set up latest tools, verified DDStandards









4.9Need to add something about Init2 into your FDD documentFDD
added Init2 into FDD fn listInterface









4.10Talk about MCAL MCU driver clock monitor function and redundancy with this functionFDD
MCAL MCU driver clock monitor function ??? Mentioned whole percentage monitoring, added paragraph about the lack of redundancy in the clock monitor system.Others









4.11Fix NTC State Info Bits (not aligning with master NTC list)FDD
matched to master NTC listStandards









4.12Change to tightest defensible tolerances for MCAL, use Renesas's Formula values for non-MCALFDD
changed to tightest defensible tolerances for MCAL, use Renesas's Formula values for non-MCAL, embedded updated spreadsheet into FDDDesign









4.13remove cautions except for Option byte, change option byte reference to statement of an assumptionFDD
removed cautions, added option byte assumptionDocumentation









4.14Delete high level descriptionFDD
deleted it.Others









4.15Check with SAN 1.20 to update SAN requirementFDD
verified that there was no change in SAN 1.20, updated FDD entry to indicate that the listed reqt was from 1.20Documentation









4.16Remove the implementation details because we are using the MCALFDD
removed them.Others









4.17remove the comments about MCAL MCU driver clock monitor function and redundancyFDD
removed them.Others









4.18














4.19














4.20














4.21














4.22














4.23














4.24














4.25














5Section 5: APPROVALS













RoleFirst ReviewDateAttendanceApproval?










Function Owner*Ed Cory3/2/2016YesYes










Peer Reviewer*Samanth KumaraswamyYes










EPDT Engineer<Name - if invited>











ES Engineer<Name - if invited>











Software Lead<Name - if invited>











Hardware Lead<Name - if invited>











Test Lead<Name - if invited>











Safety Lead<Name - if invited>











RoleSecond Review (if required)DateAttendanceApproval?










Function Owner*<Owner Name>













Peer Reviewer*<Name>











EPDT Engineer<Name - if invited>











ES Engineer<Name - if invited>











Software Lead<Name - if invited>











Hardware Lead<Name - if invited>











Test Lead<Name - if invited>











Safety Lead<Name - if invited>











RoleThird Review (if required)DateAttendanceApproval?










Function Owner*<Owner Name>













Peer Reviewer*<Name>











EPDT Engineer<Name - if invited>











ES Engineer<Name - if invited>











Software Lead<Name - if invited>











Hardware Lead<Name - if invited>











Test Lead<Name - if invited>











Safety Lead<Name - if invited>











RoleFourth Review (if required)DateAttendanceApproval?










Function Owner*<Owner Name>













Peer Reviewer*<Name>











EPDT Engineer<Name - if invited>











ES Engineer<Name - if invited>











Software Lead<Name - if invited>











Hardware Lead<Name - if invited>











Test Lead<Name - if invited>











Safety Lead<Name - if invited>











RoleAdd more if necessaryDateAttendanceApproval?










































P.S.:Yes indicates adherence














No indicates non-adherence, reviewer shall provide suitable comments at the end of this document for each point.














NA indicates not applicable














Sheet 3: Template Change Log

RevChangeAuthor
01.00.05Added lesson learned #3.5MDK
01.00.06Added lesson learned #3.6, 3.7 - Structure and writing of NVM in mfiles and models.MDK
01.00.07Clarified 3.6 and 3.7
Added lessons learned for NTCs not being set in IRQs or periodics faster than 2ms/
MDK
01.00.08Added section 1.6 to look for critical static register analysisMDK
01.00.09Added two checks - default cals and are all cals really required to be a calibrationMDK