I hate VHDL!!!

W

Weng Tianxiang

Hi,
I hate VHDL!!!
I one person had developed a large VHDL design. Now because PCB
reasons, the project has to be divided into 2 subdesigns: 95% are the
same with 30 pins different in interfaces.

So I naturally hope to write the code like this:
In entity part:
if ChipA = true, do following
signal ... : inout ...
signal ... : inout ...
....
else
signal ... : inout ...
signal ... : inout ...
....
end if;

In signal declaration part:
if ChipA = true, do following
signal ...
signal ...
....
else
signal ...
signal ...
....
end if;

In process part:
if ChipA = true, do following
process(...)(...)
process(...)(...)
....
else
process(...)(...)
process(...)(...)
....
end if;

But I cannot do that.

If it were in C or C++, #define and #undefine conditional statements
are so easy to use, we programmers can never imagine such beautiful
things are never permitted in VHDL!!!

Another problem of VHDL is the following:
In my PCI/PCI-X development, when a transaction address appears on
bus, I have to test 3 space addresses in a state machine to see what
type of actions I should take:
if(BusAddress = 32-bit-Address1) then
NextState <= stateX1;
elsif(BusAddress = 32-bit-Address2) then
NextState <= stateX2;

elsif(BusAddress = 32-bit-Address3) then
NextState <= stateX3;
end if;

Did you notice that in goto stateX3 statement it contains two other
unnecessary comparisons:
BusAddress = 32-bit-Address1
BusAddress = 32-bit-Address2

It just wastes resources!!!

Any comments are welcome.

Weng
 
P

paris

"Weng Tianxiang" <[email protected]> escribió en el mensaje

If it were in C or C++, #define and #undefine conditional statements
are so easy to use, we programmers can never imagine such beautiful
things are never permitted in VHDL!!!

indeed, C was meant for programmers: "soft"ware, and VHDL was meant for EE
engineers: "hard"ware :)
though i guess that if you put the entity and the architecture in different
files, you could use different entities and use the generate keyword on the
architecture, then a configuration file.
I recall using different files for entities, architectures and then
configurations when i first learnt VHDL, but i havent designed that way
since then.
Another problem of VHDL is the following:
In my PCI/PCI-X development, when a transaction address appears on
bus, I have to test 3 space addresses in a state machine to see what
type of actions I should take:
if(BusAddress = 32-bit-Address1) then
NextState <= stateX1;
elsif(BusAddress = 32-bit-Address2) then
NextState <= stateX2;

elsif(BusAddress = 32-bit-Address3) then
NextState <= stateX3;
end if;

Did you notice that in goto stateX3 statement it contains two other
unnecessary comparisons:
BusAddress = 32-bit-Address1
BusAddress = 32-bit-Address2

isnt "goto" bad-practice? :)
you want the comparisons to take place in parallel?
 
N

Nicolas Matringe

Weng Tianxiang a écrit:
if(BusAddress = 32-bit-Address1) then
NextState <= stateX1;
elsif(BusAddress = 32-bit-Address2) then
NextState <= stateX2;
elsif(BusAddress = 32-bit-Address3) then
NextState <= stateX3;
end if;

Did you notice that in goto stateX3 statement it contains two other
unnecessary comparisons:
BusAddress = 32-bit-Address1
BusAddress = 32-bit-Address2

It just wastes resources!!!

Well known fact. This is not a language problem, only a hardware
description problem. If you hated VHDL a bit less and decided to learn
it a bit more you would discover the fantastic 'case' statement:

case BusAddress is
when Address1_32_bit => NextState <= stateX1;
when Address2_32_bit => NextState <= stateX2;
when Address3_32_bit => NextState <= stateX3;
when others => null;
end case;
 
W

Weng Tianxiang

Hi,
You are not correct.

Their address widths are not same:
Give you an example: one is 2-bits, second 24-bits, third 12-bits in
my case, and in the future, 4th 32-bits.

Weng
 
T

Tom Hawkins

Hi,
I hate VHDL!!!
I one person had developed a large VHDL design. Now because PCB
reasons, the project has to be divided into 2 subdesigns: 95% are the
same with 30 pins different in interfaces.

Consider using GENERATE. Based on a generic, your entity could be
configured for either design_A or design_B.

