Problem using $recordvars/$recordfile under NCverilog

[Mr. Tangent]

On 7 Sep 2004 05:25:06 -0700, with raygun in hand the aliens forced
matthewparker@public-files.de (matthew parker) to write:

matt parker alias erik vonlint herzog@yahoo.com matt parker alias erick von lindt@yahoo.com the site anti%73cam.org libels uninvolved females for unwarranted commercial purposes matt parker alias e von lunsen hout@yahoo.com matt parker alias erickvonlindthout@yahoo.com matt parker alias erikvanlunsenhout@yahoo.com matt parker alias philipcrew@yahoo.com matt parker alias e van lunsen
herzog@yahoo.com matt parker alias yda@yahoo.com matt parker alias tania dochenkova@yahoo.com matt parker alias eric lunsen@yahoo.com matt parker alias erick von lunsenherzog@yahoo.com matt parker alias evanlunsen herzog@yahoo.com matt parker alias sam smith@yahoo.com matt parker alias erick vonlunsenherzog@yahoo.com matt parker alias e von lintherzog@yahoo.com matt parker alias ag@yahoo.

*SNIIIIIIP*

Shouldn't this be cross-posted to alt.alien.vampires.flonk.flonk? I
mean, it's been a WHILE since I've been on usenet but the trolls don't
seem like they have their act together anymore.

--

Mr. Tangent [the binary police]

"Religion is a magic device for turning unanswerable
questions into unquestionable answers." -Art Gecko,
Wombat Discord-1, 128649

** to e-mail me take out the "FUNK" **

 

[Javier Castillo]

Hello:

We work in a similar way than you, we first made the RT model in
SystemC, we verificate it using TLM style with SCV features and then we
made a automatic translation to Verilog using a tool we will release
very soon under GPL license at www.opensocdesign.com.
You are rigth, our measures also indicates that the simulation in
SystemC and in Verilog run at almost the same speed. SystemC creators
said that one of the advantages of SystemC is the speed, obviously is
not true, maybe Cadence NCSystemC is faster, I dont know, but the GPL
implementation of SystemC not.
But the main advantage I think is not the simulation speed. I think the
main advantage of SystemC is the verification environment, the SystemC
Verification Library and the easy way to integrate C code that allows to
create a very powerfull verification environment. It is true that you
can also can made similar things using Verilog and PLI but is not so
easy and here with simulating Verilog with PLI, the simulation is slower
than one only with SystemC.

Regards

Javier Castillo
jcastillo@opensocdesign.com
www.opensocdesign.com


singh.shailendra@gmail.com wrote in
news:ab4d6621.0409072214.6b8ae5a@posting.google.com:

Hi,
Can anybody elaborate on the speed of the simulation in systemC in
comparision with Verilog. In our case we have used the systemC for
the modeling of RTL design, then verified the systemC RTL models. As
a final step
systemC RTL is converted into verilog RTL(line by line translation).
we are surprised to see the both systemC models and Verilog models are
running at almost same speed. Can you through some light on it, what
went wrong in the process?
is it systemC coding is not proper or may be testbench not written
properly or
if we code systemC and Verilog at same level of abstraction we should
same speed only.

 

[John_H]

"Dan" <dan.costin@gmail.com> wrote in message
news:f4e089e0.0409080418.3184736@posting.google.com...

I need to do a ramp in verilog.......I need to start with 4hz
frequency and in 300 steps I need to have 12mhz.I need to do same
action every time but with every step my frequency must be
modified...(this is for a stepper motor acceleration)....

Use a high frequency clock, much greater than 12 MHz.

Either divide this master clock by a new value at each step or use a phase
accumulator where the phase value added each cycle is changed each step of
the ramp. The phase accumulator may give a better frequency match at the
higher frequencies but will also provide a little jitter. For a stepper
motor, I would suspect jitter isn't a problem.

 

[Jos De Laender]

A good starting point , in my opinion , to gain some insight in the
matter is asking :
why would _you_ think SystemC is faster or slower ?

Jos

singh.shailendra@gmail.com wrote:

