Clock Edge notation

[Edwin Naroska]

Hi,


William Wallace wrote:

You act as though being strongly typed is a good thing. I'll take
C over ADA any day,

Hmm, I think it depends on the problem that has to be solved.
For large projects, I wouldn't take C. Would you?
I love to program in C/C++, did it for years and will
continue to. But, to be honest, I also see its weaknesses.
If there are no important reasons to use C/C++ (e.g.,
maximize speed of executable) I choose another language.
I've spent too many hours hunting stupid bugs that
slipped into the code due to the "creative interpretation"
of the source code by the C/C++ compiler.

We are facing design complexities, where the major problem
is not designing but verifying that the system works
as intended. Hence, time to market is not just determined
by the design time but also by the effort to fix all the
bugs. The software guys already faced this problem and
found their solutions (e.g., shift away from C/C++
if possible).

So, the major question is whether it pays of to invest some
more effort during design in order save verification time.
In my opinion, this is the better approach for now and
especially for the future.



--
Edwin

 

[Jan Decaluwe]

Jonathan Bromley wrote:

Many an engineer who has taught himself Verilog will screw up
a few designs by misuse of blocking and nonblocking assignment.
Your argument is in favour of proper training and learning, not
a reason for using one language rather than another.

It's worse than that. The fatal Verilog flaw of not making
a distinction between variable and signal causes *eternal*
confusion, even among "gurus", and leads to absurd rules
like "don't use both blocking and nonblocking assignments
in the same always block". In VHDL, this would mean
"don't use both variable and signal assignment in the same
process". Verilog courses will happily "train" you on this
fantastic insight. Talking about progress ...

Regards, Jan

--
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
Bored with EDA the way it is? Check this:
http://jandecaluwe.com/Tools/MyHDL/Overview.html

 

[Tim Hubberstey]

Willem Oosthuizen wrote:

I have some working code that contains:

