Problem using $recordvars/$recordfile under NCverilog

[glen herrmannsfeldt]

Barry Margolin wrote:

(snip)
(someone wrote)

The LGPL language specifically mentioned the ability to reverse engineer.

It gives you the right to reverse-engineer (you have to provide your own
ability). But if the box is all hardware, with no way to load new code
into it, that right doesn't do you a whole lot of good.

More and more often they are FPGA's with code in ROM loaded on
power up. It is more difficult to reverse engineer than object
code for popular processors, though.

-- glen

 

[Jonathan Bromley]

On 9 Aug 2004 19:03:26 -0700, thopman@uoguelph.ca
(Theo Hopman) wrote:

My problem is this: The CPLD is going to be a peripheral on a 16-bit
data bus, with standard control bus signals (i.e., RD\ and WR\ and a
CS\). For now, let's assume it's a very small memory: it should store
the data on the data bus when WR\ is asserted, and put the stored data
on the data bus when RD\ is asserted, and be tristated otherwise. I
think I've got a module which does this, but I need to test it, and
that's where the heart of the problem is. I'm not sure how to set up a
testbench to verify that my "memory" module is working the way it
should. Ideally, the testbench should write a sequence of data to the
"memory" and read it back for verification, but I must be running into
some kind of mental block here. I've got the data bus set up as
'inout', but ModelSim (XE II Starter) complains if I try to assign a
value to it, which makes it a bit difficult to do writes .

This is a standard problem with standard answers....

Problem 1: Tri-state buffers on inout ports
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The inout port must be declared as inout (obviously!)
and Verilog decrees that it must therefore be a wire,
not a reg. Consequently you can't write to it from
an always block. Not directly, anyway.

module OneBitSRAM(IO, nRd, nWr);
input nRd, nWr; // active low read/write strobes
inout IO; // bidi data port

reg Internal; // internal memory cell
reg Readback; // the data to supply on read

// Always block to administer write cycles -
// the details of this will be different for
// your device, of course. This bit of code
// is a standard "transparent latch" process,
// with (!nWr && nRd) as the latch enable signal.
//
always @(IO or nRd or nWr) begin
if (!nWr && nRd) // it's a write
// latch data into the internal register
Internal = IO; // OK to read IO directly
end

// Always block to manage generation of read data -
// again, this will be different for you. In
// my case, the readback data is exactly the contents
// of the internal latch.
//
always @(Internal)
Readback = Internal;

// Here's the fun bit - Getting the readback data out
// on to the IO port when doing a read. You can't
// do this in an always block, because the inout port
// is a wire. So we use an assign statement, driving
// the IO port with either hi-Z or Readback depending
// on the state of the controls.
//
assign IO = (!nRd && nWr) ? Readback : 1'bz;

endmodule // OneBitSRAM


Problem 2: Creating a test bench
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The slave device (OneBitSRAM, etc) responds to control signals
nRd, nWr and manipulates its IO port appropriately. By
contrast, the test fixture must manipulate the control signals
AND the bidi bus to mimic the kind of bus cycles you would see
on the real physical bus. Since it's a test bench, you can do
all manner of things that would be impossible in synthesisable
hardware designs.


module TestOneBitSRAM; // no ports, it's a test fixture

// Signals to connect to the device-under-test (DUT)
//
reg test_nRd, test_nWr; // these can be reg, because I will
// connect them to input ports of the instance

wire test_IO; // must be a wire, because I'm going to connect
// it to an inout port of a module instance

reg test_IO_write_data; // this reg will hold the value I'm
// trying to write out to the SRAM module

reg drive_enable; // this reg is used to control whether I
// drive data on to the bidirectional bus

reg test_IO_read_data; // this reg will hold the value
// I have read back from the data bus during read

// Now we need to create a tri-state driver so that we can
// drive data out on to the bus, or listen to it, at will:
//
assign test_IO = drive_enable ? test_IO_write_data : 1'bz;


// Instantiate the device under test:
//
OneBitSRAM dut(.IO(test_IO), .nRd(test_nRd), .nWr(test_nWr));


// Finally, an initial block that will execute some tests:
//
initial begin : OneWrite_OneRead

// Make everything quiet
test_nRd = 1'b1;
test_nWr = 1'b1;

// ~~~~~~~~~~~~~~ WRITE CYCLE ~~~~~~~~~~~~~~~~~~
// Set up the write data
test_IO_write_data = 1'b1; // try writing a 1
drive_enable = 1'b1; // drive out the data
// After a short setup time, do a write cycle by
// pulsing nWr low, then high
#5 test_nWr = 1'b0;
#10 test_nWr = 1'b1;
// Then leave the data valid for a short hold time
// before releasing the bus back to hi-Z
#2 drive_enable = 1'b0;
// And then leave the bus floating for a short while
#3 ;

