World's 1st FPGA/CPLD Portal

One of the most common questions that programmable logic designers face today is how to connect unique, disparate modules in their system.  That is to say, “Block A needs to talk to block B and vice versa. What bus should I choose?”  There are a plethora of choices that the designer can choose from, but what most designers really need is a proven, simple-to-connect bus interface without the overhead of many proprietary bus interfaces.  Enter WISHBONE.

In case you’ve not heard of WISHBONE, it’s a popular, open source hardware interface that is promoted by the OpenCores project (http://www.opencores.org).  Being open source offers several advantages for programmable logic designs:

Open source designs:  The OpenCores project is the web’s main proponent of the WISHBONE architecture.  In addition to its role as WISHBONE advocacy, the OpenCores website offers many grass-roots built RTL modules that are available for users in both Verilog and VHDL, many of which are of course, WISHBONE ready.  This means that a designer can attach their own WISHBONE design to one or several of these OpenCores designs, saving development time on both core functionality and bus connectivity.

Flexibility: Perhaps the most subtle advantage of WISHBONE is its flexibility.  Unlike most bus system, WISHBONE can be implemented as any one major bus types including hierarchical, point-to-point, or many-to-many.  In addition, a WISHBONE bus can be multi-master or single master and can be 8, 16, 32, or 64 bits wide.  The net effect of this flexibility is that WISHBONE is appropriate for programmable logic designs of almost any complexity.

Proven:  The WISHBONE interface is a well-defined standard, has been around for more than six years and has been implemented in hundreds, if not thousands of systems.  If you want a flexible, but low-risk bus architecture, WISHBONE fits the bill.

The Price: “The WISHBONE standard is not copyrighted, and is in the public domain. It may be freely copied and distributed by any means. Furthermore, it may be used for the design and production of integrated circuit components without royalties or other financial obligations.”

Lattice and WISHBONE:

Lattice believes in the WISHBONE credo and has several resources for Lattice users:

LatticeMico32:  This is Lattice’s own 32-bit “soft” microprocessor.  It has a native WISHBONE interface and is free with an open IP core licensing agreement.  The power of the LatticeMico32 lies not only in the flexibility of the core itself (it’s synthesizable), but also that it can be connected to any WISHBONE peripherals including open source cores or your own, custom logic.

Reference Designs: Lattice offers several freely downloadable WISHBONE reference designs as a starting point for user designs.  These reference designs come complete with documentation, RTL, and testbenches.  WISHBONE modules include an I2C bus master, a SPI controller, and a LatticeMico8 WISHBONE adapter.  Again, since they are WISHBONE, these reference designs can be combined with OpenCores designs or a LatticeMico32.

System Examples:  Our successful MachXO Mini Evaluation Board comes with a native demo (“Mini SoC Demo”) that illustrates the WISHBONE bus in a working system. This demo includes our 8 bit LatticeMico8 soft processor, a UART, an I2C master, and a SPI memory controller, all connected on a WISHBONE bus.  A Lattice user can examine the WISHBONE bus connectivity by downloading the RTL and documentation for this demo at our MachXO Mini Development Kit website. At this website, find the “Demo Applications” button under “MachXO Mini Development Kit Resources” at the bottom of the page.  You can also view a video of the demo or experiment with it yourself by purchasing the board from the MachXO Mini Development Kit website.

Board design engineers are faced with a dilemma for each new microprocessor based system design that they encounter: how to integrate more processor power management function with the least amount of risk. How can we implement voltage monitoring, reset generation and watchdog timers while as few components as possible, while at the same time, keeping a shorter development cycle?

Rather than taking a traditional approach to assessing the tradeoffs, I’d suggest that we need to carefully consider the two most critical definitions:  What does “integration” mean and what does “risk” mean?

In board development discussions, integration usually means reducing the number of components on your board by bringing as much function as possible into as few components as possible.   Likewise, risk is commonly associated with the complexity of the board that you are bringing to market.

I propose that the most accurate definitions of risk and integration imply both a physical aspect and a process aspect.  That is to say, risk can be quantified not only from the physical complexity of a board, but also with the complexity of the process that brings the board to market.  In the same way, integration can mean not only a reduced BOM (bill of materials) but also a simplified development process.

Whether risk and integration complement each other or not depends on how they are combined.  Higher levels of power management integration can bring more risk if the new solution is unproven.  On the other hand, higher levels of integration can actually reduce risk if new parts actually simplify the processes that are required to bring the board to market. The right balance is achieved when we can find new power management solutions that not only increases integration, but also reduce the risk.

The mission of the ProcessorPM POWR605 is to do just this.  That is, to reduce complexity and risk not only in terms of the physical board itself, but also in the process that brings it to market.   The ProcessorPM reduces the physical complexity of a processor power solution by bringing voltage monitoring, processor reset and watchdog timer functionality all under one roof.  Higher integration and a reduced BOM translate into lower risk.

The ProcessorPM comes with a tested and pre-programmed, factory configuration. The factory configuration integrates voltage monitoring for 5V, 3.3V, 2.5V and 1.8V supply monitoring with a CPU reset and watchdog timer interrupt output generation.  Although the user can change the programming, there is no need to do so if the default functionality suits their needs.  All they need to do is include ProcessorPM into their schematics and select the appropriate strap values to set watchdog delays and reset pulse stretching.   This simplifies the development flow and reduces risk by eliminating the need to develop and test a new configuration.

Integration and risk will continue to be factors in the ever advancing pace of microprocessor based systems.  The savvy engineer will continue to look for ways to optimize both for their system power management.

In the book FPGA Simulation, I showed you how to use the ovm_top object from the OVM library to control messaging. The OVM allows you to control the verbosity of your messaging, and the actions that occur with each message.

However, using ovm_top can create a lot of typing. Consider the following simple message:

ovm_top.ovm_report_info($psprintf("%m"),"This is a simple message);

The only interesting part of this message is “This is a simple message” the rest is just extra typing. The $psprintf(”%m”) does nothing but create a string with the module path (we discussed $psprintf in another post) and the message is just a string.

Or consider a longer error in which you want to show the file and line number from the message:

ovm_top.ovm_report_error($psprintf("%m"),$psprintf("Bad data: %h",data),,`__FILE__, `__LINE__);

In that example everything but the second call to $psprintf was repeated every time you wrote an error message. This is silly!

Fortunately, SystemVerilog has a solution to this problem. Because SystemVerilog uses a preprocessor, it is able to implement macros.

Macros are text replacements that occur just before your compiler starts reading code. You can define macros anywhere, and then use them to reduce your typing.

For example, say you wanted to stop typing “$psprintf(“%m”)” every time you needed a string with the module path. Because that code is identical every time you type it, you could use a macro.

`define mod $psprintf("%m")

Notice that you define macros with the backtic and then the word “define” The macro definition all has to be on one line. Everything after the macro name is part of the macro. You can break a macro into multiple lines with the “\” continuation character.

Now you can use the macro in your message call:

ovm_top.ovm_report_info(`mod, "My message",,`__FILE__, `__LINE__);

You used the mod macro by typing backtic “mod”. Notice that the __FILE__ and __LINE__ arguments are also macros. The SystemVerilog compiler automatically defined them and fills in the appropriate information.

Using `mod is only a slight improvement over typing the entire call to a messaging routine, so let’s solve the whole problem by taking advantage of the fact that macros can accept arguments. When we pass an argument to the macro, we are telling it to place the argument string in the macro at the appropriate places.

For example, let’s fix our call to ovm_report_error to make it easier to use:

`define error(msg) ovm_top.ovm_report_error($psprintf("%m"),msg,,`__FILE__, `__LINE__);

Now we can print an error message like this:
`error ("This is an error, we are getting close to fatal");
This gives us the following message:
# OVM_ERROR macros.sv(17) @ 0 [top] This is an error, we are getting close to fatal

Now it’s easy to create `info, `warning, and `fatal as well. You can see examples of all of these on the FPGA Simulation forums.

When we create a large test bench we want to have access to all our macros without typing them into every file. We can do that with a common include file. I usually call my include file “defines.svh”. Then I put a `include at the top of every file like this:
`include "defines.svh"
import ovm_pkg::*;
module top;
...

This way you can keep all your macros in one place, and that makes it much easier to use them throughout your test bench.

Here are some more I/O specific techniques for static consumption. Try reducing the switch capacitances and frequencies of I/Os, decouple I/Os when you're in the sleep mode.

read more

SystemVerilog is becoming the defacto standard for test bench creation, even in cases where the DUT is VHDL. As more and more IP becomes available in SystemVerilog, even hard core VHDL engineers will need to have at least a passing aquaintance with the language.

With that in mind, I’ve created a primer that teaches the basic concepts and syntax in SystemVerilog in terms of VHDL. Here it is:

A SystemVerilog Primer for VHDL Coders.

This morning I attended Mentor Graphics’s webinar about FPGA Synthesis, by Roger Do and Robert Jeffery.

Synthesis is a stage in the design flow that I personally give a lot of attention to the reports and the constraints. I am always excited about Synthesis. It is a moment that the designer and the synthesis tool share a bond. The webinar was fine and the key items covered were

• Register retiming
• Resource sharing
• Physical-aware synthesis
• Incremental synthesis
• Interconnect delays

From my perspective, the webinar was not too FPGA oriented as the webinar’s title suggested but covered common elements that one will also encounter in ASIC design. I was hoping to learn more about extra features that a third-party EDA vendor might provide that the FPGA providers don’t.

At the end, I asked a question about how the TCL scripting commands/arguments. From my point of view, the more there are tools from different vendors in a design flow the more complex is to automate the flow by scripting. Hence I wanted to know more about how the learning curve is when scripting with a third-party synthesis tool for FPGA design. My question was taken as what are the benefits of scripting, but not how difficult would it be for learning different commands/arguments from different vendors which do more or less the same task.

However, I really enjoy the webinar and thank MentorGraphics for their bi-weekly webinars. I am looking forward for the next webinar about CDC (Clock Domain Crossing).

I also participated in their poll. One of the questions on the poll was about which vendor’s FPGA I am using. I am always impressed to see in such poll that 2/3 of the participants choose Xilinx’s FPGA over Altera’s FPGA. I have not yet understood the reason behind it. One of the reasons I would choose Altera’s FPGA is because their constraints are in the SDC format, whereas Xilinx uses its own. It reassures me about the certainty of the constraints I want to apply. Hence,this ensures a quicker prototyping for a junior ASIC guy like me who visits the FPGA world.

We are seeing a mixed lot of news in chip-land for semiconductor stocks this morning, but the news we have seen so far looks like it is getting the week off to a more stable start for the chip sector. We have news from Intel Corp. (NASDAQ: INTC), Marvell Technology Group Ltd. (NASDAQ: MRVL), Altera Corp. (NASDAQ: ALTR), Power-One, Inc. (NASDAQ: PWER), and Texas Instruments (NYSE: TXN).

Citigroup said that it sees margins improving at Intel Corp. (NASDAQ: INTC). The firm reiterated a buy rating on the world’s largest chipmaker, raised estimates for 2009 and 2010 by almost 10% and boosted its target price up $1.00 to 21.00. Intel shares are actually flat to down a couple pennies in early indications.

Marvell Technology Group Ltd. (NASDAQ: MRVL) is trading higher after the chip design firm raised second quarter revenue guidance to $600 million to $630 million from $540 million to $580 million. The hike is due to broad improvement in demand within multiple markets. It even expects some profit in the quarter. Shares are up almost 3% at $12.35 in early trading.

Altera Corp. (NASDAQ: ALTR) caught an upgrade. RBC Capital Markets raised the rating to an “Outperform” from “Sector Perform” this morning and raised its target to $20.00 from $16.00.

Power-One, Inc. (NASDAQ: PWER) is trading up 4%, ($1.00+ stock though) after the company announced a patent license With Texas Instruments (NYSE: TXN). This is a non-exclusive ‘Field of Use’ agreement to license Power-One’s digital power technology patents to TI.

Jon C. Ogg
June 22, 2009

This article provides an overview of the sources of FPGA power dissipation, design practices that can help reduce consumption and thus junction temperature, how to estimate and analyze power, and then some tips for managing a variety of power sources required for an FPGA implementation.

read more