Clock Edge notation

[KJ]

"jumpz" <l33tsp34kr@gmail.com> wrote in message
news:95b5027c-47ad-44f6-a96c-962dc463e5f2@b5g2000pri.googlegroups.com...

signal trigger;


If this is indeed not possible, any ideas on trying to identify what
is causing this?

Use a simulator...it will happily provide you all the clues you need.

KJ

 

[KJ]

<nitrogenocide@gmail.com> wrote in message
news:62d67656-1b11-4741-895b-b4741ced1a86@w5g2000prd.googlegroups.com...

After running "check syntax", I get the following errors.

ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 92. = has two
or more possible definitions in this scope. For example, parameter 2
(string value) can be: SIGNED or UNSIGNED
ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 114. = has two
or more possible definitions in this scope. For example, parameter 2
(string value) can be: SIGNED or UNSIGNED
ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 145. = has two
or more possible definitions in this scope. For example, parameter 2
(string value) can be: SIGNED or UNSIGNED


here are the lines being referred to:

Line 92: if setup_sample = "1111111" then

Line 114: curval <= countupstuff when setup_sample = "1111110";

Line 145: elsif apnea_count = "1101001101010101100100000" then


The errors seem to be implying that I haven't specified these signals
as either signed or unsigned. But the following part of my code does
specify all these signals as unsigned

But the thing you're comparing them to (i.e. "1111111" and "1111110" are
ambiguous). You need to tell it if it is signed or unsigned like this

unsigned'("1111110")

Note the tick mark.

KJ

(these are lines 39 through 47)


architecture Behavioral of SS08 is

signal countupstuff, curval, sample, count_1khz : unsigned (15 downto
0);
signal apnea_reset, alarm_out, clock1k, clock1k_int, inc_apnea_count,
inc_not_apnea, clock32x, clock32x_int, settozero : std_logic;
signal apnea_count, not_apnea : unsigned (24 downto 0);
signal count_1Mhz : unsigned (4 downto 0);
signal setup_sample : unsigned (6 downto 0);

begin


Interesting note, I was previously running this code on ISE 9.1 and it
didn't have a problem with it.


Can any one shed some light on why I'm getting these errors? It would
be very much appreciated. Let me know if you need any more
information.



Thanks,



Jeff

 

[KJ]

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message
news:q0a344h9akcforb27c31h38tre70d2oaml@4ax.com...

On Sat, 31 May 2008 11:58:04 -0700 (PDT), nitrogenocide wrote:


Intriguingly, this exact issue came up here only a couple
of days ago.

A regular conspiracy going on

It's almost certainly because you are accepting the goofy
Xilinx default VHDL code template which has, inter alia,

USE IEEE.STD_LOGIC_ARITH.all;

No-one can explain why Xilinx (and others too) continue
to recommend in this way the use of a package that was
superseded by the better, more complete, properly
standardised IEEE.NUMERIC_STD over a decade ago.

That would bring them up to the 90s now wouldn't it....only 15 or so years
behind the standards.

The less satisfactory fix (hack) is to make the type
of your constants explicit:

if setup_sample = UNSIGNED'("1111111") then

This is known as a "type qualification"; note the
apostrophe between the type name and the opening
parenthesis.

If for some reason you reeeeeally didn't want to properly define a constant
to do the job, I think using the type qualifier is better (not a hack)
since, even if the compiler has no ambiguity, the reader may and having the
type qualifier makes it explicit to the reader as to the intended
type...documentation comes in all forms.

Kevin Jennings

 

[HT-Lab]

"Pasacco" <pasacco@gmail.com> wrote in message
news:a1e1693e-0465-4090-819c-448d9ad5e4dc@2g2000hsn.googlegroups.com...

I hope this general discussion is scope of this group.

In my experience, when we describe in VHDL:

c = a * b;

In FPGA design flow, multiplier is automatically "inferred",

while (after synthesis) we can know "what multiplier (for example,
booth multiplier)" and "how many multipliers" are instantiated.

