Problem using $recordvars/$recordfile under NCverilog

[Jonathan Bromley]

On 12 Jul 2004 16:30:20 -0700, rbingham@dotcast.com (Raymond Bingham)
wrote:

Anyone out there know how to pass verilog parameters to a verilog
task? Synopsys and Cadence both compile okay with parameters in the
task function, but I don't know how to change them. Can you?

If you want a value that's different every time the task is
called, simply pass it in the argument list. The "parameter"
is then an input argument of the task, and therefore a local
register of the task, so you have to be careful to avoid
writing to it inadvertently.

If you want a value that's different for some instances of the
task, but fixed for each and every call of a given instance of
the task, then you need to put the task in a module and
parameterise each instance of the module.

Parameters inside a task are fine, and you can "defparam" them
from outside the task by using the task name as part of
a hierarchical name (but that's not synthesisable, of course).
Such parameters, like any others, get a fixed value when the
simulation is elaborated, and can't be changed during simulation.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Cody]

nope...i have never seen any open source codes for RC4.

Kelvin



"ERJS" <erjs@hotmail.com> wrote in message
news:30714d8d.0406281948.588aa664@posting.google.com...
> does someone have a verilog code for RC4?

 

[Jason Zheng]

Lee wrote:

Dear all,

When I do a big project, I find it is hard to deal with clock. The
most of time when I did a big project is spent on clock control
signals.

For example, when writing a control unit, if I use synchronous memory,
I need to provide address and write/read signal before the arrival of
edge of clock. At the same time, address and write/read signals are
under control of the same clock. In this situation, anybody know how
to deal with this kind of problem?

If you use the SRAM (on-chip), then you generate the address and r/w
signals between the clock ticks, everything should be fine. If you use
the SDRAM (external modules), you should write a memory controller,
because they usually run at different clock freq.

When I write verilog code, I add some delay statement(i.e. #2). But
when I synthesize the verilog code, the delay statement is ignored. So
to use delay statement is not correct for RTL, right?

Those delays are never part of the RTL.

Another way I can use may be to write State Machine. But I am not sure
if there is any other good way to do that. Can anybody share with me?

Try this (suppose you want a delay of 2 clock cycles):

old statement: always @ (w0 or w1) #2*clk_cycle w2 <= w1 ^ w0;
new statement: always @ (posedge clk) begin
w0_dly1 <= w0;
w0_dly2 <= w0_dly1;
w1_dly1 <= w1;
w1_dly2 <= w1_dly1;
end
assign w2 = w1_dly2 ^ w0_dly2;

Notice that the units of the delays can only be number of cycles (or 0.5
cycles). You shouldn't have to specify the actually timing delay (e.g. 5
ns), because each hardware is different in timing and there is no
precise way to guarantee something like 2ns delay at the design time.

 

[Jason Zheng]

Lee wrote:

Hello,

When I read synthesis tools manual, the manual suggests the design
should look like "combinational-->DFF or Latch-->combinational-->DFF
or Latch".

What is the general rule to partition the whole project into Verilog
Modules?

I am thinking of the following way, but I don't know if it is correct:

1. control unit that can generate the control signal for other
modules. That control unit should be writen in FSM.
2. all other modules. Each module has a combinational curcuit followed
by DFF or Latch.
3. memory modules is considered separately too.

Can anybody give me some comments for the design of modules?

Thanks,

When designing pipelined circuits, you might further partition your
modules by stages in the pipeline. So for each stage, you have these
components:
1. Control (FSM)
2. Stage Registers (Flops)
3. Combinational Logic (Encoding/Decoding/Datapath)

 

[Stephen Williams]

Larry Doolittle wrote:

In article <57666134.0407191227.705732bf@posting.google.com>,
Swapnajit Mittra wrote:

Howard Le <leh@alum.rpi.edu> wrote in message
news:<GK8Kc.15574$Kz3.1260665@news4.srv.hcvlny.cv.net>...

Would anyone know of a verilog simulator ported on pocketpc?

Given the memory size of a pocketPC type device, it
is hard to foresee its usefulness as a simulation
machine, don't you think?


I successfully cross-compiled Icarus Verilog to run on a
200 MHz StrongARM with 32M of RAM. It worked fine.
If "useful" means "gets the right answer for small designs",
I suspect this will fit the bill. The OP will still have
to deal with the PocketPC toolchain and targeting, my demo
used Linux as the OS on the StrongARM target. Either that,
or he could convert his PocketPC hardware to run Linux
(http://www.handhelds.org) [1/2 ].

I've also seen Icarus Verilog compiled and run on a Xilinx
Virtex-IIPro. OK, so it was running Linux on the on-chip PPC.
Is that cheating?-)

--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."

 

[Larry Doolittle]

In article <57666134.0407191227.705732bf@posting.google.com>,
Swapnajit Mittra wrote:

Howard Le <leh@alum.rpi.edu> wrote in message
news:<GK8Kc.15574$Kz3.1260665@news4.srv.hcvlny.cv.net>...
Would anyone know of a verilog simulator ported on pocketpc?

Given the memory size of a pocketPC type device, it
is hard to foresee its usefulness as a simulation
machine, don't you think?

I successfully cross-compiled Icarus Verilog to run on a
200 MHz StrongARM with 32M of RAM. It worked fine.
If "useful" means "gets the right answer for small designs",
I suspect this will fit the bill. The OP will still have
to deal with the PocketPC toolchain and targeting, my demo
used Linux as the OS on the StrongARM target. Either that,
or he could convert his PocketPC hardware to run Linux
(http://www.handhelds.org) [1/2 ].

- Larry

 

[Jason Zheng]

suz wrote:

I recently plan to buy a notebook to run verilog simulations, some of
them come with "shared graphic memory" and offer better price. I am
wondering, if this kind of structure has any impact on simualtion
performmance?
I think the simulation process itself is memory access intensive, and
if there are some display activity going on, two sides may fight for
memory buses.
anyone has idea or experience about this?

I have no experience about your situation, but I think besides the point
that the shared-memory graphics card chews up your main memory, there's
little to worry about the graphics subsystem fighting the CPU for
memory, because if you are doing simulation, all the graphical processes
happen after the number-crunching is done. I'm not sure about gaming
performance, but think about it, would you really count on playing
Unreal 2003 smoothly with a cheap intel graphics chip (with shared
memory)? Probably not even on a desktop PC, not even if it has its own
memory.

 

[Cliff Brake]

Jason Zheng wrote:

suz wrote:

I recently plan to buy a notebook tconsonantlyimulations, some of
them come with "shared graphic memory" and offer better price. I am
wondering, if this kind of structure has any impact on simualtion
performmance?
I think the simulation process itself is memory access intensive, and
if there are some display activity going on, two sides may fight for
memory buses.
anyone has idea or experience about this?

I have no experience about your situation, but I think besides the point
that the shared-memory graphics card chews up your main memory, there's
little to worry about the graphics subsystem fighting the CPU for
memory, because if you are doing simulation, all the graphical processes
happen after the number-crunching is done. I'm not sure about gaming
performance, but think about it, would you really count on playing
Unreal 2003 smoothly with a cheap intel graphics chip (with shared
memory)? Probably not even on a desktop PC, not even if it has its own
memory.

Typically, in a shared memory architecture, the display controller has to
constantly scan the frame buffer in main memory to repaint the display.
Depending on the size of your display and the memory bandwidth, this
scanning may use enough memory bandwidth to affect system performance.

--

Cliff Brake
BEC Systems
cbrake _at_ bec-systems _dot_ com

 

[R.S Hong]

Muthu <muthusnv@yahoo.co.in> wrote:

Hi,
I know that Modelsim supports PSL for VHDL. Is it supports for Verilog
? If so how to do that. Any reference for that.
Regards,
Muthu S

When you run Modelsim VHDL compiler vcom, there is an option for PSL,
but when you run Verilog compiler vlog, there is no such option,
so I guess Modelsim doesn't support that.

Maybe you can ask support guy

 

[Jason Zheng]

Anthony J Bybell wrote:

Jason Zheng <jzheng@jpl.nasa.gov> wrote in message news:<cdju0f$fqp$1@nntp1.jpl.nasa.gov>...


I have no experience about your situation, but I think besides the point
that the shared-memory graphics card chews up your main memory, there's
little to worry about the graphics subsystem fighting the CPU for
memory, because if you are doing simulation, all the graphical processes
happen after the number-crunching is done. I'm not sure about gaming
performance, but think about it, would you really count on playing
Unreal 2003 smoothly with a cheap intel graphics chip (with shared
memory)? Probably not even on a desktop PC, not even if it has its own
memory.


I think you're missing something fundamental: how does the RAMDAC draw
the display for a plain vanilla 2D framebuffer? By regular fetches to
mainstore.

I suppose you could blank the screen by disabling video during
simulation, but that might not be convenient.

-t
Yah but that's at 60-100Hz frequency, very little bandwidth.

 

[Tim Hubberstey]

Jason Zheng wrote:

Anthony J Bybell wrote:

Jason Zheng <jzheng@jpl.nasa.gov> wrote in message
news:<cdju0f$fqp$1@nntp1.jpl.nasa.gov>...


I have no experience about your situation, but I think besides the
point that the shared-memory graphics card chews up your main memory,
there's little to worry about the graphics subsystem fighting the CPU
for memory, because if you are doing simulation, all the graphical
processes happen after the number-crunching is done. I'm not sure
about gaming performance, but think about it, would you really count
on playing Unreal 2003 smoothly with a cheap intel graphics chip
(with shared memory)? Probably not even on a desktop PC, not even if
it has its own memory.



I think you're missing something fundamental: how does the RAMDAC draw
the display for a plain vanilla 2D framebuffer? By regular fetches to
mainstore.

I suppose you could blank the screen by disabling video during
simulation, but that might not be convenient.

-t

Yah but that's at 60-100Hz frequency, very little bandwidth.

That may be the refresh rate but that is NOT the refresh bandwidth
requirements. A "typical" display these days is at least 8-bit color at
1024x768 at 75 Hz refresh. This translates to a minimum of 59 MB/s
bandwidth requirement. A more common CAD setup is 24-bit color at
1280x1024 at 85 Hz refresh -> 334 MB/s. To me, that doesn't count as
"very little bandwidth".

The performance impact of shared memory depends on many design factors
in addition to the display resolution so the only true measure of
whether or not the setup is acceptable is to test it.

But consider this: you will be spending significant $ on software, does
it really make any sense to then cripple the performance of this
software to save $100 on your hardware?
--
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com

 

[Blackie Beard]

Standard "for" loops are not. In Verilog 2001, "for" loops used
for initialization of arrays is, I believe, synthesizable. Whether
or not synopsis is up to date to include that would be yet
another question.

======================================

"Lee" <yxl4444@louisiana.edu> wrote in message
news:5c3c88bc.0407230644.3fd84859@posting.google.com...

Dear all,

Is "for" statement considered as RTL code??

When it read a design with "for" statement, the design_analyzer from
synopsys that synthesized the design seemed to be down.

Thanks,

 

[Stefan Frank]

On 07/22/2004 05:55 PM, Muthu wrote:

Hi,

I know that Modelsim supports PSL for VHDL. Is it supports for Verilog
? If so how to do that. Any reference for that.

Hello,

Verilog PSL is not supported in ModelSim 5.8.
It is planned for ModelSim 6.0.

See TechNote mg38759 at Mentor Graphics SupportNet.

Bye,
Steff

 

[Jason Zheng]

Tim Hubberstey wrote:

Jason Zheng wrote:

Anthony J Bybell wrote:

Jason Zheng <jzheng@jpl.nasa.gov> wrote in message
news:<cdju0f$fqp$1@nntp1.jpl.nasa.gov>...


I have no experience about your situation, but I think besides the
point that the shared-memory graphics card chews up your main
memory, there's little to worry about the graphics subsystem
fighting the CPU for memory, because if you are doing simulation,
all the graphical processes happen after the number-crunching is
done. I'm not sure about gaming performance, but think about it,
would you really count on playing Unreal 2003 smoothly with a cheap
intel graphics chip (with shared memory)? Probably not even on a
desktop PC, not even if it has its own memory.




I think you're missing something fundamental: how does the RAMDAC draw
the display for a plain vanilla 2D framebuffer? By regular fetches to
mainstore.

I suppose you could blank the screen by disabling video during
simulation, but that might not be convenient.

-t


Yah but that's at 60-100Hz frequency, very little bandwidth.


That may be the refresh rate but that is NOT the refresh bandwidth
requirements. A "typical" display these days is at least 8-bit color at
1024x768 at 75 Hz refresh. This translates to a minimum of 59 MB/s
bandwidth requirement. A more common CAD setup is 24-bit color at
1280x1024 at 85 Hz refresh -> 334 MB/s. To me, that doesn't count as
"very little bandwidth".

Just for the sake of arguement, a laptop setup is more likely to be
1024*768*24bit at 60Hz (Active Matrix), which is about 138 MB/s. 266 Mhz
Dual Channgel DDR gives you about 3.2 Gb/s. 400Mhz Dual DDR gives you
6.4Gb/s bandwidth. Also consider the fact that the memory controller
only have to service the graphics controller every 17us.

The performance impact of shared memory depends on many design factors
in addition to the display resolution so the only true measure of
whether or not the setup is acceptable is to test it.

Point taken, you'd have to have a laptop system where you can switch
between an independent graphics card and the onboard graphics chip to
compare. I don't think you can do so unless you have a docking station
that supports AGP slots.

But consider this: you will be spending significant $ on software, does
it really make any sense to then cripple the performance of this
software to save $100 on your hardware?

I agree, but this is for a low budget setup, so the person who is making
this purchase prob. won't spend big bucks on software to begin with.

 

[Blackie Beard]

Sorry - disregard all this. I was not aware that the memory
model I replaced has built-in function to latch the address.
So I'll just build that function into my wrapper. I'm excited
to say that I did get this working in Altera EP20K60E part.
A simple program to blink an LED at 1Hz, but it shows that
the S/W code compiled with free Microchip tools is working
in Coonan's verilog synthesizable PIC core.

The PIC16C57 MCU is chosen to act as traffic cop in SoC
project. This is just the fun stuff I do at home, not the
tedious stuff I do at the daily grind (ie. work).

BB

 

[guru rajamani]

Assuming you are talking of a simple for and not a generate for, it is
synthesizable RTL subject to some constraints. If the limits depend only on
constant values/parameters or combinations of the above, synthesis tools
will be ok. Other variations are not likely to be synthesizable



"Lee" <yxl4444@louisiana.edu> wrote in message
news:5c3c88bc.0407230644.3fd84859@posting.google.com...

Dear all,

Is "for" statement considered as RTL code??

When it read a design with "for" statement, the design_analyzer from
synopsys that synthesized the design seemed to be down.

Thanks,

 

[guru rajamani]

There are a few differeneces between 2 and 3. In 2,
B gets assigned to A in clock 1 and then A gets assigned to C in the
following clock. So it is as though there are 2 registers in series between
B and C with the interim value being A.
In 3, A and C are 2 copies of the same. (I am assuming you intended to use B
in the second assignment also and it is not a typo).


"mohammed rafi" <m_mohammedrafi@yahoo.com> wrote in message
news:977f64b1.0407230138.77c214ff@posting.google.com...

hi,
canany one tell me the diffrence between the following 3 pieces of
verilog code.

1. always @ (posedge clk) begin
a = b;
c = a;
end

2. always @ (posedge clk) begin
a <= b;
c <= a;
end

3. always @ (posedge clk) begin
a <= #1 b;
c <= #1 b;
end
what is the diffrence between case 2 and case 3? what is the use of
unit delays((#1) in case 3?

cheers,
rafi.

 

[Jonathan Bromley]

On 26 Jul 2004 11:20:11 -0700,
hondainsightful@yahoo.com (Troy Heagy) wrote:

ModelSim compiles it okay, but during simulation I get an error:
Fatal: (vsim-3357) Bit-select is out of bounds.

You've declared an integer 'i' and then overridden it with
the 'genvar'. Get rid of the integer declaration.

There are no bit-selects in this code, so perhaps the
error is coming from your "dff" module? Is it correctly
parameterised for width?

Something to try: There are all kinds of tricky issues
about interaction between defparam and generate. That
part of your code looks OK to me, but it might be
safer to set the dff module's parameter at the
instantiation site using

dff #(.WIDTH(WIDTH)) i_pipeline ...

You're connecting the input and output port to each and
every flip-flop in your pipeline. This can't be good,
but I don't think it causes your error. You need to
declare an extra array of wires, to connnect the
output of each pipeline stage to the input of the next.
Luckily in Verilog-2001 you can create 2-D arrays of
nets, which makes this much easier...

wire [WIDTH-1:0] pipe_input [0ELAY];
// note: one more than the number of stages

// feed the first stage from d_in
assign pipe_input[0] = d_in;

// build the pipeline
generate begin : G1
genvar i;
for (i=0; i<DELAY; i=i+1) begin: inst
dff #(.WIDTH(WIDTH)) i_pipeline (
.clk(clk),
.d_in(pipe_input),
.d_out(pipe_input[i+1])
);
end // for
endgenerate

// export the pipeline output
assign q_out = pipe_input[DELAY];

Or something like that.

[original code]

parameter WIDTH = 16; // defines the width of the data
parameter DELAY = 5; // defines the amount of delay
input clk; // clock
input [WIDTH-1:0] d_in; // data input
output [WIDTH-1:0] q_out; // pipelined output
integer i; // counter index


// Implement a pipeline delay
generate
begin:G1
genvar i;
for (i=0; i<=DELAY-1; i=i+1)
begin :inst
dff i_pipeline
(
.clk(clk),
.d_in(d_in),
.q_out(q_out)
);
defparam i_pipeline.WIDTH = WIDTH;
end
end //for loop
endgenerate

Cheers
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[B. Joshua Rosen]

On Tue, 27 Jul 2004 08:58:39 -0700, Lee wrote:

Dear all,

After the big help from your guys, my design can be synthesized. Now I
got the gate netlist. Can anybody tell me how to calculate the count
of gates?What tools?

Thanks,

The Xilinx mapper puts a meaningless gate count in the .mrp report file.
I'm sure that Altera does the same thing.

 

[Jonathan Bromley]

On 28 Jul 2004 12:14:36 -0700, hondainsightful@yahoo.com (Troy Heagy)
wrote:

task write;
input clk;
input [15:0] data_in;
output data_serial_out;
begin
//loop that serializes the data
end
endtask

It's supposed to take the data_in, serialize it, and output it to
data_serial_out. It works flawlessly *inside* the task, but outside
it works like a function: only the last bit is output
(data_serial_out=data_in[0]).
Can this be fixed so the task is continuously updating the external
signals?

Ooh, Troy, you really ought to come on our Expert Verilog class

The answer to this question illustrates some of the great joys
of Verilog, and some of its greatest anguish.

Your task fails on two counts:

(1) Within it, you probably wait for edges on its input "clk".
That doesn't work.
(2) Within it, you make numerous updates on "data_serial_out"
and expect them to be reflected on whatever signal you
passed in the task's argument list. That doesn't work either.

Explanations first, answers later.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Verilog task arguments have copy-in, copy-out semantics. The
formal argument (that's the one declared within the task itself)
represents a variable that's local to the task.

WHAT HAPPENS TO INPUT AND INOUT
ARGUMENTS WHEN YOU CALL THE TASK
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When you call ("enable") the task, the actual argument (that's
the one that appears in the task call) is automatically
evaluated and its value AT THE MOMENT OF THE TASK CALL is
copied into the formal "input" argument within the task.
Consequently, if the actual argument is subsequently
updated whilst the task is running, the task itself
won't see any change on the formal argument. So,

Rule 1: NEVER WAIT ON A FORMAL ARGUMENT WITHIN A TASK.

WHAT HAPPENS TO OUTPUT AND INOUT
ARGUMENTS WHEN THE TASK EXITS NORMALLY
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For output and inout arguments, the formal is (again) a
local variable of the task. The task messes with those
local variables to its heart's content. When the task
is done, and ONLY then, all those arguments are automatically
copied back to the actual arguments which, one assumes,
are themselves variables in the calling environment.
Consequently, if you pass a variable (register) as an
actual output argument to a task, that variable will
never be updated whilst the task is running, but only
when the task exits normally.

Rule 2: NEVER TRY TO USE A TASK TO WIGGLE
ITS ACTUAL ARGUMENTS.

So far, all this sounds hopelessly feeble by comparison
with VHDL which has signal-class parameters (arguments)
that do precisely what you need. However, there is a
way to do it in Verilog that is even better than the
VHDL solution.

Let's build the solution from the inside outwards.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
First, fix the task so that it works the way you want.
Any signals that the task will wait on, and any signals
that it will manipulate during its life, cannot be task
arguments. Instead they must be module-level variables.
So, take "clk" and "data_serial_out" out of your
argument list and simply reference the appropriate
module-level signals.

task serialise;
input [15:0] data_in; // Just this one argument
integer i; // internal loop counter
for (i=15; i>=0; i=i-1)
@(posedge clk) // clk is module-level
ser_out <= data_in; // ser_out is module-level
endtask

Now our task will work, because it can see changes on clk
and it can directly affect ser_out. Passing data_in as
an argument is cool, because it's the value that we want
to be different each time we call the task. However,
we can't now use this task to drive any signal of our
choice; we've specialised it to work on one particular
set of signals "clk" and "ser_out" ....

OH NO WE HAVEN'T,

because we can now bury the task in its own little module,
and then instantiate that module once for each and every
set of signals that we want to drive.

module serial16_bfm (input clk, output reg ser_out);
task serialise
.... // as above
endtask
endmodule

Now let's build a test fixture to verify a device that
accepts two serial data streams with a common clock.

module test_dual_deserialiser;

// Signals to connect to DUT
reg clk, // system clock
serA, serB; // two serial inputs
......

// DUT instance
dual_deserialiser DUT (
.clk(clk),
.ser_in_A(serA),
.ser_in_B(serB),
.......
);

// Clock generator as usual:
initial begin
....
end

// Serial data stream generators
serial16_bfm SourceA(.clk(clk), .ser_out(serA));
serial16_bfm SourceB(.clk(clk), .ser_out(serB));

// Main test sequence:
initial begin
#50; // let the DUT settle down
// Send data to port A only:
SourceA.serialise(16'hDEAD); // NOTE task call
// Now send data to both ports at once:
fork
SourceA.serialise(16'hBADD); // NOTE task call
SourceB.serialise(16'hF00D); // NOTE task call
join
end // of test

endmodule

Isn't that just beautiful? You now have a test generator
module that you can instantiate at will to connect it to
whatever signals you want to drive. Whenever you want it
to do something you make a task call to the task WITHIN
THE MODULE, using hierarchical names. Arguments to the
task represent anything that will be different for
each run of the task, dynamically; ports on the generator
module represent signals that are hooked permanently
to the generator. Modules of this kind are commonly
called "BFMs" (bus functional models) even if they aren't
really operating a bus, because they are very often used
as cycle-generators and cycle-snoopers for bus structures.

I like to think of these BFM modules as pieces of test
gear, and the tasks in them as "control knobs" on their
front panel.

There are plenty more features and tricks you can add
to this kind of idea, but you wouldn't expect me to
give away *all* the trade secrets, would you?

hth
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.