top of page

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.

 

SandPiper FAQ

 

Bottom line:

Q: What's the bottom line?  How much will SandPiper improve productivity?

A: 20% today, from our experience.  That is a net benefit estimate and includes all overheads associated with incorporating something new and ramping up on it.  You can actually 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.

 

 

 

All trademarks cited herein are the property of their respective owners.

 

What Does SandPiper Mean to me?​

 
For Logic Designers

 

Work Smarter: SandPiper takes the tedium out of logic design.  Half the code to do the same job -- you can enjoy your work and spend your evenings with your family.  SystemVerilog is a language for describing event-based simulation.  TL-Verilog turns SystemVerilog into a language for hardware design, with pipeline and transaction constructs that match the way designers think.

 

"The connection between the language in which we think/program and the problems and solutions we can imagine is very close."

-- B. Stroustrup (creator of C++)

 

Break the Tug-of-War: Verification on one side and implementation on the other, and you feel like a rope pulled in both directions, unable to satisfy either side.  The verification team wants simple abstract interfaces, and the implementation team needs interfaces to be physically-optimized.  The verification team wants stability and new functionality, while the physical team needs disruptive changes to close timing.  And in your environment, it takes a long time just to get a simple change through.  SandPiper will help you make them both happy.  TL-Verilog enables logic retiming that is safe for the physical team to make independently without any risk of breaking functionality or breaking verification collateral, so they can make progress without you.  You can focus more on new functionality.

 

It Won't Hurt: There's always a learning curve with something new, but you can ease into TL-Verilog because it is a language extension.  You lose nothing.  Learn enough to get the idea at makerchip.com, then download the free limited version to use on your own proprietary models.  We'll help you get off the ground.  SandPiper usually runs in a fraction of a second, so it adds little to your build time.  In fact, it generally saves you build time by acting as a fast filter for syntax errors.  (Also, in this manner, it saves on license usage and costs of other tools.)  Generally, with generated code, it is difficult to relate errors back to the original source code.  Not so with SandPiper.  Generated code is generally either correct-by-construction or it is translated line-for-line from the source code, so an error on line 147 is an error on line 147.

 

Supporting Ecosystem: The most popular editors have support for TL-Verilog.

 

 

For Verification Engineers

 

Verification Modeling: TL-Verilog is designed for modeling synchronous behavior, be it hardware or verification models like transactors and reference models.  In contrast, SystemC is based on C++ and carries with it baggage from its software roots.  TL-Verilog enables verification models to directly interface to the transactions in hardware.  Even if other modeling languages are used, TL-Verilog can provide the gasket for transaction-level access.  While signals for transaction logic are distributed throughout the pipelines of a hardware model, they can be accessed collectively as a transaction by verification models.

 

Hardware Emulation: TL-Verilog provides synthesizable constructs for Transaction-Level Modeling.  Your TL-Verilog transactors, reference models, and assertions can be synthesized for hardware emulation rather than running them on the emulation platform's host processors.  You can get top speeds without disabling checking, and no gaskets are required between verification models on the hosts and synthesized hardware logic.

 

Earlier Models: Tired of waiting for RTL?  TL-Verilog's smaller models come to life faster.  You want your logic designers using SandPiper.

 

Fewer bugs: Redwoods are resistant to bugs!  Sandpipers eat them!  Numerous studies as well as the engineer's gospel "The Mythical Man-Month" conclude that complexity and bug count grow more than proportionally to code size.  You want your logic designers using SandPiper.

 

Less Churn: Do you feel like you spend your life chasing unstable RTL?  Get out of that funk!  Bugs are introduced constantly by changes made for physical implementation reasons, the most common of which is retiming logic to meet cycle-time.  This activity is a factory for bugs in RTL, but it is much easier and safer with TL-Verilog.  The RTL will be more stable and your logic designers will have more time to focus on the functional changes you need.  Additionally, the introduction of clock gating logic, which creates bugs late in the design process, is all-but eliminated with TL-Verilog and SandPiper.  You want your logic designers using SandPiper.

 

Debug: You can use your existing debug tools with RTL produced by SandPiper.  The produced RTL is, in fact, easier to debug than hand-written code because it follows a predictable structure and a consistent signal naming methodology no matter who wrote the source code.  About half of the produced RTL is correct-by-construction.  This includes signal declarations, state elements (flip-flops and latches), and clock-gating logic.  This code is placed in separate files that you know you can ignore.  The remaining code is directly translated from the source code and adheres to a strict signal naming convention.  You'll never see a signal with a stage 2 name go through a flip-flop and magically become a stage 4 signal; and you'll never see a signal get staged and incorporate a new condition without changing name.  You want your logic designers using SandPiper.

 

 

For Physical Designers

 

Be Empowered: Tired of waiting for the logic team to make the necessary RTL changes?  Encourage your logic designers to use TL-Verilog, so you can take control.  Many of the changes necessary to meet timing can be made by you safely without the need for regression testing, without any help from your logic designer.  Our first two online tutorials will teach you how.

 

 

For Managers

 

Increase Productivity: Sure, your engineers can get to the next milestone with their square-wheeled cart. But it's not about the next milestone, it's about the finish line. Give them round wheels. Make the next milestone getting those wheels on the cart. Engineers are most enthusiastic when they are productive and when they are on the forefront of technology.  Help them discover a better way; force them to discover a better way; they will respect you for it!

 

