Frontier

Eclipse Continues to Evolve

Yesterday's EET article today by Richard Goering on Eclipse may have slipped by you. As you may already know, the Eclipse platform supports our LatticeMico32 processor tools, which are often intended for embedded systems applications.

The EET article covers the release (actually three releases) of the Eclipse DSDP "Device Software Development Platform" program.  In a nutshell, the DSDP program is extending the Eclipse open source development environment to make it more suitable for embedded systems development.

Eclipse was originally designed for enterprise systems which don't concern themselves with common embedded systems issues such as communicating with and controlling multiple processing targets.

One of the specific items I was happy to see in the announcement was native support within Eclipse for working with Linux running on a remote embedded target.

Eclipse is open source in a manner which encourages commercial development (the EPL license). Eclipse holds the promise of creating a common development framework that we can all benefit from:

• Reducing the cost of development
• Speeding the release of new products
• Giving a similar look and feel across different toolsets
• Protecting proprietary content

This announcement is very good news as it shows the considerable development momentum that Eclipse has, and that it is going in a good direction for FPGA based embedded systems.

Webcast on open source soft processor for FPGA

It's been a very busy week for me at Lattice, but I wanted to take a moment to tell you about an event you might want to check out on Wednesday.

Wednesday: Free LatticeMico32 Webcast on Open Source, Free Soft Processor
On Wednesday, October 18th, we will be hosting a LatticeMico32 webcast. I was involved in helping to define and launch this 32-bit soft processor that is targeted for FPGAs. Our presenter will be Amr El-Shimi, from the IP marketing group. It’s a free webcast, and you can sign up at the above link. There will be a giveaway of an ispLEVER design software package as well.

If you do get a chance to attend, please let me know what you thought about the webcast. And as I mentioned in my last blog post, I'm still interested in your thoughts on using a soft processor within an FPGA.

Soft processor within an FPGA

As our recent announcements of the LatticeECP2M and LatticeMico32 products show, a lot has been going on at Lattice.  The LatticeMico32 soft processor has been a significant project for the SW tools group.  Kevin Morris' FPGA Journal article has a good summary of this product.

This soft processor was developed to address two long term trends:
1)   As the cost/gate of FPGA continues to drop, and the size of a design which can fit in an FPGA grows, there will be an increasing economic incentive to include a processor within the FPGA.
2)    A soft processor combined with the programmable logic fabric is a practical testbed for HW/SW co-design.

A lot has been written about HW/SW co-design: moving functionality between SW and HW to maximize performance/cost ratio. However, it has been mostly up to the user to cobble together the various tools to see if they can get HW/SW co-design to work.  In my opinion, this has resulted in the slow adoption of solutions, as I noted in my previous blog.  FPGA vendors are in a unique position to accelerate solutions in this area, perhaps heralding a truly new era of system design.

From the ground up, the LatticeMico32 flow was built to synchronize the HW and SW development work.  A key benefit of implementing a processor and its mix of peripherals (we use the SoC industry term "Platform" for this) in a programmable logic fabric is that the HW/SW interface can be flexible.  Functions can be added or deleted, the communications architecture can be tuned etc.

However, this additional flexibility should be offered without burdening the HW and SW developer with additional housekeeping.  This is a primary goal of the LatticeMico32 System tools, and is the cornerstone of co-design support.

I'd be interested in your thoughts on using a soft processor within an FPGA.  What do you believe are the reasons for using a soft processor, and how do you think they will, or will not, be adopted within your industry?

Formal Verification Usage with FPGAs

In a recent survey of FPGA designers on EDA tools done by EE Times, I noticed a considerable drop (almost 50%) in the use of Formal Verification (FV) between 2005 and 2006.  At the same time, they predict their usage will increase in the future.  I attribute some of this drop to the design methodology change required to get the potential benefit from FV.

A good presentation from Harry Foster, ex-Jasper, current Mentor, describes why methodology is important.  Use in the FPGA design flow will continue to creep up as previous ASIC designers move to FPGA design (and bring their FV experience with them), and design complexity continues to expand while schedules don’t.

As design complexity increases, the percentage of total design time spent on verification increases.  Common estimates are that design verification exceeds 50% of the design time. 

Traditional ASIC verification has relied heavily on simulation where test stimuli are fed to the design, and the output is checked for correct results.  Simulation has become much more common in the FPGA verification flow as well, although because of the re-programmable fabric, the FPGA designer has more chip-level options – for example using an internal FPGA logic analyzer such as Xilinx’s ChipScope™ or Lattice’s ispTRACY™ products.

