Birds Project Birds PLD by Ron Burkey Document BirdsPLD-PHAC, v1.00 07/09/2006 Document TBD-HDP by TBD, Revision ?.??, ??/??/?? Document TBD-HVVP by TBD, Revision ?.??, ??/??/?? Document TBD-HCMP by TBD, Revision ?.??, ??/??/?? Document TBD-HRD by TBD, Revision ?.??, ??/??/?? Document TBD-HDRD by TBD, Revision ?.??, ??/??/?? Document TBD-HTPR by TBD, Revision ?.??, ??/??/?? Document TBD-HATD by TBD, Revision ?.??, ??/??/?? Document TBD-HAS by TBD, Revision ?.??, ??/??/?? TBD TBD

TBD TBD Except for the "Bird Man" graphic below, this data is placed in the public domain by its author (Ron Burkey). It may be used or modified for any purpose whatever. This data is provided as-is, without any expressed or implied warrantee. The "Bird Man" graphic is copyrighted by Lynn Rothan, and cannot be used without permission.

SignatureBlock.jpg TBD <Command>Revision 0.00-0.99</Command> Uncontrolled drafts. <Command>Revision 0.00-0.99</Command> Uncontrolled drafts. <Command>Revision 0.00-0.99</Command> Uncontrolled drafts. <Command>Revision 0.00-0.99</Command> Uncontrolled drafts. <Command>Revision 0.00-0.99</Command> Uncontrolled drafts. <Command>Revision 0.00-0.99</Command> Uncontrolled drafts. <Command>Revision 0.00-0.99</Command> Uncontrolled drafts. <Command>Revision 0.00-0.99</Command> Uncontrolled drafts. <Command>Revision 0.00-0.99</Command> Uncontrolled drafts. This is a standard "Plan for Hardware Aspects of Certification" document, corresponding to the guidelines in RTCA DO-254. Among other things, it provides a system overview, a hardware overview, a description of the certification basis and justification, a description of the hardware development life cycle and data items, and a certification schedule. This is a standard "Hardware Design Plan" document, corresponding to the guidelines in RTCA DO-254. It defines the hardware design life cycle, provides a hardware product description, describes the hardware design methods, describes the hardware design environment, and itemizes the hardware item data to be produced. This is a combination of the standard "Hardware Validation Plan" and "Hardware Verification Plan" documents, corresponding to the guidelines in RTCA DO-254. It describes the validation methods, identifies the validation data, identifies and describes the validation environment used in the hardware-development effort, describes the verification procedures and verification data, describes the means to assure verification independence (where applicable), identifies and describes the verification environment, and identifies the organizational responsibilities.. This is a standard "Hardware Configuration Management Plan" document, corresponding to the guidelines in RTCA DO-254. It describes the hardware configuration management methods, describes the methods and procedures used to establish hardware baselines, describes the methods and procedures used for problem reporting and resolution, describes the methods, procedures and processes for change control, describes the procedures for storage and retrieval of life-cycle data, describes the procedures and method for controlling tools, and describes the tools and resources used for configuration management. This is a standard "Hardware Requirements Data" document, corresponding to the guidelines in RTCA DO-254. It includes system requirements allocated to hardware, identification of standards, hardware functional and performance requirements (including derived requirements), hardware reliability and quality requirements, hardware maintenance and repaire requirements, hardware manufacturability and assembly requirements, hardware testability requirements, hardware storage and handling requirements, and installation requirements. This is a standard "Hardware Design Representation Data" document, corresponding to the guidelines in RTCA DO-254. It provides conceptual design data and calls out detailed design data such as schematic-capture drawings or VHDL source code. Conceptual design data include high-level description of the hardware, the mechanical structures associated with the hardware where applicable, description of architectural and partitioning features (particularly where significant from an airworthiness point of view), top-level hardware item functional description, hardware item functional architecture, and preliminary hardware safety assessment data. Detailed design data includes a top-level drawing, assembly drawings, installation control drawings, and hardware/software interface data. This is "Hardware Test Procedures and Results" document, corresponds to the guidelines in RTCA DO-254, sections 10.4.4 ("Test Procedures") and 10.4.5 ("Test Results"). It is based on the notion that this document is printed out and used as a test form on which technicians or engineers record the results of the test procedures defined herein, and then adds the completed test form to the other Validation and Verification Data. This is a standard "Hardware Acceptance Test Criteria" document, corresponding to the guidelines in RTCA DO-254. It describes key attributes to be tested, pass/fail criteria for each key attribute, any test constraints, substantiation of the key attributes and pass/fail criteria, coverage of design aspects necessary to meet the safetey requirements, and assessment data showing proper implementation of the test criteria. This is a standard "Hardware Accomplishment Summary" document, corresponding to the guidelines in RTCA DO-254. It includes overviews of the system and its hardware, certification considerations, hardware life-cycle information and data, previously-developed hardware, differences from the PHAC, hardware identification, change history, hardware status, and a compliance statement.