As ASIC novice, today I tried ASIC flow (using Synopsys design
compiler).

After synthesis, netlist SEEMS to be correctly generated.

while I have no idea "what multiplier" and "how many multipliers" are
correctly inferred.

My question is that

1) In typical ASIC flow, should I build the multiplier module MYSELF?

You can build it yourself or instantiate one from the Synopsys Designware
library.

2) How can we know "what multiplier" and "how good the inferred
multiplier" are ?

Without specifying one I suspect that your multiplier is a black box, speak
to your Synopsys FAE,

Hans
www.ht-lab.com

 

[HT-Lab]

"Neha" <neha.karanjkar@gmail.com> wrote in message
news:2dbc87ff-f287-4511-9c4a-b1a209368632@i36g2000prf.googlegroups.com...

Hello.

I need to use Modelsim 6.2f to simulate systemC modules. However, I
have g++ 3.4.4,(x86_64 system) and according to its release notes ,
Modelsim does not support g++ 3.4.4.

I am not sure what you are trying to do but remember that Modelsim uses its
own gcc version. So you can continue to use g++ 3.4.4 with OSCI and switch
over to sccom when you need to run it on Modelsim. The only problem you
might hit is the same as you can get by switching between g++ versions.

There is an option to use another gcc version (search for CppPath in the
user manual) but the manual recommends against doing this,

Hans
www.ht-lab.com

I downloaded SystemC-2.2 library, and it works fine with g++3.4.4
I cannot use Modelsim though.

Is there something I can do to overcome this? For instance, is there a
way of pointing out the Installed systemC library to Modelsim?

I'd be thankful for any advice.

...Sorry if this is not the correct forum to post doubts on SystemC.

Regards,
Neha

 

[KJ]

<HansWernerMarschke@web.de> wrote in message
news:1fdcc58c-906c-4ec7-ad33-c9de3f635e34@m36g2000hse.googlegroups.com...

I want to "or" the "bits" of std_logic_vector for each element of the
vector like this.
data_out(i) shall be '1' if one of the elements of the vector has set
this bit to one.

Somewhat similar to the process approach already covered in this thread is
to use a generate statement...basically the same amount of typing and debug

Gen_This : for i in data_out'range generate
data_out(i) <= '1' when unsigned(data_out_array(i)) /= 0;
end generate Gen_This;

KJ

 

[HT-Lab]

"fl" <rxjwg98@gmail.com> wrote in message
news:6b3e7763-0ab6-4535-916b-16d0c7f09e46@j22g2000hsf.googlegroups.com...

Hi,
I am new to VHDL. The book "The designer's guide to VHDL", 3rd ed.
says:

VHDL-87, -93 and -2002
These versions of VHDL only allow single-line comments, not delimited
comments.

I am very curious which version VHDL allows delimited comments.

It is supported in VHDL2006/7/8/9 or whatever it will be called. Currently
only Aldec supports part of this new standard.

It is the same as in C/C++, that is, /* ... */

Hans
www.ht-lab.com

Thanks a lot.

 

[KJ]

"Jim Lewis" <jim@synthworks.com> wrote in message
news:fOidnaO0J_eR88zVnZ2dnUVZ_tninZ2d@posted.easystreetonline...

rickman
Here is an example.

CTPBitCnt is an unsigned.

What I mean...
CTPBitCnt <= 1;

What I have to write...
CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);



Jonathan just submitted a language feature request WRT to overloading
assignment, however, the standard is already at the balloting point so
it will not make the 2008 revision.

What has been added is a decimal notation for bit string literals
and a sizing indication.

signal CTPBitCnt : unsigned (14 downto 0) ; -- 15 bits
. . .
-- Representing 1 as a 15 bit object in either hex or decimal

CTPBitCnt <= 15D"1" ; -- Decimal notation
CTPBitCnt <= 15X"1" ; -- Hex notation

