Graffiti

Welcome to the graffiti section of the Icarus Verilog documentation. The ground rules here are a little different from the remainder of the iverilog wiki. This page is an experiment. The idea is to have a page that is available for more liberal editing so people can shout out suggestions for features, complaints about shortcomings, etc. Think of this as the "discussion" page for the whole wiki.

The content here should be more free, like a mailing list. But unlike a mailing list, time ordering need not be preserved. Ultimately, the Graffiti section should wind up reasonably structured and readable. This may mean that your paragraphs may be reformatted, reworded (but please get the attributions right) or replaced to manage the flow of the document. And of course you can do all that stuff to your own words.

The content here can be less formal then a bug report or feature request in the iverilog tracker database, although discussion here may lead to a formal feature request in the tracker database. Or discussion may lead to FAQ entries or entire new and more formal pages on conventional documentation.

One ground rule I would like to establish from the outset, however, is that I expect contributors to sign (with the ~~~~ string) their edits in the article, and take care with attributions when editing a signed paragraph. Along with that comes the matching rule to not put words in others mouths.

So let's see how this works.

--Stevewilliams 22:45, 4 March 2007 (UTC)

Notes on Implementing Verilog AMS

Icarus Verilog has grown enough elaboration time support for Verilog AMS that it's time to star thinking about how to implement the run time. In particular, how do we deliver A/MS specific details to the vvp run time, and how does the vvp run time efficiently use that information. This section is random notes on my thinking, that we can edit as thinking evolves. The plan is to wrap heads around an implementation plan.

A/MS Islands

The first issue is dividing the parts of the design into digital, and distinct islands of analog. Islands were first introduced to Icarus Verilog to implement switch level modeling. We needed to collect together nodes of the netlist that are connected by switches so that all the switch port values can be resolved simultaneously. That is done and and ivl core has the ivl_island_t and IslandBranch classes to support this collecting together. By collecting together islands of switches during elaboration, the code generator and the run time can know, without special processing, the bounds of each sub-problem. Only branches within an island must be solved together. That takes care of switches.

Analog processing must also be collected together into islands. Portions of the design that are disjoint (separated by digital) can be solved independently. The VAMS specification calls these islands "kernels". Within each island, the solutions need to be calculated together, but a calculation need not look beyond its island.

An island contains nodes and branches that are all of the same discipline. The compiler can also do some calculations to figure out what kind of processing engine is needed for a given island. For example, if all the math in the island does not regress in any way, a solver for that island can be chosen that simply evaluates the expressions. Or if there is math in the island that requires full-featured dynamic analysis, a more complex solver can be chosen for that island.

Non-recurrent Islands

Non-recurrent Islands have branches that do not depend on themselves. In other words, it is possible to solve a non-recurrent island by simple substitution of values. Another way of saying this: the state of the island can be described by a single expression. A non-recurrent island is not necessarily linear, and it may contain filters, but it can be solved in one pass.

Dynamic Islands

The big deal. Simultaneous differential equations, oh my.

Analog Expressions

The way Icarus Verilog currently handles expressions in structural context will not make sense in analog islands. Analog expressions may need multiple trial evaluations before the solver settles on a solution, so the infrastructure for describing a expression in context must allow for that. It is sufficient for the act of reading an expression value to cause it to be evaluated.

The infrastructure for processing analog expressions might as well be usable in other parts of the Icarus Verilog run-time. There are a couple places where this sort of functionality could be of use.

Icarus developer summit 2008

We are planning a developer summit on October 24th, 2008 in the afternoon (~3:00 PM) at Steve's house. Here are some topics/tasks for the get together. If you have something you would like us to talk about even if you are not going to be there please add them. No guarantees we will get around to them, but we will certainly try.

Meet and greet

This will be an opportunity for Steve and I to actually meet each other along with anyone else who can attend.

Where are we going

Work on defining exactly what will go into V0.9 and how we want to phase in other things like VAMS and missing functionality that does not make it into V0.9.

Multiple version support

We need to work out a plan for how we will support the installation of multiple version so that users can have both V0.8, V0.9 and possibly a development version available at the same time. I have some preliminary ideas on this.

Review the bugs and feature requests

We may work on categorizing the current bugs and feature requests and deciding which need to make it into V0.9 and which can wait for a later release.

The test suite

Are there any issues that need to be addressed in the test suite? A VCD comparison program is one known need and has been discussed on iverilog-devel.

Icarus Tour

If we have time I would like to have Steve lead a high level tour of Icarus and how he envisions the various pieces interacting.

Dinner

Any great get together must have food. Given this is a software project, pizza is the likely sustenance.

