草榴社区 Cloud
Cloud native EDA tools & pre-optimized hardware platforms
Request a Free Trial →
Faster Iteration Flows to Accelerate Hardware/Software Development
By Dr. Antonio Salazar, Senior Prototyping R&D Engineer, 草榴社区
Hardware/software co-development traditionally suffers from long iteration cycles due to inherit dependencies among separate functional and implementation specifications, protocols and engineering teams. Frequent RTL drops and debugging iterations are a few of the bottlenecks that impede the fast progression of hardware/software co-design, in particular when considering scenarios of IP integration in SoC designs.
To accelerate time-to-market, designers must make compromises in features, testing, cost/expenses, and sometimes even quality. This is particularly true when considering SoC environments that require multiple IP cores along with legacy code, which will require interfaces on both sides of the hardware/software coin. Although IP can solve a number of issues and save considerable time, energy and effort, it can be a black box of knowledge that requires a steep learning curve. While configurability and flexibility are key aspects of well-designed IP, these features can introduce complexity and challenges. Some designers need hardware-level configurability to achieve an optimized design, while others require more self-managed hardware that raises the task to a software level. In either case, designers may face a never-ending sea of databooks, user manuals, application notes, and more.
The path to SoC software design is not like the electronic kits that are sold at electronic consumer websites, but it should be closer to that experience. All SoCs are composed of similar blocks such as a CPU, a communication bus, memory controller, I2C, SPI, or similar. So then why, if designers have connected similar blocks hundreds of time before, should basic design be so difficult? Prototyping an ASIC, which arguably is mostly composed of legacy RTL and IP blocks should not take so much time and effort, nor should iterations be so laborious.
In reality, designs are never as similar to the past one as one would hope. Standards are updated, protocols change, new requirements appear, consumer tendencies shift the priorities, etc., and time-to-market pressures demand faster design.
The iteration flow has a very real effect on a product’s bottom line. After an idea for a product is proposed, specifications are generated and designers figure out the logic required to comply with the latest trends and standard of communication. This process consumes valuable design time while time-to-market pressures remain. Prototyping environments not only provide the means for accelerated hardware validation by permitting designers to address issues early in the production cycle, they can also serve as a feature and configuration exploration environment that ensures a fast iteration flow.
Prototyping a DDR IP Subsystem
Prototyping a DDR subsystem is a relatively straightforward design with well perceived functional and verification goals. The functional objective is to read and write to a target memory, while verification is achieved by physical access to commercial memory. While this may seem simple, many elements must be taken into consideration from a connectivity, configuration, initialization, and operation perspective; additionally, hardware/software collaboration is required to achieve even the most basic operation, Figure 1 illustrates a generic DDR subsystem illustrating the different blocks involved. On one side, a memory controller permits the consolidation, through an arbiter, of communication ports that connect to a PHY utility block, which connects to a PHY, which connects to the memory itself. Each block requires configuration at the hardware and software level through the use of hardwired definitions and parameters as well as register configuration that can be static, dynamic or even pseudo-dynamic. The hardware/software balance happens at multiple levels. The hardware ultimately defines the connectivity characteristics of the involved blocks as well as the range of available registers and permissible functional aspects of the blocks themselves.
Figure 1 : DDR IP Subsystem
In this DDR prototyping environment, each hardware level change requires an FPGA image rebuild, which can take hours to days depending on the size of the target. Therefore, simulating the design might be a wiser path than building a hardware prototype, but this too can take hours or days, depending on the functional aspects being tested. On the software side, an operating system is traditionally involved, which requires setting up, loading and verification, which is followed by initialization procedures. Designers must then access the proper communication busses to communicate to the target block and proceed to initialize them as well (all before the first read or write can be made). Debugging becomes a needle in a haystack without the proper elements in place and since literally one bit out of place can drive this subsystem to a halt. The iteration flow can become a tangled web of FPGA builds, simulations runs and software attempts, with the corresponding recrimination back and forth (it is a software issue, it is a hardware issue, it is a prototyping issue).
Designers need to “accelerate” this prototyping scenario with IP Prototyping Kits. 草榴社区 DesignWare IP Prototyping Kits are built around proven reference designs on a flexible and mature prototyping platform. The kits leverage widely used software such as Synplify?, Identify? and Certify?, integrated into one solution, ProtoCompiler, the HAPS? prototyping system, and the ARC? processor’s software development platform (SDP). The IP Prototyping Kits accelerate iteration cycles by providing IP reference designs in a tested, ready-to-go hardware/software environment which allows for configurability exploration, supported by hardware-aware development tools which optimize and accelerate the process. In the case of the DDR IP Prototyping Kit, 草榴社区’ Enhanced DDR Memory Controller (uMCTL2) is paired with an emulation PUB/PHY (which comes in different versions, such as DDR4 multiPHY, DDR3/2 PHY, Gen2 DDR multiPHY) and connects to an actual DDR3 memory attached through a daughterboard (with the option to use the on-board DDR3 that comes with the HAPS-DX platform). The IP is accompanied by all the necessary support logic required to connect the HAPS-DX to an ARC SDP which permits the real-time operational verification of the software counterparts. In the case of the DDR IP Prototyping Kit, a complete software example and proper drivers are included to serve as a reference for interfacing, thus permitting instantaneous productivity on both software and hardware, based on a clean, test, and configurable starting point that can be set up within a couple of minutes. When considering iterations, half the battle has been won because a large number of the delay issues are related to the RTL prototyping bring-up, which is not needed with the IP Prototyping Kits. Even if the included configuration is not provided exactly as needed, ProtoCompiler permits a fast paced FPGA image generation all within a friendly development environment with the option of including the necessary instrumentation for some real hardware/software debugging and a completely setup simulation environment. The prototyping time saved can cut up to six weeks from your development schedule.
DesignWare IP Prototyping Kits provide the essential hardware and software elements needed to reduce IP prototyping and integration effort by up to six weeks. With the IP Prototyping Kits, hardware designers have a proven reference design that can be easily modified to explore design tradeoffs and validate a specific configuration of the IP, and software developers have a proven target for early software bring-up, debug and test. DesignWare IP Prototyping Kits are now available for DesignWare USB 3.0, SSIC, PCI Express 3.0 and 2.0, MIPI CSI?2, HDMI 2.0, JEDEC UFS and DDR Memory Controller IP.
Figure 2 : DesignWare IP Prototyping Kit Block Diagram