Or better yet, look to Confluence, where every datatype is a
configuration parameter. Think of it #defines on steriods. Off hand
I can think of a slew of possibilities for abstracting out the
commonality between your two parts.

[snip]
Another problem of VHDL is the following:
In my PCI/PCI-X development, when a transaction address appears on
bus, I have to test 3 space addresses in a state machine to see what
type of actions I should take:
if(BusAddress = 32-bit-Address1) then
NextState <= stateX1;
elsif(BusAddress = 32-bit-Address2) then
NextState <= stateX2;

elsif(BusAddress = 32-bit-Address3) then
NextState <= stateX3;
end if;

As another poster pointed out, there are cleaner ways to express this.
Here's another option:

NextState <= stateX1 when BusAddress = 32-bit-Address1 else
stateX2 when BusAddress = 32-bit-Address2 else
...

Whether you choose if, case, or when, the results are more or less the
same.
Did you notice that in goto stateX3 statement it contains two other
unnecessary comparisons:
BusAddress = 32-bit-Address1
BusAddress = 32-bit-Address2

It just wastes resources!!!

It may appear so, but put a little trust in the compiler. Conditional
tree structures are extremely common. Synthesis optimizations will
clean it right up.

-Tom
 
W

Weng Tianxiang

Thank you very much. What you described is what I really and
desperately want.

One question:
Why cannot VHDL specs include the definition of #if, #ifdef... and let
all users share the greatness, easiness and beautifulness of part of C
grammar instead of letting me ask software engineers to manufacture a
make file to call other applications (C preprocessor and make
application) that doesn't belong to vhdl compiler? And I don't know
why its committee spends a lot of time doing the most frivolous
changes, but not investing time to do most important one: add
definitions of #if, #ifdef... ?

Weng
 
R

Ralf Hildebrandt

Weng Tianxiang wrote:

Why cannot VHDL specs include the definition of #if, #ifdef...

VHDL has a similar construct:

gen1_name : if (... some_condition...) generate
end generate;

gen2_name: for N in 0 to 7 generate
end generate;

Note: "some_condition" has to be static.
These constructs allow fine-grain configuration of the architectures.

Example: Depending on a constant (provided as generic parameter or
manually set) I want to switch between latch-based and flipflop-based
registers:

constant impl_ff : integer:=1;
-- 1 for FFs, 0 for latches

.....

gen_reg_latch : if implf_ff=0 generate
process(reset,enable,data_in)
begin
if (reset='1') then
reg<='0';
elsif (enable='1') then
reg<=data_in;
end if;
end process;
end generate;

gen_reg_ff : if implf_ff=1 generate
process(reset,enable,data_in)
begin
if (reset='1') then
reg<='0';
elsif rising_edge(enable) then
reg<=data_in;
end if;
end process;
end generate;


Unfortunately there is no

if (..condition...) generate
...
else generate
...
end generate


and you cannot modify an entity, whitch is the biggest disadvantage. But
in all other cases, generate statements are very useful and as you can
see very similar to #ifdef ... .


Ralf
 
J

Jim Lewis

Weng,
There is no reason you can't use CPP in your design flow.

Cheers,
Jim
Thank you very much. What you described is what I really and
desperately want.

One question:
Why cannot VHDL specs include the definition of #if, #ifdef... and let
all users share the greatness, easiness and beautifulness of part of C
grammar instead of letting me ask software engineers to manufacture a
make file to call other applications (C preprocessor and make
application) that doesn't belong to vhdl compiler? And I don't know
why its committee spends a lot of time doing the most frivolous
changes, but not investing time to do most important one: add
definitions of #if, #ifdef... ?

Weng


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

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

Jim Lewis

Weng,
And I don't know why its committee spends a
lot of time doing the most frivolous changes,

This type of remark will not make you many friends.

I take this a little personally. For the past two
years, I have been working on VHDL-200X to make
sure the next VHDL several revisions deliver
high value. Perhaps you should review the
current proposals before you make such a statement.
See:

http://www.eda.org/vhdl-200x/vhdl-200x-ft/proposals/proposals.html


Regards,
Jim Lewis
P.S.
You might remember my name. I was the one who reviewed
and helped you revise your DVCon paper a couple of years
ago.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

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

Weng Tianxiang