Hi,
Can anybody elaborate on the speed of the simulation in systemC in
comparision with Verilog. In our case we have used the systemC for
the modeling of RTL design, then verified the systemC RTL models. As
a final step
systemC RTL is converted into verilog RTL(line by line translation).
we are surprised to see the both systemC models and Verilog models are
running at almost same speed. Can you through some light on it, what
went wrong in the process?
is it systemC coding is not proper or may be testbench not written
properly or
if we code systemC and Verilog at same level of abstraction we should
same speed only.

 

[Russell Fredrickson]

Okay -- I think you (and others who replied) have missed one of the main
points of SystemC. One of the points of SystemC is to enable you to model
and simulate things at a HIGHER level of abstraction than RTL. If you write
code at the RT level -- it will probably always simulate on the same order
of magnitude whether it's Verilog or SystemC -- in fact since the Verilog
simulators are more mature -- Verilog may simulate faster than SystemC
(though I haven't done the exact measurements myself and it is simulator
dependent). The talk about SystemC being faster is making the assumption
that you write SystemC at a higher level of abstraction than your RTL.
Though, as a side note, there are several vendors out there who will
translate Verilog to optimized C/C++ or SystemC and then get about a 10x or
more improvement over Verilog (TenisonEDA and Carbon Systems come to mind).

In my opinion -- writing RTL in SystemC is a waste of time since Verilog (or
VHDL) is more suitable to that task (and maintaining RTL descriptions in TWO
languages seems like even more of a waste of time and is asking for
trouble). In any case you can always have Verilog and SystemC co-exist by
interfacing SystemC to RTL through a PLI or using one of the unified
SystemC/Verilog simulators.

My point -- adopting a new language without also adopting a new methodology
that makes use of the power of the language will only give you limited
benefit (if any benefit at all). For example, when going from schematic
capture to Verilog -- many people at first used Verilog just like a textual
schematic capture tool. This got them using an HDL (which is a step in the
write direction), but they really didn't get the full advantage of the HDL
until they started writing RTL that then could then synthesized into gates
(basically raising the level of abstraction at which they modeled their
design).

So for SystemC some of the power of the language comes in being able to do a
top-down implementation where you start with a high-level architectural
model and refine it down to the RTL level (or perhaps use a behavioral
synthesis tool once you get down to a appropriate level of abstraction).
Also the SystemC Verification extensions (SCV) is another way SystemC can be
used to improve your verification effort (here again -- you will probably
need to use a different verification methodology to make full use of SCVs
capabilities). I'll stop there -- if you look hard enough you should be
able to find other references talking about the new methodologies enabled by
SystemC.

I hope that helps,
Russell



<singh.shailendra@gmail.com> wrote in message
news:ab4d6621.0409072214.6b8ae5a@posting.google.com...

Hi,
Can anybody elaborate on the speed of the simulation in systemC in
comparision with Verilog. In our case we have used the systemC for
the modeling of RTL design, then verified the systemC RTL models. As
a final step
systemC RTL is converted into verilog RTL(line by line translation).
we are surprised to see the both systemC models and Verilog models are
running at almost same speed. Can you through some light on it, what
went wrong in the process?
is it systemC coding is not proper or may be testbench not written
properly or
if we code systemC and Verilog at same level of abstraction we should
same speed only.

 

[Jos De Laender]

Russell Fredrickson wrote:

Okay -- I think you (and others who replied) have missed one of the main
points of SystemC. One of the points of SystemC is to enable you to model
and simulate things at a HIGHER level of abstraction than RTL. If you write
code at the RT level -- it will probably always simulate on the same order
of magnitude whether it's Verilog or SystemC -- in fact since the Verilog
simulators are more mature -- Verilog may simulate faster than SystemC
SNIP

I don't count myself in the "and others who replied" ;-)
You hit the main point : Higher level of abstraction (i.e. omitting
detailed information) improves performance.
You even don't need SystemC for that. It's very well possible in VHDL
and probably Verilog too.

Jos

 

[Javier Castillo]

Hello:

