need a cheap student edition FPGA

Thanks everyone for looking at this! I started to file a bug report with
Cadence on this and in the process I was pointed to a solution that
mentioned that they knew about this issue and it is fixed in a later service
release of the NCVerilog than I am using.

Thanks again!
Russell
 
gabor@alacron.com wrote:
Is it possible that the unit delay mode is introducing a delay
in the assign statements (which would delay clk_2 two "units" after
clk)?
Click to expand...
Good suggestion, but I don't think so. Because then my little example
code would behave incorrectly when I set delay_mode to unit. I already
checked that: it does not. That's also why I put two assign statements
in the clock, to make sure it will fail if the assign statements are
affected by delay_mode.

Paul.
 
gabor@alacron.com wrote:
Is it possible that the unit delay mode is introducing a delay
in the assign statements (which would delay clk_2 two "units" after
clk)?
Click to expand...
I believe that the "correct" behavior for unit delay mode (as
defined by the behavior of Verilog-XL) is that zero delays
remain zero. Only non-zero delays become unit delays. And
I believe that NC implements it correctly.

So while it was a good suggestion, I don't think that is what
is happening.
 
owl wrote:
Hi,

However, my confusion is not gone. I know some mismatchs between pre-
and post-synthesis simulation, like certain delays, are reasonable.
Even glitches are understandable and most time (hopefully) harmless.
But, how can I know if a specific glitch/mismatch is harmless or not?
When you experts do the synthesis and find something going wrong,
you'll go for a coffee and then sit down, trying to solve the problem.
Then, the question is, how?
Click to expand...
The best way to check synthesis results is by Equivalence Checking (EC)
and Static Timing Analysis (STA). Both are static methods, which means
that no simulation is involved. That is a good thing, because coverage
by simulation heavily depends on the input vectors and observability of
the design. EC and STA are both formal methods, rigorously checking all
possibilities.

To come back on your original question: whether a different simulation
behavior is acceptable or not depends on whether it still matches the
requirements. In fact this is the same situation as when you assess the
RTL simulation results. Intelligent monitors (such as protocol checkers)
would help in this area.

Paul.
 
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:csk7uf$fj0$1@gnus01.u.washington.edu...
Russell Fredrickson wrote:

(snip)

//check output
if(out === (32'sh80000000 >>> 6'd32)) begin
$display("PASS: 32'sh80000000 >>> 6'd32 = 0x%h", in, shift, out);
end
else begin
$display("FAIL: 32'sh80000000 >>> 6'd32 != 0x%h,",
(32'sh80000000 >>> 6'd32), " actual = 0x%h.", out);
end

When I simulate with ncverilog (version 5.3-s005) I get the following
message:

FAIL: 32'sh80000000 >>> 6'd32 != 0xffffffff, actual = 0x00000000.

If you expect 0xffffffff why do you compare to 0x80000000?
Click to expand...
I'm not comparing to 0x80000000 but to 0x80000000 arithmetic shifted by 32
(which is surrounded by parenthesis). I did this to illustrate the point
that not only is the result of the calculation of the always block not what
I expect, but that the same expression calculated in different way by the
same simulator yields different results!

For many languages including C and Java, and for most hardware
including x86, a shift greater than or equal to the width of the
word does not perform as you expect. On x86 shift amount are
modulo 32, so 0x80000000 would be expected in that case.
Click to expand...
Good point -- this is in part why I posted this -- since I realize that the
result of shifting greater than or equal to the width may not be what you
think it is. Note that in my case -- since I have 6 bits for the right-hand
side (RHS) operand, I won't get modulo 32 on the shift as you suggest
(though I would get modulo 32 if I only were using a 5-bit RHS operator).

Thanks,
Russell
 
Hi Ed,
Nice test/puzzle indeed, you mad eme walk thro' LRM for $time,
$timeformat to understand it. So If I understand it correctly, it is b'cos
$time doesn't take timeprecision into a/c while reporting as it returns an
integer.

Thanks,
Sri

