Customize the ModelSim Wave View in the Xilinx ISE Simulation

When ModelSim is automatically lunched within the ISE environment it  just displays the top entity level signals in the Wave View window. However, to either facilitate debugging tasks or check specific behavior of lower level components most of the time internal signals also need to be displayed in the Wave View window of ModelSim. Moreover, coloring, ordering and grouping signals  is especially useful in complex designs. Hence, having one or several custom views and invoking them automatically will help the verification job.

Scripts files (.do) created in ISE

When ModelSim is launched from the Xilinx ISE, Project Navigator automatically creates a .do script file that contains all of the necessary commands to compile the .vhd  source  files, load, start  and run the
simulation in ModelSim.
The .do script file created by Project Navigator has different extensions based on the type of simulation launched. For instance, for a Behavioral (functional) Simulation these are the three files created:

<TestBenchName>.fdo           ModelSim commands for behavioral simulation
<TestBenchName>.udo           ModelSim user commands
<TestBenchName_wave>.fdo  ModelSim Wave window format commands for behavioral simulation

A detail of the ModelSim commands in a <TestBenchName>.fdo script file created by Project Navigator, when running a Behavioral Simulation, is described below:

The <TestBenchName>.fdo script file is regenerated each time a behavioral simulation is launched. Therefore, any modification done in this file will be automatically overwriting. Still, in this script file there is a command line, do{<TestBenchName_wave>.fdo}, that invokes the <TestBenchName_wave>.fdo script file. This script file never is neither modified nor overwritten by Project Navigator. Hence, the best file that can be used to customize the Wave window format in the ModelSim environment is the <TestBenchName_wave>.fdo script file. By default, this file has the following structure:

The ‘add wave *’ command means that, by default, all the top level entity signals will be displayed in the Wave view of ModelSim. Likewise, when running simulation after translating, mapping or PAR processes, similar script files are created. A detail of the script files created in each process is showed below:

Simulation Post-translate
<TestBenchName>.ndo            ModelSim commands for post-translate simulation
<TestBenchName>.udo            ModelSim user commands
<TestBenchName_wave>.ndo  ModelSim waves format commands for post-translate simulation

Simulation Post-Map Process
<TestBenchName>.mdo ModelSim commands for post-map simulation
<TestBenchName>.udo ModelSim user commands
<TestBenchName_wave>.mdo ModelSim waves format commands for post-map simulation

Simulation Post-PAR
<TestBenchName>.tdo ModelSim commands for post-par simulation
<TestBenchName>.udo ModelSim user commands
<TestBenchName_wave>.tdo ModelSim waves format commands for post-par simulation

In general, the script file <TestBenchName_wave>.*do will be the file to be modified to customize the Wave window in the ModelSim environment in any of the different simulation cases. As it was detailed above, the “add wave *” command states to display just the top level entity signals. However; to facilitate debugging tasks most of the time internal signals also need to be displayed in the Wave window. Moreover, coloring, ordering and grouping the signals in the Wave window is especially useful in complex designs.

Customization Process

The process to customize the Wave window in ModelSim when running the simulation flow in Xilinx ISE environment is detailed below:

1) Create a new ISE project or just open one already created. Write your VHDL code, create your test bench and execute either the functional, post-translate, post-map or post-par simulation of your design, which will open ModelSim simulation tool.

2) Within the Wave window, ModelSim offers several methods to customize the view.

• Adding internal signals: in the Instance view of ModelSim (left most pane) you can find the test bench name and underneath it, you can see the instance name of the entity under test. The instance name is actually the label used in the instantiation of the top level entity in the test bench. Click over the ‘+’ symbol to be able to see all the unit components of the top level entity. Then, select the unit that holds the signals you want to add to the Wave window by single click over the unit’s name. After that, on the Objects window (usually the window in the middle) the name of the signals of the selected unit will be displayed. Select the signal you want to add to the Wave window by single click over it, then drag and drop the signal into the Wave window. You can repeat this process and add as many signals as needed. Once a signal is added to the Wave window, you can move it up or down as explained below.
• Moving signals: it is also possible to move either up or down the signals displayed in the Wave window to facilitate reading the waveforms. For instance, you can place all the input signals on the top of all the other signals, then the control signals in the middle and the output signals at the bottom. To move up or down the signals in the Wave window, select the signal you want to move (single right-mouse click over the signal). Then, drag the signal up or down, by keeping the right-mouse button pressed and moving the mouse up or down, and drop the signal, release the mouse button, wherever you like.
• Adding dividers: signal dividers can be added in the Wave window to label the signals grouped with a specific purpose. For instance, you can add dividers labeled Input Signals, Control Signals, Rx Signals, Memory Read, Clocks, and such. To add a divider select the signal over which you want the divider. Then, right-mouse click and select ‘Insert Divider’ from the down menu. The divider dialog window will come up. You can add a name describing the function of the signals that will be under the divider. You can also set the Divider Height, though this is not usually changed.
• Coloring the waveform: for some specific purposes, for instance for a quick waveform reference among hundreds of waveforms, it is advantageous to change the color of a specific waveform as well as the color of signal name. Highlight (select) the signal that you want to change the waveform color, then right-mouse click and select Properties, the Wave Properties window should come up. In the View tab, you will find the Wave Color and Name Color selections. To change the default colors, click on the Colors button and select the desired color. When finished, click on Apply.

