I hate VHDL!!!

[Mike Treseler]

Gopi wrote:

Hello Everyone,
I am doing some programing in VHDL. I want to write a VHDL program
that accept ethernet frame and convert it to PPP frame (point to point
protocol).

http://www.cs.nyu.edu/courses/fall98/G22.2262-001/class7.html

-- Mike Treseler

 

[Just an Illusion]

See www.opencores.org

Bye,
JaI

blaze wrote:

I need project in VHDL (with description of hardware, simulations and source code)
please help

 

[Just an Illusion]

Hi Weng,

This morning I have just realized that perhaps you have a bad analyze
your true problem.

In your example, you said that condition 2 and 3 are mutually exclusive,
but that not fully true.

Let me rewrite your code with more symbolic notation:

if (Cond_1) then
DIMMNumber (4 downto 0) <= (others => '0');

elsif (Cond_2) then
if(AD_R0(28) = '1) then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(28 downto 24);
end if;

elsif (Cond_3) then
if(AD_R0(60) = '1) then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(60 downto 58);
end if;

end if;

What this structure must give you in synthesis ?
-> a 5-bit register with 3 asynchronous load conditions (Cond_1, Cond_2
and Cond_3)

Why a register ? because you haven't define all cases.

You said: Cond_2 implicate !Cond_3, and Cond_3 implicate !Cond_2, but
you can have !Cond_3 and !Cond_2.
To be really mutually exclusive (xor logique function), you must have at
least Cond_2 or Cond_3.

That is not what you have modelized (with or without your orif
structure). Your 'orif' function is equivalent to logic implication (A
-> B), which are equivalent to logical function !A+B (not A or B).

Try to write your control part like this, and perhaps that can solve
your situation.

JaI


Weng Tianxiang wrote:

I would like to show you with real code in my PCI-CORE why it is very
important to introduce "if..orif..endif" keywords into VHDL to clear
any confusions about mutual exclusive conditions.

This is very common equations in PCI core design.
A register of 5-bits at my PCI configuration space address 0x07 is
targeted by PCI host to write new data into it. When PCI bus is 32-bit
width, the write data is in low 32-bit PCI bus, if PCI bus is 64-bit
width, the write data is in high 32-bit PCI bus. There is another
internal clear signal to initialize the register.
if(DIMMNumberClear) then
DIMMNumber(4 downto 0) <= (others=>'0');

elsif(CSRAD_R0_L_DIMMNumber_H and nC_BE_R0(3 downto 0) = "0111") then
if(AD_R0(28) = '1) then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(28 downto 24);
end if;

elsif(CSRAD_R0_H_DIMMNumber_H and nC_BE_R0(7 downto 4) = "0111") then
if(AD_R0(60) = '1') then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(60 downto 56);
end if;
end if;

3 levels in the 'if..elsif..endif'.

First level has highest order to clear.

Second and 3rd are mutually exclusive.
Because PCI-bus is either 32-bit width or 64-bit width.
If you choose any other current legal writing to get its performance
benefit, you would destroy the simplicity of above equations, but if
you don't, you have to pay penalty to the priority tree inherited in
'if..elsif..endif'.

If "if..orif..endif" keywords is introduced into VHDL, how nice it
fits into the situations!

if(DIMMNumberClear) then
DIMMNumber(4 downto 0) <= (others=>'0');

elsif(CSRAD_R0_L_DIMMNumber_H and nC_BE_R0(3 downto 0) = "0111") then
if(AD_R0(28) = '1) then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(28 downto 24);
end if;

orif(CSRAD_R0_H_DIMMNumber_H and nC_BE_R0(7 downto 4) = "0111") then
if(AD_R0(60) = '1') then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(60 downto 56);
end if;
end if

1. Mutually exclusive case is easy to recognize if you pay attention
to it;
2. No any "critical boundary" exist!
3. No any confusion about simulations!
4. Not danger at all!

Any comments special to the above example are welcome.

Weng

 

[johnp]

See post here entitled "Problems with DPLLs" 3/6/2004
regards Johnp
"Naimesh" <t_naimesh@rediffmail.com> wrote in message
news:ecee4f8a.0406212202.4e0fa6be@posting.google.com...

Hello,

I need to write a DPLL to recover the clock of Manchester encoded
data. Rate of the data transmission is known(1.544Mbps).So just phase
of the clock is to be found. I have 16 time faster clock then the rate
of the transmission. Can any one help me out? pls. suggest any link or
book if possible

Thanks

 

[Tim Hubberstey]

ALuPin wrote:

but why are the signals which are not used or connected to output pins
undefined when simulating?

First, we need to clarify something: VHDL does not have "pins", it has
"ports". "Pins" are a physical feature of real parts and as such only
have meaning to a synthesizer. I'm going to assume you mean ports when
you say pins. I'm also going to assume you are talking about
std_(u)logic signals and vectors.

All std_(u)logic type signals (and variables) are assigned the value 'U'
at time=0. If nothing drives the signal, this value never changes.
Signals not connected to output ports but driven by something in the
code will have values appropriate to the attached driver(s) as defined
by the resolution function. It is important to be aware of the
distinction between the values of 'U' and 'X'. 'X' does not mean
"undefined", it means "unknown". A common cause of 'X' is
unintentionally having 2 or more drivers attached to a signal and
driving conflicting values.

When I connect them to output pins they are not!

I'm sorry but I don't believe this. A port of type "out" or "buffer"
serves only to make the value of an internal signal available outside an
architecture. It cannot influence the value assigned to the signal
driving it inside the architecture. Ports of type "inout" or "in" are
the only ports that can affect internal values.

Furthermore, 'X' always "wins", except against 'U', (see the std_logic
resolution function) so you can't attach any driver to a signal that
will make an 'X' go away. In other words, there is nothing that you can
drive through a port that will change an 'X' to something else.
--
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com

 

[Aliki]

Well Mike, the first instruction is an add4 which means that the content of
memory position 4 must be fetched and added to the accumulator. What I see
in the simulator is that the cpu downloads the memory content (27H) but
after that everything goes wrong, the contents in the registers change in
a random sequence (wrong sequence, definitelly different than what is
expected) and the IR(Instruction register) doesn't take any value at all.
The AR(address reg) has the expected values but in a wrong sequence
because after the value of memory position 4 (27H) is downloaded, all the
other contents of the memory are downloaded but the cpu does nothing since
the IR Reg. (which drives the control unit) has no value.

Thank you, Aliki.

 

[Just an Illusion]

Hi ALuPin,

For me, it seems synthezisable (but you have following errors:
clk'evevt -> Syntax error)

I think that design declare too lot of registers:
* 256x8 ff for tag
* 256x8 ff for data
* 8 ff for count
* 1 ff for full
* 1 ff for hit
* 8 ff for data_out

=> 4114 ff minimum

More it missing the value of data_out when reset

I think that you can split the code differently, and generate full, hit,
data_out through combinatory formula

Rgrds,
JaI


ALuPin wrote:

Hi,

is the following CAM-implementation
synthezisable? How does a synthesis tool handle the for-loop
in real hardware?

http://www.geocities.com/deepakgeorge2000/cam.htm

 

[Mike Treseler]

ALuPin wrote:

I mean are the 256 steps of the clock performed within
one clock cycle?

Yes. The synthesis netlist will sim the
same as the code.

-- Mike Treseler

 

[Jim Lewis]

Just an Illusion wrote:

Hi all,

In a message from Jim Lewis as response for thread "One-hot Coding State
Machines", he named the IEEE 1076.6-2004.

Someone have it ? I couldn't find it on the IEEE website.
Someone knows the availibility date, on the IEEE website, for download ?

Thanks,
JaI

Sorry I was on vacation and did not check news groups.

The latest from the chair of the group is:
In a month or so. Final edits are occurring now.

The group webpage is: http://www.eda.org/siwg/


Cheers,
jim

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Jim Lewis]

Weng,

In the last example, you have to declare every equation in 'if'
condition as a signal,
Yes.

You realize that your expression had an error right?
Show me a correct example that has mutual exclusion
and uses an equation.

and then to add assert onehot() statements at the file beginning.
I was using assert as a concurrent statement, so it can go anywhere

in the concurrent code region of the architecture.

Do you really think 'assert' is better than 'orif'?
Yes. Read on.

'if..elsif..endif' is the most beautiful and commonly used expression.
I agree.

'if..orif..endif' does the same things as beautiful and
concise as 'if..elsif..endif'.
Lets see. Here is a simple example:

Ex1 : process
begin
wait until Clk='1' ;
if ASel = '1' then
Y <= A ;
orif BSel = '1' then
Y <= B ;
orif CSel = '1' then
Y <= C ;
orif DSel = '1' then
Y <= D;

-- covers error conditions. eg: ASel = 1 and BSel = 1
errels
report "error" ;
Y <= '-' ; --

-- covers all other conditions and not required
-- else
-- Y <= Y ;
end if ;
end process ;


The following is more expressive than above. In this
example I don't think either is more concise than the
other.

assert onehot(ASel & BSel & CSel & DSel) ... ;

Ex2 : process
begin
wait until Clk='1' ;
if ASel = '1' then
Y <= A ;
elsif BSel = '1' then
Y <= B ;
elsif CSel = '1' then
Y <= C ;
elsif DSel = '1' then
Y <= D;
end if ;
end process ;

'Dangerous' is a word what belongs to a novice designer. Your statements:
assert onehot(A1, A2, A3) report "failed" severity failure ;
has the same level of 'danger' as 'orif' if there were a 'danger'.
I really don't know how the level of 'danger' is reduced by using
'assert' statement!
Which one do you think is more readable? With orif you really

need to pay attention to orif vs. elsif. With assert onehot,
look at the signals in the expression.

I think your mistake below clearly illustrates another
danger of orif. See the statemachine example for another.
With assert onehot, you easily see exactly what you are
getting.

Perhaps you meant:
assert onehot(CSRAD_R0_L_DIMMNumber_H, CSRAD_R0_H_DIMMNumber_H) ... ;

You are right.


Note your code also includes fields of nC_BE_RO.

('AND' nC_BE_RO) has no any effect on the mutually exclusive relations of above two conditions.

Your orif statement says one equation is mutually
exclusive from the other. Since you are using different
fields of nC_BE_RO, it will be considered by the synthesis
tool as being part of the mutually exclusion. Hence,
I am not convinced you will realize any hardware savings in
your example.

'if..orif..endif' has the same effect that 'assert' method cannot have.
Likewise assert has capability that if..orif..endif cannot express.

General claims of validity do nothing, show me a relevant example.

assert has another problem: when two state machines are mutually
exclusive, do you have a means to declare they are mutually
exclusive?
First it is states that are mutually exclusive not the entire

statemachine itself.

assert onehot(SM1=READ_STATE, SM2=WRITE_STATE) ... ;

If you have a sizable amount of logic, how many times are
you going to express mutual exclusion with orif? Perhaps
you should work through the logic in your statemachine
example.

Lets suppose you have specified a particular multiple
times due to different branches in a statemachine.
What happens if you have specified two conditions to
be mutually exclusive in one branch with orif, but
accidentally use elsif in another branch?
How will you detect your error? You will need a good
lint tool.

To really understand what is needed one must look at the details.
If you only consider code snippets, you will end up with a
less desirable implementation.

Your questions are convincing me even more that assert onehot
is the better solution.

You are the only person so far I have met who recognized the problem.
I don't think this is the case. I noted several who

agree there is a problem, but disagree with your solution.
Others tune out due to your approach. Starting a question
by insulting people (standards groups) generally causes
them to ignore you.

Regards,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Symon]

Viswan,
Google and read about the IEEE standard package numeric_std. It supports the
data formats you are talking about.
cheers, Syms.
"Viswan" <viswan_1981@hotmail.com> wrote in message
news:c9cb3993.0406231504.86d66a1@posting.google.com...

hi,

I have a doubt in VHDL. How could I convert a two's complement vector
to an unsigned vector and vice versa. I was designing a divider which
works only for unsigned vectors, where as all the rest of my hardware
deals with 2's complement numbers. So I planned to convert the 2's
complement vector to unsigned and get the result and convert it back
to 2's complement. Are there any other functions in VHDL that do
these kind of conversions? I know there are conversion from integers
to vectors but I doubt whether there are any conversion functions that
perform the above function.

Any other ideas on designing the above divider are also mostly
welcome.

Thanks
Viswan

 

[Matt North]

"Ken Smith" <kensmith@violet.rahul.net> wrote in message
news:cato9u$8j4$4@blue.rahul.net...

In article <carh6s$vdm@newton.cc.rl.ac.uk>,
Matt North <m.r.w.north@NO_SPAMrl.ac.uk> wrote:
I have a nice one that is about a 25 pounder. Its XP compatible.

Sounds good........i'm seriously thinking of upgrading to a THOR AP12
Aluminium and plastic hammer.
It gives the user a choice of persuasive use with the plastic head or
destruction with the aluminium head.

Now that THOR inc. has been bought out by McDisneyMart Corp. they import
cheap junk and put their label on it. If the head isn't hand forged it
won't completely uninstall XP from the hard disk.

--
--
kensmith@rahul.net forging knowledge

I cant find much information about the 'forgedness' of the THOR AP12.
I have extended my search and found the Roebuck Sledge with fibreglass
handle;
'Heads manufactured from EN9 steel fully in accordance with BS876 and fitted
with
comfortable, hardwearing cushion grips'

 

[Just an Illusion]

Hi Weng

Weng Tianxiang wrote:

Jim,


You realize that your expression had an error right?



Now let us first resolve this problem: Your claim is wrong.

My situation is:
CSRAD_R0_L_DIMMNumber_H and CSRAD_R0_H_DIMMNumber_H are mutually
exclusive derived from their physical conditions: 32-bit width PCI bus
and 64-bit width PCI bus(it cannot be modified as Just ... wrongly
indicated), so
1. (CSRAD_R0_L_DIMMNumber_H and (..))
2. (CSRAD_R0_H_DIMMNumber_H and (..))
are mutually exclusive.


Question for you: You said that your 2 above conditions are mutually

because CSRAD_R0_L_DIMMNumber_H and CSRAD_R0_H_DIMMNumber_H are mutually
exclusive, right ?

If I take the following example:
A1 <= A and B;
A2 <= C and B;

with A and C mutually exclusive. How could you pretend that A1 and A2
are mutually exclusive ?
Mutual exclusive is these both signals are never equal. It is express in
logic by the xor function (exclusive or).

I supposed that Just... is me, you can short my alias by JaI (as my
signature) ;-)

I *never* said that you must modified your code with my way. It is only
a proposal, based on fact that you have some part of your code which is
equivalent, except that you have an offset in one case and not in the
other one.

With this new information about CSRAD_R0_L_DIMMNumber_H and
CSRAD_R0_H_DIMMNumber_H mutual exclusive.
Why don't write your example with case:


if(DIMMNumberClear) then
DIMMNumber(4 downto 0) <= (others=>'0');

else
case PCI_TYPE is
when CSRAD_R0_L_DIMMNumber_H =>
if (nC_BE_R0(3 downto 0) = "0111") then
if(AD_R0(28) = '1) then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(28 downto 24);
end if;
end if;
when CSRAD_R0_H_DIMMNumber_H =>
if (nC_BE_R0(7 downto 4) = "0111") then
if(AD_R0(60) = '1') then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(60 downto 56);
end if;
end if;
when others => null;
end case;
end if;

In that case, CSRAD_R0_L_DIMMNumber_H and CSRAD_R0_H_DIMMNumber_H are
clearly exclusive.

If I rewrite my proposal, you can have something as:

type PCI_TYPE is (BAD_TYPE,PCI_32, PCI_64);

signal my_pci_type : PCI_TYPE;
signal bad_pci_type : std_logic;
signal n : integer;
....

-- I have convert CSRAD_R0_L_DIMMNumber_H and CSRAD_R0_H_DIMMNumber_H
-- according to 1076.3-1997.

process (CSRAD_R0_L_DIMMNumber_H, CSRAD_R0_H_DIMMNumber_H)
variable tmp_type : std_logic_vector (1 downto 0);
begin
tmp_type := CSRAD_R0_L_DIMMNumber_H & CSRAD_R0_H_DIMMNumber_H;

case tmp_type is
when "10" => my_pci_type <= PCI_32;
when "01" => my_pci_type <= PCI_64;
when others => my_pci_type <= BAD_TYPE;
end process;

process (my_pci_type)
begin
case my_pci_type is
when PCI_32 =>
n <= 0;
bad_pci_type <= '0';
when PCI_64 =>
n <=1;
bad_pci_type <= '0';
when others =>
n <=0;
bad_pci_type <= '1';
end case;
end process;

process (DIMMNumberClear, nC_BE_R0, n, bad_pci_type)
begin
if (DIMMNumberClear) then
DIMMNumber(4 downto 0) <= (others=>'0');
elsif (bad_pci_type = '0') then
if (AD_R0(28+n*32) = '1') then
DIMMNumber (4 downto 0) <= "10000";
else
DIMMNumber (4 downto 0) <= AD_R0(28+n*32 downto 24+n*32);
endif;
endif;
end process;

snip
Weng


JaI

 

[fred]

In article <40d81723@news1.homechoice.co.uk>, johnp <john.pearson@h
omechoice.co.uk> writes

"Naimesh" <t_naimesh@rediffmail.com> wrote in message
news:ecee4f8a.0406212202.4e0fa6be@posting.google.com...
Hello,

I need to write a DPLL to recover the clock of Manchester encoded
data. Rate of the data transmission is known(1.544Mbps).So just phase
of the clock is to be found. I have 16 time faster clock then the rate
of the transmission. Can any one help me out? pls. suggest any link or
book if possible

Thanks

See post here entitled "Problems with DPLLs" 3/6/2004
regards Johnp

Interested in seeing this thread but not found on Google groups. Any
message IDs?
--
fred

 

[fred]

In article <40db0087$1@news1.homechoice.co.uk>, johnp <john.pearson
@homechoice.co.uk> writes

"fred" <not@for.mail> wrote in message news:LR8yoLAJ8p2AFwbX@y.z...
In article <40d81723@news1.homechoice.co.uk>, johnp <john.pearson@h
omechoice.co.uk> writes

See post here entitled "Problems with DPLLs" 3/6/2004
regards Johnp

Interested in seeing this thread but not found on Google groups. Any
message IDs?
--
fred

try comp.lang.vhdl !

Yup that's where I was looking, then under the bed, then global search . . .

Wouldn't find it via DPLL, had to be DPLLing as in orig msg, jeez . . .

Anyway, thanks for tip, interesting thread.
--
fred

 

[Ray Andraka]

You can do a sigma-delta DAC in the CPLD if you run the clock fast
enough. The external components are just a resistor and capacitor in
that case. The shortwave reciever in an FPGA demo posted on my website
uses a sigma-delta converter clocked at 160 MHz to to get a high fidelity
analog audio output (25KHz sample rate going into it). I think xilinx
has an app-note that describes sigma delta converters in detail.

AlfonsoGarcia wrote:

That's what I mean. I need external circuitry in order to make the DA
converter reality. Only through a CPLD or FPGA it is not possible.
Thanks for the hints and help.
Alfonso

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759

 

[Jim Lewis]

Weng,

OK, at last Jim and JaI admit my equation is right.
I did not actually say I agreed it is correct.

I agreed that when you divulged there were additional
conditions that made A and C mutually exclusive that
the circuit would work the way you described.

A1 <= A and B;
C1 <= C and B;

Note that under the conditions you describe, orif and elsif
should synthesize equally well (because if the synthesis tool
understands terms are mutually exclusive, then it does
not need orif). Also note that you are relying on the
synthesis tool to derive the mutual exclusion (otherwise
the only thing it knows is that A1 and C1 are mutually
exclusive).

If you use "orif", and the synthesis tool cannot derive
the mutual exclusion, then you are back to the tool
understanding that A1 and C1 (because of the orif)
being mutually exclusive, but not A and C.

So what you have done for me is to demonstrate how difficult
it is for people (yourself included) to full comprehend
the implications of orif.

Tomorrow I will 'attack' Achilles heel of Jim's proposal assert()
to resolve mutually exclusive relations.
Bring it on. You have yet to demonstrate any limitations.

So far you have only further convinced me that assert is the
better answer.

It would also be helpful if you could post some reasonable
sized examples which use orif.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Just an Illusion]

As Jim said,

I haven't said that I am agree with you.

I don't think that your proposal can help synthesizer.


Weng Tianxiang wrote:

OK, at last Jim and JaI admit my equation is right.
snip

process (DIMMNumberClear, nC_BE_R0, n, bad_pci_type)
begin
if (DIMMNumberClear) then
DIMMNumber(4 downto 0) <= (others=>'0');
elsif (bad_pci_type = '0') then
if (AD_R0(28+n*32) = '1') then
DIMMNumber (4 downto 0) <= "10000";
else
DIMMNumber (4 downto 0) <= AD_R0(28+n*32 downto 24+n*32);
endif;
endif;
end process;



Above equations are wrong. n must be a constant to let compiler to
work. It is an compiler error. If n is a dynamic signal like in my
case, you must use n as in a condition for 'if' statement. If you
don't believe, try to compile it using any VHDL compiler.


I have demand you if pci type (32-b and 64-b) can be dynamically change,

you haven't answer.
So I give you an example where n is constant.

Reread my question.

Don't keep only some out of context part.

Second segment of equations is right. Thank you, JaI!!! It clearly
demonstrates how hard from current VHDL structure to get both right
and efficient code.

Sorry I don't understand which second segment.

You must rewrite total code to get efficient
code!!!

If the coder have badly write his first code version, don't blam the

language.
You have the same problem with any programming language.

Before write any vhdl code line, you *must* think before about what you
want to do.
Put some comment, and perhaps that can help you to find an other way to
write the same equation.

It is a big problem when you have a big project. It is real,
not virtual. That is why 'I hate VHDL': it is like you bought a set of
sockets to start your business and found that 3/8" socket wasn't there
and the manufacturers say it is your problem, you can deal with it
using 1/2", why do we need to manufacture a 3/8" socket especially for
your purpose?!

Sorry, I don't understand your joke about socket.

Propose to your manufacturer to multiply your buying price by ten, and
see it's answer.

That is why 'orif' is so useful in the situation: first you write
correct code, then change 'elsif' to 'orif', you get your most
efficient code without any other code and structure change.


I am not convinced.

Lot of exclusive section are implementation dependant; if you want
design a reusable module, then you can do these types of assertions.
Otherwise you have a _critical_ risk in your design.

Logical equation optimizations are in synthesizer perimeter, not vhdl.
If you write clear logic equation, you can help the synthesizer; but
look the resulting netlist, the equations are not exactly the same that
you have write.

For you, what is the difference between both following notations ?

c <=a and b;

and
InstAnd : And2 (A=>a, B=>b, Y=>c); -- where And2() is a
component of which behavioral fucntion is the logical and.

For behavioral functionality, or logic simulation (with zero delay),
none. But after synthesis, you can have two different circuit.
Why ? because with And2 case, you said to synthesizer that you want
explicitely use the gate And2 model.

Take following pseudo-examples:

ExampleA:
c <= a and b;

d <= e and f;

g <= c and d;


and:

ExampleB:
InstAndC: And2(a,b,c);
InstAndD: And2(e,f,d);
InstAndG: And2(c,d,g);

After synthesis, in case ExampleA you can use 1 and gate, with 4 inputs,
to generate 'g' (and 1 and-gate delay); but for ExampleB you have 3 and
gates, with 2 inputs, to generate the same 'g' (and 2 and-gate delay).
You have the same functionnality, but not the same implementation.


JaI

 

[Alan Fitch]

<nicolai@free.fr> wrote in message
news:d79f931b.0406040559.20c3f4f9@posting.google.com...

I use Cadence simvision for my simulations but I noticed that i
could
not reset the simulation once it started when using systemc blocs in
my configuration.

My testbench uses vhdl but it uses some components writen in c++ .
Is there a solution , do you know if it's possible to reset
simulation
with this simulator with systemc files ?

my problem is that I'd like to carry out a batch of simulation (
1000) but it takes a long time since I have to launch simvision for
each simulation.

I found that "Reinvoke Simulation" works with SystemC, but Reset
doesn't.
However I think that Reinvoke Simulation is possibly too slow for
your application. Isn't there a way of reinvoking simulation, but
attaching
it to an existing instance of Simvision?

Could you write a simulation that doesn't use waveforms and write a
self-checking
testbench instead?

regards

Alan


--
Alan Fitch
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:
alan.fitch@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.

 

[Gary Michels]

mark.andrew@gmail.com (Mark Andrew) writes:

Why don't you use your clock?

-----------------------------------------------------------------------

entity minialu is
Port ( switches : in std_logic_vector(7 downto 0);
leds : out std_logic_vector(7 downto 0);
clk : in std_logic;
pbs : in std_logic_vector(7 downto 0);
counter : out std_logic_vector(15 downto 0));
end minialu;

architecture Behavioral of minialu is
begin
xxx : process (pbs,switches)
begin
if pbs(0) = '0' then -- test for '0' works /test for '1'
fails
counter <= x"1234";
else
counter <= x"FFFF";
end if;
leds(0) <= pbs(0);
leds(7) <= switches(0) or switches(1);
leds(6) <= switches(0) and switches(1);
end process ;
end Behavioral;