Eliminate dependencies: SandPiper enables verification early, and it decouples physical timing closure work from logic and verification work.  Logic designers can deliver early functionality with a fraction of the code using TL-Verilog enabling verification activities to "shift left" on the project timeline.  While your verification team needs functionality, your physical designers need RTL changes to address broken timing paths.  With TL-Verilog and SandPiper, many timing changes can be made safely by the physical designers without any help from the logic team -- without breaking verification collateral and without any regression testing, freeing up your logic designers to focus on the functionality needed to address your long-pole activity -- verification.

 

Better results: With SandPiper, you can afford to push your clock frequency for higher performance.  Your team can deliver a lower-power solution with fewer escapes in less time.

 

Save money: That's right, save money.  Getting done faster with fewer engineers, in itself, saves time and money.  In addition, SandPiper will filter many bugs without the need to compile SystemVerilog, so you can cut back on compiler licenses while you work faster.

​

​

Does this look familiar?

Wouldn't you prefer this?

Beat your schedule, with SandPiper.

For Architects and Performance Modelers

 

High-Level Modeling (HLM): Yes, we know, you are really good with PowerPoint® and maybe even Visio®, but do you remember the days when you actually created real code that did something?  You didn't give that up because you wanted to.  You just don't have the time for that level of detail anymore.  We're going to give you back your modeling power.  High-Level Models in TL-Verilog are four to eight times smaller than they would be in SystemVerilog, and, unlike PowerPoint® slides, you can actually do something with them, and so can others.  There's nothing like seeing it work.  It's hard to find a bug in a PowerPoint® slide, but simulation doesn't lie.

 

Top-Down Design: Your HLM can live on.  Provide the logic team a starting point.  They will thank you for it, and they will be less likely to reinvent your architectural vision.  A TL-Verilog HLM can be evolved into production RTL.

 

Performance Modeling: High-Level TL-Verilog models can be used for performance modeling.  While simulation may be a bit slower than other modeling methods, simulation is not the only option.  Since TL-Verilog is synthesizable, hardware emulation becomes possible for dramatic speedups.

 

Early Verification: It enables the verification team to begin their work earlier, and verification is always the long pole to tape-out.  An early verification environment keeps the logic work on track.

 

Early Physical Feedback: Sure, your TL-Verilog HLM is not yet implementable, but it is analyzable.  The physical team can get to work on major array structures and provide feasibility feedback.

 

 

For Design Automators (DAs)

 

Easy Integration: SandPiper runs individually over each TL-Verilog .tlv source file and produces two SystemVerilog .sv files that are compiled like hand-written .sv files would be otherwise.  So, foo.tlv -> foo.sv & foo_gen.sv -- you can start that simple.  Soon enough there will be a desire for include file support -- very basic stuff.  Every environment is different.  We're happy to help with any issues.

 

 

For EDA Folks

 

Join the Movement: Be a part of the excitement through TL-X.org.

 

 

For Professors

 

TL-Verilog is ideal for education: You want to use SystemVerilog to teach logic and microarchitecture, but learning SystemVerilog requires three big books and a big reference manual.  You can take your whole semester and cover a fraction of it.  TL-Verilog greatly simplifies things.  It introduces new constructs that correspond to the microarchitecture concepts you need to teach -- state, pipelines, and transactions.  All the language overhead that exists for describing event-based simulation models is not required, so you can focus on logic and microarchitecture.  With code that's half the size, you can give assignments that are actually meaningful.

 

Online assignments: Makerchip.com is a perfect environment for class assignments in TL-Verilog.

 

Skills for the future: Teach the skills of tomorrow, not the skills of today.  Put your students ahead of the curve.

 

Help is available: We are interested in co-developing curricula.  Let us know your interest, and let's see what we can do together.

 

 

For Students

 

School projects: Have a SystemVerilog assignment?  Use makerchip.com, and let SandPiper write half of the code for you.

 

Do cool stuff: Think designing chips is complicated?  You can do it!  You'll be able to do projects in TL-Verilog that wouldn't have been possible in SystemVerilog.  Learn now .

 

Career opportunities: Learn skills the experts in the industry don't have yet.  Build your resume.  Impress potential employers.  In fact, send us a resume if you've got the chops.

 

Here's what one student had to say:

 

I am currently taking a course where I am using System C for Transaction Level Modeling and it didn't seem intuitive to me as a hardware designer due to the limited control I have over my design. Hence, I got interested in TL-Verilog and the benefits it brings with it in terms of the ease of expression of the design. I believe what you are doing as a company is extremely important to get TL-Verilog out into the industry and make it a viable substitute to current industry languages.

 

--Nikhil Ahuja, MS candidate in Comp. Eng. at NCSU

​

 

 

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.
 

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 which 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.

 

Here's a more in-depth analysis of SystemC, from Matthieu Wipliez, CTO of Synflow: SystemC is a Standard -- not the Solution.

 

 

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.

​

forLogic
forVerif
forPhys
forManagers
forArchitects
forStudents
SandPiperVersus
FAQ
ForMe
forProfs
forPostSi
forFounders
forHobbyists
forResearcher
bottom of page