3) Once you are done adding signal, dividers and changing colors, it is then necessary to save this new customized Wave window format to be able to use it again:

• Be sure to select (highlight) the Wave window among the other ModelSim views.
• Go to File -> Save Format. Then, click OK in the Save Format dialog window to save the new wave format in the default directory (ISE project directory) or in the directory you would like by browsing to it. The default name is wave.do. In case you are planning to have a customized wave view for the different simulations (like functional, post-map, post-PAR), change the default wave.do name to something like wave_f.do for functional, wave_m.do for mapping and so on for the other type of simulation.

4) Go back to the ISE Project Manager window.

5) There are a couple of options to load automatically the saved wave.do file (item 3.b) when running a simulation from Project Navigator. As it was explained before, the easiest way is to modify the <TestBenchName_wave.fdo> file. Hence, open to edit the <TestBenchName_wave.fdo> file that resides in the ISE Project Directory. Remove or comment out (by using the # character) the command line “add wave *” and then add a new command line that will invoke the customized waveform; by writing “do wave.do” (or whatever name you use when saving the Wave window format). If you have saved the wave.do file in a directory different than the ISE Project Directory, you will need to write the complete path where the file wave.do resides. Below, there are two examples of how the <TestBenchName_wave.fdo> file would look like, one for a complete directory path, and the other with a relative path:

Once finishing with the modifications, save the customized <TestBenchName_wave.fdo> file.

6) From now on for every behavioral simulation to be executed, Project Navigator will use the custom wave.do waveform format when launching ModelSim.

Even though it has been explained the process to customize the behavioral simulation, similar steps have to be followed, for instance, for customizing the post-place and route simulation. The file to be changed in this case is the <TestBenchName_wave>.tdo (as it was explained before) and just follows all the steps detailed above for the behavioral simulation.