The website statements are exciting:
"In order to achieve the same functionality as the "#if" and "#ifdef"
constructs of C/C++, the macro processor of an ordinary C compiler may
be used. Usually, C compiler have a special command line switch to
stop compilation after the preprocessing stage (e.g., "-E" for the GNU
C/C++ compiler). Hence, VHDL source code can be augmented with C
macros or "#ifdef...#endif" statements and then preprocessed with a C
compiler before it is compiled with a VHDL compiler. A "make" tool may
help to automate this two-stage approach."

But results are bad:
One of our company software engineers met a lot of errors using
suggested method due to inconsistent vhdl/C grammars and abandoned the
method and suggested to write a C program to handle the situations,
but I have to wait until the end of the month!

I will write the software & provide source code here when I finish and
test it to benefit all vhdl programmers.

You can use the program to filter vhdl file by adding #define, #undef,
#endif, #ifdef and add those statements anywhere in a vhdl file where
you want and the output file will contain correct output file name to
reflect what variables are used to avoid any inconsistency.

The following is the file specification:

Specification of C program VhdlFilter

It is used to get input vhdl file and output vhdl file, filtering all
unnecessary statements.

C statement key words used for VhdlFilter:
#define
#endif
#ifdef
#ifndef

1. All key words above use C definitions and practice.
2. '#' of all C key words above is only located at 1st character
position in a line to facilitate handling;
3. #ifdef, #ifndef and #endif can be nested.

Specifications for vhdl VhdlFilter:
1. Input command format: VhdlFilter inputname.vhd
2. Output file: inputname-X-Y.vhd in the same directory as input file
with same file extension;
3. X is the last character of variable defined in first #define
statement if the variable ends with "-X";
or its full name of the variable if there is no '-' in it.
4. Y is the last character of variable defined in first #define
statement if the variable ends with "-y";
or its full name of the variable if there is no '-' in it.

Example:
Input file name: 7460-X.vhd
Variable name defined in first #define statement: Chip-A
Variable name defined in 2nd #define statement: debug

Then the output file name would be: 7460-X-A-debug.vhd
If no second #define statement
Then the output file name would be: 7460-X-A.vhd
if first variable is defined as debug without imbedded '-', then the
output file name would be 7460-X-debug.vhd

The following is my vhdl file entity and you may see how it is easy to
use.
I want to generate 4 versions:
Chip-A-debug.vhd
Chip-A.vhd
Chip-B-debug.vhd
Chip-B.vhd

Now what I have to do is to change #define statements in the first
part of design. That's it.

By the way, my design is 15,000 line long. So one person team can be
capable of coding and simulations.

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

#define Chip-A;
--#define Chip-B;
--#define debug;