--
Srinivasan Venkataramanan
Co-Author: SystemVerilog Assertions Handbook, http://www.abv-sva.org
Co-Author: Using PSL/SUGAR for Formal and Dynamic Verification 2nd Edition.
http://www.noveldv.com
I own my words and not my employer, unless specifically mentioned
"EdA" <ed.arthur@gmail.com> wrote in message
news:1106063679.247717.199640@c13g2000cwb.googlegroups.com...
The trick is using $realtime instead of $time.
Sheesh, I've got to get back to my Verilog
roots and leave those HVL's behind :)

/Ed
Click to expand...
 
Paul Uiterlinden wrote:
Does this version of ncvlog lack support of configurations? What is
the
latest version of NCSIM anyway? (I cannot find that on the Cadence
WEB
site)
Click to expand...
According to the docs, v5.4 supports configurations, although I haven't
tried them yet.

After v5.1, Cadence marketing changed the name to Incisive and the
3-letter prefix from LDV to IUS (Incisive Unified Simulator, I think).
They also skipped a version in the process. So after LDV51 came IUS53,
and now they're up to IUS54.

Your old licenses are still valid, although I can't remember if you
have to update them through Sourcelink.

-cb
 
Does this version of ncvlog lack support of configurations?
Click to expand...
NC-Verilog version 5.1 supports configurations. However,
it only allows them in a library mapping file. It does
not allow them in Verilog source files. This should be
covered in the documentation.

The Verilog-2001 LRM is actually unclear about whether
configs are allowed in Verilog source files. The text
implies that they are, but the language grammar or BNF
does not allow it. It only allows them in library
mapping files.

The original intent was actually to allow them in the
source files. However, we believe that this was a
bad idea. We have gotten considerable support for this
view in the committees, but there has been reluctance
to actually remove it. The committee consensus process
makes that difficult.
 
Paul Uiterlinden wrote:
sharp & Neo,

Thanks for your replies. Indeed, I now understand there must be a
difference between my little example and the real design (a netlist
from
Synplify) and/or my testbench. Apparently there is some path via
blocking statements from the clock to some output. I will dig into
this.

Paul.
Click to expand...
Is it possible that the unit delay mode is introducing a delay
in the assign statements (which would delay clk_2 two "units" after
clk)?
 
Robert Finch wrote:
Hi,

Is it possible to pass an array to a module in Verilog ? If so How ? I tried
this:

module arrayTest(s, a, o);
input [2:0] s;
input [3:0] a [4:0]; // this line cause the synthesizer to
croak with an error 'expecting ; not [ '
output [3:0] o;

assign o = a;

endmodule


Thanks,
Rob


I don't think it is possible, for example I had an array of 4 x 4 bit
Click to expand...

BCD numbers, I ended up just passing a 16 bit vector and then just
splitting it up again within the module:

---
input bcd_vector [15:0];

reg [3:0] bcd_char [3:0];
integer i;


always @(bcd_vector)
begin: split_up_vector

for(i=0;i<4;i=i+1)
begin
bcd_char <= bcd_vector[(4*i +4):(4*i)];
end
end

---

Then you gotta construct the vector when passing it in.

I think though it kinda defeats the purpose fo the array in this context
- which is to allow a flexible interface to your module. Though, if you
parameterise the above code you would make it quite flexible.

I'll check the verilog XL manual, as I never really looked into it, I
just used vectors.

John
 
John McBride wrote:
Robert Finch wrote:

Hi,

Is it possible to pass an array to a module in Verilog ? If so How ? I
tried this:

module arrayTest(s, a, o);
input [2:0] s;
input [3:0] a [4:0]; // this line cause the synthesizer to
croak with an error 'expecting ; not [ '
output [3:0] o;

assign o = a;

endmodule


Thanks,
Rob


I don't think it is possible, for example I had an array of 4 x 4 bit
BCD numbers, I ended up just passing a 16 bit vector and then just
splitting it up again within the module:

---
input bcd_vector [15:0];

reg [3:0] bcd_char [3:0];
integer i;


always @(bcd_vector)
begin: split_up_vector

for(i=0;i<4;i=i+1)
begin
bcd_char <= bcd_vector[(4*i +4):(4*i)];
end
end

---

Then you gotta construct the vector when passing it in.