<docbook><informaltable> <tgroup cols=3> <colspec colwidth="2*"> <colspec colwidth="6*"> <colspec colwidth="3*"> <tbody> <row><entry>BirdsPLD-PHAC</entry><entry>Plan for Hardware Aspects of Certification</entry><entry>DO-254 10.1.1</entry></row> <row><entry>BirdsPLD-HDP</entry><entry>Hardware Design Plan</entry><entry>DO-254 10.1.2</entry></row> <row><entry>BirdsPLD-HVVP</entry><entry>Hardware Validation and Verification Plan</entry><entry>DO-254 10.1.3 and 10.1.4</entry></row> <row><entry>BirdsPLD-HCMP</entry><entry>Hardware Configuration Management Plan</entry><entry>DO-254 10.1.5</entry></row> <row><entry>-</entry><entry>Hardware Process Assurance Plan, not needed at assurance level C</entry><entry>DO-254 10.1.6</entry></row> <row><entry>-</entry><entry>Requirements Standards, not needed at assurance level C</entry><entry>DO-254 10.2.1</entry></row> <row><entry>-</entry><entry>Hardware Design Standards, not needed at assurance level C</entry><entry>DO-254 10.2.2</entry></row> <row><entry>-</entry><entry>Validation and Verification Standards, not needed at assurance level C</entry><entry>DO-254 10.2.3</entry></row> <row><entry>-</entry><entry>Hardware Archive Standards, not needed at assurance level C</entry><entry>DO-254 10.2.4</entry></row> <row><entry>BirdsPLD-HRD</entry><entry>Hardware Requirements Data</entry><entry>DO-254 10.3.1</entry></row> <row><entry>BirdsPLD-HDRD</entry><entry>Hardware Design Representation Data</entry><entry>DO-254 10.3.2</entry></row> <row><entry>BirdsPLD-HTPR</entry><entry>Hardware Test Processes and Results</entry><entry>DO-254 10.4.1, 10.4.4, and 10.4.5</entry></row> <row><entry>-</entry><entry>Review Checklists</entry><entry>DO-254 10.4.2 and 10.4.3</entry></row> <row><entry>BirdsPLD-VVD</entry><entry>Validation and Verification Data (collected filled-out HTPR and Review Checklists)</entry><entry>DO-254 10.4</entry></row> <row><entry>BirdsPLD-HATC</entry><entry>Hardware Acceptance Test Criteria</entry><entry>DO-254 10.5</entry></row> <row><entry>-</entry><entry>Problem Reports</entry><entry>DO-254 10.6</entry></row> <row><entry>-</entry><entry>Hardware Configuration Management Records, combined with Validation and Verification Data (BirdsPLD-VVD)</entry><entry>DO-254 10.7</entry></row> <row><entry>-</entry><entry>Hardware Process Assurance Records, combined with Validation and Verification Data (BirdsPLD-VVD)</entry><entry>DO-254 10.8</entry></row> <row><entry>BirdsPLD-HAS</entry><entry>Hardware Accomplishment Summary</entry><entry>DO-254 10.9</entry></row> </tbody> </tgroup></informaltable></docbook>

