Graffiti
From Icarus Verilog
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)
Contents |
[edit] Mailing list?
> The content here should be more free, like a mailing list.
How about actually having a mailing list? How many people write Verilog *and* lay out PCBs? It would also save me having to sort through 70-odd irrelevant messages every Monday morning. I only found out about the Wiki by accident.
-- Evan
Because I don't want to manage one? I'm administering a variety of things a this point, and yet another thing (a mailing list) doesn't strike me as a priority, given the geda lists are there.
It is possible, of course, that I'm wildly missing the pulse on this. If someone else put together an Icarus Verilog mailing list, I'd be willing to endorse it. Or if someone else steps up to manage it, I'd be willing to create the list on sourceforge.
--Stevewilliams 16:05, 5 March 2007 (UTC)
Well, a combination of factors (and a groundswell of public opinion) has led to the creation of the iverilog-devel and iverilog-announce mailing lists on sourceforge.net, --> here.
[edit] SDF support
For the stable version of Icarus Verilog there exists a SDF VPI plugin provided by Stephan Böttcher.
In August 2006 I tried to compile iSDF 0.2.1 with the then current development snapshot verilog-20060618 without success.
There was a discussion about this on the gEDA mailing list:
- http://archives.seul.org/geda/user/Aug-2006/msg00037.html
- http://archives.seul.org/geda/dev/Aug-2006/msg00041.html
The core issues from that discussion are:
- SDF with the current development snapshot is broken.
- When ivl/vvp does support the specify delays, SDF annotation becomes a lot easier. (Quote from Stephan Böttcher)
- SDF really has two parts. The parser that reads the SDF files can be written as a system task, and iSDF is done that way. But there needs to be some specific specify related infrastructure in the vvp run-time to provide the needed features. iSDF used some patched in hacks to get by, but we really need the core from specify block support for a proper job. (Quote from Steve Williams)
Dannori 21:23, 5 March 2007 (UTC)
SDF support has become my personal task. The 2007 Google Sommer of Code season led to some SDF support code contributions from a student (who has since gone silent) so I'm doing the core work to integrate that code in.
--Stevewilliams 04:24, 1 November 2007 (UTC)
[edit] 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)
[edit] 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)
[edit] SDF Parser/Annotator
SDF parser to parse SDF files generated by typical SDF sources such as Xilinx ISE. It should be possible to invoke this from an $sdf_annotate system task and match paths with the specify paths actually available (via vpi) in the design.
The specify paths are now available in the vvp run time, some work is needed to offer up the VPI objects that an SDF annotator needs.
This task can mostly be done in C and loaded as a VPI module. There is some work needed in the vvp run time engine to make the paths available to VPI modules, though.
--Stevewilliams 16:50, 9 March 2007 (UTC)
- This task was taken on by a GSoS 2007 student. The SDF parser has been done, but the vvp integration proved to be too immense. I'm personally completing that work, so it will not be available for future GSoC students.
- --Stevewilliams 04:29, 1 November 2007 (UTC)
[edit] Module parameters at Compile Time
The contents of this section have been moved to Talk:Projects
[edit] 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.
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