I dont think the use of SystemC for RT design is a waste of time. I think
of course ,that it main advantage is the possibility of describe the system
in a higher abstraction level and to develop the verification environment
at this level of abstraction, but for the moment there are not tools that
make a synthesis from this high abstraction level. The results is that you
have to refine the model and finally write the RT modules of your system.

If you want to take advantage of the verification environment you have
developed before, you have to write the RT modules in systemC. You will say
that you can write them in Verilog and them use a tool that allows
simulation of mixed languages, of course, but this tools are really
expensive and the code you write is not compatible with the SystemC GPL
implementation.

We use systemC in that way, we first develop a verification environment and
a high level model of the system. Then we refine the model to a RT
description in SystemC and we use the same verification environment
changing the transactors to verificate the RT model. When the RT model is
correct, we translate the RT model to Verilog with a automatic translation
tool in ordet to synthetise it. We dont maintain two descriptions since
the Verilog is an automatic translation from systemC and believe me, that
is works really well.

I dont know if you have used SystemC for RT design, we use it extensively
and I can say it can be used for RT design without any problem.
I dont understand why to use PLI or mixed language simulators since there
are a working implementation of syntemC, suitable for RT design, that works
fine.
If you dont believe me, go to www.opencores.org and download SystemCAES,
SystemCDES or SystemCMD5 projects and you will see systemC RT designs with
a high level model and a verification environment and its automatic
translation to verilog working.

Regards

Javier Castillo
jcastillo@opensocdesign.com
www.opensocdesign.com


"Russell Fredrickson" <russell_fredrickson@hp.com> wrote in
news:chnpum$vq2$1@news.vcd.hp.com:

Okay -- I think you (and others who replied) have missed one of the
main points of SystemC. One of the points of SystemC is to enable you
to model and simulate things at a HIGHER level of abstraction than
RTL. If you write code at the RT level -- it will probably always
simulate on the same order of magnitude whether it's Verilog or
SystemC -- in fact since the Verilog simulators are more mature --
Verilog may simulate faster than SystemC (though I haven't done the
exact measurements myself and it is simulator dependent). The talk
about SystemC being faster is making the assumption that you write
SystemC at a higher level of abstraction than your RTL. Though, as a
side note, there are several vendors out there who will translate
Verilog to optimized C/C++ or SystemC and then get about a 10x or more
improvement over Verilog (TenisonEDA and Carbon Systems come to mind).

In my opinion -- writing RTL in SystemC is a waste of time since
Verilog (or VHDL) is more suitable to that task (and maintaining RTL
descriptions in TWO languages seems like even more of a waste of time
and is asking for trouble). In any case you can always have Verilog
and SystemC co-exist by interfacing SystemC to RTL through a PLI or
using one of the unified SystemC/Verilog simulators.

My point -- adopting a new language without also adopting a new
methodology that makes use of the power of the language will only give
you limited benefit (if any benefit at all). For example, when going
from schematic capture to Verilog -- many people at first used Verilog
just like a textual schematic capture tool. This got them using an
HDL (which is a step in the write direction), but they really didn't
get the full advantage of the HDL until they started writing RTL that
then could then synthesized into gates (basically raising the level of
abstraction at which they modeled their design).

So for SystemC some of the power of the language comes in being able
to do a top-down implementation where you start with a high-level
architectural model and refine it down to the RTL level (or perhaps
use a behavioral synthesis tool once you get down to a appropriate
level of abstraction). Also the SystemC Verification extensions (SCV)
is another way SystemC can be used to improve your verification effort
(here again -- you will probably need to use a different verification
methodology to make full use of SCVs capabilities). I'll stop there
-- if you look hard enough you should be able to find other references
talking about the new methodologies enabled by SystemC.

I hope that helps,
Russell



singh.shailendra@gmail.com> wrote in message
news:ab4d6621.0409072214.6b8ae5a@posting.google.com...
Hi,
Can anybody elaborate on the speed of the simulation in systemC in
comparision with Verilog. In our case we have used the systemC for
the modeling of RTL design, then verified the systemC RTL models. As
a final step
systemC RTL is converted into verilog RTL(line by line translation).
we are surprised to see the both systemC models and Verilog models
are running at almost same speed. Can you through some light on it,
what went wrong in the process?
is it systemC coding is not proper or may be testbench not written
properly or
if we code systemC and Verilog at same level of abstraction we should
same speed only.

 