We plan to post information about what we actually cover and anything else that is pertinent to the iverilog-devel mailing list and we will also update the appropriate sections here on the wiki.

--Cary 01:03, 30 September 2008 (UTC)

Why bother?

When timing sims come up in NG or list messages, the usual response is "don't bother, STA will do the job for you". However, it's not always this straightforward. I've added a list below of some arguments for (+) and against (-) carrying out timing sims. YMMV, of course:

- If you've (a) got an FPGA, and (b) it's completely synchronous, and (c) it has one input clock, and (d) you haven't added any additional clock buffers to, for example, drive off-chip RAMs, and (e) your STA tool lets you constrain input setup *and* hold times, and (f) you're confident that you can write the constraints without error, then carrying out a timing sim is probably a waste of time.

+ An STA run *doesn't* tell you that your chip will work. All it tells you is that your chip should work if, and only if, your constraints are correct. If there's an error in your constraints, then an STA run tells you nothing.

+ The only way to find out if the vendor believes that your chip will work is to carry out a timing simulation. This is never a guarantee, for lots of reasons, but it's the closest you'll get to a guarantee. You don't get this guarantee with STA, because STA relies on the correctness of your timing constraints.

- A timing simulation is useless if your testbench can't provide worst-case stimulus to your chip. This is normally much harder than it sounds. It's not just clock frequency: you have to drive all inputs with the minimum allowed setup and hold times, and you have to sample all outputs immediately that they're guaranteed valid. for a complex device, it can be very difficult to do this manually. It can also be difficult to generate specific test cases that result in worst-case timing. This is all automatic and trivial with (correct) STA.

+ You can't check asynchronous inputs with STA; you just instruct the tool to ignore these inputs. In principle, you *can* check async inputs with a timing simulation (but, in practice, it's difficult).

+ If you run STA, then you need to check the timing reports, even if the summary tells you that all your constraints passed. For a real chip, there can be dozens or hundreds of these. If this is an ASIC and you're not doing the back-end work, then you may have trouble getting someone to actually generate all the reports you need. If you're running a timing simulation, with a good testbench, then the simulation just tells you itself whether or not it has passed.

+ Sometimes a timing sim will tell you something that STA won't tell you. I had a case recently where a library PLL was "guaranteed by design", including the digital parts. The digital bits were false path'ed, and so missed STA. However, there was timing data in the sdf (don't ask how it got there - I don't know!), and the timing sim failed - the digital feedback divider didn't work. Turned out it wasn't "guaranteed by design".

- sdf data may or may not be accurate. On my last chip the vendor added a 15% derating in PrimeTime to cover path-based uncertainty, OCV, and so on, and they said that it wasn't possible to include this in the sdf data. They couldn't explain why. Anyway, in this case, the sdf was not as accurate as the STA results.

Moral: if you're responsible for a chip which is anything more than a simple FPGA, and you sign it off without a timing simulation, then you're going to need to invent some pretty good excuses, and brush up your CV while you're at it.

--Eml 11:36, 19 March 2007 (UTC)

I want to add a counter-balance to the above article - while getting STA constraints correct is difficult, finding a worse case timing path with simulation is equally difficult if not more so. Back-annotated simulation for timing reasons is only as good as the completeness of your simulation - no better or worse. Same is true with STA, but STA will examine every possible path, while simulation can't even come close to that kind of claim.

I've found in the ASIC world, the best choice is to depend heavily on STA, and spend appropriate amount of time getting it right, then back it up with a couple of back-annotated simulations to take care of physical effects that STA won'find. I've found mostly clock-tree issues with simulation under these circumstances.

Steve Wilson

Google Summer of Code 2007 Suggestions

I'm creating a new page, "Projects", where we can keep this list.

For the purposes of the Google Summer of Code, Icarus Verilog is putting itself under the gEDA umbrella. The gEDA page for gsoc covers the larger subject of procedures for applying.

Below are some suggestions for Icarus Verilog tasks for the Google Summer of code. (Of course, they are not strictly reserved for that purpose.)

--Stevewilliams 15:18, 10 March 2007 (UTC)

SDF Parser/Annotator

This is now available for both the stable and development branches.

Module parameters at Compile Time

The contents of this section have been moved to Talk:Projects

Add a developer page to the wiki

I've created the Developer Guide page with a minimal outline. I'm convinced of the value of this idea, and I think it should be pursued with vigor. To that end, we can start copying content over to the actual page. --Stevewilliams 18:55, 3 April 2007 (UTC)

My idea is to add a "quick start for developers" page to the wiki, explaining how to get started with development on Icarus Verilog. After an outline of ideas I will start creating content here in this paragraph, that can later be copied to that new to be created page.

Outline of ideas:

