Breaking News
Blog

Bridging the gap between RTL development and design implementation

Eyal Odiz
3/28/2011 10:39 PM EDT

 4 comments   post a comment
NO RATINGS
View Comments: Newest First | Oldest First | Threaded View
KarlS
User Rank
Rookie
re: Bridging the gap between RTL development and design implementation
KarlS   3/31/2011 2:19:09 PM
NO RATINGS
Another aspect is that it is more important to get a big complex design to work than it is to optimize every path and every Boolean function. Forty years ago the opposite was true. Another thing is embedded processors are programmed in a high level language, but the compiling process breaks the code down into such tiny steps that it takes millions of cycles to do any meaningful function. Things like pipelining, branch prediction, multilevel caches are assumed to be absolute necessities but they are not. The typical if/else. for, while, do are just structured ways of expressing compare and jump constructs and assignments can be streamlined by putting them into Reverse Polish Notation. Then the cpu becomes a very small physically, and use of multiport memories allows the statements to execute in very few cycles. The result is that function is coded in high level language, code size is small, power is low because thousands of flipflops do not have to be clocked simultaneously. Changes are done by altering memory content rather than redoing the entire chip compilation and timing. One concern might be that a total chip design may be a few cycles faster, but effectively doing more function per cycle offsets that effect.

lifewingmate
User Rank
Rookie
re: Bridging the gap between RTL development and design implementation
lifewingmate   3/30/2011 6:33:50 AM
NO RATINGS
As a technical communicator writing while the IC architecture team worked with the RTL development and design teams, I encountered the frustrations the author, Odiz, seeks to prevent. This article is an excellent recommendation to improving IC development/design--making sure the teams all around the world compile, aggregate, and build/test designs implications more quickly. One of the solutions my company looked at was company-wide (global) use of an executable specification. Our teams wrote scripts to test the RTL code against the design recommendations. We were able to detect early on the changes that we needed to make before it hit a critical path.

old account Frank Eory
User Rank
Rookie
re: Bridging the gap between RTL development and design implementation
old account Frank Eory   3/29/2011 5:35:29 PM
NO RATINGS
This new tool, DC Explorer, really fills a gap in the methodology.

KarlS
User Rank
Rookie
re: Bridging the gap between RTL development and design implementation
KarlS   3/29/2011 2:29:57 PM
NO RATINGS
As an old timer, one of the most frustrating things is to have to wait for synthesis and or placement to run first. Early in the design, it is the logic that matters, not whether it has been optimized or whether everything feeds an output pine, else it gets synthesized away. I have proposed to map the HDL into a set of generalized classes to be used in an OOP simulator so the hardware function can be used in the software development environment. This way, the existing IP as well as the new design all come together in a program IDE where the debug and compiler checking is much better than in the hardware design flow. Why not take an evolutionary approach such as what this article suggests without all the uncertainties of HLS? After all when HLS matures and obsoletes HDL that too can be used in a similar way.

Top Comments of the Week
August Cartoon Caption Winner!
August Cartoon Caption Winner!
"All the King's horses and all the KIng's men gave up on Humpty, so they handed the problem off to Engineering."
5 comments
Like Us on Facebook

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Times on Twitter
EE Times Twitter Feed
Radio
LATEST ARCHIVED BROADCAST
David Patterson, known for his pioneering research that led to RAID, clusters and more, is part of a team at UC Berkeley that recently made its RISC-V processor architecture an open source hardware offering. We talk with Patterson and one of his colleagues behind the effort about the opportunities they see, what new kinds of designs they hope to enable and what it means for today’s commercial processor giants such as Intel, ARM and Imagination Technologies.
Flash Poll