This is the time of year where we look back at how we did in the previous year (or decade) and resolve to do better.  With that in mind, I recommend three possible new years resolutions regarding FPGA design and debug.  You don’t need to add all three of these to your flow to see results.  Any one of them will make a big difference:

• Start measuring code coverage before going to the lab—This simple step is the basis for faster lab debug.  Notice that I’m not saying improve the code coverage, I’m just saying measure it.  Get the number, publish the number, and then continue with your work.  You’ll see an improvement in your lab debug time by this simple step.
• Publish a simulation plan before you simulate—Create a list of features in your device under test, and create a list of ways that you’ll simulate them.  If nothing else, you can use the list of features in the lab to make sure you’ve tested all the necessary behavior.
• Add OVL assertions to your design—Assertions check to make sure that your blocks are following their protocols directly, and that the inputs to your design match your assumptions.  They catch bugs earlier in the simulation process, and this cuts debug time in half.

If you add any one of these steps to your design and simulation process, you’ll have a much less stressful 2013.

Happy New Year!

Today I wrote an article for FPGA Journal the explains Focused Expression Coverage (FEC).  Enjoy!

I have an article on eeweb.com this week on State Machine Design.

Enjoy!

Today I started preparation for an article I’m writing for fpgajournal.com on Focused Expression Coverage. I broke out the example code from FPGA Simulation and ran the example from chapter 2, section six.

The simulation hung.

This was puzzling, because it certainly ran when I wrote the book and nobody had mentioned the design hanging. I dug through the design (the TinyCache) and found that the culprit was the signal that signified a cache miss:

assign cpuwait = ((key_ram[cache_address] != cpu_address) || (invalid [cache_address]) ) && cpu_rd;


The signal was always coming out to be X because the key_ram was full of X’s. But this was not right because the invalid register was full of 1′s and 1 OR X = 1. What gives?

The problem was twofold. First there was a bug in Questa 10.0a which is now fixed in Questa 10.0c (and was probably fixed in 10.0b). But the second problem was that I had written unclear Verilog. I had lazily copied the expression on this line from a condition that started like this:

if (((key_ram[cache_address] != cpu_address) || (invalid [ca...


Notice that I had used the || operator in my condition. This is the correct use of that operator. It's a logical OR intended for use inside a condition. However, I had taken that line and copied into my expression. I should have used the | operator in the expression (bitwise OR) like this:

assign cpuwait = ((key_ram[cache_address] != cpu_address) | (invalid [cache_address]) ) & cpu_rd;


When I made this modification, the code ran properly in 10.0a and 10.0c.

The code should have worked either way. The logical || operator and the bitwise | operator should act the same when there is only one bit in the expression. I had definitely caught a bug. But, I wouldn’t have seen the bug if I had written the code more cleanly.

This is a good example of being as clear as possible when you work with EDA tools. There’s no harm in writing it the correct way, and sometimes you can get bitten when you bend the rule.

I designed the transaction methodology in FPGA Simulation to make transaction level communication look like wire level communication. The idea was that you would put the TLM fifos on the port list, just as you do with wires, and you’d be able to use a familiar style in a new way.

Sadly, the Cadence IUS simulator doesn’t support putting references to TLM fifos on a port list (I presume it will in the future). While this news fills me with evil glee since I am a Mentor Graphics FAE, it makes it impossible for readers to use the IUS simulator on the TLM examples in the book. So, I’ve created a solution to the problem for those who have an IUS simulator. The solution also works with Questa.

The key is to note that the references to the TLM fifos are just variables that hold handles to objects. We don’t have to use the port list to communicate that information.  We can use Verilog hierarchical references instead.  So that’s what I recommend.  Here is an example of that coding style from chapter 12.4 in FPGA Simulation:


module top ;
tlm_fifo #(int) fifo;

initial
begin
fifo = new("fifo");
prod.data_f = fifo;
cons.data_f = fifo;
fork
prod.run();
cons.run();
join_none
end
endmodule


You can see that I now explicitly put the handle to the TLM FIFO into the variables in the modules. This approach works with both simulators.

You can download the examples from Chapter 12.4 done in IUS style here.

I’ve just discovered an excellent way to keep up with news in the FPGA/EDA world.  Amelia’s Fish Fry over at www.fpgajournal.com is a funny, irreverent, 10-minute, look at the week’s tech news.  Listening to Amelia’s broadcast is much more rewarding than wading through emails and web pages.

I recently got a question about how to store a test plan in ModelSim and match it to code coverage data.  I’ve uploaded the example to the SystemVerilog examples page.  The example also shows you how to merge code coverage information from multiple tests.

Enjoy, and feel free to post any questions about the example here.

This morning FPGA Simulation was #6 in the Digital Design category on Amazon.  It is the most popular FPGA Development book.  It’s right after:

1. GPS for Dummies
2. Marine Diesel Engines
3. Two-Stroke Engine Repair and Maintenance
4. Digital Integrated Circuits
5. I Got My Kindle!  Now What Can I Do?

A least for this morning, FPGA Designers dominate the list.

This is a nice article about GateRocket.  GateRocket allows you to synthesize your FPGA and place it in an actual part.  Then it stimulates the FPGA using your test bench.

Techfocus Media :: Best of Both Worlds.

If you are creating automatic stimulus using the randomize() method and you need a value to be one-hot, you can use the built in $onehot assertion.  This assertion returns a 1 if the value inside it is a one-hot.  The assertion looks like this:

assert(myreq.randomize() with{
$onehot(onehot_reg) == 1;});


This code will clear all the bits in onehot_reg then randomly set one of them.