The BirdsPLD is a derived requirement of the BirdsCWS project, and therefore does not trace directly to the system requirements. The BirdsCWS system requirements (BirdsCWS-SCD) contains a system requirement for hardware backwards and forwards compatibility as a means of easing software reusability. The derived requirement for the BirdsPLD is the means of providing that hardware compatibility. In the Hardware Requirements Data (HRD) document, the hardware requirements are itemized in individual document sections. Each hardware requirement is be associated one or more design items in the Hardware Design Representation Data (HDRD) document, and the design item in the HDRD specifically calls out the associated detailed design data. At the top of each such hardware-requirement section in the HRD, the associated design data from the HDRD document are referenced. Conversely, in the HDRD document, the design data are itemized and each design datum references the associated hardware requirement in the HRD document.

TBD

The Hardware Requirements Data (HRD) document itemizes the hardware requirements. The Hardware Design Representation Data (HDRD) document itemizes the design elements, including the detailed design data. The Hardware Test Procedures and Results (HTPR) document itemizes all test cases. Each hardware requirement can be associated with one or more test cases, while each design element can also be associated with one or more test cases. At the top of each section of the HRD devoted to a hardware requirement, there is a traceability reference to the section of the HTPR containing the associated test case(s). Conversely, the test cases associated with a hardware requirement are grouped together in the HTPR, and at the top of the section containing these test cases, there is a traceability reference to the associated section in the HRD. Similarly, at the top of each section of the HDRD devoted to a design element, there is a traceability reference to the section(s) of the HTPR containing the associated test case(s). Conversely, in the HTPR, at the top of each section devoted to a test case for a design element, there is a traceability reference to the associated section in the HDRD. TBD

This document organizes data in a manner consistent with DO-254 section 10.1.1, including the ordering of data and the section headings. In practice, the match is so obvious that there would be no benefit in having explicit section-by-section traceability to DO-254.