-------------------------------------------------------------------
entity PCI_CORE is
port(
CLK66M : in std_logic;
nRESET : in std_logic;
M66EN : in std_logic;
AD : inout std_logic_vector(63 downto 0);
nC_BE : inout std_logic_vector(7 downto 0);
PAR : inout std_logic;
PAR64 : inout std_logic;
nFRAME : inout std_logic;
nIRDY : inout std_logic;
nTRDY : inout std_logic;
nSTOP : inout std_logic;
nDEVSEL : inout std_logic;
IDSEL : in std_logic;
nREQ : out std_logic;
nGNT : in std_logic;
nREQ64 : inout std_logic;
nACK64 : inout std_logic;
nPERR : inout std_logic;
nSERR : out std_logic;
nCS : out std_logic_vector(31 downto 0);
DQM : out std_logic_vector(15 downto 0);
CKE : inout std_logic_vector(15 downto 0);
A0 : out std_logic_vector(12 downto 0);
A1 : out std_logic_vector(12 downto 0);
A2 : out std_logic_vector(12 downto 0);
A3 : out std_logic_vector(12 downto 0);
BA0 : out std_logic_vector(1 downto 0);
BA1 : out std_logic_vector(1 downto 0);
BA2 : out std_logic_vector(1 downto 0);
BA3 : out std_logic_vector(1 downto 0);
nRAS : out std_logic_vector(3 downto 0);
nCAS : out std_logic_vector(3 downto 0);
nWE : out std_logic_vector(3 downto 0);
nData74Read : out std_logic_vector(3 downto 0);
DQ : inout std_logic_vector(71 downto 0);
SCL : out std_logic_vector(1 downto 0);
SDA : inout std_logic_vector(1 downto 0);
nFail5V : in std_logic;
nFail3V : in std_logic;
nPowerReady : in std_logic;

#ifdef Chip-A
nINTA : out std_logic;
RTC_SCL : out std_logic;
RTC_SDA : inout std_logic;
RTC_Square : in std_logic;
ROM_WriteProtect : out std_logic;
PowerState : out std_logic;
MicroCtrl : out std_logic;
PowerDownMode : out std_logic;
PowerLED : out std_logic;
InitializeTo74 : out std_logic_vector(1 downto 0);
InitializeFrom74 : in std_logic_vector(1 downto 0);
LEDClock : out std_logic;
BatteryClock : in std_logic;
BatteryAD : in std_logic;
BatteryData : in std_logic
#ifdef debug
; -- not the last statements in entity
#endif; -- debug
#endif; -- Chip-A

#ifdef Chip-B
nPCIBUS31_IntA : in std_logic;
nPCIBUS31_IntB : in std_logic;
nPCIBUS31_IntC : in std_logic;
nPCIBUS31_IntD : in std_logic;
nPCIBUS32_IntA : in std_logic;
nPCIBUS32_IntB : in std_logic;
nPCIBUS32_IntC : in std_logic;
nPCIBUS32_IntD : in std_logic;
nPCIBUS1_Bridge1_Int : in std_logic;
nPCIBUS2_Bridge1_Int : in std_logic;
nPCIBUS2_Bridge2_Int : in std_logic;
nPCIBUS31_Bridge2_Int : in std_logic;
nPCIBUS2_Bridge3_Int : in std_logic;
nPCIBUS32_Bridge3_Int : in std_logic;
nPCIBUS1_Processor_Int : in std_logic;
nPCIBUS1_Gigabit_Int : in std_logic;
nPCIBUS1_SATA_Int : in std_logic;
nPCIBUS1_PMC_Int : in std_logic;
nPROC_IRQ_0 : out std_logic;
nPROC_IRQ_1 : out std_logic;
nPROC_IRQ_2 : out std_logic;
nPROC_IRQ_3 : out std_logic;
nPROC_IRQ_4 : out std_logic;
nPROC_NMI : out std_logic;
DONE : in std_logic;
RTC_RSTn : in std_logic;
PROC_SA11 : in std_logic;
LINK_1000n : in std_logic;
LINK_100n : in std_logic;
LINKn : in std_logic;
SDMA12_RESET : in std_logic;
SDMA13 : in std_logic;
SDMA14_CHKSTOP_INn : in std_logic;
PROC_FLASH_PE : in std_logic;
RCS0n : inout std_logic;
RCS1n : in std_logic;
RCS2n : in std_logic;
RCS3n : in std_logic;
JTAG_TRSTn : in std_logic;
JTAG_HRESETn : in std_logic;
PCIBUS1_RSTn : out std_logic;
PROC_SA0 : out std_logic;
PROC_SA1 : out std_logic;
PROC_DQ32 : out std_logic;
ROM_CEn : out std_logic;
ROM_FOEn : out std_logic;
LINK_10n : out std_logic;
ROM_A21 : out std_logic;
ROM_A22 : out std_logic;
ROM_A23 : out std_logic;
ROM_A24 : out std_logic;
PCIBUS1_REQ64n : out std_logic;
PCIBUS2_REQ64n : out std_logic;
PCIBUS31_REQ64n : out std_logic;
PCIBUS32_REQ64n : out std_logic;
CPU_RSTn : out std_logic;
TRSTn : out std_logic
#ifdef debug
; -- not the last statements in entity
#endif; -- debug
#endif; -- Chip-B

#ifdef debug
FeedDataToDQ : out std_logic;
SDRAMIsReady : out std_logic;
DMASDRAMWait : out std_logic;
DMASemaphoreWait : out std_logic;
DMADescriptorWait : out std_logic;
ClockSerialA : in std_logic;
SDRAMPtrLoad_O : out std_logic;
SDRAMPtr35_3_O : out std_logic_vector(34 downto 3);
RTC_SDA_In_Enable : out boolean;
RTC_SDA_Latch_Enable : out boolean;
SDA_In_Enable : out boolean;
SDA_Latch_Enable : out boolean
#endif; -- debug
);
end PCI_CORE;

