Real Time Solutions

History

This Site

Some Comments on Digital Design

Embedded Verification

High Performance Z80

 

PCI Express

UART with BIST

 

People and Connections

 

 

 

History

Real Time Solutions (RTS), a digital design consulting company, was formed in 1990.  It developed processors, caches and memory systems under fixed price contracts.  RTS also developed an inexpensive logic analyzer.

 

Subsequently, RTS merged with a startup to help compose and sell a business plan for fault tolerant storage systems.  While the plan was solid, acceptable financing was never offered.  The principles all obtained other employment.

 

Fast forward to 2004. Real Time Solutions is being resurrected again as a digital design consulting company specializing in front-end ASIC design and verification.

 

We are looking for design work (to pay the bills) and are assisting the open cores community (to highlight our skills).

This Site

Inspiration for this site comes from a number of sources. Perhaps the most important is “Ask The Headhunter”.  We share Nick Corcodilos’ view that the hiring process in this country is “broken”. We have decided to do what we can to help fix it.

 

The specific issue we are addressing here relates to “doing the job”.  The hiring process is far too focused on résumé’s.  Ten or more years of achievement cannot be encapsulated on two pages of paper. We need to find ways for hiring managers to get through the HR filters (with their emphasis on buzzwords) and find people who can actually do the work.  

 

In the software development industry there is a very large public community dedicated to open source software development.  The Free Software Foundation and the Linux Project are well known outgrowths of this community. These communities allow programmers to showcase their skills and network in a focused manner with peers around the world. Therefore, these communities represent an excellent source for finding exceptional programming talent.

 

It turns out that the hardware development industry has a similar community, albeit much smaller: The Open Cores Project.  Open source hardware development has been seriously hampered by the cost of hardware development tools.  Commercial HDL simulators start at around $5,000 and can cost up to $100,000.  Fortunately, full featured and free hardware development tools are becoming available. The gEDA site is a focal point for the development of EDA tools that run under UNIX (and UNIX variants) and conform to the GNU General Public License.  Most importantly for our purposes, free verilog compilers are now available  (Icarus Verilog   and GPL CVER).  It is now possible for anyone with an inexpensive computer to design and verify significant cores.

Some Comments on Digital Design

We are strong advocates of the KISS principle. Simple solutions are the best solutions.  We are also advocates of the notion that design requirements come from the customer.  When customer requirements conflict with the KISS principle, “The customer is always right”.

 

We have Included in this site a couple of free designs.  The common thread in these designs is “Bult-In-Self-Test” or “embedded testbench”.      

 

While we hope these designs will find use in “stand alone” applications, we also hope that some will see the beauty in the simple approach to large system verification embedded in these designs. 

 

That being said, we also recognize that the real problem with SoC verification revolves around a lack of standards for verification methodologies.   If another methodology manages to gain sufficient traction (even if it is only with a specific customer), we would gladly embrace it.  

High Performance Z80

The high performance Z80 (wb_z80) Is our implementation of an 8 bit CISC processor that has been around for a number of years.  This processor enjoys a large body of support in the free software community. Important features are:

 

  • Compatible with standard ASIC bus (Wishbone)
  • Byte instructions execute in a single clock tick
  • Clock frequency limited only by internal SRAM access speed
  • Full software compatibility with z80
  • Embedded and complete verification suite
  • Documented to Standards set on the Open Cores site

 

This processor is in development using facilities and tools provided by the Open Cores site:

 

     Wishbone High Performance Z80: Overview   

 

 

You may also download a snapshot of the processor and testbench from this site:

 

wb_z80.zip

 

This snapshot represents a “reasonably” complete design.  A very good instruction test has been successfully executed.  The test has been augmented to verify interrupt operation.  However, the verification plan has not been written, and a number of planned tests have not been completed.   An FPGA build of this snapshot is probably quite appropriate – use in a large SoC project is premature.

 