I think though it kinda defeats the purpose fo the array in this context
- which is to allow a flexible interface to your module. Though, if you
parameterise the above code you would make it quite flexible.

I'll check the verilog XL manual, as I never really looked into it, I
just used vectors.

John



OK you can only pass in a flat array, so you have two options:
Click to expand...



1) pass in flat array

module array(a);
input [M:0] a;

2) pass in vector

module vector(a);
input a [N:0];


BUT not

module mixed(a);
input [M:0] a [N:0];

sorry!
 
Why not use VHDL directly?

Not try to mix two language together. I think you can find another
method to solve you problem if you do not think it in VHDL but
implement it in VERILOG.

Good luck
 
Robert Finch wrote:
Is it possible to pass an array to a module in Verilog ?
Click to expand...
No, it isn't.

I think that arrays in Verilog were originally intended
to represent memories in hardware. You don't generally
pass the entire contents of a memory across a bus. You
only read and write single words of it, and pass those
across busses.

Using arrays as an abstraction to represent a wide bus
made up of smaller pieces probably wasn't considered at
that point.
 
On Sat, 22 Jan 2005 23:31:01 -0500, "Robert Finch"
<robfinch@sympatico.ca> wrote:

Hi,

Is it possible to pass an array to a module in Verilog ? If so How ? I tried
this:

module arrayTest(s, a, o);
input [2:0] s;
input [3:0] a [4:0]; // this line cause the synthesizer to
croak with an error 'expecting ; not [ '
output [3:0] o;

assign o = a;

endmodule
Click to expand...

You might be more comfortable using a different HDL, such as VHDL,
which has concise, simple and effective support for such constructs.
It's synthesisable, too.

Regards,
Allan
 
mpub@sohu.com wrote:
Why not use VHDL directly?
Click to expand...
There's nothing that I'd rather do than doing just that, but it simply
is not an option. The complete design and testbench is in Verilog.

Not try to mix two language together. I think you can find another
method to solve you problem if you do not think it in VHDL but
implement it in VERILOG.
Click to expand...
Hey, I did not start it, it's Verilog that started this! :)

I mean: VHDL constructs like generates and configurations have been
brought into the language. Now that I try to use one of them, it appears
it is not usable (at least not the implementation in NCSIM).

Paul.
 
Hi,

Thanks a lot for Paul and Vikram. I'm sorry I haven't replied earlier.
Simply too busy with solving that problem. Finally my problem was
solved with the help of an engineer, who had done a similar design. In
the original RTL code, which we got as an IP core, they forget to reset
a few registers, which causes the protocol violations caught by an
self-test testbench.

However, my confusion is not gone. I know some mismatchs between pre-
and post-synthesis simulation, like certain delays, are reasonable.
Even glitches are understandable and most time (hopefully) harmless.
But, how can I know if a specific glitch/mismatch is harmless or not?
When you experts do the synthesis and find something going wrong,
you'll go for a coffee and then sit down, trying to solve the problem.
Then, the question is, how?

Best,
Owl

Paul Uiterlinden wrote:
owl wrote:
Hello,

As the subject.

What kind of mismatches are you talking about? If is is just
differences
in propagation delay sampling the outputs with an appropriate clock
would solve that.

Mismatches can also be caused by differences in the initial state of
both implementations. Reset would help there.

If the mismatches are caused by difference in abstraction level, then

observing both designs on a higher level would be the way to go. A
testbench with some intelligence, giving a pass/fail indication would
be
the best solution. This is the best solution anyway.

Paul.
Click to expand...
 
On Wed, 02 Feb 2005 16:55:06 +0000, Jonathan Bromley
<jonathan.bromley@doulos.com> wrote:

[snip]
reg [31:0 v;
...
v = 32'0xz1;
Click to expand...
whoops, that'll teach me never to re-type the code snippet
instead of pasting it... two dropped characters in three
short lines! That should have been

reg [31:0] v;
...
v = 32'h0xz1;

sorry
--
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.
 
The key phrase in the LRM is "as if ... the data were in a
s_vpi_vecval structure (See 27.14, Figure 179)." If you
look at that structure definition, you will see that the fields
are defined in the order aval then bval. Simulator B is
not compliant with the standard.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top