The type of syntax only a mother could love. Let's compare the approaches
A: CTPBitCnt <= 1;
B: CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);
C: CTPBitCnt <= to_unsigned(1);
D: set(CTPBitCnt, "<=", 1)
E: CTPBitCnt <= CTPBitCnt'lengthD"1" ; or CTPBitCnt <= CTPBitCnt'lengthX"1"
??
F: CTPBitCnt <= 8D"1" ; or CTPBitCnt <= 8X"1"

'A' is illegal, but represents what is intended. Violates strong type
checking which is a 'good' thing about VHDL (in my opinion).

'B' has been valid since VHDL'93 but is overly wordy and prone to error if
you inadvertnatly take the 'length of something other than the left side of
the statement. Has an issue that you would need separately names procedures
if the thing being assigned to is a signal or a variable. Jim, is there
anything on the table about being able to overload procedures when
parameters differ by class so that a single name could be used? If not,
maybe I'll submit it for consideration.

'C' is illegal, but represents what is intended and conforms nicely with the
strong type checking of VHDL. Requires acceptance of overloading of the
"<=" and ":=" operators as Jonathon has proposed.

'D' is valid VHDL where 'set' is a procedure that implements the syntax of
'B'. No chance for the possible user error mentioned above for 'B'. The
second parameter "<=" is not used in the procedure it is there simply to aid
the user of the procedure.

'E' may be valid VHDL'2008 (not sure if the bit width specification needs to
be a hard coded can be replaced with something that will be maintainable if
'CTPBitCnt' is subject to size changes ....ummm, kind of at a loss to say
anything that I like about that syntax.
'F' is valid VHDL'2008 but again can't say what there may be to like about
it from the perspective of someone looking at the code or writing it.