constant Wait4Fas0_State : std_logic_vector(Ts_Sync_State'range) :=
conv_std_logic_vector(0,Ts_Sync_State'length);

and

case Ts_Sync_State is
when Wait4Fas0_State => if Fas_Found_Unbound = '1' then

This normally gives me a warning, but with Modelsim SE I get an Error:

** Error:
D:/mentor/Hds/hds_projects/my_project/my_project_lib/hdl/basic_e1_syncer_STA
TE_MAC.vhd(128): Case choice must be a locally static expression.

Surely constants are locally static? Any way to set the tool up to change
the error to a warning? I have lots of code that uses
conv_std_logic_vector to generate constants. It is pain to rewrite the code.

<rant on>

Many things in VHDL *SHOULD* be locally static but aren't. I consider
this a huge error on the part of the original language developers. The
justification for this was to make it easier for the compiler! Talk
about misplaced priorities. This is what happens when you let tool
developers specify a language instead of the users.

<rant off>

ModelSim PE has the following switch in the modelsim.ini file:

; Keep silent about case statement static warnings.
; Default is to give a warning.
NoCaseStaticError = 1

I don't know if this is available in SE but it's worth looking into. I
don't remember this switch in older versions of PE so it may be a
relatively new addition. Is your SE version current?

On a more philosophical note, you should avoid doing anything that
violates the LRM, even if your tool allows it. At some point you may
need to change tools, or the tool supplier may decide to correct the
non-conformance, and then you'll be screwed (like now).
--
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com

 

[William Wallace]

Renaud Pacalet <MonPrenom.MonNom@PasDeSpam.MonInstitution.France> wrote in message news:<bi4kpp$1jmr$1@avanie.enst.fr>...

Could you explain where it comes
from and what are the associated semantics?

It was a rant, and this particular rant was based on a problem for which I do
not remember all the details, so I withdraw it

 

[Jos De Laender]

Just a related thought. You can safely interchange C with Verilog and
ADA with VHDL


I've finally become convinced that C really IS better than Ada,
for the following reasons:


FOR THE PROGRAMMER

...Hacking away in C is fun, you can add trapdoors and trojan horses real
easy

...You can write neat stuff like the following code fragments:

#define BITCOUNT(x) (((BX_(x)+(BX_(x)>>4)) & 0x0F0F0F0F) % 255)
#define BX_(x) ((x) - (((x)>>1)&0x77777777) \
- (((x)>>2)&0x33333333) \
- (((x)>>3)&0x11111111)
p = BX_;

n = ((n>>1) & 0x55555555) | ((n<<1) & 0xaaaaaaaa);
n = ((n>>2) & 0x33333333) | ((n<<2) & 0xcccccccc);
n = ((n>>4) & 0x0f0f0f0f) | ((n<<4) & 0xf0f0f0f0);
n = ((n>>8) & 0x00ff00ff) | ((n<<8) & 0xff00ff00);
n = ((n>>16) & 0x0000ffff) | ((n<<16) & 0xffff0000);

which is difficult to understand, and makes you look really, really
clever,
even though it does something utterly trivial ( p is the number of
bits in n,
and n ends up with its bit order reversed )

...You'll always have a secure job, trying to make sense of other
people's code
after they've left

...You'll always have a secure job, as with well-written, terse, tight
and
efficient C YOU are the ONLY one who can easily understand your own
code!

...You'll always have a secure job, as large C programs always have lots
of bugs,
and require oodles of maintenance

...Compiling is really easy - even when the stuff you're compiling is
utter
garbage, the compiler won't tell on you

...You can ignore most of your coding errors until quite late in the day
- with
any luck, until you've left the project


FOR THE SUPPLIER

...You can always find C hackers, and they're dirt cheap

...With C, you get the initial build done quick, cheap and dirty, and
make a
fortune over the next 10 years putting in new bugs while removing old
ones.


FOR THE CUSTOMER

...Because programmers and suppliers tell you so.



Ada is worse than C because

...Only Anal-retentive weenies who mumble about Quality and
Professionalism
would get any fun out of Ada

...You'd get into the habit of writing stuff like

with MACHINE_SPECIFIC;

procedure COUNT_BITS_AND_REVERSE
( THE_WORD : in out MACHINE_SPECIFIC.WORD_TYPE,
THE_COUNT : out MACHINE_SPECIFIC.BIT_COUNT_TYPE
) is

declare

package BIT_OPS renames MACHINE_SPECIFIC.BIT_OPERATIONS;

begin

THE_COUNT := BIT_OPS.BIT_COUNT_OF(THE_WORD);
BIT_OPS.REVERSE_BIT_ORDER_OF(THE_WORD);

exception

when others => raise CODE_CORRUPTED_OR_HARDWARE_ERROR;

end COUNT_BITS_AND_REVERSE;

which any fool can easily understand, even though it does trap some
of
the errors caused by the over-running array bounds in the C you've
had
to PRAGMA INTERFACE to, soft errors, and hardware glitches.
Not only that, it works on 16, 32, 64, 48 etc bit machines as well.
so
can't get lots of bucks writing different versions.
And then the compiler barfs, and tells you what you've done wrong!

...You spend a long time looking for a job, as your code on the last
project
worked so well that the project completed on time, and you were no
longer
needed.

...You spend a long time looking for a job, as the maintenance effort
needed
consisted of 2 part-timers rather than the whole development team

...You spend a long time looking for a job, as no-one uses Ada

...Getting a Clean Compile of anything non-trivial is quite difficult.

...Your Ego takes a hammering by the compiler constantly showing you
where
you made mistakes. And if not the compiler, the Linker!


FOR A SUPPLIER

...Ada programmers are rare and expensive. You can't hire cheap graduate
coolies.

...It costs more initially to make a system, and it takes longer. Much
worse,
there's almost no maintenance, so your only revenue is from the
initial sale.


FOR A CUSTOMER

...Because the programmers and suppliers tell you so.


That's the bottom line, people. The only people who benefit from Ada are
the
customers and users. The user riding on a 777 generally doesn't know
that any
programming was involved, and the customers rely on advice from their
suppliers.

Until we understand that, all arguments regarding the qualities of Ada
are
irrelevant.

 

[Jan Decaluwe]

William Wallace wrote:

Types in VHDL are nice, if you know what you're doing, and realize
you're playing with sharp knives, but too many VHDL designers use
these sharp knives as crutches, without taking the time to consider
what the types represent, and run into, for example, sign extension
bugs, counters with more bits than necessary, etc.

It's not using (abstract) types that will cause problems, but *not* using
them. For example, by trying to map everything to std_logic_vector.

I've seen std_logic_vectors converted to signed, sent to another
module, where it was again converted to an integer, where it was added
to a constant integer and incorrectly used in a comparison with
another integer that had its range restricted to positive numbers,
resulting in a bug that was not detected due to (and this is not a
VHDL issue) incomplete testing at the module level.

Where was the bug exactly? There's nothing wrong with comparing
a potentially negative number with a positive one.

If only this
whole thing had been done with std_logic_vectors...

but you *can't* without ending up with obscure code. For example,
you cannot use std_logic_vector as a number without either
- using non-standard, even standard-violating, obscure packages (please don't!)
- coding at a very low level with all 0's and 1'
- using obscure type conversions all over the place

You can chalk it up to poor engineering (if a module level test bench
had be written testing the range of inputs, this bug would have been
discovered earlier and less expensively), but my intuition tells me
that if the whole thing had been coded with std_logic_vectors, or in
Verilog, the issue would not have reared its head.

Use reason over intuition this time then. That should tell you
that trying to use a strongly type language as lowly type one,
will naturally get you into trouble.

The problem you describe seems to have something to do with
the valid range of a number. What would be the appropriate
type then? Obviously, a constrained integer subtype. These
at least give you a *chance* to flag a problem much earlier than
any of the other types (including the Verilog ones) because
you basically get bound-check assertions for "free".

Regards, Jan


--
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
Bored with EDA the way it is? Check this:
http://jandecaluwe.com/Tools/MyHDL/Overview.html

 

[Colin Paul Gloster]

Jonathan Bromley wrote:
"[..]
Your argument is in favour of proper training and learning, not
a reason for using one language rather than another."

In article <3F45E6EE.C40B89C3@jandecaluwe.com>, Jan Decaluwe wrote:

"[..] The fatal Verilog flaw of not making
a distinction between variable and signal causes *eternal*
confusion, even among "gurus", [..]
Verilog courses will happily "train" you on this
fantastic insight. Talking about progress ..."

Ah, miseducation. I recently looked at HDL lecture notes by a
Verilog lecturer reputed to be anti-VHDL. There was one just
VHDL example in the notes I saw. He used a signal assignment
operator on a variable.

 

[Weng Tianxiang]

It is not a big deal to correct the error:

signal Wait4Fas0_State_S : std_logic_vector(Ts_Sync_State'range);

Wait4Fas0_State_S <= Wait4Fas0_State; -- outside any process

case Ts_Sync_State_R is
when Wait4Fas0_State => if Fas_Found_Unbound = '1' then

It will work.

Weng

Tim Hubberstey <sendme@no.spam> wrote in message news:<3F4642C1.41912976@no.spam>...

Willem Oosthuizen wrote:

I have some working code that contains:

constant Wait4Fas0_State : std_logic_vector(Ts_Sync_State'range) :=
conv_std_logic_vector(0,Ts_Sync_State'length);

and

case Ts_Sync_State is
when Wait4Fas0_State => if Fas_Found_Unbound = '1' then

This normally gives me a warning, but with Modelsim SE I get an Error:

** Error:
D:/mentor/Hds/hds_projects/my_project/my_project_lib/hdl/basic_e1_syncer_STA
TE_MAC.vhd(128): Case choice must be a locally static expression.

Surely constants are locally static? Any way to set the tool up to change
the error to a warning? I have lots of code that uses
conv_std_logic_vector to generate constants. It is pain to rewrite the code.

rant on

Many things in VHDL *SHOULD* be locally static but aren't. I consider
this a huge error on the part of the original language developers. The
justification for this was to make it easier for the compiler! Talk
about misplaced priorities. This is what happens when you let tool
developers specify a language instead of the users.

rant off

ModelSim PE has the following switch in the modelsim.ini file:

; Keep silent about case statement static warnings.
; Default is to give a warning.
NoCaseStaticError = 1

I don't know if this is available in SE but it's worth looking into. I
don't remember this switch in older versions of PE so it may be a
relatively new addition. Is your SE version current?

On a more philosophical note, you should avoid doing anything that
violates the LRM, even if your tool allows it. At some point you may
need to change tools, or the tool supplier may decide to correct the
non-conformance, and then you'll be screwed (like now).

 

[Allan Herriman]

Francisco Camarero wrote:

Hello!

The design I am currently working with (E0) makes
two instances (U1 and U2) of a component defined by
the entity E1 that has several architecture
versions, in my case up to 4.

I hope this code extract helps to explain myself:

entity E1 is
..
end E1;

architecture A1 of E1 is
..
end architecture A1;

architecture A2 of E1 is
..
end architecture A2;

architecture A3 of E1 is
..
end architecture A2;

architecture A4 of E1 is
..
end architecture A2;


entity E0 is
..
end E0;

architecture A0 of E0 is
..
component E1
..
begin
..
U1: E1
..
U2: E1
..
end architecture A0;


I am using Modelsim, and I would like to be able
to choose which configuration to use for the E1s
when I call vsim.

Currently I would have to use 16 different VHDL configurations
for this purpose:


configuration C11 of E0 is
for A0
for U1 : E1
use entity work.E1(A1);
end for;
for U2 : E1
use entity work.E1(A1);
end for;
end for;
end configuration C0;

configuration C12 of E0 is
for A0
for U1 : E1
use entity work.E1(A1);
end for;
for U2 : E1
use entity work.E1(A2);
end for;
end for;
end configuration C0;

..

configuration C44 of E0 is
for A0
for U1 : E1
use entity work.E1(A4);
end for;
for U2 : E1
use entity work.E1(A4);
end for;
end for;
end configuration C0;



Is there no more efficient way to do this ?

Is there a posibility to give this configuration through
the vsim command line ? something like:

vsim work.E0 U1=E1(A2) U2=E1(A2) ?

You can specify a configuration on the vsim command line, in place of
the top level entity (E0 in this case). This would still require 16
configurations.

You can also specify a generic on the command line with the
-g<label>=<value> or -G<label>=<value> switches, and use an if-generate
statement in your code to select the configuration.
This requires 8 configurations (with two generics).

Or, you could avoid configurations altogether, and use two sets of four
if-generates that select the architecture directly (with two generics).


Regards,
Allan.

 

[Allan Herriman]

Jonathan Bromley wrote:

"Francisco Camarero" <camarero@ee.ethz.ch> wrote in
message news:3F4E0482.2FA5855B@ee.ethz.ch...

I am sincerely thinking about having Perl or Tcl automatically
generate the configuration file, compile it, and call vsim with
the result.

[big snip]

Is there any *fundamental* reason why the name of a VHDL component (or
entity or configuration) being instantiated has to be fixed?

As long as it is globally static (i.e. known at elaboration time) it
ought to be possible to use an expression to provide the component name.

I have written modules (sorry, entity/architecture pairs) in the past
that have just been a big series of if-generate statements, each around
an instantiation that only differs in the name of the entity being
instantiated. Being able to use a function to determine the entity name
would reduce this code to a single instantiation.

This, of course, would be a major change to the language and tools, and
I'm not seriously proposing it as a change.

Regards,
Allan.

 

[Francisco Camarero]

Very nice!

A little overkill for my needs, but I can start from here.

Thanks!

Fran.


Jonathan Bromley wrote:

So I've
built a little macrogenerator in Tcl (which means, of course,
that you can run it from within ModelSim). It uses <n> as the
name of a macro, where n is any string of digits.
Each macro is given a list of possible values using
a metacomment line such as "--<1> A1 A2 A3 A4".
The macrogenerator collects together all these macro
definitions, and then does a substitution on the source
text, once for each possible combination of all the
macros' values. It works for any number of macros(!)
but here's the code that solves Francisco's problem:

~~~~~~~~~~~~~~~~ macro source file ~~~~~~~~~~~~~~~~~
~~~~~~~ to be processed by the Tcl script ~~~~~~~~~~

-- Automatically generated VHDL configuration
-- using architecture <1> for instance U1
-- and architecture <2> for instance U2
--
-- Here's the list of architectures to use
-- for the various substitutions:
--
--<1> A1 A2 A3 A4
--<2> A1 A2 A3 A4
--
--<begin
configuration Cfg_<1>_<2> of E0 is
for A0
for U1 : E1
use entity work.E1(<1>
end for;
for U2 : E1
use entity work.E1(<2>
end for;
end for;
end configuration Cfg_<1>_<2>;
--<end

~~~~~~~~~~~~~~ end of macro source file ~~~~~~~~~~~~

And here's the Tcl script, or strictly speaking, the
bunch of Tcl procedures. Source this script into a
Tcl interpreter, then invoke the top-level proc

build_configs sourcefile.vhd resultfile.vhd

(with obvious changes to filenames as needed).

It's left as a trivial exercise for the reader
to turn it into something robust and useful

Does anyone know if the same thing is possible
using m4 or some existing macro processor?

~~~~~~~~~~~~~~~~Tcl script~~~~~~~~~~~~~~~~
# ConfigTemplate.tcl Jonathan Bromley, 28 Aug 2003
#
# This is a specialised macro preprocessor with the
# special property that each macro in the source code
# is given a LIST of possible replacement values.
# The macro substitution is then performed once for
# every possible combination of all the replacement
# values. So, for example, if your source text contains
# two macros, one with three possible values and the other
# with four possible values, you will get a result with
# twelve different copies of the original.
#
# The macro syntax is intended to be appropriate for
# VHDL code. You define a macro, and its list of possible
# replacement values, in a VHDL comment thus:
# --<n> rep1 rep2 rep3 ...
# where n is any string of digits, and rep1... are the
# possible replacements which MUST NOT CONTAIN the
# special characters backslash, square brackets,
# dollar sign or curly brackets. Note there is NO
# whitespace between the comment marker and the angle
# bracket.
# Typically you will not want these macro definitions
# to appear in the resulting text, so special metacomments
# --<begin> and --<end> mark the beginning and end of
# the text that will be macro-replaced; anything outside
# these markers will not be replaced. Within these
# markers, however, any occurrence of a macro name <n
# will be replaced with the corresponding macro value.

# _________________________________________________ linecount ___
#
# Just a utility procedure for debugging.
#
proc linecount {s} {
return [llength [split $s "\n"]]
}

# __________________________________________ make_substitution ___
#
# proc make_substitution performs exactly one round
# of macro substitution. $template is the substitutable
# template text taken from between --<begin> and --<end>.
# "replacements" is a list with two elements for each macro:
# the macro name (like <1&gt and the replacement value.
# The result value is the entire substituted text.
#
proc make_substitution {template replacements} {
foreach {macro value} $replacements {
regsub -all $macro $template $value template
}
return $template
}

# ____________________________________________ make_substLists ___
#
# This procedure iterates over all macros to create the
# cross-product of all macro replacements. It does this by
# iterating over all values of the first macro in the list,
# recursively calling itself for all remaining macros in
# the list.
#
proc make_substLists {
remainingMacros baseSubst resultVar replacementArray
} {

# Get access to the array of substitution values
upvar $replacementArray rA
# Get access to the result list
upvar $resultVar rV

if {[llength $remainingMacros]}

# More macros to scan recursively. Get the macro to scan over:
set macro [lindex $remainingMacros 0]
# And scan over all its possible values:
foreach value $rA($macro) {
make_substLists \
[lrange $remainingMacros 1 end] \
[concat $baseSubst $macro $value] \
rV rA
}
} else

# No more to scan
lappend rV $baseSubst
puts -nonewline "INFO: Adding substitution"
foreach {macro value} $baseSubst {
puts -nonewline " $macro=$value"
}
puts {}
}
}

# ________________________________________ build_configs ___
#
# This is the top-level procedure.
# Give it two filenames: the source file (containing
# all the macro definitions etc) and the name of a
# result file, which will be created (overwriting
# any existing file of the same name).
#
proc build_configs {template_file result_file} {

# Slurp the template file
set f_template [open $template_file r]
set template {}
while {![eof $f_template]} {
append template [read $f_template]
}
close $f_template
puts "INFO: Read [linecount $template] lines from template file"

# Find the lists of substitutions by looking for
# all --<n> macros.
set substitutions \
[regexp -inline -all -linestop -- {--<\d+>.*} $template]

# Pick the meaningful VHDL out of that template
# by extracting all text between the --<begin
# and --<end> macros
regexp -- {--<begin>(.*)--<end>} $template -> template
puts "INFO: Found [linecount $template] lines of useful code"

# Process each substitution line to extract the <n> macro and
# the list of substitution values. Build a Tcl array of
# these substitution lists, indexed by the macro.
foreach s $substitutions {
regexp -- {--(<\d+&gt(.*)$} $s -> macro substList
set replacements($macro) $substList
}
set macros [lsort -dictionary [array names replacements]]
puts "INFO: Found macros: $macros"

# Make a list of substitution-lists
set substList {}
make_substLists $macros {} substList replacements

# Open the result file
set f_result [open $result_file w]

# For each substitution-list, add the substituted text to
# the output file
foreach reps $substList {
puts $f_result [make_substitution $template $reps]
}

# We're done
close $f_result
puts "INFO: Result created in file $result_file"
}
~~~~~~~~~~~~ end of Tcl script ~~~~~~~~~~~~~~~~~~~~~~~~
--
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, Hampshire, 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.

 

[Jonathan Bromley]

"Francisco Camarero" <camarero@ee.ethz.ch> wrote in
message news:3F4EF336.5109A13@ee.ethz.ch...

[re my Tcl macrogenerator script...]

Very nice!
A little overkill for my needs, but I can start from here.

Nicer with this bugfix:

# Pick the meaningful VHDL out of that template
# by extracting all text between the --<begin>
# and --<end> macros
# FIX: Allow arbitrary comment text on the --<begin> line
regexp -lineanchor -- {--<begin>.*?$(.*)--<end>} $template -> template

--

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, Hampshire, 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.

 

[Allan Herriman]

Jonathan Bromley wrote:

"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:3f4ec073@dnews.tpgi.com.au...


Is there any *fundamental* reason why the name of a VHDL component (or
entity or configuration) being instantiated has to be fixed?


%SYS-F-BRAINOVFL, Fatal error: Question too hard.


As long as it is globally static (i.e. known at elaboration time) it
ought to be possible to use an expression to provide the component name.


I've had a run-in with some VHDL experts on this before. In
general, determining whether an expression is a constant is
too hard for compilers to solve - and VHDL has chosen not to
take the weasel path of imposing a bunch of arbitrary conditions
to make the problem easy. Whether this is a good thing is
another matter.


I have written modules (sorry, entity/architecture pairs) in the past
that have just been a big series of if-generate statements, each around
an instantiation that only differs in the name of the entity being
instantiated. Being able to use a function to determine the entity name
would reduce this code to a single instantiation.


Forgive my dim question, but isn't this what the indirection of
component+configuration is intended to solve?

Probably.

I've avoided using them because of tool support has been rather poor (in
the past). I trust it is better now.
I've moved to Verilog so I won't get the chance to try them

Regards,
Allan.

 

[David Jones]

In article <c1408b8c.0308290104.6150d2d9@posting.google.com>,
arkaitz <arkagaz@yahoo.com> wrote:

Hi,

I have a doubt about the result of a VHDL code when simulating.

I'd like to know result of a Process statement when two or more events
on the signals of the sensitivity list happen simultaneously.

Here's a little example:

PROCESS (a, b, c)
BEGIN

if (a = '1') then
result <= a;
elsif (b = '0') then
result <= b;
elsif (c'event) then
result <= c;
end if;

END PROCESS;

So, imagine an hypotetical case where ocurs an event on the three
signal a, b and c. Which would be the value of "result"?

Depends on the values of a/b/c.

There is only one driver for result in this process - the process itself
contributes the driver.

If there are concurrent events, then this is treated the same way as
single events - the process is triggered, and it computes a value for
result based on the logic.

Note, however, that this code is not recommended. Due to delta delays,
the events on a/b/c may not actually truly be concurrent, but may arrive
in any order, even though they appear to happen at the same simulator time.
Recall that each tick of simulator time is further subdivided into delta,
as many as required to resolve all activity during that tick.
In this case, that last c'event claude can be order-sensitive.

 

[Tim Hubberstey]

Fouad wrote:

FATAL_ERROR:Xstortability/export/Port_Main.h:126:1.13 - This
application has discovered an exceptional condition from which it
cannot recover. Process will terminate. To resolve this error,
please consult the Answers Database and other online resources at
http://support.xilinx.com. If you need further assistance, please open
a Webcase by clicking on the "WebCase" link at
http://support.xilinx.com

Welcome to the wonderful world of all too fallible EDA tools. Your only
real recourse is to do the rest of what the error message said:

If you need further assistance, please open
a Webcase by clicking on the "WebCase" link at
http://support.xilinx.com

Before doing that, you should make sure you have the latest version of
the software with the latest service pack installed. Tech support people
will often refuse to go any further until you have done this.

This isn't really a VHDL issue and you might do better by posting on
comp.arch.fpga. I suggest you do a google search of the comp.arch.fpga
archives first just in case this has already been covered.
--
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com

 

[Renaud Pacalet]

Fouad wrote:

Hi,

I'm new to VHDL... I have a proble that requires me to use a VHDL CAN
(Controller area Network) Core... I got the core from an open source..
and I get an error as below

FATAL_ERROR:Xstortability/export/Port_Main.h:126:1.13 - This
application has discovered an exceptional condition from which it
cannot recover. Process will terminate. To resolve this error,
please consult the Answers Database and other online resources at
http://support.xilinx.com. If you need further assistance, please open
a Webcase by clicking on the "WebCase" link at
http://support.xilinx.com
Error: XST failed

It's a XST bug (FATAL_ERROR, PANIC, etc are nice words for bug). You can
try to build a small piece of code that crashes XST by commenting out
some parts of the code. If you succeed in identifying what statement or
group of statements are responsible for the crash then maybe you'll find
a workaround.

Regards,
--
Renaud Pacalet, ENST, 46 rue Barrault 75634 Paris Cedex 13
###### Tel. : 01 45 81 78 08 | Fax : 01 45 80 40 36 ######
# Fight Spam! Join EuroCAUCE: http://www.euro.cauce.org/ #

 

[Edwin Naroska]

Hi,

Giuseppeł wrote:

Where did you find the open source core of the CAN controller?
I'm interesting too in the CAN application for study pourpose.

You may try

* Hurricane: ftp://ftp.estec.esa.nl/pub/ws/wsd/CAN/can.htm
* CAN protocol controller from opencores:
http://www.opencores.org/projects/can/

--
Edwin

 

[Ralf Hildebrandt]

Hi Max!

Please answer to the posting, do not write a new posting (news thread).

the following code:

global_read: process (reset, reg_en, rd)
begin
if reset = '1' then
ctrl_data_bus <= (others => 'Z'); -- all warnings are here!
else

No default assignment for the output signals(s) here. This is the
safest way to assure that you won't get a latch.

what do you mean?

A Latch is a Register, that has an enabling-singal. - Template:

process(latch_enable,reset,data_in)
begin
if (reset='1') then
latch<='0';
elsif latch_enable='1') then
latch<=data_in;
end if;
end process;


Note, that there are conditions, where this "thing" igores the input!
(if not reset and not latch_enable) -> This is the reason because it is
a storage element (register).


For clarity - take a look at pure combinational logic:

process(switch,reset,data_in1,data_in2)
begin
if (reset='1') then
outp<='0';
elsif switch='1') then
outp<=data_in1;
else outp<=data_in2
end if;
end process;

All possible input-combiations are covered. Everytime the output depends
directly on the input.

-> If you write an if / case - clause, where not all possible input
combinations are covered, you get a latch, otherwise this will be
combinational logic (or a tri-state-buffer, if the default condition is
'Z').


Latches are small and consume low power, but you have to take care, that
the "latch-enable" is hazard-free and your circuit does not care about
the fact, that the latch-output "glitches" as long as the latch_eable is
active.
FPGAs often do not contain latches. They build latches with
combinational logic and feedbacks. -> FPGA-synthesis tools warn you, if
a latch is inferred, because normally you should avoid latches on FPGAs.



Ralf

 

[VhdlCohen]

I am looking for a Tool that I can generate VHDL and/or Verilog
directly from a timing diagram. I have a bus system in my design that
is common to many IP blocks and its currently specified as a series of
read and write bus cycles. I would like to enter these bus cycle
timings and generate HDL directly from them. Anyone have any good
ideas.

I am questioning the whole premise on the need to generate HDL from
a timing diagram for TB designs. I personally prefer"
1. A transaction-based approach (see my site under models, veriflang.pdf
Document: Transaction-Based Verification in HDL) where the transator (or
client) makes high level transaction requests, and the server provides the
low-levl interfaces to the DUT. It is not difficult to code a server to do
READs, WRITEs, DMA, IDLE, etc. classes of cyles. If that is difficult, then
you don't understand the design.

2. I also encourge the use of PSL to perform white-box verification for
simulation or formal verification.

----------------------------------------------------------------------------
Ben Cohen Publisher, Trainer, Consultant (310) 721-4830
http://www.vhdlcohen.com/ vhdlcohen@aol.com
Author of following textbooks:
* Using PSL/SUGAR with Verilog and VHDL
Guide to Property Specification Language for ABV, 2003 isbn 0-9705394-4-4
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn
0-9705394-2-8
* Component Design by Example ", 2001 isbn 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
------------------------------------------------------------------------------

 

[Alvin Andries]

"Max" <cialdi@firenze.net> wrote in message
news:8e077568.0309120313.22e2d7f3@posting.google.com...

in my project I have some components that share data_bus. data_bus is
defined always inout.

the error is in map phase:

ERROR:LIT:62 - Multiple TBUFs on the same base are sharing enable
signal. They
are: TBUF symbol "control_i3_0" (output signal=data_bus_5_iobuf),
TBUF symbol "control_fifo_i7_0" (output signal=data_bus_5_iobuf).
To allow
the design to pass with this configuration, please set environment
variable
XVK_MAP_ALLOW_BUS_CONTENTION. This error will become a warning if
the
environment variable is set.

I cannot understand what is wrong. I think the problem is near
data_bus, but I don't know why.

thanks

Hi,

It looks like you're enabling multiple tri-state buffers at the same time,
which most likely is something you don't want to do. This should also have
shown up during the simulations you did.
Summarized: double check that only one driver is enabled at any time in your
code.

Regards,
Alvin.