luke
/
iverilog
mirror of https://github.com/steveicarus/iverilog.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Spelling fixes from Larry.

This commit is contained in:
steve 2005-02-23 18:37:52 +00:00
parent 327c897d7e
commit 5ea4152162
2 changed files with 9 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
examples/sqrt-virtex.v
View File

@ -16,13 +16,13 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
*
* $Id: sqrt-virtex.v,v 1.4.2.1 2005/02/19 16:39:32 steve Exp $"
* $Id: sqrt-virtex.v,v 1.4.2.2 2005/02/23 18:37:52 steve Exp $"
*/
/*
* This module is a synthesizeable square-root function. It is also a
* detailed example of how to target Xilinx Virtex parts using
* Icarus Verilog. In fact, for no particular reason other then to
* Icarus Verilog. In fact, for no particular reason other than to
* be excessively specific, I will step through the process of
* generating a design for a Spartan-II XC2S15-VQ100, and also how to
* generate a generic library part for larger Virtex designs.
@ -130,7 +130,7 @@
* contains Verilog code that simulates the mapped design. This output
* Verilog has the single root module "chip_root", which came from the
* name of the root module when we were making the EDIF file in the
* first place. The module has ports named just line the ports of the
* first place. The module has ports named just like the ports of the
* chip_root module below.
*
* The generated Verilog uses the library in the directory

13
vvp/README.txt
View File

@ -1,7 +1,7 @@
/*
* Copyright (c) 2001 Stephen Williams (steve@icarus.com)
*
* $Id: README.txt,v 1.47.2.1 2005/02/19 16:39:32 steve Exp $
* $Id: README.txt,v 1.47.2.2 2005/02/23 18:37:52 steve Exp $
*/
VVP SIMULATION ENGINE
@ -283,7 +283,7 @@ statement, it creates no functors. The symbol list is a list of
functors that feed into each bit of the vector, and the vpiHandle
holds references to those functors that are fed it.
The <label> is required and is used to locate the net object that is
The <label> is required and is used to locate the net object that it
represents. This label does not map to a functor, so only references
that know they want to access .nets are able to locate the symbol. In
particular, this includes behavioral %load and %wait instructions. The
@ -312,7 +312,7 @@ second word.
Structural read access is implemented in terms of address and data
ports. The addresses applied to the address port are expected to be
withing the ranges specified, not based at zero.
within the ranges specified, not based at zero.
A read port is a vector of functors that is wide enough to accept all
provided address bits and at least as wide as the requested subset of
@ -381,12 +381,11 @@ EVENT STATEMENTS
Threads need to interact with the functors of a netlist synchronously,
as well as asynchronously. There are cases where the web of functors
needs to wake up a waiting thread. The web of functors signals threads
through .event objects, that are declare like so:
through .event objects, that are declared like so:
<label> .event <type>, <symbols_list>;
<label> .event "name";
This event statement declares an object that a %wait instruction
can take as an operand. When a thread executes a %wait, it puts
itself in the notification list of the event and suspends. The
@ -509,7 +508,7 @@ similar:
Whereas the arithmetic statements create an array of functor outputs,
there is only one useful functor output for the comparators. That
functor output is 1 1f the comparison is true, 0 if false, and x
functor output is 1 if the comparison is true, 0 if false, and x
otherwise. The plain versions do unsigned comparison, but the ".s"
versions do signed comparison. (Equality doesn't need to care about
sign.)
@ -742,7 +741,7 @@ compile.cc. This function in turn calls all the *_init() functions in
other parts of the source that need initialization for compile. All
the various sub-init functions are called <foo>_init().
Compilation is controlled by the parser, it parse.y. As the parser
Compilation is controlled by the parser, in parse.y. As the parser
reads and parses input, the compilation proceeds in the rules by
calling various compile_* functions. All these functions live in the
compile.cc file. Compilation calls other sections of the code as