Any comments are welcome.

Weng
 
S

Symon

Hi Weng,
I don't want to upset you or your software guys and I know you want to
"share the greatness, easiness and beautifulness of part of C grammar" but
it strikes me that I could write a Perl script to do that in about a hour,
certainly in less than a day.
Oranges aren't the only fruit...
cheers, Syms.
 
J

Jim Lewis

Weng,
I just tried the CPP version that comes with cygwin.
You have some syntax problems with your cpp
directives that you need to fix. Once I fixed them
everything seems to work fine. Oh CPP had some annoying
status output that starts with #, that you will need to
deal with. Sum total about 10 minutes of time.

BTW, CPP could care less about VHDL syntax. It is your
directives that have the errors that you need to fix.

Want the file? You need to learn to be less
insulting when you have a problem. I work in that
standards group that you took your frustration out on.
Perhaps I would be a little nicer about sharing if
you appologized. Otherwise, do your own debugging.

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

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

Holger Baxmann

This seem definetely OT.

should be posted in comp.lang.perl

No need for obfuscated assembler here.

;-)

bax
 
N

Nicolas Matringe

Hi,
You are not correct.

Yes I am

Their address widths are not same:

How should I know?

Give you an example: one is 2-bits, second 24-bits, third 12-bits in
my case, and in the future, 4th 32-bits.

You still compare a signal called BusAddress am I right? So its length
is 32 bits. Whatever you do, the comparisons will be on 32 bits vectors.
If you want a variable width comparison, you'll have to mask some bits
(and I'm not talking VHDL here but language-independent hardware).
Anyway, the 'case' statement is what you need.

If what you want is something like
if BusAddress1 = 2-bits-constant-address1 then
....
elsif BusAddress2 = 12-bits-constant-address2 then
....
elsif BusAddress3 = 32-bits-constant-address3 then
....
end if;
you should have said.
I'm no wizard (seems I already wrote this not so long ago), I can't
understand what you *think* you wrote.
 
J

Jonathan Bromley

Thank you very much. What you described is what I really and
desperately want.

One question:
Why cannot VHDL specs include the definition of #if, #ifdef... and let
all users share the greatness, easiness and beautifulness of part of C

Oh, please.

Yes, there are some things that are more intuitive when done
with a preprocessor. But preprocessor options are global,
and take effect at compile time. The VHDL alternative,
which IMHO is much, much prettier, is to use "generate";
this can be controlled PER-INSTANCE, a concept that seems
to have escaped the C preprocessor enthusiasts. Oh, I
suppose that's because VHDL has the concept of "elaboration",
yet another concept that's foreign to C.

If you want VHDL to be C, then kindly use C instead,
and go ahead and write your own stuff to do all the things
that VHDL does with silky smoothness - sensitivity of
processes to events, unconstrained arrays, named association
lists... SystemC has solved these problems:

www.systemc.org

but only by appealing to the considerable power of C++.
System-level design and verification problems are simply
too hard to be solved comfortably with the C compiler
and preprocessor that you seem to favour.
--
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, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:[email protected]
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.
 
W

Weng Tianxiang

This is a Achilles heel for VHDL or Verilog.

You don't have any feasible means to avoid the situations I mentioned
in any state machine unless you waste resources as you wrote.

NextState <= stateX1 when BusAddress = 32-bit-Address1 else
stateX2 when BusAddress = 32-bit-Address2 else
...

NextState will involve all first comparisons made for the last
statements, but actually they are mutually exclusive.

The best way to do it is:
if(BusAddress = 32-bit-Address1) then
NextState <= stateX1;
orif(BusAddress = 32-bit-Address2) then <-- a new suggested keyword
"orif"
NextState <= stateX2;
orif(BusAddress = 32-bit-Address3) then
NextState <= stateX3;

NextState <= stateX1 when BusAddress = 32-bit-Address1 elsor <-- a new
suggested keyword "elsor"
stateX2 when BusAddress = 32-bit-Address2 elsor
...
It means if one of comparison is true, jump to the state without
referring to others. Because they are mutually exclusive.

Otherwise, if you are performance sensitive, you must put least width
comparison equations at the first places to minimize any unnecessary
penalty due to many mutually exclusive choices that you, programmers,
know well, but compiler doesn't know due to lack of expression means.
"Synthesis optimizations will clean it right up."

No ways! Compiler doesn't know they are mutually exclusive unless VHDL
or Verilog provides a mean programmer can use.

If you like to know more, send me an email and I had a paper dealing
with the situations.

Weng
 
W

Weng Tianxiang

Nicolas,
Sorry for not clearly describing the situations.

I am a PCI/PCI-X core designer. While partial or a full 32-bit address
are used to select one of target space, additional signal IDSEL is
used to determine the choice. But the address comparisons are still
mutually exclusive. It means in any cases, only one choice will be
selected. So any means in VHDL or Verilog fail to write a mutually
exclusive statements in a state machine.

Weng
 
N

Nicolas Matringe

Weng Tianxiang a écrit:
Nicolas,
Sorry for not clearly describing the situations.

I am a PCI/PCI-X core designer. While partial or a full 32-bit address
are used to select one of target space, additional signal IDSEL is
used to determine the choice. But the address comparisons are still
mutually exclusive. It means in any cases, only one choice will be
selected. So any means in VHDL or Verilog fail to write a mutually
exclusive statements in a state machine.

The real question behind is "How would you do it in hardware?". Then
describe the hardware the way you like.
You still need one comparator per address to be decoded. Then their
outputs are used to determine the next state. This piece of logic
behaves in a certain way when two (or more) of its inputs are true, even
if this should not happen.
What I would do is separate the comparisons and the next state
determination.

Anyway, the subject is wrong, this is not a VHDL-only problem ;o)
 
