Muutke küpsiste eelistusi

E-raamat: Hardware/Firmware Interface Design: Best Practices for Improving Embedded Systems Development

4.08/5 (23 hinnangut Goodreads-ist)
(N/A)
  • Formaat: PDF+DRM
  • Ilmumisaeg: 31-Oct-2009
  • Kirjastus: Newnes (an imprint of Butterworth-Heinemann Ltd )
  • Keel: eng
  • ISBN-13: 9780080880198
Teised raamatud teemal:
  • Formaat - PDF+DRM
  • Hind: 58,03 €*
  • * hind on lõplik, st. muud allahindlused enam ei rakendu
  • Lisa ostukorvi
  • Lisa soovinimekirja
  • See e-raamat on mõeldud ainult isiklikuks kasutamiseks. E-raamatuid ei saa tagastada.
Hardware/Firmware Interface Design: Best Practices for Improving Embedded Systems DevelopmentSuurem pilt
  • Formaat: PDF+DRM
  • Ilmumisaeg: 31-Oct-2009
  • Kirjastus: Newnes (an imprint of Butterworth-Heinemann Ltd )
  • Keel: eng
  • ISBN-13: 9780080880198
Teised raamatud teemal:

DRM piirangud

  • Kopeerimine (copy/paste):

    ei ole lubatud

  • Printimine:

    ei ole lubatud

  • Kasutamine:

    Digitaalõiguste kaitse (DRM)
    Kirjastus on väljastanud selle e-raamatu krüpteeritud kujul, mis tähendab, et selle lugemiseks peate installeerima spetsiaalse tarkvara. Samuti peate looma endale  Adobe ID Rohkem infot siin. E-raamatut saab lugeda 1 kasutaja ning alla laadida kuni 6'de seadmesse (kõik autoriseeritud sama Adobe ID-ga).

    Vajalik tarkvara
    Mobiilsetes seadmetes (telefon või tahvelarvuti) lugemiseks peate installeerima selle tasuta rakenduse: PocketBook Reader (iOS / Android)

    PC või Mac seadmes lugemiseks peate installima Adobe Digital Editionsi (Seeon tasuta rakendus spetsiaalselt e-raamatute lugemiseks. Seda ei tohi segamini ajada Adober Reader'iga, mis tõenäoliselt on juba teie arvutisse installeeritud )

    Seda e-raamatut ei saa lugeda Amazon Kindle's. 

Why care about hardware/firmware interaction? These interfaces are critical, a solid hardware design married with adaptive firmware can access all the capabilities of an application and overcome limitations caused by poor communication. For the first time, a book has come along that will help hardware engineers and firmware engineers work together to mitigate or eliminate problems that occur when hardware and firmware are not optimally compatible. Solving these issues will save time and money, getting products to market sooner to create more revenue.

The principles and best practices presented in this book will prove to be a valuable resource for both hardware and firmware engineers. Topics include register layout, interrupts, timing and performance, aborts, and errors. Real world cases studies will help to solidify the principles and best practicies with an aim towards cleaner designs, shorter schedules, and better implementation!
  • Reduce product development delays with the best practices in this book
  • Concepts apply to ASICs, ASSPs, SoCs, and FPGAs
  • Real-world examples and case studies highlight the good and bad of design processes

Arvustused

"I did not have to read too far into this book to realize that the author has extensive experience with not only microcontroller programming but also the management of engineering projects involving hardware and firmware. The format of the book is characterized by numerous boxed text inserts and copious bullet items. However, the content is not fluff; the book is loaded with information, some significant fraction of which can be found only in industry among those with development experience. This author has it." --Dennis L Feucht, www.en-genius.net"The book is loaded with information, some significant fraction of which can be found only among those with development experience. This author has it. This is a good book for anyone who is involved in hardware-firmware development and who knows just enough to want to better understand how to organize and design it all." --EN-Genius Network

Muu info

Hardware and firmware are at the core of electronic products; this book shows engineers how to optimize performance through best practices!
Preface x
Introduction
1(18)
What Is the Hardware/Firmware Interface?
2(5)
What Are Hardware, Chips, and Blocks?
2(4)
What Are Firmware and Device Drivers?
6(1)
What Is a Best Practice?
7(3)
What Is a Principle?
9(1)
Benefits of Principles and Practices
10(1)
``First Time Right'' Also Means
10(3)
Easier to Program
11(1)
Easier to Debug
11(1)
Easier to Work around Defects
12(1)
Target Audience
13(1)
Hardware Engineers
13(1)
Firmware Engineers
13(1)
This Book in a University Setting
14(1)
Project Life Cycle
14(1)
Case Study
15(2)
Monochrome Video Block in the Unity ASIC
15(2)
A Case Study of a Good Example?
17(1)
Summary
17(1)
References
18(1)
Principles
19(12)
Seven Principles of Hardware/Firmware Interface Design
19(11)
Collaborate on the Design
20(1)
Set and Adhere to Standards
21(2)
Balance the Load
23(2)
Design for Compatibility
25(1)
Anticipate the Impacts
26(1)
Design for Contingencies
27(2)
Plan Ahead
29(1)
Summary
30(1)
Collaboration
31(20)
First Steps
31(4)
Roles
31(3)
Kick-off Activities
34(1)
Formal Collaboration
35(9)
Regular Meetings
35(2)
Initial Firmware Support
37(1)
Co-Development Techniques
38(2)
End-Game Hardware Support
40(1)
Documentation
41(3)
Informal Collaboration
44(4)
Formal Organizational Structure
44(1)
Hardware Engineers' Initiative
45(1)
Firmware Engineers' Initiative
46(1)
Collaborative Problem Solving
47(1)
Summary
48(1)
Supporting Principles
49(1)
References
49(2)
Planning
51(22)
Industry Standards
51(5)
Existing Standards
52(1)
Implementing the Standard
53(2)
Derivations or New Creations
55(1)
Common Version
56(2)
Compatibility
58(3)
Range of Backward and Forward Compatibility
59(1)
Combinations of Old vs. New
60(1)
Defects
61(5)
Document Defects
61(2)
Fix Defects
63(2)
Test Plan to Look for Defects
65(1)
Analysis
66(4)
Shared Pins
66(1)
Buffer Management
67(1)
Hardware/Firmware Interactions
67(2)
Analyzing Third-Party IP
69(1)
Postmortem
70(1)
Summary
71(2)
Supporting Principles
72(1)
Documentation
73(50)
Types
74(5)
Level and Types of Documentation
74(1)
Chip-Level vs. Block-Level Documentation
75(2)
Supported vs. Unsupported Documentation
77(2)
Document Management
79(4)
Document Standards
79(1)
When to Write
80(1)
Accuracy
81(2)
Reviews
83(4)
When to Review
83(1)
Tracking Documentation Changes
84(1)
Firmware Engineers' Responsibilities Regarding Reviews
85(2)
Content
87(8)
General Content
87(1)
Sample Document Template
88(1)
History
89(2)
Features and Assumptions
91(1)
Reference and Tutorial
92(2)
Glossary and Errata
94(1)
Registers
95(8)
Document Registers
95(1)
Register Design Tools
96(4)
Table of Registers
100(1)
Register Details and Description
101(2)
Bits
103(5)
Register Map Format
103(1)
Bit Positions, Types, and Defaults
104(2)
Bit Descriptions
106(1)
Abort Impact
106(1)
Test and Debug Bits
107(1)
Interrupts
108(3)
Edge- vs. Level-Triggered
108(1)
Enabling and Acknowledging Interrupts
109(1)
Interrupts Not Quite Done
110(1)
Interrupts Repeating without Intervention
110(1)
Time
111(3)
Ranges of Time
111(2)
Unit of Time
113(1)
Errors
114(5)
Two Types of Errors
115(1)
Copious Information about the Errors
116(1)
State of the Block after an Error
117(1)
Firmware Steps to Recover
118(1)
Information
119(2)
Illegal Configuration
119(1)
State Machines
119(1)
How to Abort
120(1)
Summary
121(2)
Supporting Principles
122(1)
Superblock
123(26)
Benefits of a Superblock
123(8)
The Block's Entourage
124(1)
Reasons for Having Unused Logic
124(5)
Reasons against Having Unused Logic
129(2)
Consolidation
131(6)
Make a Superblock
131(2)
Make a Supermodule
133(1)
Evolutionary Design
133(2)
Add Future Features
135(2)
Superblock Version Number
137(1)
I/O Signals
137(2)
Parameterization
139(7)
Reducing the Silicon Space
139(1)
Minimizing Parameterization Risks
140(2)
Parameterization Information for Firmware
142(3)
Optional vs. Fixed Registers and Bits
145(1)
Summary
146(1)
Supporting Principles
147(1)
Reference
147(2)
Design
149(22)
Event Notification
149(8)
No Indication
150(1)
Timed Delay
151(2)
Status Bit
153(2)
Interrupts
155(2)
Performance
157(4)
Increasing the Buffer
158(1)
Working Ahead
159(1)
Tuning
160(1)
Margins
161(1)
Power-On
161(3)
Power-On Interaction
161(2)
Power-On State of I/O Lines
163(1)
Block-Level Power Control
163(1)
Communication and Control
164(5)
Error Information
164(1)
DMA Features
164(2)
Sharing I/O Pins
166(1)
Hiding Implementation Details
167(2)
Summary
169(2)
Supporting Principles
170(1)
Registers
171(52)
Addressing
172(11)
Processor Access
172(3)
Chip Base Addresses
175(1)
Block Offset and Base Addresses
176(2)
Register Offset Addresses
178(1)
Sub-Blocks
179(1)
Bursting
179(1)
Unused Address Locations
180(1)
Changes in the Next Chip
181(2)
Bit Assignment
183(16)
Assigning Bit Positions
183(2)
Multi-Bit Fields
185(2)
Multi-Register Fields
187(1)
Unused Bit Positions
188(1)
Changes in the Next Revision
189(3)
Bit Types
192(3)
Bit Types in Registers
195(2)
Grouping by Operational Mode
197(1)
Multiple Instantiations of a Block
198(1)
Data Types
199(8)
Integers
200(1)
Real Numbers
201(4)
Pointers
205(2)
Constants
207(1)
Hardware Identification
207(3)
Chip ID and Version
208(1)
Block ID and Version
209(1)
Communication and Control
210(11)
Necessary Information
210(1)
Queuing Tasks in the Block
211(5)
Coherent Register Contents
216(1)
Atomic Register Access
217(4)
Summary
221(2)
Supporting Principles
222(1)
Interrupts
223(40)
Design
224(12)
An Interrupt Supermodule
224(2)
Hierarchical Interrupt Structure
226(2)
Interrupt Sharing
228(2)
Source Signal Integrity
230(1)
Types of Interrupt Triggers
231(5)
Pending Register
236(4)
Acknowledging an Interrupt
236(3)
Order of Interrupt Positions
239(1)
Enable Register
240(3)
A 1 Enables the Interrupt
241(1)
Enable Controls Interrupt
241(2)
Default Settings for Enable
243(1)
Optional Registers
243(5)
Source Status Register
243(2)
Post Register
245(1)
Atomic Enable/Disable Registers
245(1)
Masked Register
246(1)
Instantiation Register
246(1)
Addresses of Optional Registers
247(1)
Interrupt Module Review
248(5)
Interrupt Channels
249(2)
Interrupt Module
251(1)
External Connections
252(1)
Triggering on Both Edges
253(4)
Use Two Interrupt Channels
253(2)
Channel Positions of Leading and Trailing Interrupts
255(2)
Using the Interrupt Module
257(3)
When to Allocate an Interrupt Channel
257(2)
Repeated Interrupts
259(1)
Address Mapping
259(1)
Summary
260(3)
Supporting Principles
261(2)
Aborts, etc
263(14)
Definitions
263(2)
Halts
265(1)
Resets
266(2)
Aborts
268(7)
The Need for Aborts
268(2)
Firmware's Interaction with Aborts
270(2)
Abort Behavior
272(2)
Abort Interactions between Blocks
274(1)
Summary
275(2)
Supporting Principles
276(1)
Hooks
277(24)
Designing for Hooks
278(3)
What Hooks to Add
279(1)
Adding Registers
279(1)
Looking for Potential Problem Areas
280(1)
Removing Workarounds
280(1)
Peek
281(6)
Internal Registers
281(1)
Signals
282(1)
Memory
283(2)
State Machines
285(2)
...And Poke
287(2)
Destructive Reads and Writes
287(1)
Input and Output Signals
288(1)
Overwriting Registers
289(1)
Monitor
289(4)
Event Tracking
289(2)
Timers
291(1)
Data Watching
292(1)
More Hooks
293(5)
Bypass Paths
293(2)
Extra Resources for Test and Debug
295(2)
Dedicated Processor
297(1)
Summary
298(3)
Supporting Principles
299(2)
Conclusion
301(6)
Key Points
301(1)
Benefits
302(1)
Seven Principles of Hardware/Firmware Interface Design
302(1)
It Finally Works! Let's Ship It!
303(4)
Appendix A: Best Practices 307(20)
Appendix B: Bicycle Controller Specification 327(18)
Appendix C: elsevierdirect.com/companions/9781856176057 or garystringham.com/hwfwbook
Appendix D: Glossary 345(4)
Index 349
Gary Stringham is the founder and president of Gary Stringham & Associates, LLC. He has 30+ years of experience in the embedded systems industry, assisting clients in their product development and engineering training. He has extensive expertise in diagnosing and resolving a broad range of engineering problems, including: helping litigation clients understand technical aspects of case; working on the design, implementation, and testing of solutions involving software, hardware, and firmware.

Gary previously worked for Hewlett-Packard Company, where he developed and maintained several device drivers controlling a variety of blocks on various ASICs and SoCs for HP LaserJet printers. This involved diagnosing chip problems when they occurred and designing and developing firmware workarounds.

Gary helped develop various tools used for the development, testing, and manufacturing of HP-UX workstation and LaserJet printer products. For a printer emulator tool, he developed the board design, the FPGA code, the firmware running on the tool, and the software running on the host computer. In one instance, the emulator reduced a 40-hour manual test to a 35-minute automated test. For a manufacturing test tool, he architected the tool, led a team of 10 engineers to develop it, and deployed it at five manufacturing sites world-wide.

Gary is a Senior Member of IEEE. He holds a BSEE from Brigham Young University and an MSEE from Utah State University.
Lisainfo e-raamatute kohta Lisainfo e-raamatute kohta
Püsilink: https://www.kriso.ee/db/97800808801982e.html
Märksõnad: