Design Challenges: Avoiding the Pitfalls, winning the game - Xilinx

More documents

Recommendations

Info

V I E W P O I N T The issue here is not what is common but what is not. The design community as a whole has spent much more time and resources developing hardware simulators and emulators. of a hardware platform at the onset of the project, you developed an emulated host environment that allows you to develop and test your code. You start with basic tests of the OS. You test function calls, interrupts, and the GUI. You optimize the code for performance and verify the operational paths. You check the algorithms and verify the corner cases. You do everything possible to ensure that the software will be ready when the boards are available, only to be told you will receive the hardware six weeks later than expected. (The project end date does not move.) You finally receive the hardware. You track down the power supply and cables that did not show up with the board. You power up the board – the system appears dead. Now you begin the arduous task of debugging and working through the system. You discover that the hardware is Big Endian, despite an earlier agreement that data will be transferred in Little Endian format. You sit down with the hardware engineer and ask what they are doing. They immediately start telling you how their test code works and that they are sure the hardware is correct. You wonder what these guys have been doing for the last six months – don’t they even have basic hardware functioning? The Counselor Says ... Although the preceding sections are somewhat exaggerated, the odds are that you recognized either a past or current project in them. But the reason why you may not see a lot written about this subject is because the issues involved don’t make much sense. If Figure 1 applies to both hardware and software, then obviously the design flows are very similar and almost interchangeable – shouldn’t that help with integration? What about the software/hardware interface document (or whatever you call it at your company) that describes how the hardware and software interact – wouldn’t it preclude any problems when integrating? The issue here is not what is common but what is not. The design community as a whole has spent much more time and resources developing hardware simulators and emulators. This began in earnest with the advent of VHDL by the military and has expanded to Verilog and more recently C-to-gates technology. Simulation technology has developed to the point that it is quite reliable and accurate. Most vendors now provide HDL models that you can use to simulate entire hardware systems as opposed to individual devices. On the flip side, the engineering community has largely ignored the other parts of the system. Software testing without a target platform relies on the designers to build a model of the system on a host. Software engineers have to develop and test the system software using this model. And although this model is, in many cases, even more complex than the software to be designed, it cannot accurately model all of the facets of a system (much less all individual components). Unlike the hardware models available to hardware designers, few companies offer similar models to software designers. Cosimulation offers little advantage to either software or hardware designers, because it can be prohibitively time-consuming to simulate even a few simple instructions – much less an entire routine or operation. The design flows may look basically the same, but when it comes to the way in which they are executed they are quite different. It is this difference (and the lack of understanding the difference) that accounts for the majority of the issues during integration. To some extent, the hardware team does not understand that the software team requires the actual hardware to truly validate even what the hardware team may consider a simple function. On the other hand, the hardware team has become in many cases overreliant on technology. Most hardware designers will tell you that the person writing a test bench and the person doing the design should be different people. However hardware engineers will write their own test code for board debug and could be lulled into a false sense of validation, making the same wrong assumptions writing the test code as when designing the logic. To minimize the pain of integration, you must rely not on technology, but communication, understanding, and empathy. Understanding what your counterparts on the other side of the wall are doing and the processes and techniques they follow and use will allow you to better prepare for integration. Communicating with them will minimize the time and pain associated with integration. Initially this will require a little extra effort on both sides. One of the best ideas is to have the software team write the test code that the hardware team uses to verify the board. Although this is typically not planned or scheduled, it makes sense from several angles. First, if the software team writes the test code, it minimizes the possibility that a requirement could be interpreted differently by the two teams – it will be resolved in this early phase. Second, many of the small problems that can cause major delays later (such as Big Endian versus Little Endian) will be found and their impacts minimized. This, combined with a software test plan that allows the hardware team to know what software will be tested (and in what order) can go a long way in easing integration. 8 Xcell Journal Third Quarter 2005
The second idea is to have the hardware team document their design early and often. As the software team cannot truly test until they have target hardware, they must rely heavily on the documentation supplied by the hardware team. It is critical that the software team receives complete documentation – and that the documentation is kept up to date. The hardware team must also consult with the software team before making design changes. Although a change may seem trivial from a hardware perspective, it could result in an extensive software change, particularly in the latter stages of the project. Finally, the software team must have a stable target platform. This does not mean a perfect, bug-free platform but rather a consistent, known platform. It is important that the hardware team relay any and all known board/logic issues to the software team. This will prevent the software team from wasting time chasing down a known problem. Happily Ever After ... Specifications may fluctuate. Timelines may change. Management may have pointy hair. Many technical and operational challenges exist in every project, but nothing jeopardizes a project or brings more stress to a design engineer than when hardware and software are integrated. The challenge is to plan and design for that event from the beginning. There is no magic formula for a smooth hardware/software integration plan. However, there should be a plan and an understanding of what the other guy is doing – or is going to do. Having this understanding and actually talking with your hardware or software counterpart will make integration a lot less painful. A few sacrifices now will be rewarded in the end. Although the software team may not have planned on writing test code for the hardware team, burning a few extra cycles to write it will allow both teams to detect and correct problems early. This – combined with a good integration/test plan, well-documented hardware (including unintended design features), and a stable hardware platform – will go a long way in making integration easier. V I E W P O I N T Third Quarter 2005 Xcell Journal 9
Page 1 and 2: Xcell Issue 54 Third Quarter 2005 j
Page 3 and 4: EDITOR IN CHIEF Carlis Collins edit
Page 5 and 6: THIRD QUARTER 2005, ISSUE 54 Xcell
Page 7: Hardware Said ... The design flow s
Page 11 and 12: and automatic module generation wil
Page 13 and 14: Designing Control Circuits for High
Page 15 and 16: Figure 2 - Implementing an FSM in S
Page 17 and 18: Let’s consider these challenges i
Page 19 and 20: demonstrated by Dr. Howard Johnson,
Page 21 and 22: Pblocks can direct the flow of the
Page 23 and 24: Virtex-4 beats competing FPGAs in e
Page 25 and 26: In addition, you may also use techn
Page 27 and 28: Using Precision Sythesis, Block Mul
Page 29 and 30: 14-Bit, 125Msps ADC Only 395mW Lowe
Page 31 and 32: Non-Symmetric Aspect Ratios/FWFT Ap
Page 33 and 34: QWERTY Building Blocks Our solution
Page 35 and 36: FPGA-Based Video Games Implementing
Page 37 and 38: The Atari 2600 Video Computer Syste
Page 39 and 40: The architecture wizards inside ISE
Page 41 and 42: Smart Telematics Systems from Xilin
Page 43 and 44: interfaces available, Microsoft int
Page 45 and 46: TXPLL TxData[7:0] FIFO an x4 link c
Page 48 and 49: POWER MANAGEMENT Design Techniques
Page 50 and 51: Power Estimation Tools Xilinx provi
Page 52 and 53: POWER MANAGEMENT Performance vs. Po
Page 54 and 55: POWER MANAGEMENT is the first time
Page 56 and 57: POWER MANAGEMENT Merging CPLD Featu
Page 58:
POWER MANAGEMENT A Clear Choice Wit
Page 62 and 63:
POWER MANAGEMENT Spartan-3 FPGA Pow
Page 64:
POWER MANAGEMENT 5 V_INPUT Highly i
Page 67 and 68:
Tool Example Electrical Simulations
Page 69 and 70:
y Bill Hargin Product Manager, Hype
Page 71 and 72:
Typically used bit patterns, or “
Page 73 and 74:
ages and densities for increased fl
Page 75 and 76:
see the start sequence, it continue
Page 77 and 78:
The Virtex-4 ML450 Development Boar
Page 79 and 80:
CONNECTIVITY Bridging System Packet
Page 81 and 82:
put stream of SPI-4.2 data. A progr
Page 83 and 84:
Controlling Noise A well-designed p
Page 85 and 86:
Prototype Your PCIe ASIC HERE See u
Page 87 and 88:
knowing what is in R3 of the proces
Page 89 and 90:
X-ray X-ray vision vision for for y
Page 91 and 92:
The program size is smaller because
Page 93 and 94:
Communications) and Verilog PLI, so
Page 95 and 96:
Figure 1 - Period constraint in Syn
Page 97 and 98:
DEBUGGING Using the actual constrai
Page 99 and 100:
Bus Triggering and Display Traditio
Page 101 and 102:
Designer Challenges for Pb-Free and
Page 103 and 104:
A Shortcut to Effective Hierarchica
Page 105 and 106:
Xilinx Education Services: Knowledg
Page 107 and 108:
BIDIR_PAD(7.0) BIDIR this course, w
Page 109 and 110:
Xesium Global Clocking • 500MHz D
Page 111 and 112:
Xilinx Virtex-4 FPGAs www.xilinx.co
Page 113 and 114:
Xilinx CPLD www.xilinx.com/devices/
Page 116:
Design Example: 1.5 volt LVCMOS 4mA
show all

Design Challenges: Avoiding the Pitfalls, winning the game - Xilinx

Create successful ePaper yourself

Delete template?

Save as template?