J

Just an Illusion

Hi Weng,

Weng said:
This is a Achilles heel for VHDL or Verilog.

You don't have any feasible means to avoid the situations I mentioned
in any state machine unless you waste resources as you wrote.

NextState <= stateX1 when BusAddress = 32-bit-Address1 else
stateX2 when BusAddress = 32-bit-Address2 else
...

NextState will involve all first comparisons made for the last
statements, but actually they are mutually exclusive.

The best way to do it is:
if(BusAddress = 32-bit-Address1) then
NextState <= stateX1;
orif(BusAddress = 32-bit-Address2) then <-- a new suggested keyword
"orif"
NextState <= stateX2;
orif(BusAddress = 32-bit-Address3) then
NextState <= stateX3;

NextState <= stateX1 when BusAddress = 32-bit-Address1 elsor <-- a new
suggested keyword "elsor"
stateX2 when BusAddress = 32-bit-Address2 elsor
...
It means if one of comparison is true, jump to the state without
referring to others. Because they are mutually exclusive.
A stupid question: do you have read the VHDL LRM ? or do you base your
conclusion with your knowledge of C programming, and interpretation ?
Because the case structure implicate "mutually" exclusive conditions. In
case of "if..then..else", you have a priority structure.

Don't confuse HDL (VHDL/Verilog) interpretation, with C code
interpretation. It seems equivalent on paper, but not in fact.

Remember that VHDL target some physical implementation as transistors.
The hw can be generate at run time (no one has seen spontaneous
transistor generation ;-)). You must decide before which ressources do
you need.

Perhaps do you need try to imagine how hw "physically" handle your
address analyze. In that case, you can see that your remarks have none sens.

Otherwise, if you are performance sensitive, you must put least width
comparison equations at the first places to minimize any unnecessary
penalty due to many mutually exclusive choices that you, programmers,
know well, but compiler doesn't know due to lack of expression means.
That is a tool's implementation issue, not a VHDL problem.
No ways! Compiler doesn't know they are mutually exclusive unless VHDL
or Verilog provides a mean programmer can use.
In VHDL, the compilation is not enough. To make simulation or synthesis,
you need instantiate your design, and during this phase you made cleaning.

That not exactly the same, but to give you an idea. Compare the
Synthesis with a sw executable generation.
In both case you have a compilation, but that give you only a data
structure in memory. To be able to do something with it, you must
instantiate/synthesize (for hw), or link (for sw).
This is the resulting code that you truly use.

Rgrds,
JaI
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,734
Messages
2,569,441
Members
44,832
Latest member
GlennSmall

Latest Threads

Top