// ~~~~~~~~~~~~~~~ READ CYCLE ~~~~~~~~~~~~~~~~~~
// Stop driving data out. I know this is paranoid,
// because I just did it (above). But if you move
// this piece of code around the place, it will
// now continue to work even if it is used at a
// time when some idiot left drive_enable active :-(
drive_enable = 1'b0;
// Drop nRd so that the memory starts to drive
// data back on to our bus
test_nRd = 1'b0;
// Hang around a while to allow the memory enough
// access time, then capture the result from the bus
#10 test_IO_read_data = test_IO;
// Release nRd
test_nRd = 1'b1;
// Check the answer is right:
if (test_IO_read_data !== 1'b1) //<whatever you expected&gt
$display("ERROR: Bad read data");
// Let everything settle, then check the memory
// really did let go of the bus...
#5 if (test_IO !== 1'bZ)
$display("ERROR, bus is still driven!");

end // OneWrite_OneRead

endmodule // TestOneBitSRAM

Note the use of "case inequality" !== (or case equality ===)
to test for *exact* matching between two values, which allows
you to check for the existence of X and Z values on a wire.

Once you've got the hang of this, PLEASE take the trouble to
package up the read and write cycle code as tasks, so that you
can write more interesting tests.

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.

 

[John_H]

For your multiplexed assignment, if mux_out is already 8 bits try:

assign mux_out = result_save >> (multiplier_width - 8 * (mux_select+1) );

 

[Byron A Jeff]

In article <591da479.0408111427.2f5bd2d9@posting.google.com>,
y_p_w <y_p_w@hotmail.com> wrote:

byron@cc.gatech.edu (Byron A Jeff) wrote in message news:<cf4amh$fkb@cleon.cc.gatech.edu>...
In article <cf12g501i0q@enews3.newsguy.com>,
Phil Tomson <ptkwt@aracnet.com> wrote:
-In article <591da479.0408051151.3a1491d4@posting.google.com>,
-y_p_w <y_p_w@hotmail.com> wrote:
-

It's funny. I spent last night having a very similar LGPL discussion on
the PICLIST mailing list about LGPL'ed libraries for embedded systems.

I decided to check in here because I think you may have gotten some bad
moo-shoo here.

->So I'll just sum up what we're looking at, what we'll do with it,
->and what we can or would rather not do:
-
->1) I've located an open-source Verilog description (released under
-> the LGPL) of a hardware function we'd like to use.
->2) We would have no problem releasing our modifications of this
-> code or giving credit to the original author; it only seems
-> fair.

Glad you think it's fair. The LGPL makes it a requirement.

Well - I'm thinking in my experience how there are companies that
pay for or otherwise obtain licenses for products, components,
services, IP, software, etc. from third parties, and want to keep
those arrangements hush-hush. Some of those companies seem to think
it hurts their reputations or standing among customers if there's a
perception that they sought outside help to do something that might
have been performed in-house. As a consumer I just want what works.

Too true. That and the effect on the bottom line. And free designs can
possibly help the bottom line of the cost of a product by lowering the
barrier to the value add.

-
-That may or may not be required, however it's nice that you're flexible in
-this area.

It is required. Changes to LGPL'ed source are essentially GPL in nature.
You must release the changes (or make a written offer to do so) to anyone who
receives the final work.

I didn't quite get that at first. I was under the impression that the
changes must be publicly available. If we only need to deliver the
changes and netlists to the customer, then it might be feasible. Most
won't really care.

->3) My employer would be extremely hesistant to release our other
-> HDL source code used in this design. Like most companies in
-> our industry, we are in the business of selling proprietary
-> hardware.

It's the standard clash of the titans between free and non-free components.

I'm a realist about how things really work. Most of the IC design
world is proprietary. We use proprietary tools, IP, and processes,
and there's not much I can do about it. I like the idea of open
source IP cores, but their licensing should take into consideration
the proprietary nature of "The Other Stuff" that is used to bring a
complete design to hardware.

I agree. I have tentatively named this imaginary license the YourCode License.
Here are its tenants:

1) Your Code is your code. Publish it, hide it, whatever. It's not my concern.

Notes: This completely drops the 10 line source test of the LGPL. If it's
code that you generate, I really don't care how you generated it or whatever
headers from MyCode are required to get the two to work together.

2) MyCode however is My Code. And I want my code to be free. So feel free to
use it as you like unmodified. But if you change MyCode, then you must treat
it GPL style i.e. publish or make offer to distribute source, note changes,
inform the users of their rights with respect to MyCode typically by
distributing a copy of the YouCode license with MyCode's modified source.