All verification techniques have their pros and cons.  As more time is spent in simulation, the coverage improves at a slower rate.  Moreover, the best that simulation can tell a designer is that, “no bugs have been found yet”, rather than the much more useful, “this design is correct”.

Formal verification is a technique that takes a very different approach to verifying a design.  It also has its pros and cons, but the consensus is that that Simulation and Formal Verification are very complementary.  Together, they have the potential of giving the highest verification coverage in the fastest time (lowest cost).

Formal verification relies on “rules” that have been defined by the user that characterize how the design should behave – the so-called design intent.  For example, in a bus protocol, if bus signal A should never be high two cycles after bus signal B goes low, this can be captured as a rule.  These rules can be checked in two fundamental ways:

• Dynamic or Simulation Based: while the design is running in simulation, the rules are checked for any violations.
• Static: through formal analysis of the netlist, counter-examples are created which show how a rule can be violated.  If this counter-example was run through a simulator, the violation could be observed.

Both dynamic and static FV approaches are used in Assertion Based Verification (ABV).  Like a simulation testbench, the FV rules have to be created by the design or verification engineer.  Two rule languages have emerged:

• SystemVerilog Assertions (SVA) are part of the SystemVerilog language, and can be a powerful method for designers to capture and formally document their design intent during design entry.
• PSL is more HDL language neutral, and has additional support for more advanced formal verification techniques.

A paper comparing the two languages can be found at: http://www.pslsugar.org/papers/pslandsva.pdf

Formal verification is not new, and its general adoption has been slow.  Certain designs that have high concurrency and lower sequential depth (e.g. processors), are ideal for formal verification and the technique is commonly used.  A few rules can accomplish much more than many simulation test vectors.

However, the fact that simulation and formal verification are complementary requires the user to know how they are going to apply the two techniques.  This requires much more upfront planning, expertise in rule generation, and basically adopting a new design methodology.  That kind of thing doesn’t happen overnight.

Why FPGA will jumpstart shift toward ESL

Hello, I'm Mike Kendrick.

I am the guy who writes the requirements for the SW design tools .

Given the scope of the FPGA design flow, as you would expect, I don’t do this by myself. I also don’t do it in a vacuum. My main objective of writing this blog is to spark some conversation with designers on some of the current directions that FPGA based design could and should go.

Historically, FPGA design flow has been in the wake of the ASIC design flow. As they say, “Today’s ASIC designer issue is tomorrow’s FPGA designer’s issue”. That is not entirely true as many of these issues are addressed with the design of the FPGA chip itself. For example, a designer using an FPGA has a low skew clock tree available as a feature of the FPGA, but they have to build that as part of their ASIC development (and thus, there are tools in the ASIC flow which enable this).

But many design challenges faced by a designer targeting FPGA were first encountered by the ASIC designer. I would expect that basic trend to continue, and we will continue to look at the design issues in the ASIC world for our planning. I am extremely interested in designer’s thoughts on what issues they have or anticipate emerging.

I also see where the FPGA designer will face issues that were not faced by the ASIC designer. These relate to FPGA applications that for various reasons were not ASIC applications. ASICs are characterized by high fixed costs to get the first chip built, and design changes are costly. ASIC is not a technology that lends itself to experimentation, unless that experimentation can be accomplished solely through software running on the ASIC. FPGAs are now big enough where they can be used unlike an ASIC could realistically ever be used. For example – ESL.

ESL stands for Electronic System Level, and I think was originally coined by Gary Smith at Gartner/DataQuest. It’s a term that has been applied to many things and many products (by many marketing people). My personal definition of it is, “the thing which is the next abstraction after RTL”. It’s not taking a big risk to forecast that a design paradigm will eventually emerge that will be at a higher level of abstraction, thus allowing mere humans to design even more complex systems. This has been the inevitable march of engineering (remember schematic?).

The basic promise of ESL is that it would allow designers to describe the function of their system, and design automation tools would convert that to an implementation. Some tool flows were developed (e.g. CoWare, Cadence SPW, Synopsys CoCentric Studio) and targeted at the ASIC designer. However, given the economics of ASIC, all the experimentation with implementation had to be done in simulation. Other than being slow, this also created a need for simulation models which take time and resources to develop.

FPGAs can go after the ESL problem with quite a different paradigm. Different system implementations can quickly be evaluated in-system to analyze system throughput. Given their size, it’s now possible to see the system-level results of making system level changes such as: moving functionality between the SW and HW, changing the communication structure (e.g. shared bus vs. point-point). In my mind, FPGA is a much better technology for realizing the potential of ESL. A potential hurdle to progress is the size of the available pool of engineers which have the system level expertise to work with both HW and SW in their chip implementation.