FONT SIZE : AAA
In this section, we outline several important organizational considerations for the prototyping program. There are, of course, many options as to the organizational reporting structure of the prototyping team, however, there should be careful consideration in how the prototyping team’s integration into the organization (and other procedural decisions) affects communication between the design, software, verification, and prototyping teams. Moreover, every effort should be made to integrate and formalize the dataflow and unify the databases, regression, and engineering changes.
Table 22 gives a short summary of the key procedural guidelines that we will cover during this chapter.
The guidelines focus on managing the communication between the different teams during the whole project, including the prototypers as core members of the project from the start of the project (when architectural trade-offs design goals are first being considered).
The success of the overall project is going to be improved if everyone can embrace the idea that there is one design with two target technologies. In addition to FPGA skills, the engineers assigned to the prototype will likely be creating supplemental design RTL and making or recommending changes to the original RTL as well. As such, they need to be integrated in the SoC design team or the organization will likely experience duplication of effort and schedule delays. Project management must strive to create a shared responsibility and avoid the behavior of “throwing the design over the fence” at schedule milestones. It is important to have the prototyping team as part of RTL design team, , trained on same tools, using same RTL coding standards, and having access to same design validation suite (i.e., testbenches and scripts). Involving the SoC design team in the early prototyping effort will also make the prototyping easier.
There are design teams known to the authors in which each SoC designer takes responsibility for the retargeting of their own blocks into FPGA and this is a sure fire way to have those blocks beat the third law of prototyping.
If management thinks that the design team cannot accommodate an initial prototype implementation, management should strive to cross-train the design engineers to understand both SoC and FPGA technology. By increasing common skill levels it will be easier for engineers to create new logic blocks or introduce engineering changes that will work for both technologies. When technology specific coding is necessary then we should plan it in advance rather than try to redo our design after the event, risking delay in the project.
SoCs and FPGA-based prototypes share many of the same design issues, By developing FPGA skills within the SoC design group we will allow common solutions to these design issues to be established quickly without excessive iterations.
At the start of a prototyping project, the prototyping team needs more than just the RTL. It is important to have a hand-off list of deliverables so that we can check it before the start of the project, or at least understand early on what is missing In this way the prototyping team will not waste time later in the project.
Table 23 shows a typical list from a major semiconductor prototyping lab where a design-for-prototyping methodology is being pioneered.
It may seem like a simple idea but all scripts and file lists should be kept as part of the source control of the project. By capturing more than just the RTL code it will be possible for others to recreate the build process if needed in the future. The best solution is to create common project make-files for SoC and FPGAs with macrodriven branching for different targets. In this way, the design team captures all key details involved in a “run-able specification.” Ideally, most target specific differences will be isolated to independent modules that can be used as a library for a given target. The alternative of laboring to write lengthy instructions may still fail to document all important setup details and discarding key build scripts is asking for trouble later. By just establishing simple procedures and “mindset,” this important chore can become routine activity.
The key point that must be addressed by the team is that a single RTL description will be implemented in two target technologies (FPGA and SoC). A conscious effort should be made to separate technology specifics from the intended functional definition. It is important to create clean architectural interfaces with identical behavior in both implementations. Design practices incorporating this idea during engineering change (EC) activity and quickly communicating design impact in a predictable manner to all team members will increase the effectiveness of the project.
Some organizations building complex systems with new hardware and embedded software struggle with communication problems between the hardware and software groups. Because of the high software content in a modern SoC, it is critical that the FPGA prototype group regards the software group as its customer. Part of the ROI for the prototype is giving software developers early access to functioning hardware and the two groups must have good working relationship to achieve this goal.
A process to track software changes alongside RTL changes will minimize confusion and wasted effort due to compatibility issues. All changes to RTL code should be tracked by a source code control system (like Perforce or SCCS), probably the same one that is used by the SoC and software developers.
Since the prototype will run slower than the final SoC implementation, some areas of the software may need to be rewritten for error-free operation running on the FPGA prototype. Also the designers of the prototype hardware need to consult with the software developers to consider establishing extra probing points, resets or other capabilities that can help in software debug and which are not possible in the SoC implementation. The important point is that early interaction between the two groups can establish extra requirements on both the software design and the prototype design that will help the project achieve it goals and can be included in schedules at the front-end of the planning cycle.
Manufacturer:Xilinx
Product Categories: FPGAs
Lifecycle:Obsolete -
RoHS: No RoHS
Manufacturer:Xilinx
Product Categories: FPGAs
Lifecycle:Obsolete -
RoHS: No RoHS
Manufacturer:Xilinx
Product Categories: FPGAs
Lifecycle:Obsolete -
RoHS: No RoHS
Manufacturer:Xilinx
Product Categories: FPGAs
Lifecycle:Active Active
RoHS:
Manufacturer:Xilinx
Product Categories: FPGAs
Lifecycle:Active Active
RoHS:
Support