[glen herrmannsfeldt]

Swapnajit Mittra wrote:

gah@ugcs.caltech.edu> wrote in message news:<chl0cq$1am$1@gnus01.u.washington.edu>...

(snip)

I have seen gates with tri-state outputs used to drive such
inputs, allowing all three input levels to be used.
One could simulate this with the 1`bZ state, I suppose.

The Cypress chip (and many others in its category - clock skew
generators, PLLs, VCOs etc.) are not binary digital logic
circuit that Verilog can handle (I use 'binary' as opposed
to many-valued logic, which are realizable in hardware
since mid 60s for them and 'digital logic' as opposed to mixed
signal domain).

Yes, they are in a different category. It was interesting to me
that the question came up when only last week I learned about
the Cypress chip, and also one other using three level inputs.

There was also discussion some years ago about using four level
inputs to carry two bits between chips using half as many pins
as binary signals.

After considering for so long that digital circuits couldn't
detect 1`bZ, it is interesting to see a case where they can.

-- glen

 

[jtw]

"Varun Jindal" <varunjindal@yahoo.com> wrote in message
news:a132b4b3.0409092047.6e2980bc@posting.google.com...

Hello Russell,

I have a model in SystemC and to simulate it with Verilog testbench, i
am using a PLI (for VCS). you have mentioned SystemC/Verilog
co-simulators, but i have not been able to find any. Does anybody know
any such simulators available?
Modelsim, for one: VHDL, verilog, and SystemC (to a limited extent.)

Of course, you need the appropriate licen$e$.

Thanks in Advance.

regards
Varun.

Jason

 

[Russell Fredrickson]

