need a cheap student edition FPGA

Chris Briggs wrote:
For simulation tools check out Cliff Cummings' Verilog-2001
scoreboard
doc at http://www.sunburst-design.com/papers/.
Click to expand...
It should be noted that this paper was written early in 2003, and is
a couple of years out of date by now. Tool vendors have not been
sitting still during that time.
 
Chris Briggs wrote:
For simulation tools check out Cliff Cummings' Verilog-2001
scoreboard
doc at http://www.sunburst-design.com/papers/.
Click to expand...
It should be noted that this paper was written early in 2003, and is
a couple of years out of date by now. Tool vendors have not been
sitting still during that time.
 
owl wrote:
Hello,

As the subject.
Click to expand...
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.
 
owl wrote:
Hello,

As the subject.
Click to expand...
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.
 
glen herrmannsfeldt wrote:
Jason Zheng wrote:

Has anyone compiled cver on a sparc platform?


I tried to compile it on a sun blade 1000 workstation, but i get the
following error:


(snip)

Undefined first referenced
symbol in file
strerror_r ../objs/v_ex.o
ld: fatal: Symbol referencing errors. No output written to ../bin/cver


strerror_r is the reentrant version (with an extra argument) of
the C library strerror routine. It seems that Solaris doesn't have one.

It might be that source is readily available, though I am surprised that
to configuration script didn't figure it out.

-- glen

I got a reply from cver's support email. Turns out you can change
Click to expand...
strerror_r to strerror. It compiled just fine.

Jason
 
owl wrote:
Hello,

As the subject. I'd like to know normally how you experts resolve the
mismatches. I'm more used to higher abstract level design, but now I'm
assigned a design with more than 100k gates and it resulted in tons of
mismatches between the pre- and post-synthesis simulations! If anybody
can give me some hint, like a link to a paper, book or website...
Thanks and bye,
Owl

see Cliff Cumming's paper on simulation/synthesis mismatch:
Click to expand...
http://www.sunburst-design.com/papers/CummingsSNUG1999SJ_SynthMismatch_rev1_1.pdf
 
Hi,
your descrition inside the edge clocked process dosent match any
realizable logic element, thats the reason its complaining. when you
use edges of clock then you cannot have parallel if constructions, you
have to use if-else-else if constructs. Or you will have to remove the
posedge constructs from your sentivity list- which will give latches.
 
Take a look at $timeformat system task to see if it helps.

HTH,
jimwu88NOOOSPAM@yahoo.com (remove capital letters)
http://www.geocities.com/jimwu88/chips