Notes: The is pretty much how the LGPL operates. This is the part I want to
keep. Note that most of the freer licenses than the LGPL like zlib and BSD
don't have this requirement. I like the above because if you're using MyCode
and you improve it so as to make it work better with YourCode, then while as
pointed out in step 1 that YourCode is your code, I'd sure like to have access
to the changes that you made to MyCode. That's fair. Right?

3) In embedded systems YourCode and MyCode generally need to be combined to
create a system. The YourCode license makes no claim upon the combined
YourCode+MyCode work subject to the following two restrictions:

A) Documentation for the work must list the usage of MyCode under the
YourCode license.
B) If the work uses a modified MyCode as outlined in section 2 then the
modified MyCode source (or an offer to distribute) must accompany the
work as outlined in section 2 above.

Notes: The rebuild right is dropped to the floor. There simply has to be som
balance in the environment that YourCode will be used, deeply embedded
systems, where the ability to rebuild and the resources to do so (which may
in fact be the sources to YourCode + your tools) often makes the cost
exhorbitant

4) Usual legalese about no warrantee, no fitness for any purpose, it's not my
fault, yada yada.

Notes: Typical CYA management.


-
-> The need for an Embedded GPL needs to exists for situations like this.

BTW this Embedded GPL is this YourCode License outlined above.

It
would have the core of the LGPL but needs language to squash these really
extraneous issues. Section 6 needs to be rewritten to modify or
eliminate the rebuild right.

I can imagine some customers might have the ability to rebuild and
perhaps produce their own versions of hardware products. I suspect
most won't go through that trouble if there's a commidity part for
sale. I'm also guessing an FPGA based-design will be impractical -
have you seen the prices for Xilinx FPGAs?

Nope. But I'll bet it's steep.

It seems to have worked well for the OSS movement, where there has
been enough critical mass to assemble something as complex as Linux.

But traditional Linux has the facilities to allow for all of GPL, LGPL, BSD,
ZLIB, and non free software to all coexist. BTW embedded Linux is having some
of the same issues we're discussing here.

As far as I can tell, most commercial Linux developers are either
selling maintenance contracts and/or selling hardware. IBM seems
to be successful at doing both.

Some are selling actual software too. But many developers and power users get
used to being able to support themselves and get annoyed when some company
tries to pull out the rug by releasing binary only software.

But a license that protects the rights of both free and non free developers
when code has to be in close proximity is needed.

Does anyone know if an existing free license matches the tenants of the
proposed YourCode license above?

BAJ

 

[y_p_w]

Byron A Jeff wrote:

In article <591da479.0408111427.2f5bd2d9@posting.google.com>,
y_p_w <y_p_w@hotmail.com> wrote:

byron@cc.gatech.edu (Byron A Jeff) wrote in message news:<cf4amh$fkb@cleon.cc.gatech.edu>...

In article <cf12g501i0q@enews3.newsguy.com>,
Phil Tomson <ptkwt@aracnet.com> wrote:
-In article <591da479.0408051151.3a1491d4@posting.google.com>,
-y_p_w <y_p_w@hotmail.com> wrote:
-

It's funny. I spent last night having a very similar LGPL discussion on
the PICLIST mailing list about LGPL'ed libraries for embedded systems.

I decided to check in here because I think you may have gotten some bad
moo-shoo here.

->So I'll just sum up what we're looking at, what we'll do with it,
->and what we can or would rather not do:
-
->1) I've located an open-source Verilog description (released under
-> the LGPL) of a hardware function we'd like to use.
->2) We would have no problem releasing our modifications of this
-> code or giving credit to the original author; it only seems
-> fair.

Glad you think it's fair. The LGPL makes it a requirement.

Well - I'm thinking in my experience how there are companies that
pay for or otherwise obtain licenses for products, components,
services, IP, software, etc. from third parties, and want to keep
those arrangements hush-hush. Some of those companies seem to think
it hurts their reputations or standing among customers if there's a
perception that they sought outside help to do something that might
have been performed in-house. As a consumer I just want what works.



Too true. That and the effect on the bottom line. And free designs can
possibly help the bottom line of the cost of a product by lowering the
barrier to the value add.



-
-That may or may not be required, however it's nice that you're flexible in
-this area.

It is required. Changes to LGPL'ed source are essentially GPL in nature.
You must release the changes (or make a written offer to do so) to anyone who
receives the final work.

I didn't quite get that at first. I was under the impression that the
changes must be publicly available. If we only need to deliver the
changes and netlists to the customer, then it might be feasible. Most
won't really care.


->3) My employer would be extremely hesistant to release our other
-> HDL source code used in this design. Like most companies in
-> our industry, we are in the business of selling proprietary
-> hardware.

It's the standard clash of the titans between free and non-free components.

I'm a realist about how things really work. Most of the IC design
world is proprietary. We use proprietary tools, IP, and processes,
and there's not much I can do about it. I like the idea of open
source IP cores, but their licensing should take into consideration
the proprietary nature of "The Other Stuff" that is used to bring a
complete design to hardware.