If I were to rank them by personal preference the ordering would be
1. C (clear and consise)
2. D (kinda kludgy but does the trick)
3. B (it's legal after all)
4. A (I'd almost rather have less strong type checking then 'E' or 'F').
5. E or F....the designer's intent has been completely lost.....to me

BTW, these are also in Accellera standard VHDL-2006-rev3.0, so
if your vendors were looking out for your interests, they would
have already should implemented these.

Make sure to submit these as bug/enhancement requests. This is important
as this is what lets them know the VHDL community wants the new features.

I'll wait for one I like to see first.

Kevin Jennings

 

[KJ]

"rickman" <gnuarm@gmail.com> wrote in message
news:37c87ac4-768f-405f-a262-fe3e4dd0c51b@x35g2000hsb.googlegroups.com...

You present a nice list. Thanks.

'A' has the advantage of clarity of intent...it has the drawback of
requring loose type checking in the language.

This is the issue that I am struggling with understanding. Strong
type checking is good in many contexts. But I fail to understand why
it has to prevent me in this case. In fact, I think that someone said
that this is being proposed for the next, next rev of the language.
So obviously it does not present any real issues to make it
incompatible with strong type checking.

It breaks the rules of strong type checking because 'CTPBitCnt' is of type
'unsigned' and '1' is of type integer and assigning something of one type to
something that is of another type directly without some form of conversion
function breaks what is considered to be strong type checking.

Relaxation of the rules in certain instances (like this one) can be a
productivity enhancer and a 'good' thing for the language but you should
also accept that this relaxing of the rules IS a violation of strong type
checking.

<snip>

'B' has the advantage of clarity of intent...and it meets the
requirements of strong type checking and is not overly wordy.

I honestly don't understand why the intent is not clear in example A.

Flip back and you'll see that I said that both 'A' and 'B' are clear about
the designer's intent.

I specified that CTPBitCnt was an unsigned signal in the declaration.
Does it make any sense to assume that I mean the literal 1 to be
anything other than an unsigned equivalent?

I hate having to flip back to the declaration to see what the type of a
particular signal is.

Maybe my software courses
in college were too long ago for me to have learned why strong typing
has to be so cumbersome.

It needn't be...overrides for "<=" and ":=" would solve the wordiness
problem and still provide for the strong type checking....as someone else
stated, other languages have it. The needed conversion function can be the
function that provides an operator overload....just like how one can
overload "and", "or", etc. to work with custom types today.

<snip>

'D' is kludgy but fairly succint in getting the intent across.

I assume this is a special procedure to perform the required function
by reading the middle term? Interesting...

Yes, it would be a homegrown procedure that one would put into a package of
commonly used functions. Just as you get into the habit of including the
std_logic stuff at the begining of every VHDL file you would start to
include your package of homegrown stuff and then always have these shortcuts
handy.

By the way, the middle term "<=" wouldn't even be used by the procedure it
would simply be there to aid the reader since something like this

set (this, that)

would always cause someone to say, well does that mean
this <= that
or
that <= this?

whereas
set (this "<=" that);
would be more clear...at the expense of more typing....for a parameter that
doesn't functionally contribute anything...I can hear the moans and groans
already, but you can make your homegrowns your way, I'll make 'em mine.

The procedure should have an assert to make sure that the middle term is
"<=" though so that some smarty pants that said

set (this, "=>" that)

would get hammered in simulation by firing an assertion.

'E' is valid VHDL'2008 that has lost the designer's intent...15D??
hmmm....

To be honest, I don't see how this one can even work. Is this
intended to indicate a signed or an unsigned value? How do you
indicate the other? I don't need to say anything about the 15 part...

VHDL has a lot of nice things....this one isn't one of them...well, assuming
that it actually gets approved.

The more I read about this, the more I like Verilog... at least until
I start using it ;^)

comp.lang.verilog is always looking for members....and from what I read

Verilog is finally catching up to VHDL.

KJ

 

[Symon]

Charles Xavier wrote:

On Jun 13, 5:46 pm, Eric Smith <e...@brouhaha.com> wrote:
Charles Xavier wrote:
If anyone has attempted to download anything in the 8GB range,
you'll find that well.. if you're missing enough parts of the file,
the par2 recovery can be a painful, painful process taking up to
three hours in some cases.
The XBOX 360 doesn't play x.264 and all the good movies are in
x.264. Converting from x.264 to h.264 could be done offboard on an
FPGA

I have a hard time believing that those are the "two most annoying
problems on usenet". I've been using Usenet since 1984, and I've
never personally encountered either problem.


Since it doesn't appear that there is any real problem here, it also
doesn't appear that there is any need for an FPGA-based "solution".

Thank you for sharing. Let your next post be in contribution to the
project.

If it doesn't apply to you and you don't see the need, why even reply?

Hi Charles,
Maybe to share the benefit of his experience to help you avoid wasting your
time on a solution without a problem?
Good luck, Syms.

 

[Symon]

Charles Xavier wrote:

On Jun 13, 5:46 pm, Eric Smith <e...@brouhaha.com> wrote:
Charles Xavier wrote:
If anyone has attempted to download anything in the 8GB range,
you'll find that well.. if you're missing enough parts of the file,
the par2 recovery can be a painful, painful process taking up to
three hours in some cases.
The XBOX 360 doesn't play x.264 and all the good movies are in
x.264. Converting from x.264 to h.264 could be done offboard on an
FPGA

I have a hard time believing that those are the "two most annoying
problems on usenet". I've been using Usenet since 1984, and I've
never personally encountered either problem.


Since it doesn't appear that there is any real problem here, it also
doesn't appear that there is any need for an FPGA-based "solution".

Thank you for sharing. Let your next post be in contribution to the
project.

If it doesn't apply to you and you don't see the need, why even reply?

Hi Charles,
Maybe to share the benefit of his experience to help you avoid wasting your
time on a solution without a problem?
Good luck, Syms.

 

[KJ]

"rickman" <gnuarm@gmail.com> wrote in message
news:bdf4e73d-f1d1-460d-a92c-be0518f01f56@d45g2000hsc.googlegroups.com...

On Jun 13, 10:35 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
"rickman" <gnu...@gmail.com> wrote in message

news:37c87ac4-768f-405f-a262-fe3e4dd0c51b@x35g2000hsb.googlegroups.com...


would always cause someone to say, well does that mean
this <= that
or
that <= this?

whereas
set (this "<=" that);
would be more clear...at the expense of more typing....for a parameter
that
doesn't functionally contribute anything...I can hear the moans and
groans
already, but you can make your homegrowns your way, I'll make 'em mine.

Personally, I think set (this, that) is just fine. It is a strange
construct to begin with. But once someone learns about it, it is very
easy to remember that the order is the same as in an assignment. No
confusion there.

But you would also have to admit that the learning curve upon first seeing
set(this, "<=", that) is lower (hopefully non-existent) than it is for
set(this,that) since the "<=" parameter makes it plainly obvious which is
the target of the assignment (although one can certainly quibble about the
name, maybe 'copy' would be better than 'set').

So now you get into the tradeoff between productivity gained while banging
in the code (if you don't have to type in the "<=" every time you use it)
versus productivity lost (from having to go back to refresh your noggin on
which is the target if you don't use this on a daily basis) in later
supporting the code. While you're focusing right now on the code entry
hassles, remember that effort only gets done once, but you (or someone else)
will have to look at it more than once and not always while it's still fresh
in your mind, maybe years later...or perhaps by someone else who has to
support your design after you move on....then again, maybe the obscure
approach is better from a future support contracting perspective....after
all, that's partly why suppliers generate obtuse code for 'wizard' generated
widgets to make it at least a bit of a pain to go back and
rework/modify/extend it.

Anyway, I just tossed this procedure one out as an idea and admitted it is
klunky, but certainly less so than the 15D/15X prefix thing.

We're certainly off on a tangent from your original query. You can always
submit an enhancement request in to the VHDL gods. I don't have the link
handy but if you Google for Accelera and VHDL enhancements you can probably
find the link, Jim Lewis' posts sometimes have it since he is part of that
group. I submitted a couple that got accepted...although I'm not sure
when/if they ever will/did make it into the new standard.

Kevin Jennings

 

[KJ]

"MikeWhy" <boat042-nospam@yahoo.com> wrote in message
news:FsK4k.13880$co7.9937@nlpi066.nbdc.sbc.com...

"rickman" <gnuarm@gmail.com> wrote in message
news:bdf4e73d-f1d1-460d-a92c-be0518f01f56@d45g2000hsc.googlegroups.com...
I can see some issues. But so far, it sounds like you only want to better
define assignment of signed/unsigned integer values and literal constants.
Size promotion rules will cover it without fighting that battle.

What other use would you have for assignment overload?

I second Jonathon's post. The new fixed/floating point library is an
excellent example of why you would want this. While it's great that it can
be used with existing VHDL-93, having to put the size of the thing being
assigned to on the right hand side just so the function can know the size of
the thing being assigned to really clutters up and obscures things. The
declaration of a signal becomes quite interesting in how to format it to
even look intelligible to the reader.

Kevin Jennings

 

[KJ]

"Jim Lewis" <jim@synthworks.com> wrote in message
news:48555383.1090500@synthworks.com...

KJ,
BTW, these are also in Accellera standard VHDL-2006-rev3.0, so
if your vendors were looking out for your interests, they would
have already should implemented these.

Make sure to submit these as bug/enhancement requests. This is
important
as this is what lets them know the VHDL community wants the new
features.


I'll wait for one I like to see first.

Don't hold your breath.

I never do, I find work arounds instead...much more effective than breath
holding.

The only way to get what you can live with (not necessarily even
what you want) is to participate in the standards development.

I think you misinterpreted what I meant. By saying "I'll wait for one I
like to see first" I was simply stating that this particular member of the
VHDL community wasn't going to bug the vendors for *this* particular
enhancement to be implemented since I just don't see myself using it for the
reasons that have been pointed out. A new feature that I *am* interested in
using is something I would bug them for if it wasn't already implemented.

Presumably the indiviauals that thought the 'D' 'X' notation is what the
VHDL world needs are the ones that should be voicing their needs if their
tools don't support it.

Yacking out here is like screaming at a mountain.

Not really, it's an open forum to discuss problems that others might know a
solution for. Kind of a pre-screening before submitting a bug/enhancement
request. Sometimes the gripe ends in a legitimate enhancement request,
sometimes it ends in the griper learning something they didn't know.

P.S.
If you are an expert VHDL coder there is no reason you should
not be participating.

No idea whether I would qualify as an expert, but I can peruse Accelera and
see what the needs might be.

Kevin Jennings

 

[KJ]

"Jim Lewis" <jim@synthworks.com> wrote in message
news:O9GdnawnGcWjz8jVnZ2dnUVZ_rDinZ2d@posted.easystreetonline...

Jonathan,
More important still, it would prevent errors that are currently
unavoidable: if you use := or <= to copy a fixed-point value from one
place to another, and the target object is of the wrong subytpe, you can
get its
fixed-point scaling silently and disastrously screwed-up.

For fixed point math, to address the range issue, this seems
reasonable, but it also seems open other issues. For example,
if I use an intermediate object that is too small, overloading
":=" will automatically downsize it.

Another solution might be to allow a function access to attributes of the
thing being copied to. Similar to C++ and 'this', maybe a function that
could get the range of the target with something like that'range. So you
could do

function blah(a, b:ufixed) return ufixed is
variable ReturnVal: ufixed(that'range);
begin
....
return(ReturnVal);

Or (perhaps simpler), 'that' would be the thing that can be assigned to and
returned. It would likely require the user of function blah to explicitly
define the range of the target so composing multiple function like

y <= blah(a, blah(b, c))

might not be possible....or maybe it could if the function would define the
range that *it* thought was correct, and just use that'range to error out if
the range wasn't appropriate. In any case, it would give the function some
knowledge of attributes of the target beyond just the signal/variable type.

Kevin Jennings

 

[Andreas Ehliar]

On 2008-06-11, Charles Xavier <skelotar@gmail.com> wrote:

The XBOX 360 doesn't play x.264 and all the good movies are in x.264.
Converting from x.264 to h.264 could be done offboard on an FPGA
because it takes for-ever to complete on my system (8 hours). This
should have the same premise as the previous issue, minus using a x.
264 decoding core and possibly directly converting it to h.264 or
doing a decompression-recompression..

I'm not sure what the problem with x.264 is, but lets just say that
it is far from trivial to write a H.264 decoder/encoder. The decoder
is especially tricky as you need to be able to parse all parts of the
standard whereas you can select only the parts you care about for the
encoder.

If you are an expert on video codecs and a newcomer to FPGAs, this
would probably be a quite ambitiouis project to start with. If you
are not an expert on video codecs, you will have to spend a lot of
time to understand H.264 before you can even get started on the FPGA
parts.

This is written from personal experience by the way, I have written
a grayscale H.264 decoder in C to get an understanding of how the
standard works. Lets just say that it took way more time than I wanted
to...

In summary: I don't recommend a H.264 codec as a first FPGA project.

The Reed-Solomon application seems like a much more reasonable project.
You will still have a lot of things to figure out like how you are going
to communicate with your FPGA board, but the problem itself is much more
limited.

/Andreas

 

[jtw]

Alternatively, force the clock(s) to stop. The simulation will stop when
there are no more scheduled transactions.

JTW

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message
news:q4md54959sqcr4d3d9n1it7np8e7oecg1c@4ax.com...

On Sun, 15 Jun 2008 06:27:59 -0700 (PDT), wrote:

[...]
What is the problem with the test bench?

It was a little hard to follow the details of your description -
it's always difficult to describe timing behaviour in words -
but I suspect the problem is that you are applying stimulus
exactly at the moment of the active clock edge. Although this
is probably OK in a zero-delay RTL simulation, it gives no
hold time for the inputs and it is usually very confusing to
try to interpret the results.

It is far better to set up the input stimulus so that it gives
reasonable setup and hold time relative to the clock edge. One
useful technique is to apply the stimulus on inactive clock
edges, and to sample both the stimulus and the DUT's outputs
exactly at the moment of the clock edge when you are sure that
the DUT has not yet had a chance to react to the clock.

This is a part of the test bench [...]

It looks basically OK, apart from the stimulus timing problem
I already described. Also, the testbench will not stop
automatically when your stimulus file is exhausted; it
is probably a good idea to do something about that. For example,
just before the end of your process:

assert (NOT ENDFILE(inp1)) or (NOT ENDFILE(inp2))
report "Input data exhausted - NORMAL SIMULATION STOP"
severity FAILURE;

HTH
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[jtw]

Alternatively, force the clock(s) to stop. The simulation will stop when
there are no more scheduled transactions.

JTW

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message
news:q4md54959sqcr4d3d9n1it7np8e7oecg1c@4ax.com...

On Sun, 15 Jun 2008 06:27:59 -0700 (PDT), wrote:

[...]
What is the problem with the test bench?

It was a little hard to follow the details of your description -
it's always difficult to describe timing behaviour in words -
but I suspect the problem is that you are applying stimulus
exactly at the moment of the active clock edge. Although this
is probably OK in a zero-delay RTL simulation, it gives no
hold time for the inputs and it is usually very confusing to
try to interpret the results.

It is far better to set up the input stimulus so that it gives
reasonable setup and hold time relative to the clock edge. One
useful technique is to apply the stimulus on inactive clock
edges, and to sample both the stimulus and the DUT's outputs
exactly at the moment of the clock edge when you are sure that
the DUT has not yet had a chance to react to the clock.

This is a part of the test bench [...]

It looks basically OK, apart from the stimulus timing problem
I already described. Also, the testbench will not stop
automatically when your stimulus file is exhausted; it
is probably a good idea to do something about that. For example,
just before the end of your process:

assert (NOT ENDFILE(inp1)) or (NOT ENDFILE(inp2))
report "Input data exhausted - NORMAL SIMULATION STOP"
severity FAILURE;

HTH
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[HT-Lab]

"jtw" <wrightjt @hotmail.invalid> wrote in message
news:XZ%5k.1918$LG4.1333@nlpi065.nbdc.sbc.com...

Alternatively, force the clock(s) to stop. The simulation will stop when
there are no more scheduled transactions.

In the current Modelsim and I believe ActiveHDL you can use the new standard
VHDL env package subprogram STOP/FINISH, example:

library std;
use std.env.all;

-- 0 prints nothing
-- 1 prints simulation time and location
-- 2 prints simulation time, location, and statistics about
-- the memory and CPU times used in simulation

STOP(1);

Which will result in a clean simulation stop:

# ** Note: stop
# Time: 360 ns Iteration: 0 Instance: /test_tb

Hans.
www.ht-lab.com

 

[HT-Lab]

"jtw" <wrightjt @hotmail.invalid> wrote in message
news:XZ%5k.1918$LG4.1333@nlpi065.nbdc.sbc.com...

Alternatively, force the clock(s) to stop. The simulation will stop when
there are no more scheduled transactions.

In the current Modelsim and I believe ActiveHDL you can use the new standard
VHDL env package subprogram STOP/FINISH, example:

library std;
use std.env.all;

-- 0 prints nothing
-- 1 prints simulation time and location
-- 2 prints simulation time, location, and statistics about
-- the memory and CPU times used in simulation

STOP(1);

Which will result in a clean simulation stop:

# ** Note: stop
# Time: 360 ns Iteration: 0 Instance: /test_tb

Hans.
www.ht-lab.com