The one we are using is the Cadence Insicive Unified Simulator. I know
Mentor has a version as well (don't know about Synopsys). I don't know
about the Mentor version -- but The Cadence implementation is very nice in
that you can do things like call Verilog functions/tasks from SystemC (and
in the next version -- IUS 5.4 -- you are supposed to be able to call
SystemC functions from Verilog), instantiate SystemC inside Verilog (and
vice versa), directly access Verilog memories from SystemC, etc. In
addition, they do have an integrated environment debug environment and a
good transaction recording facility (from what I can tell -- I haven't used
the transaction recording too much yet). Cadence also has it's hands in
donating major portions of the SystemC add on libraries (SCV, TLM
methodology) -- so they really good in terms of full support for most
anything you want to do with SystemC. Again, I really don't have any data
on Mentor's version, so I can't comment on it.

Russell


"Varun Jindal" <varunjindal@yahoo.com> wrote in message
news:a132b4b3.0409092047.6e2980bc@posting.google.com...

Hello Russell,

I have a model in SystemC and to simulate it with Verilog testbench, i
am using a PLI (for VCS). you have mentioned SystemC/Verilog
co-simulators, but i have not been able to find any. Does anybody know
any such simulators available?

Thanks in Advance.

regards
Varun.





"Russell Fredrickson" <russell_fredrickson@hp.com> wrote in message
news:<chnpum$vq2$1@news.vcd.hp.com>...
Okay -- I think you (and others who replied) have missed one of the main
points of SystemC. One of the points of SystemC is to enable you to
model
and simulate things at a HIGHER level of abstraction than RTL. If you
write
code at the RT level -- it will probably always simulate on the same
order
of magnitude whether it's Verilog or SystemC -- in fact since the
Verilog
simulators are more mature -- Verilog may simulate faster than SystemC
(though I haven't done the exact measurements myself and it is simulator
dependent). The talk about SystemC being faster is making the
assumption
that you write SystemC at a higher level of abstraction than your RTL.
Though, as a side note, there are several vendors out there who will
translate Verilog to optimized C/C++ or SystemC and then get about a 10x
or
more improvement over Verilog (TenisonEDA and Carbon Systems come to
mind).

In my opinion -- writing RTL in SystemC is a waste of time since Verilog
(or
VHDL) is more suitable to that task (and maintaining RTL descriptions in
TWO
languages seems like even more of a waste of time and is asking for
trouble). In any case you can always have Verilog and SystemC co-exist
by
interfacing SystemC to RTL through a PLI or using one of the unified
SystemC/Verilog simulators.

My point -- adopting a new language without also adopting a new
methodology
that makes use of the power of the language will only give you limited
benefit (if any benefit at all). For example, when going from schematic
capture to Verilog -- many people at first used Verilog just like a
textual
schematic capture tool. This got them using an HDL (which is a step in
the
write direction), but they really didn't get the full advantage of the
HDL
until they started writing RTL that then could then synthesized into
gates
(basically raising the level of abstraction at which they modeled their
design).

So for SystemC some of the power of the language comes in being able to
do a
top-down implementation where you start with a high-level architectural
model and refine it down to the RTL level (or perhaps use a behavioral
synthesis tool once you get down to a appropriate level of abstraction).
Also the SystemC Verification extensions (SCV) is another way SystemC
can be
used to improve your verification effort (here again -- you will
probably
need to use a different verification methodology to make full use of
SCVs
capabilities). I'll stop there -- if you look hard enough you should be
able to find other references talking about the new methodologies
enabled by
SystemC.

I hope that helps,
Russell



singh.shailendra@gmail.com> wrote in message
news:ab4d6621.0409072214.6b8ae5a@posting.google.com...
Hi,
Can anybody elaborate on the speed of the simulation in systemC in
comparision with Verilog. In our case we have used the systemC for
the modeling of RTL design, then verified the systemC RTL models. As
a final step
systemC RTL is converted into verilog RTL(line by line translation).
we are surprised to see the both systemC models and Verilog models are
running at almost same speed. Can you through some light on it, what
went wrong in the process?
is it systemC coding is not proper or may be testbench not written
properly or
if we code systemC and Verilog at same level of abstraction we should
same speed only.

 

[glen herrmannsfeldt]

Alexander Gnusin wrote:

I do believe, that it is possible to write design in SystemC. There
may be some advantages of this approach for people with strong C
background. There are obviously drawbacks too, and I would like to
outline some of them.

Personally, I am against HDL's that are more C like than verilog.

To me, they make people believe that one can think serially, as
when writing in a programming language. In hardware, everything
at least has the possibility of being active all the time, and the
language should emphasize that.

Consider the ability to port a serial algorithm written in C to a
hardware implementation of that algorithm.

-- glen

 

[vikramts]

hi zohar

i am trying to learn instantiation and simulation and i dont know how to
write testbenches either.could you please share any tips/suggestions that
u r aware of?

thanx

vikram

 

[Javier Castillo]

aaruljain@gmail.com (Aarul Jain) wrote in
news:15891236.0409130014.5e7a0662@posting.google.com:

Hello

I am trying to learn systemc. Systemc was already installed in one of
the servers and I am using Solaris 2.8 with gcc 3.3

I am trying to run example programs from the installation directory.
However when I run make i get error message

-------compiles the code and generates .o --------
----
g++ -I. -I..
-I/_TOOLS_/dist/systemc-2.0.1/sparc-sun-solaris2.8/include -L. -L..
-L/_TOOLS_/dist/systemc-2.0.1/sparc-sun-solaris2.8/libS/gcc-3.2.2 -o
run.x source.o sink.o fft.o main.o -lsystemc -lm 2>&1 | c++filt
Undefined first referenced
symbol in file
CoolLog::CoolLog[in-charge](char const*, char*,
bool)/_TOOLS_/dist/systemc-2.0.1/sparc-sun-solaris2.8/libS/gcc-3.2.2/li
bsystemc.a(sc_main.o) ld: fatal: Symbol referencing errors. No output
written to run.x collect2: ld returned 1 exit status

I tried to do everything I could but it seems there is some problem in
makefiles.

Following are the makefiles I used.

Makefile

TARGET_ARCH = gccsparcOS5

CC = g++
OPT = -O3
DEBUG = -g
OTHER = -Wall
EXTRA_CFLAGS = $(OPT) $(OTHER)
# EXTRA_CFLAGS = $(DEBUG) $(OTHER)

MODULE = run
SRCS = source.cpp sink.cpp fft.cpp main.cpp
OBJS = $(SRCS:.cpp=.o)

include ../Makefile.defs


Makefile.defs

## Variable that points to SystemC installation path
SYSTEMC = /_TOOLS_/dist/systemc-2.0.1/sparc-sun-solaris2.8


INCDIR = -I. -I.. -I$(SYSTEMC)/include
LIBDIR = -L. -L.. -L$(SYSTEMC)/libS/gcc-3.2.2
Hello:

Try to use gcc 3.2 instead 3.3

Regards

Javier Castillo
jcastillo@opensocdesign.com
www.opensocdesign.com

LIBS = -lsystemc -lm $(EXTRA_LIBS)


EXE = $(MODULE).x

.SUFFIXES: .cc .cpp .o .x

$(EXE): $(OBJS) $(SYSTEMC)/libS/gcc-3.2.2/libsystemc.a
$(CC) $(CFLAGS) $(INCDIR) $(LIBDIR) -o $@ $(OBJS) $(LIBS) 2>&1 |
c++filt

.cpp.o:
$(CC) $(CFLAGS) $(INCDIR) -c $

.cc.o:
$(CC) $(CFLAGS) $(INCDIR) -c $

clean::
rm -f $(OBJS) *~ $(EXE) core

ultraclean: clean
rm -f Makefile.deps

Makefile.deps:
# $(CC) $(CFLAGS) $(INCDIR) -M $(SRCS) >> Makefile.deps

#include Makefile.deps


Please help somebody, bu mailing me a running code or suggesting any
modifications to this code.

 

[Javier Castillo]

Hello:

I dont want to have a discussion about what is better, because is obvious
that actually Verilog or VHDL are more mature HDLs and SystemC is a newbie.
The thing I want to transmit is that systemC can be used for RT design with
its current limitations. I say current because the SystemC Synthesis
Working Group is working in improve the SystemC capabilities in order to
make SystemC a RT solution as Verilog is.

About your comments, I am agree in some of them because is obvious that
tools have a Verilog input and doesnt support SystemC. This Verilog input
is the reason to make a translation of the SystemC code, but I expect the
EDA suppliers will add SystemC support in their products.

But I am not agree in other things, for example when you said:

In addition to design, I also doubt that SystemC is a good choise for
the whole verification environment. For the system-level verification,
it is a good choise since it allows seamless interoperability with the
software. For the functional verification, verification-specific
languages (HVL)or SystemVerilog would be much better choise.
Functional verification requires advanced coverage, random generation,
assertion support as well as may other items such as random stability
etc. I doubt that SystemC has similar capabilities comparing to HVLs
or SV.

One of the strongest features of SystemC is the verification capabilities.
The SystemC Verification Library provides random generation, transaction
recording and many other features. Assertion or advance coverage is not
possible, the only thing you can do is a line coverage metric using GNU
gcov program. But as I said I expect EDA vendors will supply a SystemC
front end in their products.

1. Translation problems. I am really suspicious about "complete
automatization" of language translation process. The problem is to
make it work in ALL the cases. The easiest way to cleanup translation
may be to reduce "translatable" subset in SystemC. It may not be a
problem, but then it reduces "synthesizable" subset of SystemC and
converts it to even more limited subset of synthesizable Verilog RTL.
2. Descriptive power.
Verilog as a language was developed for RTL coding and constantly
improves during years of practice. For example, Verilog 2001 and then
SystemVerilog defines new useful constructs such as always_comb,
always_ff etc allowing designer to specify design intent in a way that
tools can verify. I doubt that SystemC has similar operator or can
produce them during code translation.

We are talking about using SystemC as a RT language, and as a RT language
you can do the same things you make in Verilog. Verilog and SystemC are
different, and since they are different some things are described in a
different way, for example assign statement in Verilog has to be translated
into a combinational process in SystemC, but it can be translated. I think
that all the Verilog RT subset has translation into SystemC.


Regards

Javier Castillo
jcastillo@opensocdesign.com
www.opensocdesign.com

 

[John_H]

var = data>>i*width; // assumes var is "width" wide


"Jon Beniston" <jon@beniston.com> wrote in message
news:e87b9ce8.0409170713.1f5891de@posting.google.com...

Hi all,

Does anyone know of a crafty way of emulating the behaviour of Verilog
2001 indexed vector part selects in Verilog 1995?

i.e.

var = data[i*width +: width];

where i is a variable in a function, and width is constant.

Cheers,
Jon

 

[Petter Gustad]

varunjindal@yahoo.com (Varun Jindal) writes:

i am looking for a tool, which can flatten my verilog design,

I wrote such a tool around 1990, it was used to generate netlists for
the Dazix CAD system. Unfortunately, I don't have access the source
anymore. Writing such a program wasn't that difficult. Nowadays it's
probably simpler since you can find parsers available on the net. You
can also run your design through synthesis (works at least in Synopsys
Design Compiler) and flatten the design and write it out to a Verilog
file.

Petter

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[Marko]

You might try the following:

377> always @(*)
378 case(pri_sel) // synopsys parallel_case full_case
379 2'd0: pri_out = pri_out0;
380 2'd1: pri_out = pri_out1;
381 2'd2: pri_out = pri_out2;
382 endcase


On 17 Sep 2004 00:05:20 -0700, cornel.arnet@gmail.com (Cornel Arnet)
wrote:

Hi there,

I'm trying to synthesize wb_dma (opencores.org) from the Xilinx
Project Navigator 6.2.03i. It's the first time that I'm using Verilog
and the Xilinx tools (I've got some experience with VHDL and Altera
tools though).

XST yields the following error:

ERROR:Xst:1468 - wb_dma_ch_pri_enc.v line 377: Unexpected event in
always block sensitivity list.

and refers to:

...
377> always @(pri_sel or pri_out0 or pri_out1 or pri_out2)
378 case(pri_sel) // synopsys parallel_case full_case
379 2'd0: pri_out = pri_out0;
380 2'd1: pri_out = pri_out1;
381 2'd2: pri_out = pri_out2;
382 endcase
...

There's something wrong with my preferences I guess...thanks.

Regards,
Cornel

 

[glen herrmannsfeldt]

rickman wrote:

Actually, what you are describing is a VHDL coding issue, not a MAP
issue. If you want a 21 bit result from a VHDL add (I don't know
Verilog well enough to say) you have to have at least one 21 bit input.
VHDL won't assume that you expect a 21 bit result.

I am not sure about verilog. If I assign to a variable
the same width as the operands of +, I get warnings
about truncated bits.

One book says that {cout, sum} = in1 + in2 + cin;
will generate a full adder.

Another book says that the width for + is maximum of the width
of the two operands.

cross posted to comp.lang.verilog, to see if anyone there can say.

-- glen

 

[Petter Gustad]

varunjindal@yahoo.com (Varun Jindal) writes:

Well, if the problem statement requires the flattened netlist NOT to
be in form of logic gates ... i dont know if it can be done through
the Synopsys Design Compiler.

You should be able to set the dont_touch attribute on the blocks that
you don't want to be compiled, even though I haven't tried just to
flatten a netlist without doing any compliation in DC myself.

Petter

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[John_H]

The led needed to be a reg (preferred) or taken outside of the always block
to an assign. The reg is prefered because some glitching might occur for a
combinatorial assign - not a big problem for a visual indicator, but why not
get in the habit of making it a clean signal?.

"John_H" <johnhandwork@mail.com> wrote in message
news:XG%5d.2$r56.1366@news-west.eli.net...

module pulse(led_o, clk50);

input clk50;
output led_o;
reg [25:0] c; // 2^26 = 67108864 > 50000000
reg led_o; // pointed out elsewhere, a reg is needed
always @(posedge clk50) //Trigger on 50MHz clock
begin
if (c == 50000000) //Convert 50MHz Clock to 1Hz
// begin/end needed before else if more than 1 statement
c <= 0;
else
c <= c + 1; //Step up c +1
led_o <= (c[25:21] >= 5'h15); // ~60ms until reset
end

endmodule