• Getting started with the source code
  • Check out code from CVS and get it to compile
  • Generating patches that are useful for submission
  • Debugging hints
• How to verify that what I added did not break anything else
  • How to add new tests to the test cases

Some of the topics will just be copy and paste from the icarus.com page. I did that because I think it would be good to keep the information together at one place.

---

Getting started with the source code

For development it is suggested to base changes on the CVS snapshot. This will allow to submit changes as a patch against the latest CVS version.

There is a section in the Installation Guide that explains how to check out the code. It also explains how to prepare it to compile on the local system.

From this point on now, CVS can be used to track the local changes done and submit them as a patch via the Icarus Bug/Feature tracker.

To generate a patch go in the respective directory of your changes or the top folder of the checked out code and run:

% cvs diff > my-file.patch

This will recursively generate a diff of all changed files and redirect the output to the my-file.patch. Make sure it only contains what you meant for it to and submit the patch.

---

There is actually a section in the Installation Guide that covers this very same subject. I would put a reference to that section instead of repeating it.

What you can add is how to make context diffs (patches) that are useful for submisison.

--Stevewilliams 03:54, 25 March 2007 (UTC)

OK, I did that change. I am bit slow here, so it will take me some time to get this all together how I think it should look. Let me know if you think I should reword something or just jump in and do it. I won't be offended :)

Concerning the cvs diff command, I recognized that it also redirects new file names that are not put under cvs control to the patch file. From the cvs help I did not find an option how to supress that, or I missunderstood an explanation. Does that matter?

Concerning debugging, I followed a recent discussion on the mailing list about different assert statements. I will take some time and read through the code to find out what possibilities there are. But I have a question about debugger support. Is there a quick way to compile the source that it can be used with the debugger or is that just not feasible?

--Dannori 14:42, 26 March 2007 (UTC)

How to verify that what I added did not break anything else

There is a test suite maintained by Steve Wilson at http://sourceforge.net/projects/ivtest.

A snapshot of the test suite is available via anonymous CVS:

% cvs -d:pserver:anonymous@ivtest.cvs.sourceforge.net:/cvsroot/ivtest login

(For password hit ENTER)

% cvs -z3 -d:pserver:anonymous@ivtest.cvs.sourceforge.net:/cvsroot/ivtest co -P testsuite

A test plan describes the purpose of various tests.

--Dannori 12:23, 18 March 2007 (UTC)

Binary nor operator?

Icarus has a binary nor operator, which looks the same as a reduction nor, ie.

wire result2 = A ~| B; // from ivltests/binary_nor.v

Is this in common usage? It's not listed on the extensions page (and neither is the binary nand).

BTW, I only found the extensions page on google. Is there some way to navigate the Wiki pages?

Eml 17:38, 16 May 2007 (UTC)

They seem to be accidental extensions and should be documented as extensions. They certainly seem reasonable, but I just checked the 2005 standard, and sure enough they are not there.

So these should be noted in the User Guide where language extensions are documented.

Stevewilliams 03:13, 18 May 2007 (UTC)

C-source output instead of interpreted vvp scripts?

Did you ever considered c-source output instead of interpreted vvp scripts? This should speed up execution considerably, the approach would be similar to the one of verilator (http://www.veripool.com/verilog_sim_benchmarks.html).

Implementation would probably not too hard, since all vvp constructs could get implemented as matching c-macro or inline function call, which would get optimized by gcc? Since gdb could get used for debugging (when the output is compiled without excessive optimization flags), the vvp debug shell is maybe not necessary anymore.

-- 89.247.99.203 21:30, 27 February 2008 (UTC)

Maybe using LLVM in JIT-mode would be an option, too. The C-interface seems easy-to-use in the tutorial: http://llvm.org/docs/tutorial/

-- 89.247.34.197 15:13, 5 October 2008 (UTC)

Well, ghdl works like that and do you have any idea how amazingly slow it is?-) Also, early Icarus Verilog did generate C++ output. That was a big mistake. It would probably have been much better to target C, but oh well we've got vvp instead. It is possible that writing out C code instead of vpp will go faster, but that's not were it is now.

-- Stevewilliams 04:08, 10 October 2008 (UTC)

Actually, I took a peek at LLVM and it does look interesting, but I still think it would be a poor match for targeting Icarus Verilog. Keep in mind that even in behavioral code, Verilog expressions have types that are different from conventional CPUs, and the bit vectors are arbitrary width. This alone is a poor match for CPU virtual machines, but the killer is that the structural code (the parts that are not behavioral) don't have the control flow of a typical CPU. The Verilog compiler to a large degree just sets up a discrete event simulator and feeds it with some data to get is started.

-- Stevewilliams 16:09, 11 October 2008 (UTC)