To the extent practical, this document organizes data in a manner consistent with DO-254 section 10.1.2, including the ordering of data and the section headings. However, because of the limitations of the documentation system used, some rearrangements of data have been made, as follows: <docbook><itemizedlist> <listitem><para>The hardware product description section (DO-254 10.1.2 #2) precedes rather than follows the hardware design life cycle section (DO-254 10.1.2 #1), and is titled "Hardware Overview".</para></listitem> <listitem><para>The hardware design methods section (DO-254 10.1.2 #3) appears as a sub-topic of the hardware design life cycle (DO-254 10.1.2 #1), rather than following the life-cycle description. </para></listitem> <listitem><para>The hardware item data section (DO-254 10.1.2 #5) appears within the hardware design life cycle section (DO-254 10.1.2 #1), rather than following it.</para></listitem> </itemizedlist></docbook>

This document organizes data in a manner consistent with DO-254 section 10.1.3 and 10.1.4, including the ordering of data and the section headings. In practice, the match is so obvious that there would be no benefit in having explicit section-by-section traceability to DO-254.

This document organizes data in a manner consistent with DO-254 section 10.1.5, including the ordering of data and the section headings. In practice, the match is so obvious that there would be no benefit in having explicit section-by-section traceability to DO-254.

This document organizes data in a manner consistent with DO-254 section 10.3.1, including the ordering of data and the section headings. In practice, the match is so obvious that there would be no benefit in having explicit section-by-section traceability to DO-254.

This document organizes data in a manner consistent with DO-254 section 10.3.2, including the ordering of data and the section headings. In practice, the match is so obvious that there would be no benefit in having explicit section-by-section traceability to DO-254.

This document organizes data in a manner consistent with DO-254 section 10.4.1, 10.4.4, and 10.4.5, including the ordering of data and the section headings. In practice, the match is so obvious that there would be no benefit in having explicit section-by-section traceability to DO-254.

This document organizes data in a manner consistent with DO-254 section 10.5, including the ordering of data and the section headings. In practice, the match is so obvious that there would be no benefit in having explicit section-by-section traceability to DO-254.

This document organizes data in a manner consistent with DO-254 section 10.9, including the ordering of data and the section headings. In practice, the match is so obvious that there would be no benefit in having explicit section-by-section traceability to DO-254.

<docbook><informaltable> <tgroup cols=2> <colspec colwidth="1*"> <colspec colwidth="3*"> <tbody> <row><entry>Identification of hardware tested, by p/n and s/n</entry><entry></entry></row> <row><entry>Hardware version tested</entry><entry></entry></row> <row><entry>Name and version of embedded software</entry><entry></entry></row> <row><entry>Test summary</entry><entry>PASS FAIL (circle one)</entry></row> <row><entry>Test technician(s)</entry><entry></entry></row> <row><entry>Test witnesses(s)</entry><entry></entry></row> <row><entry>Test dates</entry><entry></entry></row> <row><entry>List of attachments</entry><entry></entry></row> </tbody> </tgroup> </informaltable></docbook> The system being developed is an crew-warning or annunciator system, in which activation of various electrical inputs causes annuciation of aural warnings. The system, referred to as the Birds Crew Warning System ("BirdsCWS") is CPU based. However, this documentation deals only with the Programmable Logic Device (PLD) sub-system of the annunciator. The PLD sub-system, referred to as the "BirdsPLD", is present as a derived requirement. The BirdsCWS system requirements call for the use of a hardware architecture which is reusable across differing hardware generations or even to projects other than the BirdsCWS, in order to increase reusability of software libraries and documentation. Thus, as a derived requirement, the BirdsPLD is provided to help maintain constancy of hardware/software interfaces. Considered as a system of itself, the BirdsPLD provides the following capabilities: <docbook> <orderedlist numeration="arabic" continuation="restarts" inheritnum="ignore"> <listitem><para>It interfaces to the CPU via the CPU's data/address bus.</para></listitem> <listitem><para>It provides an 8-bit latched parallel-data output port.</para></listitem> <listitem><para>It provides an 8-bit input parallel-data port.</para></listitem> <listitem><para>It provides a watchdog timer which can be disabled via a signal intended to be controlled by a hardware jumper.</para></listitem> <listitem><para>It provides decoding for some peripheral devices.</para></listitem> <listitem><para>It provides for flexible routing of serial data on the basis of electrical signals intended to be controlled via DIP switches.</para></listitem> </orderedlist></docbook> Although the BirdsCWS CPU may itself have some of these facilities embedded within it, using the BirdsPLD rather than the embedded capabilities of the CPU allows much more flexibility in choice of CPU without software change. This is because it is much easier to replace the CPU with one having a 100% compatible instruction set rather than one with 100% compatible peripheral devices. There are no identifiable failure conditions of the BirdsPLD sub-system. <docbook><informalfigure><mediaobject> <imageobject><imagedata fileref="BirdsCWS-block-diagram" align=center></imageobject> <caption><para>BirdsCWS Block Diagram</para></caption> </mediaobject></informalfigure></docbook> The BirdsPLD is a derived requirement, implemented entirely in hardware. There are no safety requirements associated with the BirdsPLD. The BirdsCWS (for which the BirdsPLD is a derived requirement) system requirements are described in Birds Project document BirdsCWS-SCD. There are no differences between the System Overview as described in the PHAC and as described in the HAS. TBD TBD Registers internal to the BirdsPLD interface to the CPU via the CPU's address/data/control bus. Each of these internal registers is 8 bits in width. A single chip-select signal from the CPU is used, and the BirdsPLD internally decodes 4 address signals and a read/write control line to select the specific registers and the data direction. TBD

<trace>Implementation TBD</trace> TBD TBD TBD TBD TBD TBD

TBD TBD TBD TBD TBD The BirdsPLD has a single internal 8-bit register (see "Interface to CPU" above) which, upon being written to by the CPU, latches the data and delivers it to 8 discrete output pins of the BirdsPLD. The register may also be read by the CPU, in which case the contents of the latch are returned. TBD