I agree. I have tentatively named this imaginary license the YourCode License.
Here are its tenants:

1) Your Code is your code. Publish it, hide it, whatever. It's not my concern.

Notes: This completely drops the 10 line source test of the LGPL. If it's
code that you generate, I really don't care how you generated it or whatever
headers from MyCode are required to get the two to work together.

2) MyCode however is My Code. And I want my code to be free. So feel free to
use it as you like unmodified. But if you change MyCode, then you must treat
it GPL style i.e. publish or make offer to distribute source, note changes,
inform the users of their rights with respect to MyCode typically by
distributing a copy of the YouCode license with MyCode's modified source.

Notes: The is pretty much how the LGPL operates. This is the part I want to
keep. Note that most of the freer licenses than the LGPL like zlib and BSD
don't have this requirement. I like the above because if you're using MyCode
and you improve it so as to make it work better with YourCode, then while as
pointed out in step 1 that YourCode is your code, I'd sure like to have access
to the changes that you made to MyCode. That's fair. Right?

3) In embedded systems YourCode and MyCode generally need to be combined to
create a system. The YourCode license makes no claim upon the combined
YourCode+MyCode work subject to the following two restrictions:

A) Documentation for the work must list the usage of MyCode under the
YourCode license.
B) If the work uses a modified MyCode as outlined in section 2 then the
modified MyCode source (or an offer to distribute) must accompany the
work as outlined in section 2 above.

Notes: The rebuild right is dropped to the floor. There simply has to be som
balance in the environment that YourCode will be used, deeply embedded
systems, where the ability to rebuild and the resources to do so (which may
in fact be the sources to YourCode + your tools) often makes the cost
exhorbitant

4) Usual legalese about no warrantee, no fitness for any purpose, it's not my
fault, yada yada.

Notes: Typical CYA management.


-
-> The need for an Embedded GPL needs to exists for situations like this.

BTW this Embedded GPL is this YourCode License outlined above.


It
would have the core of the LGPL but needs language to squash these really
extraneous issues. Section 6 needs to be rewritten to modify or
eliminate the rebuild right.

I can imagine some customers might have the ability to rebuild and
perhaps produce their own versions of hardware products. I suspect
most won't go through that trouble if there's a commidity part for
sale. I'm also guessing an FPGA based-design will be impractical -
have you seen the prices for Xilinx FPGAs?


Nope. But I'll bet it's steep.


It seems to have worked well for the OSS movement, where there has
been enough critical mass to assemble something as complex as Linux.


But traditional Linux has the facilities to allow for all of GPL, LGPL, BSD,
ZLIB, and non free software to all coexist. BTW embedded Linux is having some
of the same issues we're discussing here.


As far as I can tell, most commercial Linux developers are either
selling maintenance contracts and/or selling hardware. IBM seems
to be successful at doing both.


Some are selling actual software too. But many developers and power users get
used to being able to support themselves and get annoyed when some company
tries to pull out the rug by releasing binary only software.

But a license that protects the rights of both free and non free developers
when code has to be in close proximity is needed.

Does anyone know if an existing free license matches the tenants of the
proposed YourCode license above?

Don't know, yet. I've looked at some of the less restrictive license
terms, and most just say that any derivative code must contain the same
license header. Nothing about making it available like the GPL or LGPL.

 

[Ralf Hildebrandt]

mohammed rafi wrote:

can you pepole tell me how to verify a generic microprocessor.

Do you mean testing of the correct imlementation of all instructions
with "verification"?
If yes - just write a program that covers everything at a functional
level: Test of every instruction with every possible processor flag set
/ reset and every addressing mode plus every exception.


It might be helpful to put all expected results into the test program -
example for Assembler (MSP430):

mov #0x1234,R4
mov #0x5678,R5

ADD R4,R5 ;I want to test this ADD

cmp #0x68AC,R5 ;expected result
jeq good
;do error handling
good: ...


Ralf

 

[Jim Wu]

i have not seen any message about verification posted in both
comp.lang.verilog and comp.lang.vhdl. i want to initiate a discussion
about verification.