If you download the zip file check the readme.doc file first.  It gives a general Idea about what is included and how to build the testbench.

UART with Built In Self Test

The General Problem

The impetus of this project has been problems that the author has experienced with “re-usable” cores in some of his recent ASIC design work.  The scenario has been (we suspect) not atypical:

 

A large complex core was developed and tested (to a very limited extent) on a small test-bed and immediately integrated into a complex test-bed for one of the target ASICS. In this new test-bed, more significant testing occurred. Bugs were found and fed back to the core developers.  In the meantime, the “re-usable” core was integrated into new target ASICS. The new ASICS used different test-beds and different test methodologies.  The process of integration into new ASICS exposed new requirements as well as new bugs. Inevitably the core was modified in ways that make it incompatible with the original ASIC  (in which it had becme fully validated). 

 

This created a dilemma, as there were now multiple branches of the code tree for the “common core” and no common method available to fully validate all code branches.  

 

We stumbled on a very similar issue with the “core” selected for this project.  The designers implemented a nicely documented core and test-bench.  They did some simple testing on that test-bench (which is included in the core documentation) but then apparently did more complete testing on a SoC test-bed – and subsequently, significant testing in real hardware. Unfortunately, there is no easy way to run the complete verification in the “simple” test-bed.  Thus the actual verification suite is unavailable to a potential user of the core.

 

The Solution

Our solution is to integrate the “simple test-bench” into the core, use the simple test bench for complete functional verification and maintain a single core, test bench, and verification throughout all modifications.

 

The purpose of this project was to demonstrate in a simple case how this might work in practice.

 

From a perspective of the design modules, the implementation was changed by the addition of a single “BIST” module below the top level module where it could be conditionally conditionally compiled. 

 

 

 

 

 

 

 

 

 

 

 

 


The “Built In Self Test” module is written in RTL that could be synthesized. We honestly don’t have strong feelings about this. However, there are clear advantages to RTL code here. As logic becomes less expensive, the downside to synthesizing the BIST becomes negligible. 

 

The BIST module itself is a simple 64 state linear sequencer with a 14 bit “test  vector” output.  The test vectors implement wishbone writes, verifies, and sense type instructions. 

 

Results

It was anticipated that the 64 state sequencer would be sufficient to obtain verification with close to 90% code coverage.  While we do not presently have access to coverage tools (and so cannot validate our expectations), the general feeling is that coverage is below the goal - but could be extended above it with careful coding.  The size of the test could of course be easily doubled to 128 states.  (Spare states are mandatory as the approach assumes modifications and maintenance.)

 

We did find at least one “bug” in the core. There was also behavior we did not expect. We call unexpected behavior “issues”. Bugs and issues are listed in the header of the uart_bist.v file in the documenatation package.

 

Documentation Package

The documentation package is available as uart.zip on this web page. Of interest are the test_plan.txt files (in the docs directory) and particularly the uart_bist.v file (in the rtl directory).

 

PCI Express

The PCI Express project started as a very high end PCI Express commercial core with up to 8 lanes, 8 virtual channels, and support for almost all optional features.   When the coding for this core was mostly complete, it became clear that the verification effort would be not only very expensive, but also very time consuming.  

 

Accordingly, the approach has been scaled back considerably.  A free core will be coded without most optional features.  That will be made available to all on Open Cores.   Hopefully there will be enough interest that we can get the design verified in hardware.

 

The project has been started on Open Cores.   Progress can be tracked there. 

http://www.opencores.org/projects.cgi/web/pci_express/overview

 

People and Connections

 

B.J. Porcella

 

 

B.J. Porcella started his career as a design engineer in the mini-computer industry during the 1970’s. In the next decade he held positions as V.P. of engineering at a number of small companies involved with computer architecture. More recently, he has been designing ASICS.

 

(see resume) 

 

For information or comments about this site contact:

rts_asic@sbcglobal.net