"EdA" <ed.arthur@gmail.com> wrote in message
news:1105998609.215969.141790@z14g2000cwz.googlegroups.com...
% cat junk.v
`timescale 1ns/100ps

module tb();
reg [7:0] snd;
reg clk;

initial begin
$dumpvars;
$timeformat(-9, 1, "ns", 6);
end

initial begin
clk = 0;
snd = 0;
$display("INFO %t clk: %b send: %h", $time, clk, snd);
#30 $finish;
end

always @(posedge clk) begin
#0.3 snd = snd + 1;
$display("INFO %t clk: %b send: %h", $time, clk, snd);
#0.3 snd = snd + 1;
$display("INFO %t clk: %b send: %h", $time, clk, snd);
#0.3 snd = snd + 1;
$display("INFO %t clk: %b send: %h", $time, clk, snd);
#0.3 snd = snd + 1;
$display("INFO %t clk: %b send: %h", $time, clk, snd);
end

always begin
#10 clk = ~clk;
end

endmodule


Why is the output like:

INFO 0.0ns clk: 0 send: 00
INFO 10.0ns clk: 1 send: 01
INFO 11.0ns clk: 1 send: 02
INFO 11.0ns clk: 1 send: 03
INFO 11.0ns clk: 1 send: 04


And not:

INFO 0.0ns clk: 0 send: 00
INFO 10.3ns clk: 1 send: 01
INFO 10.6ns clk: 1 send: 02
INFO 10.9ns clk: 1 send: 03
INFO 11.2ns clk: 1 send: 04


The $dumpvars dump file has it right (VCS and Verilog-XL):

#103
b00000001 !
#106
b00000010 !
#109
b00000011 !
#112
b00000100 !


Thanks,
/Ed
Click to expand...
 
Been through the manual (LRM) many times.
Tried various values.

$timeformat(-9, 1, "ns", 6);

-9 - nanosections
1 - places past the decimal point (tried, 3, 6)
"ns" - string
6 - total chars (tried 9, 10, 20)

/Ed
 
Prime wrote:
Hi, I am trying to replace an LS573 latch with a CPLD (because in future
I want to be able to do address decoding as well as latching, and a CPLD
will keep my chip count down). But am running into problems, here is my
current code :-

odule avrinterface(AD,RD,WR,ALE,Ahigh,Addr,Dram,CS,RRD,RWR);
input RD; // RD from AVR
input WR; // WR from AVR
input ALE; // Address Latch from AVR
input Ahigh; // High address lines [8..15] from AVR

output [15:0] Addr; // Address lines to RAM
output CS; // Chip select to RAM
output RRD; // RD to ram
output RWR; // WR to ram

inout AD; // Multiplexed low address lines/data lines
from AVR
inout Dram; // Data lines to/from RAM

reg [7:0] Alow = 8'h00;
reg [7:0] DataBuf = 8'h00;
reg [15:0] Addr = 16'h0000;

wire [7:0] Dramin;

assign RRD = RD;
assign RWR = WR;
assign CS = 0;

assign Dramin = Dram;

assign AD = RD ? DataBuf : 8'bz;
assign Dram = WR ? DataBuf : 8'bz;

always @(posedge ALE or posedge RD or posedge WR)
begin
if (ALE == 1)
begin
Alow <= AD;
Addr <= {Ahigh,Alow};
end

if (RD == 1)
begin
DataBuf <= Dramin;
end

if (WR == 1)
begin
DataBuf <= AD;
end
end

endmodule


The latch is used to interface an AVR microcontroler to some standard
SRAM, the AVR multiplexes the bottom 8 address bits and the data bits on
the same port, the top address bits are not multiplexed. The ALE signal
determines if the multiplexed port is data or address, High=Address, RD
and WR are standard active high Read and Write signals.

The problem I get is that when I try and synthisise the above code I get
:-

ERROR:Xst:899 - avrinterface.v line 38: The logic for <Alow> does not
match a known FF or Latch template.
ERROR:Xst:899 - avrinterface.v line 39: The logic for <Addr> does not
match a known FF or Latch template.
Click to expand...
The template you are using for a latch is not correct. It should be:

always @(en, din)
if (en)
qout <= din;

Furthermore, you cannot combine different enables into one always block.
So the correct way is:

always @(ALE or AD or Ahigh or Alow)
if (ALE)
begin
Alow <= AD;
Addr <= {Ahigh,Alow};
end


Hmm, for DataBuf you need something more: a mux followed by a latch, I
suppose.

assign DB = RD ? Dramin : AD;
always @(RD or WR or Dramin)
if (RD | WR)
DataBuf <= DB;

All untested of course.

Paul.
 
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
 
Jason Zheng wrote:
owl wrote:
Hello,

As the subject. I'd like to know normally how you experts resolve
the
mismatches. I'm more used to higher abstract level design, but now
I'm
assigned a design with more than 100k gates and it resulted in tons
of
mismatches between the pre- and post-synthesis simulations! If
anybody
can give me some hint, like a link to a paper, book or website...
Thanks and bye,
Owl

see Cliff Cumming's paper on simulation/synthesis mismatch:

http://www.sunburst-design.com/papers/CummingsSNUG1999SJ_SynthMismatch_rev1_1.pdf
Click to expand...

It may help to run a formal verification tool on the netlist and RTL.
If this results in a lot of mismatches, then try running on the
individual modules of the design and get them to pass and then move
onto the top level.

-Vikram.
 
Paul Uiterlinden wrote:
I have a general question: is it safe to have a continuous assign
statement in a clock line, or does this introduce a race condition?
Click to expand...
It can certainly introduce a race condition. Actually, to be correct,
the design contains a race condition, and putting a continuous assign
in a clock path may cause it to be exposed, i.e. produce a different
result by changing the order that changes occur. In general, putting
a continuous assignment in a clock path may delay the output to a later
point in the same time slice.

A certain simulation (which has an assignment in a clock line) passes
in
ModelSim, but fails in ncsim (only when delay_mode is set to unit, as
I
found out later).
Click to expand...
Different results in different simulators indicates either a bug in one
of them, or a race condition in your design.

Below is some code that I created to reproduce the error. Whatever I
try
though, q1, q2 and q3 correctly clock in the data from before the
rising
clock edge, so I'm not quite sure whether the assign im the clock is
a
prolem or not.
Click to expand...
Since your sample code uses nonblocking assignments, which introduce a
delay into the data path that is guaranteed to be greater than any
number
of zero-delay continuous assignments in series, it should not have any
races between clock and data.

Presumably your actual design is different from this sample code in
some way.
 
Russell Fredrickson wrote:
Hi all,

I'm seeing some mismatching results for a Verilog 2001 arithmetic shift

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

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

So in other words, the output of the always block is 0x00000000 when I would
expect it to be 0xffffffff (which is what the manual testbench calculation
and the synthesis come out to). Is this a bug in NCVerilog? What does the
Verilog 2001 LRM specify in this regards when the arithmetic shift is
greater or equal to the width of the operand? When one envisions how one
would implement an arithmetic shift in hardware (by left-filling with the
sign bit), I would expect the answer to be 0xffffffff.

Thanks in advance,
Russell
Click to expand...

Russel,

I ran your code through gplcver and it passed. Could it be a ncverilog
glitch?
 
Jason Zheng wrote:
Russell Fredrickson wrote:

Hi all,

I'm seeing some mismatching results for a Verilog 2001 arithmetic
shift

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

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

So in other words, the output of the always block is 0x00000000 when I
would
expect it to be 0xffffffff (which is what the manual testbench
calculation
and the synthesis come out to). Is this a bug in NCVerilog? What
does the
Verilog 2001 LRM specify in this regards when the arithmetic shift is
greater or equal to the width of the operand? When one envisions how one
would implement an arithmetic shift in hardware (by left-filling with the
sign bit), I would expect the answer to be 0xffffffff.

Thanks in advance,
Russell



Russel,

I ran your code through gplcver and it passed. Could it be a ncverilog
glitch?
Click to expand...
This is the simulator output:

GPLCVER_2.10a of 10/12/04 (Sparc-Solaris).
Copyright (c) 1991-2004 Pragmatic C Software Corp.
All Rights reserved. Licensed under the GNU General Public License
(GPL).
See the 'COPYING' file for details. NO WARRANTY provided.
Today is Tue Jan 18 17:09:16 2005.
Compiling source file "shift_test.v"
Highest level modules:
ArithmeticShiftTest

PASS: 80000000 >>> 32 = 0xffffffff
0 simulation events and 0 declarative immediate assigns processed.
8 behavioral statements executed (4 procedural suspends).
Times (in sec.): Translate 0.0, load/optimize 0.1, simulation 0.1.
End of GPLCVER_2.10a at Tue Jan 18 17:09:16 2005 (elapsed 0.0 seconds).

Compilation finished at Tue Jan 18 17:09:16

I got similar results on ncverilog (5.10), however.

- Jason
 
I ran you code in latest version of modelsim ie 6.0 and it ran fine,
got the message as :
PASS: 32'sh80000000 >>> 6'd32 = 0x8000000032 -1
I think it should work as you expected.

-Neo
 
I dont see why there should be any race condition with this code. it
should work perfectly as though there was only a single clock 'clk'
since you are using non-blocking statements in the procedural blocks.
-Neo
 
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.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top