More on Customization
Besides of modifying the <TestBenchName_wave.fdo> file for customizing the Wave window format, another ModelSim commands can also be added with other purposes. For instance, one useful command for designs with a large amount of internal signals is the following: log –r /*

This command will log all the data objects in the design. For example, if after running the simulation you find out you would like to see an internal signal not currently displayed in the Wave view, you just need to select the signal you want to add, drag and drop it in the Wave view. Then, its respective waveform will immediately be displayed.

Without the log command, if that particular internal signal is not in the list of signals in the wave.do script, it is not logged; therefore no waveform will be displayed for that signal. In this case, it will be necessary to add the signal to the Wave window, save the wave.do again and then rerun the simulation.

The drawback of the log command is that it could make the simulation much slower since it needs to log all the signals of the design. One point to keep in mind is the fact that internal signals after PAR usually do not keep the same name as before the PAR. This means that the wave.do saved for functional simulation, may or may not be able to display all the internal signals when doing a post-PAR simulation.

One solution for this problem is to create another customized wave.do for the post-PAR simulation naming it something like wave_par.do. Then, change the <TestBenchName_wave.tdo> file as explained in point 5 above. Another helpful point to know is the fact that it is possible to rerun the simulation without closing ModelSim, avoiding returning to Project Navigator.

For instance, if you find an error when running the simulation in one of the .vhd source files, you can edit the VHDL file, still keeping open ModelSim (even you can use ModelSim text editor), save the modifications of the VHDL file and rerun the simulation by typing do {TestBenchName.fdo} and pressing enter in the transcript window (bottom window) of ModelSim. You can also use the up-arrow key in the transcript window to go through all the executed commands until you find the do {TestBenchName.fdo} command, and then just press enter to execute it.

Get free daily email updates!

Follow us!

Tips for Implementing State Machine

At a low level of abstraction, a protocol is often most easily understood as a state machine. Design criteria can also easily be expressed in terms of desirable or undesirable protocol states and state transitions. In a way, the protocol state symbolizes the assumptions that each process in the system makes about the others. It defines what actions a process is allowed to take, which events it expects to happen, and how it will respond to those events.

The Xcell Journel Issue 81 gives some important tips on implementing state machines in your FPGA

Link to Xcell Journel issue 81

Get free daily email updates!

Follow us!

A Brain-On-A-Chip

Sounds Interesting !!!!!

The idea is to devise a “micro-environment’’ that mimics the human brain. Researchers hope to study neurodegenerative conditions such as Alzheimer’s disease, strokes and concussions. The eventual goal is to study the effects of drugs and vaccines on the brain.

Draper, a spinoff from the Massachusetts Institute of Technology (MIT), and USF are using embryonic cells from rats, but researchers plan to use human cells in the future. The brain-on-a-chip combines several technologies, including an emerging field called microfluidics.

Microfluidics deals with the control of fluids in devices. Tiny chip-like devices using microfluidics are used in many applications, such as cell sorting and detection, gene analysis, inkjet print heads, lab-on-a-chip units and point-of-care diagnostic tools. Meanwhile, lab-on-a-chip, and a related field, organ-on-a-chip (i.e. brain-on-a-chip), are systems that integrate various functions in a chip-like format. Some, but not all, lab-on-a-chip systems use microfluidics.

Read More >>

Get free daily email updates!

Follow us!

Verilog and bit shifting (‘<<' and '>>’): Don’t push your luck

In Verilog there’s a bit shifter operator, which isn’t used a lot, since FPGA designers prefer to state exact bit vectors. But sometimes bit shifting makes the code significantly more readable. Too bad that Xilinx’ XST synthesizer doesn’t get it right in a specific case.

Namely, the following statement is perfectly legal:

always @(posedge clk)
  reduce <= 1 + (end_offset >> (6 + rcb_is_128_bytes - format_shift) );

But it turns out that Xilinx ISE 13.2 XST synthesizer gets confused by the calculation of the shift rate, and creates something wrong. I can’t even tell what it did, but it was wrong.

So the rule is simple: It’s fine to have the shift number being a register (even combinatoric) or a wire, but no inline calculations. So this is fine:

always @(format_shift or rcb_is_128_bytes)
  if (rcb_is_128_bytes)
    case (format_shift)
      0: shifter <= 7;
      1: shifter <= 6;
      default: shifter <= 5;
    endcase
  else
    case (format_shift)
      0: shifter <= 6;
      1: shifter <= 5;
      default: shifter <= 4;
    endcase

always @(posedge clk)
  reduce <= 1 + (end_offset >> shifter );

(assuming that format_shift goes from zero to 2).

Actually, I would bet that it’s equally fine to calculate the number of shifts and put the result in a wire. I went for the case statement hoping that the synthesizer will take the hint that not all values that fit into the registers are possible, and will hence avoid implementing impossible shift values.

Needless to say, I know about this because something went horribly wrong all of the sudden. I believe XST version 12.2 handled the shift calculation OK. And then people ask me why I don’t like upgrades.

Verilog and bit shifting (‘<<' and '>>’): Don’t push your luck

In Verilog there’s a bit shifter operator, which isn’t used a lot, since FPGA designers prefer to state exact bit vectors. But sometimes bit shifting makes the code significantly more readable. Too bad that Xilinx’ XST synthesizer doesn’t get it right in a specific case.

Namely, the following statement is perfectly legal:

always @(posedge clk)
  reduce <= 1 + (end_offset >> (6 + rcb_is_128_bytes - format_shift) );

But it turns out that Xilinx ISE 13.2 XST synthesizer gets confused by the calculation of the shift rate, and creates something wrong. I can’t even tell what it did, but it was wrong.

So the rule is simple: It’s fine to have the shift number being a register (even combinatoric) or a wire, but no inline calculations. So this is fine:

always @(format_shift or rcb_is_128_bytes)
  if (rcb_is_128_bytes)
    case (format_shift)
      0: shifter <= 7;
      1: shifter <= 6;
      default: shifter <= 5;
    endcase
  else
    case (format_shift)
      0: shifter <= 6;
      1: shifter <= 5;
      default: shifter <= 4;
    endcase

always @(posedge clk)
  reduce <= 1 + (end_offset >> shifter );

(assuming that format_shift goes from zero to 2).

Actually, I would bet that it’s equally fine to calculate the number of shifts and put the result in a wire. I went for the case statement hoping that the synthesizer will take the hint that not all values that fit into the registers are possible, and will hence avoid implementing impossible shift values.

Needless to say, I know about this because something went horribly wrong all of the sudden. I believe XST version 12.2 handled the shift calculation OK. And then people ask me why I don’t like upgrades.

Get free daily email updates!

Follow us!

Intel's 335 Series SSD reviewed

SSDs have come a long way since Intel released its first, the X25-M, a little more than four years ago. That drive was a revelation, but it wasn't universally faster than the mechanical hard drives of the era. The X25-M was also horrendously expensive; it cost nearly $600 yet offered just 80GB of capacity, which works out to about $7.50 per gigabyte.

My, how things have changed.

Solid-state drives gotten a lot faster in the last few years. They're already pushing up against the throughput ceiling of the 6Gbps Serial ATA interface, leaving mechanical hard drives in the dust. I can't remember the last time we saw an HDD score better than an SSD in one of our performance tests.

More importantly, SSDs have become a lot more affordable. Today, you can get 80GB by spending $100. The sweet spot in the market is the 240-256GB range, where SSDs can be had for around $200—less than a dollar per gigabyte. Rabid competition between drive makers deserves some credit for falling prices, particularly in recent years. Moore's Law is the real driving factor behind the trend, though. The X25-M's NAND chips were built using a 50-nm process, while the new Intel 335 Series uses flash fabricated on a much smaller 20-nm process.

Designed for enthusiasts and DIY system builders, the 335 Series is aimed squarely at the sweet spot in the market with a 240GB model priced at $184. That's just 77 cents per gig, a tenfold reduction in cost in just four years. The price is right, but what about the performance? We've run Intel's latest through our usual gauntlet of tests to see how it stacks up against the most popular SSDs around.

Die shrinkin'
Intel and Micron have been jointly manufacturing flash memory since 2006 under the name IM Flash Technologies. The pair started with 72-nm NAND flash before moving on to the 50-nm chips used in the X25-M. The next fabrication node was 34 nm, which produced the chips used in the second-generation X25-M and the Intel 510 Series. 25-nm NAND found its way into the third-gen X25-M, otherwise known as the 320 Series, in addition to the 330 and 520 Series. Now, the Intel 335 Series has become the first SSD to use IMFT's 20-nm MLC NAND.

Building NAND on finer fabrication nodes allows more transistors to be squeezed into the same unit area. In addition to accommodating more dies per wafer, this shrinkage can allow more capacity per die. The 34-nm NAND used in the Intel 510 Series offered 4GB per die, with each die measuring 172 mm². When IMFT moved to 25-nm production for the 320 Series, the per-die capacity doubled to 8GB, while the die size shrunk slightly to 167 mm².

Two 4GB 34-nm dies, one 8GB 25-nm die, and the new 8GB 20-nm die. Source: Intel

The Intel 335 Series' 20-nm NAND crams 8GB onto a die measuring just 118 mm². That's not the doubling of bit density we enjoyed in the last transition, but it still amounts to a 29% reduction in die size for the same capacity. Based on how those dies fit onto each wafer, Intel says 20-nm production increases the "gigabyte capacity" of its flash fabs by approximately 50%. IMFT has been mass-producing these chips since December of last year.

As NAND processes shrink, the individual cells holding 1s and 0s get closer together. Closer proximity can increase the interference between the cells, which can degrade both the performance and the endurance of the NAND. Intel's solution to this problem is a planar cell structure with a floating, high-k/metal gate stack. This advanced cell design is purportedly the first of its kind in the flash industry, and Intel claims it delivers performance and reliability comparable to IMFT's 25-nm NAND. Indeed, Intel's performance and endurance specifications for the 335 Series 240GB exactly match those of its 25-nm sibling in the 330 Series.

Intel says the 335 Series 240GB can push sequential read and write speeds of 500 and 450MB/s, respectively. 4KB random read/write IOps are pegged at 42,000/52,000. Thanks to the lower power consumption of its 20-nm flash, the new drive should be able to hit those targets while consuming less power than its predecessor. The 335 Series is rated for power consumption of 275 mW at idle and 350 mW when active, less than half the 600/850 mW ratings of its 25-nm counterpart.

On the endurance front, Intel's new hotness can supposedly withstand 20GB of writes per day for three years, just like the 330 Series. As one might expect, the drive is covered by a three-year warranty. Intel reserves its five-year SSD warranties for the 320 and 520 Series, whose high-endurance NAND is cherry-picked off the standard 25-nm production line. I suspect it will take Intel some time to bin enough higher-grade, 20-nm NAND to fuel upgrades to those other models.

Our performance results will illustrate how the 335 Series compares up to those other Intel SSDs. Expect the 320 Series to be much slower due to its 3Gbps Serial ATA interface. That drive's Intel flash controller can trace its roots back to the original X25-M, so the design is a little long in the tooth. The 520 Series, however, has a 6Gbps interface and higher performance specifications than the 335 Series. The two are based on the same SandForce controller silicon, though.

Get free daily email updates!

Follow us!

Intel’s 335 Series SSD

Intel has revved up its mainstream SSD line from the Series 330 to the Series 335, and the company sent over a 240GB model for evaluation (and 240GB is apparently the only capacity it is launching this series with). The new drives feature 20nm NAND flash memory, compared with the 25nm chips in the older series, but Intel continues to use an LSI/SandForce SF-2281 controller with custom Intel firmware. The company uses the same controller in its Series 330 and Series 520 drives.

But what may be of most interest to consumers is that the Series 335 is significantly cheaper per gigabyte: Intel expects this 240GB drive to cost about the same as a 180GB Series 330. And while the product was officially embargoed until 8:30 a.m. on October 29, we saw it listed for sale online the evening of October 28 at prices between $184 and $225, including shipping.

Like its most recent predecessors, the Series 335 is outfitted with a SATA revision 3.0 (6gbits/s) interface, and the drive comes housed inside a 2.5-inch enclosure that is 9.5mm thick. That thick profile renders it unsuitable for many current ultraportables; however, the stout of heart can easily remove the board from its enclosure and fit it inside a thinner case or install it directly into a vacant drive bay (although doing either will likely void Intel’s three-year warranty).

Here are some results of 10GB copy and read tests. Keeping in mind that our current test bed uses a 7200-rpm hard drive to feed and read data from our test subjects, the 335 performed very well. It wrote our 10GB mix of files and folders at 93.2MBps and read them at 57.9MBps; and it wrote our single 10GB file at 124.1MBps while reading it at 129.8MBps.

 

Intel 335 Series SSD Features and Specifications:

• CAPACITY: 240GB
• COMPONENTS:
  • Intel 20nm NAND Flash Memory
  • Multi-Level Cell (MLC)
• FORM FACTOR: 2.4-inch
• THICKNESS: 9.5mm
• WEIGHT: Up to 78 grams
• SATA 6Gbps BANDWIDTH PERFORMANCE (IOM QD32):
  • SUSTAINED SEQ READ: 500 MB/s
  • SUSTAINED SEQ WRITE: 450 MB/s
• READ & WRITE IOPS (IOM QD32):
  • RANDOM 4KB READS: Up to 42,000 IOPS
  • RANDOM 4KB WRITES: Up to 52,000 IOPS
• COMPATIBILITY:
  • Intel SSD Toolbox w/SSD Optimizer
  • Intel Data Migration Software
  • Intel Rapid Storage Technology
  • Intel 6 Series Express Chipsets (w/ SATA 6Gpbs)
  • SATA Revision 3.0
  • ACS-2 (ATA/ATAPI Command Set 2)
  • Limited SMART ATA Feature Set
  • Native Command Queuing (NCQ) Command Set
  • Data Set Management Command Trim Attribute
• POWER MANAGEMENT:
  • 5 V SATA Supply Rail
  • SATA Link Power Management (LPM)
• POWER:
  • Active (MobileMark 2007 Workload: 350 mW (TYP)
  • Idle: 275 mW (TYP)
• TEMPERATURE:
  • Operating: 0°C to 70°C
  • Non-Operating: -55°C to 95°C
• CERTIFICATIONS & DECLARATION:
  • UL
  • CE
  • C-Tick
  • BSMI
  • KCC
  • Microsoft WHQL
  • VCCI
  • SATA-IO
• PRODUCT ECOLOGICAL COMPLIANCE:
  • RoHS

 

Get free daily email updates!

Follow us!