Details and FAQ
How Does SandPiper Relate to...
High-Level Synthesis
With HLS, designs can be expressed at the algorithmic level and tools implement the algorithm on a particular target technology with constraints provided by the engineers. High-level synthesis is great when you have a software algorithm that you want to turn into hardware. It is far less ideal when you simply want to implement hardware.
The industry has invested heavily in HLS and has generated a great deal of hype around using it to design hardware, which leaves many people confused as to why the adoption rate has been so disappointing and why opinions vary so widely.
There's a simple explanation. In some domains, today's HLS tools work quite well. And where it does well, the productivity gains are dramatic. These domains are the ones with deep computational pipelines, like graphics processors and digital signal processing. HLS tools are very good at distributing logic within a pipeline and optimizing computational resources. In other domains, such as CPUs, network adaptors, routers, etc., with complex control logic, design teams have struggled with HLS. Backpressure mechanisms, prediction, exception handling, replays, and ISA optimizations are examples of techniques designers use to optimize performance while managing area and power. It will be quite some time before a tool is capable of outperforming an experienced logic designer at managing the complex trade-offs involved in this sort of design. An understanding of the workloads and performance requirements is at the heart of these decisions. Tools today do not even have that information.
In contrast, SandPiper provides a fairly uniform benefit for all designs. This is depicted in the over-simplified diagram to the right, which suggests that HLS eliminates all work in some design spaces, while SandPiper eliminates some of the work for all designs. Both technologies will continue to evolve and eventually merge to address exponential complexity growth.
Several complaints are common with HLS, which SandPiper addresses:
-
Steep learning curve: HLS is written for SystemC, so transitioning from an RTL methodology to HLS requires complete design rewrites and significant ramp-up on new technology. Teams generally take a hit for the first and sometimes second designs they do with HLS before getting a proper feel for best practices. In contrast, TL-Verilog introduces language extensions that can be introduced incrementally into a design as it makes sense to do so.
-
The generated RTL is not readable/debuggable: HLS generates post-synthesis RTL, which is difficult to relate to the source code. SandPiper produces RTL that is directly implied by and can be easily correlated with the source code.
-
Debug tools are insufficient: HLS debug tools are less mature than those for RTL, and using RTL debug tools to debug the RTL generated from HLS models is not a real solution. HLS infrastructures fall back on C++ debug tools, like GDB, for debug, meaning hardware engineers are debugging their models as software, not as hardware.
-
Long build times: HLS tools do a lot for you. And they do it every time you have to compile. This means you get to wait a lot. Using TL-Verilog, the details of your implementation are carried along with your high-level model in a manageable form. Compilation does less. SandPiper often runs in under a second.
-
Design instability: Any small change in the high-level model can result in physical design change. This creates churn and presents challenges to design closure and ECO flows. With TL-Verilog, all changes are implied directly from the source code changes.
-
Abstraction can only go so far: Customers who expect to take a C++ algorithm and have a tool turn that into hardware for them, are in for a surprise. A model with behavior, structure, and timing is required. An untimed model does not serve the needs of performance verification and cannot provide realistic simulation behavior. TL-Verilog models contain these details.
-
HLS language (SystemC) support is incomplete and non-standard: HLS tools have standardized upon SystemC as a high-level description language, for lack of a better option. This introduced incredible complexity to the tools. Supporting the gambit of C++ is infeasible. Different HLS tools are based on different SystemC libraries and support different subsets of the language. (See "SystemC" section below for more about SystemC.) The abstractions introduced in TL-Verilog are 100% synthesizable. TL-Verilog would be a much more natural language choice upon which to deploy HLS. Too bad it didn't come along sooner. We've got some interesting thoughts on supporting HLS in SandPiper (but we can't share them yet).
-
HLS models are subject to concurrency bugs: Part of the abstraction benefit of high-level models is that they are not strictly timed. This leaves the door open to concurrency bugs, such as deadlock, which appear in some, but not all, implementations, and can be extremely difficult to catch and debug. TL-Verilog models create a clear delineation between a model's behavior and its implementation, and implementation changes cannot introduce concurrency bugs.
-
HLS tools are ridiculously expensive: Yes, they are.
TL-Verilog provides a happy middle ground between RTL and High-Level Synthesis (HLS) -- a best of both worlds that provides benefits through abstraction but keeps the designer in control. And TL-Verilog is far less disruptive to RTL design teams.
This article does a nice job of summarizing thoughts in the industry on HLS: Is System-C Broken? by Brian Bailey.
SystemC, OpenCL, and oneAPI
SystemC, OpenCL, and oneAPI are C++-based languages for high-level modeling. SystemC is "a C++-based standard for designers and architects who need to address complex systems that are a hybrid between hardware and software". OpenCL and oneAPI aim to provide future where algorithms can be implemented using a C++=based modeling library and compiled for various platforms, as a mix of software or hardware.
The ability to describe hardware behavior in a software setting has its place for sure. Co-simulation of software and hardware is increasingly important in today's complex systems. And compiling software into hardware is an amazing feat. But it is important to understand that using a software language to design hardware is an unnatural act, and C++ was a strange language choice for HLS. For modeling mixed hardware/software systems, one must decide whether to: model hardware in a software infrastructure; model software in a hardware infrastructure (running RTL simulations to execute software); do both; or co-simulate in a mixed environment. TL-Verilog has the same constraints as SystemVerilog when it comes to making this decision, though TL-Verilog decreases the modeling effort.
While modeling hardware as software has mixed-environment benefits, for designing hardware,
SystemC, HLS, and OpenCL are hardly solving the problem at hand, by
adding an unnatural set of hard C++ problems to the mix.
--Aliaksei Chapyzhenka, Principal Engineer
For OpenCL and oneAPI, the goal is to shelter the developer from the burden of understanding their target platform. This is an admirable goal that will result in some interesting innovations, but the overall vision is naive. Hardware is not software and never will be. The performance loss in automated synthesis necessitates optimization efforts that degenerate to multiple platform-aware C++-based implementations. Developing alternate native implementations from the start is less work for more gain. Here's some food for thought. As software parallelism increases, software is starting to look a lot like hardware. If a unified modeling framework really is desirable, perhaps we should be looking to hardware modeling for answers rather than software. Granted, we need a better hardware modeling language first.
In contrast to SystemC's software roots, TL-Verilog, is a language for hardware design -- perhaps the first language for hardware design! "Say what??!!" you are thinking. "There are many of them," Indeed there are. But, like SystemC, every hardware description language (HDL) that has gotten traction has its roots in software, simulation, and/or verification modeling. (See notes on "RTL Languages" below.) TL-Verilog, on the other hand, is designed for modeling hardware -- all TL-Verilog code (other than \SV or \SV_plus code blocks) is pure hardware description. Furthermore, where other languages are description languages, TL-Verilog is a design language. It is constructed to be optimal for the process of modifying a design, not for describing a static one. If you want to model hardware, you want TL-Verilog.
SystemC was introduced as an option for modeling behavior at a higher level than RTL. It is a completely different language and environment than that of RTL modeling. SandPiper, in contrast, raises the abstraction level, integrated into a Verilog/SystemVerilog environment.
RTL Languages and HDLs
The most common RTL languages, Verilog and VHDL, were designed to model behavior to validate schematics. They are languages for describing event-based simulation. SystemVerilog allows us to avoid the most egregious aspects of that legacy on the surface, but the legacy remains inherent in the tools. TL-Verilog puts us on a path to abandon that legacy. SandPiper relegates that legacy to the second tier.
SoC
System-on-Chip (SoC) is a necessary answer to exponentially escalating chip complexities. We cannot afford to design complete chips from scratch any longer, so the task of chip design is divided into two levels: IP design, and IP integration.
It is much faster to build out of LEGO® bricks, but you also have to give something up. It is challenging for IP designers to provide designs that work for different customers with different design constraints, especially clock speed. Some IP teams are resorting to HLS out of necessity to address the need to deliver one design to customers with different constraints. Integration teams get what they get. They may be able to make optimizations, changes, and customizations, but once the IP is cracked open it must be reverified. It has become difficult for chip makers, with access to the same building blocks, to differentiate and compete on design quality.
TL-Verilog is addressing all of these challenges in spaces where HLS is not ideal. It simplifies IP design and makes it easier to safely customize and optimize the IP (whether done by the IP provider or by the integration team). For example, see the WARP-V TL-Verilog RISC-V (or MIPS, etc.) CPU core generator.
TLM 2.0
TLM-2.0 provides the ability to specify interfaces at the transaction level and connect those interfaces to models in different languages such as SystemC or RTL. This enables mixed modeling at varying abstraction levels. While TLM provides transaction-level abstraction at interfaces, TL-Verilog incorporates a simple notion of transactions throughout the model, incorporating register level and transaction level together. The model can be directly interfaced at the transaction level anywhere in the design.
TL-Verilog does not in any way interfere with the use of TLM 2.0, though it may diminish the need for it. With abstraction inherent in your TL-Verilog model, the need for separate high-level models may go away altogether.
Bluespec SystemVerilog (BSV)
We love BSV and are sad that it hasn't seen better adoption. BSV and TL-Verilog are similar in that:
-
Both introduce synthesizable higher-level language constructs for hardware design.
-
Both were born of real needs perceived by server chip design teams.
-
Both lead to significant productivity gains.
Of course, if we didn't think we had a new story to tell, we wouldn't be here. The technologies are very different, as is their approach to introducing new capabilities.
-
SandPiper's generated SystemVerilog/Verilog code correlates directly with the source code, which nearly eliminates the debug hurdle presented by an intermediate language and tool.
-
SandPiper extends existing capabilities with open standard language features that can be utilized as opportunity arises, rather than replacing them with a new language requiring complete code rewrite.
-
The learning curve for TL-Verilog is significantly less than that of BSV, especially for someone familiar with Verilog, and it can be learned incrementally. TL-Verilog constructs correlate with the concepts microarchitects use and with the logic that is implied. BSV draws more from concurrent programming concepts.
-
TL-Verilog does not impose any particular design pattern, whereas BSV is built around a specific backpressure protocol.
-
There is no hurdle for individuals who wish to use TL-Verilog 1a, even commercially (in most countries). SandPiper Starter Edition is available at no charge (with no "time bomb"). Bluespec's pricing was a deterrent.
Chisel
Chisel, BSV, Lava, HardCaml, and several other languages can be considered Hardware Construction Languages (HCLs). They are built on functional programming languages and have good properties for flexibly constructing hardware programmatically. They are superior to RTL for building generic building blocks. Chisel, from UC Berkeley, is popular in academic circles, recently, especially due to its association with the RISC-V ISA. Similar to other HCLs, Chisel's obstacles to adoption have included:
-
a lack of maturity and formalism in the specification
-
incomprehensible error messages
-
the unfamiliarity of functional programming to hardware designers
-
difficulty correlating generated Verilog with the source
-
slow Verilog simulation (noting that faster C++ simulation is supported)
On the whole, Chisel is a better RTL; TL-Verilog is better than RTL.
SandPiper FAQ
For me:
Q: How does SandPiper benefit me?
A: See separate pages based on your role: Logic Design, Verification, Architecture/Performance Modeling, Physical Designer, Management, Professor, or Student.
Bottom line:
Q: What's the bottom line? How much will SandPiper improve productivity?
A: Your benefit will increase over time as your team becomes more comfortable and you use features more aggressively. From our experience, you can get as much as 2x with today's capabilities. That is a net productivity estimate for the entire chiplet, or IP design project considering all overheads. You can beat your schedule, or get it back on track with reduced headcount.
Risks:
Q: What new issues are presented by SandPiper?
A: New tools have a habit of bringing with them new headaches. They introduce new build-time overhead, cost, training, migration, coordination, etc. We are keenly aware of that, and every aspect of SandPiper was designed with these concerns in mind. As a result, we have developed a product that: reduces the time you spend waiting for builds, reduces your costs, simplifies the design process, requires no migration, and improves code quality and consistency. SandPiper is easy to incorporate into your build flow and runs fast. It extends your environment, rather than changing it. Many of the complexities of SystemVerilog are no longer needed, but they are still supported. SandPiper can be tuned for your needs and provides an opportunity to enforce consistent coding style and adherence to project methodologies. It is much easier to convince a tool to follow strict practices than it is to convince a team of a hundred coders. There is one serious risk we must call out however -- the risk that you do nothing. The remaining answers in this FAQ clarify these claims for specific concerns. While we are confident that SandPiper will only improve your life, project methodologies are unique and complex, and we suggest localized pilot use and careful consideration of project methodologies prior to broad deployment. We offer assistance with pilot use, so check out our pilot program and contact us.
Build overhead:
Q: How much runtime is added to the build flow by SandPiper?
A: The answer is rather shocking. You'll spend less time waiting for your builds. SandPiper runs on individual files (with include files in some cases). It generally runs in about a second. And if SandPiper finds an error, you don't even have to compile your SystemVerilog code. How long does it take you to catch a syntax error in your build flow?
Build flow integration:
Q: How difficult is it to incorporate SandPiper into my project's build flow?
A: It's not difficult at all. Every build flow is different so we can't give you a definitive answer, but the SandPiper build flow is very simple. It runs on each source file independently. Some may have includes (but nothing like the include tree of your SystemVerilog files). If your build flow is Make-based, it's just a few lines, which we can provide for you.
Functional debug:
Q: How do I relate SystemVerilog debug back to TL-Verilog source?
A: Excellent question. There is a fundamental challenge with any preprocessing/code-generation tools that downstream tools are unaware of the source code and cannot relate error messages and debug information back to the source. This was a very fundamental concern with the development of SandPiper, and our answer is simple. The SystemVerilog code SandPiper produces comes in two flavors: generated code and translated code. Each is produced in its own file. The generated code is correct-by-construction. You can ignore it when debugging. The translated code is kept aligned line-for-line with the source code. Errors reported on the translated code are easily correlated to the source file. Note that SystemVerilog supports a `line directive for exactly this situation that would, in theory, allow a relaxation of strict line-for-line alignment. It creates a correlation back to source code lines for generated SystemVerilog code. SandPiper can use this feature, though we also stick to strict alignment as not all downstream tools support this feature well.
Coding standards:
Q: How will the code generated by SandPiper fit with my project's coding standards?
A: SandPiper includes a project-specific layer that can be tuned to meet project-specific methodologies and coding practices.
Reset:
Q: If SandPiper is generating the flip-flops, how do I control reset for them?
A: There is nothing special about reset (today). Reset logic is coded like any other logic. Reset is not directly modeled as part of the flip-flops but rather as combinational logic. Logic synthesis tools are capable of utilizing resettable state elements from this expression of logic. Using TL-Verilog does provide a material benefit for the reset network. It helps to distinguish "state flops" from "staging flops". Staging flops do not require reset as they do not hold valid data during reset. One commercial customer studied this benefit for a production design block and estimated an area reduction of nearly 15%!
Clock gating/enabling:
Q: How do I control clock gating logic if it is generated automatically?
A: Fine-grained clock gating or clock enabling is constructed automatically from knowledge about the need for clock pulses. Clock gating can be in place from day one. You have the ability to control clock conditioning logic using SandPiper command-line flags (--clk*), and you can provide a project-specific module for the clock gaters. In the event that further control is needed, source code changes can be implemented. Falling back on Verilog for specific cases is, of course, an option, though it is rarely necessary. The importance of power optimization and the methodological shift-left implications of automatic clock gating are covered in this blog post.
Debug/test Logic:
Q: What control is lost for debug and test logic?
A: None. Debug and test logic are coded like any other logic. Scan interacts directly with state elements, which are now generated by SandPiper. Some methodologies insert Scan logic in back-end flows. This can be done on generated code as with hand-written.
Using SystemVerilog libraries:
Q: Am I still going to be able to use my favorite SystemVerilog libraries and project header files?
A: Absolutely. You can use SystemVerilog constants and invoke SystemVerilog macros, modules, and functions in TL-Verilog context. The logic they define can be easily and safely retimed as with other TL-Verilog logic.
Clock/power domain crossings:
Q: How does SandPiper deal with clock and power domain crossings?
A: SandPiper operates internally to clock and power domains. Your approach to clock and power domain crossings remains unchanged.
Physical hierarchy boundaries:
Q: Is there any impact to physical interfaces that would impact physical methodology requirements?
A: No. SandPiper operates internally to module (physical) boundaries.
Formal Equivalence Verification (FEV):
Q: How do we know we are building what we are verifying in simulation?
A: Methodologies vary, but all teams need to know that the physical design matches the simulation model. There are many reasons to introduce "instrumentation" logic for simulation that is not part of the final silicon. Reasons include assertions and checkers, logic interfacing with verification collateral, dont-care (X) injection logic, injectors, etc. Generally, the same SystemVerilog code provides simulation and physical models, where differences are enabled through a `define (eg: #ifdef SIM). In the recommended SandPiper methodology, the common codebase would be TL-Verilog source, and different code could be generated for simulation and the physical design. Either way, where there are differences, there is an opportunity for bugs to sneak into the physical design. With SandPiper, tools are providing assurances about those differences, but even tools must be verified. This verification is provided with Formal Equivalence Verification (FEV) tools. The physical design, at well-defined physical boundaries, is verified to implement the simulation model at the same boundaries. Generally, these boundaries correspond to SystemVerilog module boundaries. Currently, SandPiper operates purely within module boundaries. As such there is no change to FEV methodology, with the minor exception that the use of different physical and simulation SystemVerilog source files may be new. Though the general SandPiper premise that generated code is easier to control than hand-written code should ease your mind, a project's FEV methodology should be carefully reviewed w/ SandPiper in mind to be sure.
Backend flows (eg, Scan insertion):
Q: Some environments, though this is becoming rare, do post-processing of the physical design to add test/debug logic such as Scan logic, and there's collateral relating to state elements for this. With state elements now generated automatically, how with these flows work?
A: The generated code is 100% predictable (as long as project-specific tuning of SandPiper is held consistent). SandPiper does not synthesize logic. Signal names for state element inputs and outputs as well as the generated state element syntax follow rigid conventions that can be defined by the project. So backend tools can predictably interface with generated content. Rather than creating issues, SandPiper creates opportunities for downstream tools which can now have stricter guarantees about the nature of the generated code. There are also opportunities to insert logic at the front of the flow, rather than in the backend, enabling functional debug of the inserted logic and visibility of this inserted logic to physical placement tools.
Verification models' use of generated SystemVerilog signals:
Q: How do verification models interface with generated SystemVerilog?
A: Since the generated code is 100% predictable, verification models can interface with generated code as they would hand-written SystemVerilog. Most verification collateral these days interfaces at well-defined interfaces, generally module boundaries. Since TL-Verilog currently operates internally to module boundaries, the use of TL-Verilog is immaterial. In some cases, coverage monitors and checkers might monitor internal, generated signals, and that is perfectly fine, at least as far as TL-Verilog use is concerned. It might be discouraged so that internal changes don't break verification collateral. From this standpoint, TL-Verilog can help, because monitors written to utilize TL-Verilog can be sheltered from logic retiming changes.
Assertions:
Q: How are assertions written in TL-Verilog?
A: Assertions can be written using SystemVerilog assertion syntax with the addition that TL-Verilog can help align signals of a transaction that are distributed throughout pipeline stages in hardware. TL-Verilog modeling can also provide a more convenient way to define logic for more complex assertions. Assertions and other "instrumentation" code that does not represent hardware logic can be excluded from the physical model (using M4 macro preprocessing). This includes SandPiper-generated staging of transaction signals into the assertion, which is awkward to deal with in pure SystemVerilog.
Hardware emulation:
Q: How does SandPiper impact hardware emulation?
A: There is no direct impact, but there is plenty of opportunity to do more with emulation using TL-Verilog. All TL-Verilog constructs are synthesizable. You can use TL-Verilog for high-level models, reference models, checkers, assertions, and transactors and run them on the emulator, rather than on the host system for your emulator platform, and get a dramatic performance boost.