You may want to post your question on Verification Guild
(http://verificationguild.com/).

HTH
Jim (jimwu88NOOOSPAM@yahoo.com remove NOOOSPAM)
http://www.geocities.com/jimwu88/chips

 

[Blackie Beard]

Coverification is the best way.
Cover all the instructions and addressing modes w/ tests.
Write the tests in c.
compile.
convert the object to ascii hex.
use verilog readmemh into program rom.
build some small testbench w/ processor and rom and whatever.
begin sim.
If you develop Hardware Abstraction Layer you can use it
1. in your tests.
2. as library for final product.
All your simulation code will be in c.
If test reads something wrong (use assert macro) then you
write some unique pattern to a unique location which will
trigger sim to halt.






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

hi,

i have not seen any message about verification posted in both
comp.lang.verilog and comp.lang.vhdl. i want to initiate a discussion
about verification.
can you pepole tell me how to verify a generic microprocessor. if you
give me the verification plan, testplan and the list of corner cases
it will be very useful.

cheers,
m. rafi

 

[Chris F Clark]

Svilen asked:

time 100: clk = 1'b0;
//line 5: transition 1'b0 -> 1'b1 trigers @(posedge clk)

time 100: clk = 1'b1;
//line 6: The newly schedualed event executes at the same time step
100 but clk already has a changed value.
WHY?????????

In the books they say that the non-blocking assignment '<=' executes
as the last event after all blockin assignments schedualed for this
time step are executed. Even the newly trigered events

Let me see if I can answer this. You are wondering why the event
triggered on a posedge clock is happening after the non-blocking
assignment that makes the clock have the value one, despite believing
that the assignment occuring on a non-blocking edge occurs after all
other events in the time step.

It's the last part of your belief that has you mistaken. There *IS*
an order of execution spelled out for how things happen within a given
time step. That order of execution does put non-blocking assignments
as the last thing that happens. So, if you had some other statement
that occured in the time step, say the following code below that sets
zebra to 0 in time step 100, it would occur first--that is zebra would
get 0 before clk would get 1.

initial #100 zebra = 0; // clk will still be 0 when this code is executed

The same thing would be true of the following statement:

initial #100 zebra = clk; // clk will still be 0 when this code is executed

So, far you are happy right? The update event which makes clk 1
happens after all other events schduled in the same time step.

However, the order of exectuion also allows new events to be added to
the list of things to do in the time step. Your always @(posedge clk)
falls into this category. That is, the simulator action which changes
the value of clk occurs "before" (and is the cause of) the code in the
posedge clk block executing. Thus, when the simulator is doing the
updating of the value of clk as part of what was previously thought to
be the last part of the time step. It notices then (and only then,
because it is the change in the value of clk that causes it to notice)
that clk is now 1 where it used to be zero, and thus a posedge has
occurred, that it must execute the code in the posedge clk block. It
cannot execute before that, because the value of clk has not changed
(and thus a posedge has not occurred).

When this happens (and the standard spells out in fairly nice
mechanical detail how the simulator "must" make it happen), the
simulator notices that there are more activities to process in the
time step and processes those activities. (I believe the standard
calls these activities "events", but I don't have my copy at hand
right now, so I may have my terminology off. The activities that can
happen right away are active events; the activities that happen "at
the end of the cycle" are update events; and there are other classes
of events also (inactive events are at least one of them).) In any
case, by mechanically walking through the algorithm in the standard,
it is possible to see exactly when each thing in a simulator is
supposed to happen (at least for those parts the standard spells
out)-- For example, that the update events as part of non-blocking
assingments happen after #0 events in the same time cycle. However,
the occurance of one event might cause another event to be1 placed in
one of the queues described in the standard, which means that there
can be blocking assignments (normally an active event) or events
delayed by a #0 (normally an inactive event) to occur after an update
event, there simply needs to be an intervening edge trigger that gates
the later events.

Now, not to put words into your mouth, but I think you were assuming
that the non-blocking assignment "clk <= 1'b1;" immediately scheduled
(triggered) the posedge event, because the simulator knows that the
clock is going high, and left the update event until after the
triggered event happened. However, the simulator model doesn't work
that way, the posedge event doesn't "happen" until the clock changes
value. That is, it is not the event the establishes what the value of
clk will be (the first part of the non-blocking assignment determines
the value to be assigned to clk and is a normal "active" event), but
the actual changing of the value of clk that triggers the posedge
(this is the second part of a non-blocking assignment, called the
update event).

Now, part of what your books may be attempting to describe is how the
queues are structured, with the update event queue being one of the
last queues. For example, the following code may help illustrate:

initial begin
a = 0;
b = 0;
c = 0;
d = 0;
e = 0;
#1 a <= 1;
b = 1;
c = 1;
end;

always @(posedge a) e = 1;

always @(posedge b) d = 1;

At time step 0: we set all the values to 0 (and they are done by
blocking assignments, so they will be done "in order". Thus, a will
transition for x to 0, then b, then c, then d, then e.

At time step 1, we encounter a non-blocking assignment for a to 1, 1
is noted as the "next" value of a (an update event that sets a to 1 is
created). Next, a blocking assignment for b to 1 is executed.

At this point a, c, d, and e are all still 0 and b becomes 1. the
update event for a is still pending.

Now, since b is 1, the posedge block that sets d to 1 can run.
However, so can the next blocking assignment that sets c to 1. This
is a race condition. The standard doesn't tell us which will happen
first. In fact, different simulators, different options, and even
the phase of the moon may determine which the simulator picks to
execute first.

In either case, one of the two variable c or e will be set to 1.
Thus, b and either c or e will be 1 and a, d, and the other variable e
or c will be 0. The update event for a will still be pending.

If c = 1 was executed first, then the e = 1 event is the only
remaining active event and it will execute next. Similarly, if the e
= 1 event was execute first, the c = 1 event will be the only active
event, and it will be executed next.

In either case, now b, c, and e will be 1 and a and d will be 0, and
the update event for a will still be pending.

At this point, we have exhausted all the active events. If there were
any inactive events (scheduled by a #0), they could now run. the
inactive events could also trigger other events and they would run
also.

However, since there are no inactive events and no active events, the
simulator runs the update events. In this case, there is one, the one
which sets a to 1. At this point, then a, b, c, and e are all 1--e is
still 0.

Since, the posedge on a has occured, the e = 1 event can now happen
and it does and all five variables are now 1.

For this set of code, the standard has clearly spelled out which
orders the variables can be set in (and intentionally left some of the
ordering up to the implementation). It is possible to use the same
part(s) of the standard to reason through other cases. Does this make
what happens more clear to you?

Hope this helps,
-Chris

*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------

 

[John_H]

Each port would be a module.
If the ports are "identical" you don't need parameters, just unique names
for the modules.
Verilog only takes 1-D vectors through the module ports, so you should
convert the 3-D control to a 1-D vector before instantiating the module and
convert back from 1-D to 3-D within the port module.

Another approach might be to use the Verilog 2001 generate statement to
implement n ports in a generate for loop allowing better access to the 3-D
array. No paramters are used, just the genvar to count through the n
instantiations with a unique value for each port.

"Dilin" <dilin_divakar@yahoo.com> wrote in message
news:7fec3fec.0408161458.29666bda@posting.google.com...

Hello All,

Can anyone tell me how to solve the following problems

Context: I'm designing a multiport device which has identical ports,
therefore i would like to make my ports flexible, basically reuse the
same port just by changing the parameter value. Someone please help me
to solve this issue.

Also tell me how to create a 3D array in verilog. I need a 3D array
to represent the control signal for all the ports, which is accessible
by all the ports. Even the Size of the 3D array will be decided by the
number of port, which is going to be flexible.

please give me a reply ASAP

thanks in advance
DILIN

 

[Blackie Beard]

Can you give me link to familiarize myself with "cycle c"?
Never heard of it before.

Regards,
BB

"john jakson" <johnjakson@yahoo.com> wrote in message
news:adb3971c.0408150633.58edd691@posting.google.com...

m_mohammedrafi@yahoo.com (mohammed rafi) wrote in message
news:<977f64b1.0408132104.29346160@posting.google.com>...
hi,

i have not seen any message about verification posted in both
comp.lang.verilog and comp.lang.vhdl. i want to initiate a discussion
about verification.
can you pepole tell me how to verify a generic microprocessor. if you
give me the verification plan, testplan and the list of corner cases
it will be very useful.

cheers,
m. rafi

If you have the time to model the cpu in both HDL and Cycle C (RTL
style) you can directly do most of the verification in C.

You should have a compiler to gen bin code for cpu ISA and run that on
the model to produce trace logs for all important busses,signals.
These logs could run to millions of cycles. If you can boot an OS your
in pretty good shape.

Then its a matter of pruning down the tests to run on HDL to make sure
HDL is same as Cycle C model bus by bus.

Maintaining 2 models seems alot of trouble but you do get to do most
of the work in a programming env in a tiny fraction of the time.

Ofcourse you need a 3rd C model that is free of HW detail that is used
to check the cycle C model too, opcode by opcode assuming cpu is in
order design.

regards

johnjakson_usa_com

 

[Blackie Beard]

"john jakson" <johnjakson@yahoo.com> wrote in message
news:adb3971c.0408171631.3e92d4d5@posting.google.com...

chris@engim.com (Chris Briggs) wrote in message
news:<f8e87dac.0408170631.667c7617@posting.google.com>...
Well, there was a startup 4-5 years ago called C-Level Design that
promoted a C-based design style called "Cycle C." They claimed
incredible simulation speedups based on it and they had a tool to
convert it to synthesizable Verilog RTL. Apparently either it didn't
work too well or they couldn't convince anyone that it did, because if
memory serves the company basically ran out of money and was acquired
by Synopsys for a song. Synopsys dropped the products and said that
some of C-Level's simulator technology would make its way into VCS.

However, I'm not sure this is what john jakson was referring to. I
think what he meant is a cycle-accurate C model. This would be a model
of your cpu, written in C, that behaves correctly down to the
interface level with cycle timing. I.e., internally it's a behavioral
model that has no timing or delays and probably doesn't describe the
actual internal organization. But you should be able to compare its
interface behavior with the real RTL model and they should match.

-cb



snipping

True, there were once half a dozen C companies showing their wares at
DAC, don't think any survived. On John Cooleys website you can find
some old anti C discussion. Most VLSI guys detest the thought of using
C but as I said if you can live with the severe limits its not so bad
for single clock small hierarchy etc. Wouldn't want to force it on
anyone and its not easy to persude people to use something faster but
is also not easy to use.

My ideal solution would be a V compiler that is mostly C even a little
C++ but with some verilog syntax & semantics added to it to make it
possible to write RTL Verilog that but has cycle C perf but is also
synthesieable. It might not have any event model to start.

SystemVerilog does it the other way round and isn't done yet either.
Too big for my tastes.

regards

johnjakson_usa_com

// ==================================================== //

Wow, that was a pretty intense explanation, thanks for taking out the time.
I think you're right about the ideal solution. I'd always previously
believed
that at least certain things ought to be unified, like the '{' & '}' instead
of the
"begin" & "end", (concatenation could be represented some other way), and
the switch/case instead of the case/(state list). Then there's the
"#define"
instead of the " `define". Seems like if the designers of verilog really
wanted
it to look like C, they could have done a better job. I also wish they
could
roll back assembly and make it look more like C - to this day I still write
assembly programs and catch myself using "//" for comments. Sheesh.

But since a lot of tools I use don't always have the latest options, I just
code
in Verilog to be safe. I don't even code in Verilog2001, yet. It's not
just
because I'm an old fart, I just want my code to be compatible with any tool,
any foundry, etc.

Best regards,
BB

 

[Shalom Bresticker]

No.

Shalom


Ron wrote:

Is multidimensional arrays allowed to be used as ports in Verilog 2000 syntax??

Ex. input wire [31:0] dummy [31:0];

--
Shalom Bresticker Shalom.Bresticker @freescale.com
Design & Reuse Methodology Tel: +972 9 9522268
Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478

[ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary

 

[Jason Zheng]

marc wrote:

Hello all,
i am fairly new to the verilog syntax and concepts
and so the following code may seem inapropriate

however, i am trying to build a cla with a module within a module
approach
i receive the following errors over the assign lines can someone
wxplain my wrondoings?


** Error: D:/This_is_my_Hard_disk/year3/Summer/Techen/Tl_examp/four_bit_cla.v(22):
LHS in force may not be a net: g_one_zero
** Error: D:/This_is_my_Hard_disk/year3/Summer/Techen/Tl_examp/four_bit_cla.v(23):
LHS in force may not be a net: p_one_zero


module two_bit_cla(g_one_zero,p_one_zero,s_2bit,x_2bit,y_2bit,cin);
input [1:0] x_2bit,y_2bit;
input cin;
output [1:0]s_2bit;
reg Dont_care;
reg [1:0]gen,prop;
reg c1;
output g_one_zero,p_one_zero;

adder s0(Dont_care,s_2bit[0],x_2bit[0],y_2bit[0],cin); //using 1-bit
adder
generate_prop gp0(x_2bit[0],y_2bit[0],gen[0],prop[0]);

adder s1(Dont_care,s_2bit[1],x_2bit[1],y_2bit[1],c1); //using 1-bit
adder
generate_prop gp1(x_2bit[1],y_2bit[1],gen[1],prop[1]);

always @(x_2bit or y_2bit or cin)
begin
c1 = gen[0] || (prop[0] && cin);
//c2 = gen[1] || (prop[1] && gen[0]) || (prop[1] && prop[0] && cin);
//c3 = gen[2] || (prop[2]&& gen[1]) || (prop[2] && prop[1] && gen[0])
//||(prop[2]&& prop[1] && prop[0]&&cin);
assign g_one_zero = gen[1] || (prop[1] && gen[0]);
assign p_one_zero = prop[1] && prop [0];
Continuous assignments should be placed outside of always blocks.

You did not user x_2bit or y_2bit within this block, why put them in the
sensitivity list?

end
endmodule

module generate_prop(x,y,gen,prop);
input x,y;
output gen,prop;
always@(x or y)
begin
end
assign gen = x && y;
x & y
assign prop = x ^ y;
endmodule

module adder ( cout, sum, a, b, cin ) ;

parameter n = 0 ;

output cout ;
output [n:0] sum ;

input [n:0] a, b ;
input cin ;

assign { cout, sum } = a + b + cin ;

endmodule


i try to use instances of models in one larger model as my idea is
to recursivly use 2bit cla for a 4bit cla and so on.

Thanks in advance,
marc.

 

[Kholdoun TORKI]

Try this link. A great software utility running on Windows.

http://www.logiccell.com/~jean/LFSR/

Regards,
=================
Kholdoun TORKI
http://cmp.imag.fr
==================

Dev wrote:

Hi all,


Could you pls explain what LSFR is ?
or where can I obtain some information on them.

thanks in advance

Dev

 

[Javier Castillo]

Hello:

It depends the simulator you are using. But in most of them they provide a
binary to generate a VHDL wrapper for the verilog module you can
instantiate into your VHDL code. Then you compile all and works.

Regards

Javier Castillo

jcastillo@opensocdesign.com
www.opensocdesign.com


chandrika.anad@gmail.com (cka) wrote in news:def708b0.0408270435.2bbc1466
@posting.google.com:

hi,
i have code written in verilog and want to download it onto an FPGA.
the top level file with the port assignments is in VHDL. how can the
keyword foreign in vhdl be used to instantiate the verilog module in
vhdl?
can somebody give me an example on how to do this?
thank you.
cka.

 

[Glen Herrmannsfeldt]

Steven Sharp wrote:
(snip)

Here is my understanding of the history.

Verilog was designed as a simulation language. It is a programming
language with specialized constructs for modeling digital hardware.
If you created a design from existing hardware components, and wrote
accurate models for those components, you could simulate the design.
You could also write more abstract architectural models of a system,
and then do stepwise refinement of the design. When it became detailed
enough that it was expressed in terms of your available low-level
components, you would have a completed design.

Were both structural model and behavioral model in from the
beginning? I usually try to write structural model, as it
seems to map to logic design more directly. The one
exception is that flip-flops and latches don't have a good
structural representation, though I enclose them in a
module and reference it in structural model.

At a later time, somebody came up with the idea of synthesizing
Verilog into hardware. A synthesis tool tries to perform the later
lowest-level stages of refinement to actual components for you,
automatically. It tries to produce hardware that closely approximates
the behavior of the model it is given. It can only handle a subset
of the Verilog language, and it doesn't always approximate it as
accurately as would be desired.

If one considers verilog (or VHDL) as a way to express the
wiring up of logic gates, it isn't hard to guess what should
and should not be synthsizable.

Some of the errors in approximation
occur because you can write things in Verilog that can't be done in
actual hardware (for example, I can write a model for a nand gate with
a 1fs propagation delay, but that doesn't mean I really have such a
component). Others are because the tool isn't smart enough to
"understand" the model like a human would, and the rules it uses
produce wrong results in some cases.

Some are because the people who write the synthesizers don't
believe anyone would want to do some operations. As I understand
it, most won't synthesize divide, and I almost don't disagree.
A real combinatorial divider for a reasonable number of bits
will be very large and very slow. Still, it might be that one
is useful and needed. Logic density is increasing fast, and what
wasn't useful yesterday may be today or tomorrow.

Synthesis has become so commonly used that many engineers make the
mistake of regarding the output of synthesis as "defining" the
meaning of the input Verilog code. New users hear that they can
compile Verilog into hardware, and assume they can throw in any
Verilog and get hardware that perfectly matches the specified
behavior, like a software compiler.

New users of compiled software languages make the same mistakes.
I remember when I was first learning Fortran (in the F66 days)
trying to use a variable for the FORMAT statement number. It would
be possible to compile it, probably not efficient, but the standard
doesn't allow it.

Experienced users have learned
what hardware gets produced for given Verilog input. As they write
Verilog, they keep in mind what hardware they expect to be produced,
and start to regard that as the "meaning" of the Verilog.

I usually consider it the other way, I know the logic I want
and then consider the verilog that should generate it,
preferably without too much writing.

In fact, the meaning of the Verilog language itself is defined by
the simulation behavior. The behavior of the synthesis output just
tells you how well (or poorly) the synthesis tool managed to match
that.

(snip)

-- glen

 

[CEO-VCC]

Virtual Compute Corporation does not supply or support or supply this
product. I think you may have the wrong corporation.

 

[CEO-VCC]

We have never supplied this product I can only assume you have the wrong
company!

Edward Hawes
CEO - VCC

 

[David Roberts]

On Sat, 28 Aug 2004 22:37:37 -0700, Steve Hamm wrote:

Hello everyone

I am a beginner in Verilog and want to know how does Specify Blocks
work.

specify
in => out = 3;
endspecify

out = in & 1;

does it mean that in & 1 will be evaluated at t=3ns and then assigned to
out or in & 1 will be evaluated at t=0ns and then after 3ns it will be
assigned to out.

The evaluation occures when ever the inputs change. If a
new output value is detected the output will be scheduled
to change after the requested delay. As in your example
above at t=0ns out is detected to change. The value scheduled
to change 3ns later.

--David Roberts

Thanks in advance for helping me.

Regards
Steve Hamm