I hate VHDL!!!
Weng Tianxiang
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
Symon
Do you know how to Google? I guess not or you would've found this:-
http://www.vhdl.org/comp.lang.vhdl/FAQ1.html#cond_compile
and this
http://www.vhdl.org/comp.lang.vhdl/FAQ1.html#case
Could've saved yourself all thet typing. When someone hates with that much
energy, it's something inside they're hating.
cheers, Syms.
paris
"Weng Tianxiang" <w...@umem.com> escribió en el mensaje
news:511e4538.04060...@posting.google.com...
<snip>
> 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?
Nicolas Matringe
> 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;
--
____ _ __ ___
| _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le -
| | | | | (_| |_| | Invalid return address: remove the -
|_| |_|_|\__|\___/
Weng Tianxiang
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
Nicolas Matringe <matringe...@numeri-cable.fr> wrote in message news:<40C01688...@numeri-cable.fr>...
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
Weng Tianxiang
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
"Symon" <symon_...@hotmail.com> wrote in message news:<2i9nvkF...@uni-berlin.de>...
Ralf Hildebrandt
> 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
Jim Lewis
There is no reason you can't use CPP in your design flow.
Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:J...@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787
Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
> 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:J...@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787
Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Weng Tianxiang
"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
"Symon" <symon_...@hotmail.com> wrote in message news:<2i9nvkF...@uni-berlin.de>...
Symon
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.
Jim Lewis
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:J...@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787
Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Holger Baxmann
should be posted in comp.lang.perl
No need for obfuscated assembler here.
;-)
bax
"Weng Tianxiang" <w...@umem.com> schrieb im Newsbeitrag
news:511e4538.04060...@posting.google.com...
Nicolas Matringe
> 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.
> Weng
>
> Nicolas Matringe <matringe...@numeri-cable.fr> wrote in message news:<40C01688...@numeri-cable.fr>...
>
>>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;
>
--
____ _ __ ___
| _ \_)/ _|/ _ \ I didn't even have a real coffee this morning.
| | | | | (_| |_| | Didn't I say I shouldn't read this newsgroup
|_| |_|_|\__|\___/ before having my 2nd mug of coffee?
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:
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:jonathan...@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.
Weng Tianxiang
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
> 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.
>
Weng Tianxiang
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
Nicolas Matringe <matringe...@numeri-cable.fr> wrote in message news:<40C40D02...@numeri-cable.fr>...
Nicolas Matringe
> 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)
--
____ _ __ ___
| _ \_)/ _|/ _ \
| | | | | (_| |_| |
Just an Illusion
Weng Tianxiang wrote:
>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.
>
>
>
>>"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.
>
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
Wallclimber
> > "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.
For the statement below:
> NextState <= stateX1 when BusAddress = 32-bit-Address1 else
> stateX2 when BusAddress = 32-bit-Address2 else
> ...
there is NO reason why a decent synthesis tool cannot see that they
are mutually exclusive: all comparisons compare against the same
input, BusAddress. It's extremely simple for a synthesis tool to
recognize this an act accordingly.
Long time ago (before you sent me your paper, which was, I think, 2
years ago), I did some tests on this and DC was able recognize this
mutual exclusiveness without problems.
In other words, for the most common case, there is enough information
for a synthesizer to do a good job.
The only case where your suggestion could have merit, is an example
like this:
Decode1 <= '1' when Addr = Addr1;
Decode2 <= '1' when Addr = Addr2;
Decode3 <= '1' when Addr = Addr3;
Decode4 <= '1' when Addr = Addr4;
Decode5 <= '1' when Addr = Addr5;
if Decode1='1' then
RdData <= Data1;
elsif Decode2='1' then
RdData <= Data2;
...
In this case, it's less likely that the synthesizer will recognize
that DecodeX is mutual exclusive. This is certainly the case if the
Decode signals are reclocked for whatever (timing?) reason.
My standard way to solve this is as follows:
v_RdData := (others => '0');
if Decode1='1' then
v_RdData := v_RdData or Data1;
elsif Decode2='1' then
v_RdData := v_RdData or Data2;
...
RdData <= v_RdData;
This solves 90% of the 5% of cases where a standard if-then-else tree
would give you trouble.
Your solution would be this:
if Decode1='1' then
RdData <= Data1;
orif Decode2='1' then
RdData <= Data2;
...
Yes, this could be a way to solve your problem, but, in my opinion,
it's not worth the trouble.
Not only would such a keyword be very confusing for beginners in
Verilog or VHDL, it only would introduce ambiguous behavior in the
language.
The way things are now, if you use the standard constructs, you can
reasonably be sure(*) that whatever your wrote will be synthesized
accordingly into gates and you can use formal equivalence check to
verify.
What if the designer using your new keyword makes a mistake and
conditions are NOT mutex? In that case, the simulator may give
different results for gatelevel simulation than for RTL simulations.
I'm sure there will be formal equivalence check consequences also.
In my opinion, you will open a can of worms that's just not worth
opening...
> This is a Achilles heel for VHDL or Verilog.
Given that his heel was the reason for his Achilles' death, this is a
slight exaggeration. Just like beginning of your rant. If you just
learned to moderate your tone a little bit, more people actually might
listen to what you really have to say. If, on the other hand, the
subject of this thread had the intention to have readers dismiss you
as a brainless troll (which you are not), you probably succeeded very
well...
Tom
(*) incomplete sensitivity lists may be an exception here, but a
synthesis tool can easily warn for those.
Weng Tianxiang
> like this:
> Decode1 <= '1' when Addr = Addr1;
> Decode2 <= '1' when Addr = Addr2;
> Decode3 <= '1' when Addr = Addr3;
> Decode4 <= '1' when Addr = Addr4;
> Decode5 <= '1' when Addr = Addr5;
> if Decode1='1' then
> RdData <= Data1;
> elsif Decode2='1' then
> RdData <= Data2;
> ...
> In this case, it's less likely that the synthesizer will recognize
> that DecodeX is mutual exclusive. This is certainly the case if the
> Decode signals are reclocked for whatever (timing?) reason.
In my PCI/PCI-X core and related designs, there are more than 70
places in one project I recognized there are mutually exclusive
situations. That is why I hate VHDL that doesn't provide a mean to
effectively express such situations.
Why I mentioned address comparison is because everyone uses it, but
not because it is the only place to use it.
For example, do you have counters in your design? see all of them and
their loading conditions: they must be mutually exclusive with loading
conditions!!! If you have 30 counters, there are 30 places where most
likely mutually exclusive situations happen!!!
> My standard way to solve this is as follows:
> v_RdData := (others => '0');
> if Decode1='1' then
> v_RdData := v_RdData or Data1;
> elsif Decode2='1' then
> v_RdData := v_RdData or Data2;
> ...
> RdData <= v_RdData;
I don't know if your method is valid for a state machine: two state
machine names can be "OR"ed?
If each time you are handling the situations like what you suggest,
what do you think?
I have two other engineer's emails, one from IBM, another Lockheed
Martin, telling me other two methods to resolve the problem. That says
language needs something new to resolve the problem, even few
engineers saw it and need it. The fact is the more you recognize that
are mutually exclusive situations, faster speed and less resources you
can get. It's essential for my project to get 66MHz for PCI and 133MHz
for PCI-X while using FPGA.
> This solves 90% of the 5% of cases where a standard if-then-else tree
> would give you trouble.
> Your solution would be this:
> if Decode1='1' then
> RdData <= Data1;
> orif Decode2='1' then
> RdData <= Data2;
> ...
> The way things are now, if you use the standard constructs, you can
> reasonably be sure(*) that whatever your wrote will be synthesized
> accordingly into gates and you can use formal equivalence check to
> verify.
It has very clear definition of gates!!!
RdData <= (Decode1='1' and Data1) or (Decode2='1' and Data2) or
(Decode3='1' and Data3);
or
NextState <= (Decode1='1' and State1) or (Decode2='1' and State2) or
(Decode3='1' and State3);
> What if the designer using your new keyword makes a mistake.
Jim Lewis did a very good suggestion: add a debugging parameter:
"errels". if error happens, go to error handling in simulation.
Weng
Wallclimber
> places in one project I recognized there are mutually exclusive
> situations. That is why I hate VHDL that doesn't provide a mean to
> effectively express such situations.
As I and you have shown, there is a way to do it. It's just not very
pretty. Which is good, since it's a dangerous construct. :-)
> For example, do you have counters in your design? see all of them and
> their loading conditions: they must be mutually exclusive with loading
> conditions!!! If you have 30 counters, there are 30 places where most
> likely mutually exclusive situations happen!!!
Counters are another place where you can very easily apply the OR
technique.
> I don't know if your method is valid for a state machine: two state
> machine names can be "OR"ed?
> If each time you are handling the situations like what you suggest,
> what do you think?
If you declare the states of your statemachine as a vector instead of
an enum (which, admittedly, I don't really like), you can solve the
problem the same way.
Again, it's pretty way, but using
v_State := v_State or c_NextPhase;
instead of
State <= e_NextPhase;
isn't really the end of the world.
> I have two other engineer's emails, one from IBM, another Lockheed
> Martin, telling me other two methods to resolve the problem. That says
> language needs something new to resolve the problem, even few
> engineers saw it and need it.
To me, that says that there are now at least 3 ways around it. :-)
> > What if the designer using your new keyword makes a mistake.
>
> Jim Lewis did a very good suggestion: add a debugging parameter:
> "errels". if error happens, go to error handling in simulation.
Yes, this would partially solve the problem. Though you'd still get
undefined behavior in the real world.
This is especially true for state machines. It's often not easy to
prove that 2 signals are mutually exclusive and it could happen in a
rare boundary case for which you don't simulate since you don't expect
it in the first place.
If an orif-orelse statement were available in the language, I'd
probably use it to read data and, maybe, for the counter statement
(although that's already a boundary case). But there are easy ways
around it, so it's not really problem.
For state assignments, I'd *always* forbid the usage of these
keywords. It's just too dangerous to assign undefined statements...
Coming back to the training aspect: I have seen many bright engineers
who still make mistakes about where and how to use variables. As a
result, we generally avoid them for registers, even if it would speed
up simulations quite a bit. At least with variables, the synthesizer
will implement do exactly what has been simulated.
This is not the case of orif/orelse: when used by somebody who doesn't
have an in-depth understanding of the problem, you're guaranteed to
run into major trouble. Given the current costs of a silicon respin,
it's just too dangerous.
The orif/orelse andif/andelse keywords are an interesting concept, but
for me the problem it wants to solve isn't serious enough to hate the
language or to warrant adding them to the standard.
Tom Verbeure
Weng Tianxiang
"orif"/"orels"/"errels" will be introduced into VHDL.
2. I think the task is laid on Jim Lewis shoulder, he is my paper
reviewer, "errels" suggestor and member of VHDL committee. Now he is
fully qualified to do that. I will help him push the movements.
3.
< "The "orif"/"orels"/"errels" keywords are an interesting concept"
I am glad that your attitude changes from "brainless troll" to
"interesting concept".
It is just a tip of iceberg. Its power is far more than what you have
thought.
For example, all 5 methods(yours, my 2, engineer from IBM and Lockheed
Martin) fail when states of state machine are declared in enumerated
type(I never declare states as coded numbers to save time and energy
to elsewhere).
In general, the key words "orif"/"orels"/"errels" provide VHDL users
with very powerful tools to deliver any useful mutually exclusive
information well known to designers to VHDL compilers and it will
"immediately" reduce resource waste and increase final project speed
without big code change(change from "elsif" to "orif" delivers the
information to compiler) .
The following is an example:
If(A1) then // maybe if(A1 or A2 or A3) then
NextState <= state1;
orIf(A2) then // A1 will be excluded in final equation here
NextState <= state2;
orIf(A3) then // A1/A2 will be excluded in final equation here
NextState <= state3;
elsIf(A4) then // maybe elsif(A4 or A5 or A6) then
NextState <= state4;
orif(A5) then // A4 will be excluded in final equation here
NextState <= state5;
orIf(A6) then // A4/A5 will be excluded in final equation here
NextState <= state6;
elsIf(A7) then
NextState <= state7;
orIf(A8) then // A7 will be excluded in final equation here
NextState <= state8;
else
NextState <= state0;
end if;
It tell compilers that there are 3 groups of conditions that are
mutually exclusive:
A1/A2/A3;
A4/A5/A6;
A7/A8;
Further more logic saving can be achieved if you select common factor.
For example:
A1 <= B1 and C1;
A2 <= B1 and C2;
A3 <= B1 and C3;
"if(A1 or A2 or A3) then"
can be replaced by
"if(B1) then"
or
If(A1) then // maybe if(A1 or A2 or A3) then
Data <= Data1;
orif(A2) then // A1 will be excluded in final equation here
Data <= Data2;
orif(A3) then // A1/A2 will be excluded in final equation here
Data <= Data3;
elsif(A4) then // maybe elsif(A4 or A5 or A6) then
Data <= Data4;
orif(A5) then // A4 will be excluded in final equation here
Data <= Data5;
orif(A6) then // A4/A5 will be excluded in final equation here
Data <= Data6;
elsIf(A7) then
Data <= Data7;
orIf(A8) then // A7 will be excluded in final equation here
Data <= Data8;
else
Data <= Data0;
end if;
In another words, the power of 3 keywords is that
with any declaration to compiler that there are mutually exclusive
conditions, you get benefits in both speed and resources!!!
As we know, the most effective expression in VHDL is case statement.
The more case statement you use, the more efficient your design is.
Why? It indicates to compiler that there are mutually exclusive
relations. Case statement has a drawback: the case variable must be a
state machine name or it must have fixed number of bits. Again, why?
The reason is in a state machine, all states are mutually exclusive.
For a fixed number of bits, all different values are mutually
exclusive.
OK, now I would like to tell in real world there are far more
situations where there are mutually exclusive situations than 2 above
cases: not only within one state machine there are mutually exclusive
relations, there are possibilities that mutually exclusive relations
exist among a group of state machines if you can recognize them. In my
paper, I enumerated 11 cases where mutually exclusive relation may
exist. 3 years later I have accumulated more than that.
For example, let us refer to PCI transactions. If a PCI write
transaction is targeting at one of 4 spaces of a device, the 4 write
state machines in 4 different spaces are mutually exclusive: Only one
working state is permitted at any time among the 4 state machines.
This is why I suggest another two key words "machine" and "exclusive"
to declare which state machine is mutually exclusive with others.
Now VHDL standard become bottleneck, the code inefficiency source.
Why? it fails to provide users with a means to declare non-standard
mutually exclusive conditions that are ubiquitous.
Just an Illusion
A little question for you,
If you have this code :
if (C1) then
...
elsif (C2) then
...
endif
and if you know that C1 and C2 are mutually exclusive, why don't simply
write ? ;-)
if (C1) then
...
endif
if (C2) then
...
endif
If you reply me by 'if...then...elsif...then...else...endif', I give you
immediatly the solution:
process (...)
variable temp : type;
begin
temp := elsevalue;
if (C1) then
temp := C1value;
end if;
if (C2) then
temp := C2value;
end if;
...
S <= temp;
end process;
That give you the expected result, and you have no more relation between
C1 and C2.
I am agree, you continue to check the value of C1, but I am not sure
that you 'loose' the same among of time that with the 'elsif' structure.
Somewhere this method is equivalent to a case structure, if C1 and C2
have the same 'bit length' structure (i.e. can be express as a bus, and
give one value by condition).
That doesn't invalidate your idea, but you can seen that VHDL have the
possibility to implement this structure, and can give some information
on uncorrelation between signals (for compiler).
I seen one advantage with you notation; during the VHDL origin, people
want make a 'language' with more abstraction (than transistor and
logical gate). Your proposal continue this concept.
JaI
Nicolas Matringe
> and if you know that C1 and C2 are mutually exclusive, why don't simply
> write ? ;-)
>
> if (C1) then
> ...
> endif
>
> if (C2) then
> ...
> endif
>
> If you reply me by 'if...then...elsif...then...else...endif', I give you
> immediatly the solution:
>
> process (...)
> variable temp : type;
> begin
> temp := elsevalue;
> if (C1) then
> temp := C1value;
> end if;
> if (C2) then
> temp := C2value;
> end if;
> ...
> S <= temp;
> end process;
I don't see much difference between all these solutions.
Your first example is equivalent to an if ... elsif ... else ... end if;
structure, only you write it with the least priority first.
The second example is exactly the same. The use of a variable doesn't
change anything.
What would happen if CI and C2 were both true? You know it won't happen
but the tools don't so they take the case into account.
--
____ _ __ ___
| _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le -
| | | | | (_| |_| | Invalid return address: remove the -
Just an Illusion
In my case, if I want be sure that no ambiguity exist for the tools, I
write the logical function.
I am agree too that supplementary logic add some compile time, and
generate some unused code.
But could you explain me how you translate your 'external' exclusive
constraint on silicium ?
JaI
Nicolas Matringe
>
> constraint on silicium ?
No, and I'm still wondering about it too :o)
Wallclimber
> variable temp : type;
> begin
> temp := elsevalue;
> if (C1) then
> temp := C1value;
> end if;
> if (C2) then
> temp := C2value;
> end if;
> ...
> S <= temp;
> end process;
>
> That give you the expected result, and you have no more relation between
> C1 and C2.
Sorry, but that's not true.
Your examples is equivalent to
if (C2) then
S <= C2value;
elsif (C1) then
S <= C1value;
else
S <= elsevalue;
end if;
You have only reversed the priority.
Tom Verbeure
Michael Riepe
Nicolas Matringe wrote:
> Just an Illusion a écrit:
>
>> and if you know that C1 and C2 are mutually exclusive, why don't
>> simply write ? ;-)
>>
>> if (C1) then
>> ...
>> endif
>>
>> if (C2) then
>> ...
>> endif
Because it will most likely produce a chain of 2:1 muxes.
if ... elsif ... else ... end if, on the other hand, may produce an n:1
mux but with probably more complex control logic.
[...]
> What would happen if CI and C2 were both true? You know it won't happen
> but the tools don't so they take the case into account.
The IMHO best solution is a case statement:
-- assuming something like std_logic here...
constant x : some_vector := C1 & C2;
case x is
when "00" =>
temp := elsevalue;
when "10" =>
temp := C1value;
when "01" =>
temp := C2value;
when others => -- don't care
temp := (others => 'X');
end case
It's not exactly the same as the proposed "orif/orels" statements, but
serves the same purpose.
Conclusion: There's no need to put even more bloat into VHDL.
--
Michael "Tired" Riepe <Michae...@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
roller
"Weng Tianxiang" <w...@umem.com> escribió en el mensaje
news:511e4538.04061...@posting.google.com...
<snip>
> This is why I suggest another two key words "machine" and "exclusive"
> to declare which state machine is mutually exclusive with others.
>
oh please!, how many keywords do you want to add? maybe you could write your
own language and then write the parser you talked about in this thread, and
then you'd be happy?!
in your OP you mentioned:
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!!!
now, you could use one-hot state machine encoding like:
signal NextState : std_logic_vector(2 downto 0);
and then you assign:
NextState(0) <= '1' when (BusAddress = 32-bit-Address1) else '0';
NextState(1) <= '1' when (BusAddress = 32-bit-Address2) else '0';
NextState(2) <= '1' when (BusAddress = 32-bit-Address3) else '0';
but it still need the comparisons to take place in parallel(and be really
sure that they are exclusive!!), and there's no other way to do it! cause
even if the conditions are mutually exclusive, you still have to check if
they are met! so you need a comparator for EACH condition (or you could
"develop" -like unrolling a loop- the comparisons by writing 3 logic
functions in the form of and-or terms of the input BusAddress and then use
one-hot state machino coding)
instead of hearing your attacks to VHDL and your new keyword proposals, i'd
like to know if you have actually thought thru how this whole "mutual
exclusive" thing could be implemented in real hardware, as it'd be far more
interesting than your "i hate vhdl" thingy...
Weng Tianxiang
> like to know if you have actually thought thru how this whole "mutual
> exclusive" thing could be implemented in real hardware, as it'd be far more
> interesting
If you are interested in latest technique of how Xilinx implements
multiplex, go to U.S. Patent and Trademark Office website and the
following is their patent number and title:
6,556,042 FPGA with improved structure for implementing large
multiplexers
6,505,337 Method for implementing large multiplexers with FPGA lookup
tables
6,466,052 Implementing wide multiplexers in an FPGA using a
horizontal chain structure
6,323,682 FPGA architecture with wide function multiplexers
6,191,610 Method for implementing large multiplexers with FPGA lookup
tables
6,144,220 FPGA Architecture using multiplexers that incorporate a
logic gate
...
Reading the latest one is enough for a junior engineer.
They will tells you that
1. Multiplexer is implemented very efficient from hardware level of
FPGA, not mention ASIC;
2. Minimum levels of paths and minimum path delay if multiplexer is
used.
The patents specifies every details you want to know and they want to
protect and the methods are very genius.
Why mutually exclusive conditions are very important is each time a
new mutually exclusive condition is told to VHDL compiler, you
immediately get benefits in term of speed and resources saving without
any logic change.
Do you think it is the better & concise way to express it:
if(A) then
NextState <= State1;
orif(B) then
NextState <= State1;
orif(B) then
NextState <= State1;
end if;
Weng
roller
<snip>
>
> Why mutually exclusive conditions are very important is each time a
> new mutually exclusive condition is told to VHDL compiler, you
> immediately get benefits in term of speed and resources saving without
> any logic change.
>
ok, so you admit that in real hardware there's no logic change?
and that the benefits will only be in simulation time?
and so the simulator, instead of simulating the real behaviour of the
hardware, by simulating all the conditions, it'd simulate only one, and so,
you get an super terrific amazing speedup?!
in anycase, how would you implement the mutual exclusive condition test in
software (the simulator will have to do it)?, please, i just woke up so i
may be forgetting something, but IMHO i still think that you need to perform
all the comparisons to check if they are actually met!, so where would the
speedup be?
> Do you think it is the better & concise way to express it:
>
> if(A) then
> NextState <= State1;
> orif(B) then
> NextState <= State1;
> orif(B) then
> NextState <= State1;
> end if;
>
> Weng
assuming the previous code was correct (cause it isnt, you have two B tests
and always assign the same value...)
how's that better than "elsif"?
Just an Illusion
Wallclimber wrote:
>>process (...)
>> variable temp : type;
>>begin
>> temp := elsevalue;
>> if (C1) then
>> temp := C1value;
>> end if;
>> if (C2) then
>> temp := C2value;
>> end if;
>> ...
>> S <= temp;
>>end process;
>>
>>That give you the expected result, and you have no more relation between
>>C1 and C2.
>>
>>
>
>Sorry, but that's not true.
>
>
You are right.
>Your examples is equivalent to
>
> if (C2) then
> S <= C2value;
> elsif (C1) then
> S <= C1value;
> else
> S <= elsevalue;
> end if;
>
>You have only reversed the priority.
>
>
But here you are not totally right.
I haven't only change priority, but the logical equation too.
>Tom Verbeure
>
>
Just an Illusion
My objective is _not_ to give a circuit that give equation of exclusive
signals based on usage of 'if..then..else' structure; it is impossible.
But show that you can _visually_ help designer to identify them.
The structure 'if..then..else' and his extension 'if..then..elsif..else'
are equivalent to logical equation (read lrm, section 8.7):
A1.B1 + !A1.A2.B2 + !A1.!A2.B3
where :
if (A1) then (B1) elsif (A2) then (B2) else (B3)
If A1 and A2 are mutually exclusive, you can simplify the equation to
A1.B1 + A2.B2 + !A1.!A2.B3
_But_ A1.B1 + A2.B2 + !A1.!A2.B3 <> A1.B1 + !A1.A2.B2 + !A1.!A2.B3,
except if A1 and A2 are mutually exclusive
Conclusion: 'if..then..elseif..else' can modelize the equation A1.B1 +
A2.B2 + !A1.!A2.B3, but it cover more than this.
If you want modelize _exactly_ the equation A1.B1 + A2.B2 + !A1.!A2.B3,
don't use 'elsif' structure. It's not a problem on the vhdl, but a
problem of logic ;-)
JaI
Wallclimber
> and that the benefits will only be in simulation time?
Sorry roller, but while I agree that adding these keywords is a bad
idea, it *is* true there are optimization benefits to it. His example
with the addresses comparators is a bad example. For a better one,
look at one of my previous postings.
> and so the simulator, instead of simulating the real behaviour of the
> hardware, by simulating all the conditions, it'd simulate only one, and so,
> you get an super terrific amazing speedup?!
No, this is not what it's about.
> > Do you think it is the better & concise way to express it:
> >
> > if(A) then
> > NextState <= State1;
> > orif(B) then
> > NextState <= State2;
> > orif(C) then
> > NextState <= State3;
> > end if;
> >
> > Weng
>
> assuming the previous code was correct (cause it isnt, you have two B tests
> and always assign the same value...)
> how's that better than "elsif"?
(I changed 'B' to 'C' and '1' to '2' and '3' in the example above.)
When you use elsif, you give the A case a higher priority than the B
case, which has a higher priority than the C case. In term of
hardware, this gives you cascaded multiplexers for each State
assignement. If you guarantee that A, B and C are mutually exclusive,
than you can optimize this to a flat and-or tree. The second solution
is more hardware efficient and had a shorter critical path.
Tom
Wallclimber
> Hi Wallclimber,
You can say 'Tom'. If anybody knows how to change the name associated
with a Google Groups account, let me know! :-)
> My objective is _not_ to give a circuit that give equation of exclusive
> signals based on usage of 'if..then..else' structure; it is impossible.
> But show that you can _visually_ help designer to identify them.
>
> The structure 'if..then..else' and his extension 'if..then..elsif..else'
> are equivalent to logical equation (read lrm, section 8.7):
I'm afraid section 8.7 doesn't talk about logic implementation...
> A1.B1 + !A1.A2.B2 + !A1.!A2.B3
> where :
> if (A1) then (B1) elsif (A2) then (B2) else (B3)
Agreed.
> If A1 and A2 are mutually exclusive, you can simplify the equation to
> A1.B1 + A2.B2 + !A1.!A2.B3
Agreed.
> _But_ A1.B1 + A2.B2 + !A1.!A2.B3 <> A1.B1 + !A1.A2.B2 + !A1.!A2.B3,
> except if A1 and A2 are mutually exclusive
>
> Conclusion: 'if..then..elseif..else' can modelize the equation A1.B1 +
> A2.B2 + !A1.!A2.B3, but it cover more than this.
Hmmm. Highly depends on how you define "... can modelize this ...".
For me, this works both ways. A formal equivalence check between RTL
and gatelevel would flag it as not equivalent. At the end of the day,
that's the only thing that counts.
> If you want modelize _exactly_ the equation A1.B1 + A2.B2 + !A1.!A2.B3,
> don't use 'elsif' structure.
Well, you can work around it:
v_C := '0';
if A1 then v_C := C or B1;
elsif A2 then v_C := C or B2;
else v_C := C or B3;
end if;
C <= v_C;
>It's not a problem on the vhdl, but a
> problem of logic ;-)
I'm afraid that I'm not really sure what point you wanted to make. :-)
Tom
Wallclimber
> >
> > if (C2) then
> > S <= C2value;
> > elsif (C1) then
> > S <= C1value;
> > else
> > S <= elsevalue;
> > end if;
> >
> >You have only reversed the priority.
> >
> >
> But here you are not totally right.
> I haven't only change priority, but the logical equation too.
How is the logic equation different?
Tom
Weng Tianxiang
A1.B1 + !A1.A2.B2 + !A1.!A2.A3.B3
If A1, A2 and A3 are mutually exclusive, and my suggestion is used:
'if..ORIF..ORIF..endif'
you will get the equation:
A1.B1 + A2.B2 + A3.B3
Same equation as if a "case" statement were used.
1. You tell compiler to generate statements like "case" statement.
2. More items means long route, longer delay and decreased running
frequency.
The speed-up and resource saving is the FPGA chip final result, not
simulation!
I have never mentioned simulation saving.
When you don't fully understand a situation, you may feel it
"dangerous", "can of worm", "Pandora's box". But when you understand
it, it will makes your chip run faster and with confidence and without
any new simulation burden if and only if VHDL provides a means to do
that!
A CONCLUSION OF MUTUALLY EXCLUSIVE CONDITIONS IS NOT BASED ON THEIR
CONDITION VALUES, BUT ON PHYSICAL CONDITIONS!!!
You are sleeping, you cannot be eating. And you are eating, you cannot
be sleeping;
You are at home, you cannot be at theater, you are at theater, you
cannot be at home;
You are dead, you cannot be alive, you are alive, you cannot be dead;
You are 20 years old, you cannot be 40 years old, you are 40 years
old, you cannot be 20 years old;
A true $20 note cannot be false, a false $20 note cannot be true;
But "You are a son, you cannot be a father, you are a father, you
cannot be a son" is wrong!!! You don't have to do simulations, no, not
a second, to prove if they are mutually exclusive.
So there is no confusion at all and there is never a "rare" "critical"
boundary condition to be tested!!!
If you can provide me with an example, I will tell you where you are
wrong.
Weng
roller
"Wallclimber" <hom...@gmail.com> escribió en el mensaje
news:f7896340.04061...@posting.google.com...
> > ok, so you admit that in real hardware there's no logic change?
> > and that the benefits will only be in simulation time?
>
> Sorry roller, but while I agree that adding these keywords is a bad
> idea, it *is* true there are optimization benefits to it. His example
> with the addresses comparators is a bad example. For a better one,
> look at one of my previous postings.
>
> > and so the simulator, instead of simulating the real behaviour of the
> > hardware, by simulating all the conditions, it'd simulate only one, and
so,
> > you get an super terrific amazing speedup?!
>
> No, this is not what it's about.
>
well, the OP wasnt clear about it then :)
>
> > > Do you think it is the better & concise way to express it:
> > >
> > > if(A) then
> > > NextState <= State1;
> > > orif(B) then
> > > NextState <= State2;
> > > orif(C) then
> > > NextState <= State3;
> > > end if;
> > >
> > > Weng
> >
> > assuming the previous code was correct (cause it isnt, you have two B
tests
> > and always assign the same value...)
> > how's that better than "elsif"?
>
> (I changed 'B' to 'C' and '1' to '2' and '3' in the example above.)
>
> When you use elsif, you give the A case a higher priority than the B
> case, which has a higher priority than the C case. In term of
> hardware, this gives you cascaded multiplexers for each State
> assignement. If you guarantee that A, B and C are mutually exclusive,
> than you can optimize this to a flat and-or tree. The second solution
> is more hardware efficient and had a shorter critical path.
>
> Tom
so, it's something like the example i posted, ok then.
roller
> 'if..elsif..elseif..endif' generates following equation:
> A1.B1 + !A1.A2.B2 + !A1.!A2.A3.B3
>
> If A1, A2 and A3 are mutually exclusive, and my suggestion is used:
> 'if..ORIF..ORIF..endif'
> you will get the equation:
> A1.B1 + A2.B2 + A3.B3
> Same equation as if a "case" statement were used.
>
> 1. You tell compiler to generate statements like "case" statement.
so, again you admit that it'd be the same than a case statement....as you
previously admitted that there was no logic change while another poster
showed that indeed there was a possible optimization (something like the
solution i gave in the first place)
> 2. More items means long route, longer delay and decreased running
> frequency.
>
> The speed-up and resource saving is the FPGA chip final result, not
> simulation!
> I have never mentioned simulation saving.
>
> When you don't fully understand a situation, you may feel it
> "dangerous", "can of worm", "Pandora's box". But when you understand
> it, it will makes your chip run faster and with confidence and without
> any new simulation burden if and only if VHDL provides a means to do
> that!
>
> A CONCLUSION OF MUTUALLY EXCLUSIVE CONDITIONS IS NOT BASED ON THEIR
> CONDITION VALUES, BUT ON PHYSICAL CONDITIONS!!!
>
no need to shout...
> You are sleeping, you cannot be eating. And you are eating, you cannot
> be sleeping;
> You are at home, you cannot be at theater, you are at theater, you
> cannot be at home;
> You are dead, you cannot be alive, you are alive, you cannot be dead;
> You are 20 years old, you cannot be 40 years old, you are 40 years
> old, you cannot be 20 years old;
> A true $20 note cannot be false, a false $20 note cannot be true;
>
> But "You are a son, you cannot be a father, you are a father, you
> cannot be a son" is wrong!!! You don't have to do simulations, no, not
> a second, to prove if they are mutually exclusive.
>
> So there is no confusion at all and there is never a "rare" "critical"
> boundary condition to be tested!!!
>
> If you can provide me with an example, I will tell you where you are
> wrong.
>
no need, you didnt answer any of my previous questions on the
first place. And besides, i'll say it again, you ended up admitting that
your new keywords are identical to a "case", and also that there was no
logic
change.
In anycase, I agree with Tom (wallclimber)
> Weng
E. Timothy Uy
links to Espacenet:
http://patents.oncloud8.com/?pns=6,556,042;6,505,337;6,466,052;6,323,682;6,191,610;6,144,220
Weng Tianxiang
words in VHDL, it can let users use it and "IT WILL GENERATE LOGIC SO
EFFICIENT AND FAST THAT IT IS SIMILAR TO CASE STATEMENT".
Do you know "case" statement is the most efficient and fastest
statement in VHDL?
2. "there was no logic change."
It means the following:
If you write statements:
if(A1) then
NextState <= S1;
elsif(A2) then
NextState <= S2;
elsif(A3) then
NextState <= S2;
end if;
then it can be changed in the following way to add mutually exclusive
conditions:
if(A1) then
NextState <= S1;
orif(A2) then
NextState <= S2;
orif(A3) then
NextState <= S2;
end if;
That's it. "NO OTHER LOGIC CHANGE" and it will give you saving!!!
Weng
Just an Illusion
if (C1) then (E1) elsif (C2) then (E2) else (E3) =>
C1.E1+!C1.C2.E2+!C1.!C2.E3
if (C2) then (E2) elsif (C1) then (E1) else (E3) => C2.E2
+!C2.C1.E1+!C1.!C2.E3
I think that both equation aren't totally equivalent :-)
JaI
Just an Illusion
Weng Tianxiang wrote:
>1. What I said is if "orif"/"ofels"/"errels" are adapted as new key
>words in VHDL, it can let users use it and "IT WILL GENERATE LOGIC SO
>EFFICIENT AND FAST THAT IT IS SIMILAR TO CASE STATEMENT".
>
As roller previously said, your don't need to shout (uppercase words are
equivalent to shout in news group).
In summary, you propose to extend usage of 'case' keyword.
If you be able to use a mechanism of bit masking (or 'don't care') for
case with vector condition, you have your expected result.
>
>Do you know "case" statement is the most efficient and fastest
>statement in VHDL?
>
*joke* This is not the combinatory statement : s <=a and b; :0)
>
>2. "there was no logic change."
>It means the following:
>If you write statements:
>if(A1) then
> NextState <= S1;
>elsif(A2) then
> NextState <= S2;
>elsif(A3) then
> NextState <= S2;
>end if;
>
>then it can be changed in the following way to add mutually exclusive
>conditions:
>if(A1) then
> NextState <= S1;
>orif(A2) then
> NextState <= S2;
>orif(A3) then
> NextState <= S2;
>end if;
>
>That's it. "NO OTHER LOGIC CHANGE" and it will give you saving!!!
>
>
The real problem is that some mutually exclusive conditions come from
higher level that your entity/architecture block. If you want really a
reusable block, that is not pre-synthesized, you must let the full chip
synthesis decide how optimize your full design. In lot of case, some
local optimization can hardest the global optimization.
>Weng
>
>
JaI
Weng Tianxiang
> idea, it *is* true there are optimization benefits to it.
"bad idea?", why? for beginners? I just use 30% of VHDL structures and
never pay attention to what I have never used.
It is not a little benefit. My experiences told me that when I was
failing the final running frequency, either 66MHz for PCI or 133MHz
for PCI-X, the only way that helps me is to try to use more case
statements to reduce number of levels in "if..elsif..elsif..endif"
structure.
"if..elsif..elsif..endif" structure is Fortran language's product. In
software, there is no impact on performance, everything must be
executed in serial order. But in hardware, its essence is concurrent
implementation.
"if..orif..orif..endif" structure provides a similar, but excellent
structure to supplement "if..elsif..elsif..endif" structure: either in
serial implementation area or in concurrent implementation area.
Weng
Just an Illusion
Weng Tianxiang wrote:
>...
>
>"if..elsif..elsif..endif" structure is Fortran language's product. In
>software, there is no impact on performance, everything must be
>executed in serial order.
>
Do you know that the vhdl origin is ada, not fortran :-)
> But in hardware, its essence is concurrent implementation.
>
I am not agree with you about this point, 'case' is the concurrent
implementation 'spirit'; 'if' defined a policy of priority then you
expected than you found a mux cascade at the end.
>
>"if..orif..orif..endif" structure provides a similar, but excellent
>structure to supplement "if..elsif..elsif..endif" structure: either in
>serial implementation area or in concurrent implementation area.
>
>
An other remark, you haven't any 'serial' implementation area, but
'sequential' ;-)
And neither 'if' nor 'case' can be define into a concurrent statement
area. They are typically sequential statement (must be embedded into a
process statement part, that is a sequential statement). It is not
because process executions are concurrent, than there 'code' is
concurrent too.
>Weng
>
>
Rgrds,
JaI
Weng Tianxiang
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
Mike Treseler
> 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.
> Any comments special to the above example are welcome.
see:
http://groups.google.com/groups?q=overlapping+cases+priority+hinze
-- Mike Treseler
roller
> important to introduce "if..orif..endif" keywords into VHDL to clear
> any confusions about mutual exclusive conditions.
right, cause you're the only one who actually need it...
>
<snip>
>
> Any comments special to the above example are welcome.
>
> Weng
yes, it's never late to learn...
i cant believe this issue is still being discussed while several solutions
were showed to be feasible...
roller
whatever you say dude
roller
> > Sorry roller, but while I agree that adding these keywords is a bad
> > idea, it *is* true there are optimization benefits to it.
>
> "bad idea?", why? for beginners? I just use 30% of VHDL structures and
> never pay attention to what I have never used.
and maybe you should...because "case" didnt seem to fit in your 30%
>
> It is not a little benefit. My experiences told me that when I was
> failing the final running frequency, either 66MHz for PCI or 133MHz
> for PCI-X, the only way that helps me is to try to use more case
> statements to reduce number of levels in "if..elsif..elsif..endif"
> structure.
>
> "if..elsif..elsif..endif" structure is Fortran language's product.
man, VHDL comes from ADA...and the need for "if...endif" is to give
priority, whether Fortran, C and every other language uses it or not is not
the issue here.
> In software, there is no impact on performance, everything must be
> executed in serial order. But in hardware, its essence is concurrent
> implementation.
and it was showed that could be achieved without new keywords...
>
> "if..orif..orif..endif" structure provides a similar, but excellent
> structure to supplement "if..elsif..elsif..endif" structure: either in
> serial implementation area or in concurrent implementation area.
>
whatever man
> Weng
Just an Illusion
I am definitively not a pci designer expert but I have a question for
you: could you change dynamically the size of the pci bus ?
Otherwise I think that you can parametrize some part of the design below.
if (DIMMNumberClear) then
DIMMNumber(4 downto 0) <= (others=>'0');
elsif (update_condition) 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;
Now you need only something to calculate value of 'n' and the
'update_condition'
As you can read, you don't need any more some exclusive keyword, because
in equations it is clearly not possible to have 'n' with simultaneous
different values.
Bye,
JaI
Uncle Noah
> "Weng Tianxiang" <w...@umem.com> escribió en el mensaje
> news:511e4538.04061...@posting.google.com...
> > 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.
>
OK, we got the point... you certainly are unaware of VHDL.
So WHY don't you code your PCI component in Verilog? And leave us in peace?
You are obviously a Verilog-berserk.
It is sad yet very offensive, that so many people are arguing over such tiny issue.
To my experience, in almost ALL occasions, languages suffice, people don't...
regards
Uncle Noah a.k.a. "The G.B. Man"
P.S.: Many useful people shouldn't get wasted in this thread...
Just an Illusion
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
Jim Lewis
Ironic, I go on vacation and the rant goes on and on
and on. I wanted to comment on a couple of things.
> 1. I deeply believe that sooner or later the key words
> "orif"/"orels"/"errels" will be introduced into VHDL.
> 2. I think the task is laid on Jim Lewis shoulder, he is my paper
> reviewer, "errels" suggestor and member of VHDL committee.
Upon two years of reflection, I think there is a more consise
way to express what you want without the down side and
perhaps gain even more flexability:
assert onehot(A1, A2, A3) report "failed" severity failure ;
assert onehot(A4, A5, A6) report "failed" severity failure ;
assert onehot(A7, A8) report "failed" severity failure ;
-- New condition
assert onehot(A1, A7) report "failed" severity failure ;
process( ...)
begin
...
If(A1) then
NextState <= state1;
elsIf(A2) then
NextState <= state2;
...
elsIf(A8) then
NextState <= state8;
else
NextState <= state0;
end if;
...
end process ;
I like this as it is easy to express the error conditions.
Synthesizing assertions is a task for 1076.6 and would not
require any language change.
> Now VHDL standard become bottleneck, the code inefficiency source.
> Why? it fails to provide users with a means to declare non-standard
> mutually exclusive conditions that are ubiquitous.
Your suggestion of adding keywords needed to be
mulled over. At the end of the day, it was determined
not to be the best answer - too much complexity,
too much chance for error, and there is a better
method (illustrated above).
It would be really helpful if you would desist from
being so insulting. While I don't agree with brainless
troll, you are definitely acting like a troll.
> 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;
I am not sure an algorithm can extract what is mutually exclusive
above. Perhaps you ment:
assert onehot(CSRAD_R0_L_DIMMNumber_H, CSRAD_R0_H_DIMMNumber_H) ... ;
Note your code also includes fields of nC_BE_RO.
Regards,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:J...@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787
Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
> 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.
Weng Tianxiang
> 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.
The following is an excerpt from my paper:
Rule 4: Signals are mutually exclusive if their time marks are
mutually exclusive.
Example:
SignalA <= (AState = A1_S and (…)) (2)
or (AState = A2_S and (…));
SignalB <= (AState = A3_S and (…)) (3)
or (AState = A4_S and (…));
SignalA and SignalB are mutually exclusive, no matter how complex the
logic in (…) is.
Its extension is:
if two signals are mutually exclusive based on whatever reasons, the
derivative signals: A1, B1 are mutually exclusive:
A1 <= A and (..);
B1 <= B and (..);
That is what my equation says. (if..orif..endif).
Jim, if you recognized your wrong claim, I can go with your next
question.
Weng
Jim Lewis
See below.
>>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.
Your full code is shown below. I agree that the entire
expression in 1 is mutually exclusive from the entire
expression in 2, however, this is all that can be
concluded from the orif in the code below.
To be fair, this is the code you showed:
> 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;
If there is additional logic in this logic
block (entity/architecture) that independently
shows that CSRAD_R0_L_DIMMNumber_H is mutually exclusive
from CSRAD_R0_L_DIMMNumber_H, then you probably don't
need the orif statement. If there is additional
logic this is the first you have mentioned it in your
argument.
> The following is an excerpt from my paper:
> Rule 4: Signals are mutually exclusive if their time marks are
> mutually exclusive.
> Example:
> SignalA <= (AState = A1_S and (…)) (2)
> or (AState = A2_S and (…));
> SignalB <= (AState = A3_S and (…)) (3)
> or (AState = A4_S and (…));
> SignalA and SignalB are mutually exclusive, no matter how complex the
> logic in (…) is.
I agree with this. It is possible that a synthesis tool
could derive that these two signals are mutually exclusive.
I don't know if they currently do this. I would
not want to have to specify that this is onehot. I would not
be surprised if I had to. I expect to have to use onehot
when signals come from another block or some condition
exists that is not easy to derive.
> Its extension is:
> if two signals are mutually exclusive based on whatever reasons, the
> derivative signals: A1, B1 are mutually exclusive:
> A1 <= A and (..);
> B1 <= B and (..);
>
> That is what my equation says. (if..orif..endif).
What does orif say? It says that the one entire expression
is mutually exclusive from the other. Hence it says that
A1 is mutually exclusive form B1. You cannot conclude that
A and B are mutually exclusive.
On the other hand, if rather than orif you use:
assert onehot (A, B) ... ;
Then you are saying that A and B are mutually exclusive and
you can deduce/derive that A1 and B1 are also mutually
exclusive.
Again any additional logic that you have not shown or explained
previously will change the validity of my claim, however,
please note, I only have a limited amount of ESP.
The only thing your current examples have done is
convince me that assert onehot is a better solution
than orif. Do you have anything else?
Cheers,
Just an Illusion
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
Weng Tianxiang
> 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).
Mutual exclusive relation means only one of them can be true at any
time, and they can be all false, so it /= 'XOR'.
> 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.
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. You must rewrite total code to get efficient
code!!! 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?!
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.
Tomorrow I will 'attack' Achilles heel of Jim's proposal assert() to
resolve mutually exclusive relations.
Weng
Jim Lewis
> OK, at last Jim and JaI admit my equation is right.
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,
Just an Illusion
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
Weng Tianxiang
> If you use "orif", and the synthesis tool cannot derive the mutual exclusion
"orif" is used to TELL compiler that the relating conditions are
mutually exclusive, no any doubt, do it and optimize the code for me.
The most important reason why 'orif' is suggested is currently popular
VHDL compilers are not as smart as we thought. I have used: Exemplar(1
years ago) and Xilinx(6.01), neither of them can optimize code the way
my paper suggested.
So 'orif' is used as a method to tell compiler what to do.
If 'orif' keyword is introduced, no matter how bad a VHDL compiler
code optimization technology is, you will still be guaranteed that you
get the most efficient implementation if 'orif' statements are widely
& correctly used. You may have to wait another 20 years to get all
VHDL compilers to do the smart job (at least in the last 20 years
since VHDL was introduced, you haven't met a smart VHDL compilers.
Why? it doesn't generate more money, but with risks.) After 'orif' is
introduced, you immediately get the performance advantages without
waiting for smart VHDL compilers.
I will post another message focusing on Achilles heel of Jim's
proposal assert() Monday.
Weng
Weng Tianxiang
Now let me focus on yours assert() disadvantages.
1. Your first usage of assert() is wrong!
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 ;
It should look like this:
Ex2 : process
begin
wait until Clk='1' ;
assert onehot(ASel & BSel & CSel & DSel) <--- !!!
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 ;
2. You must put an assert statement after clock edge statement to
correctly detect and report an error.
3. You must put an assert statement in a process() anywhere if 'orif'
statements are used. Otherwise you cannot correctly detect and report
an error.
4. You must define a new name for any conditions in 'if' or 'elsif'
statements that contain more than one signal before any assert
statement can be called;
5. If you are trying to let simulator to detect & report error
condition without each special calling, you create an unprecedented
language element that violates the principle rule of any languages:
first declare it, then it is legally to be used.
6. Your onehot name is misleading. Why? The following example tells
that a condition can represent many states:
type nCSStateType is (nCSIdle_S,
nCS0_S, nCS1_S, nCS2_S, nCS3_S,
nCS4_S, nCS5_S, nCS6_S, nCS7_S,
nCS8_S, nCS9_S, nCS10_S, nCS11_S,
nCS12_S, nCS13_S, nCS14_S, nCS15_S,
nCS16_S, nCS17_S, nCS18_S, nCS19_S,
nCS20_S, nCS21_S, nCS22_S, nCS23_S,
nCS24_S, nCS25_S, nCS26_S, nCS27_S,
nCS28_S, nCS29_S, nCS30_S, nCS31_S
);
signal nCSState : nCSStateType;
if(nCSState /= nCSIdle_S)
nCSState /= nCSIdle_S represents 32 states in the above state machine.
it is a statement from my design.
7. I have declared a new keyword 'exclusive' that is used to declare
group of signals and state machines they are mutually exclusive. It is
declared once, and it is valid globally, but in definition area.
8. 'exclusive' and 'orif' provide two complementary methods to tell
compiler the information of mutually exclusive. One is global in an
entity, another local.
9. You are the man to first suggest to introduce 'errels' after
'orif'. I wrote your idea into my paper not because of its necessity,
but with the purpose to soothe somebody's scare that if no error
detection mechanism, my 'orif' idea may be too 'danger'. The real and
easier solution is very simple:
VHDL committee mandates 'if 'orif' or 'exclusive' statements are
called, any simulation tools must report any conflicting error
situations like the way currently commonly and widely used by any
simulators when many sources drive one bit'.
When many sources driver one bit, designers don't have to write
special code to tell simulators to tell if they are wrong.
Doing so will relieve all designers from writing all unnecessary
assert or 'errels' to detect errors.
Amy comments are welcome.
Weng
Jim Lewis
> 1. Your first usage of assert() is wrong!
> correctly detect and report an error.
I agree. The way this circuit works, the assertion must
be re-written so that it only evaluates on the active
edge of clock. Going in a process, like you
show, is one possibility.
The other possibility is to have an assertion that only
evaluates its condition at the active edge of a particular
clock. This capability will be part of VHDL when PSL is
integrated (planned as part of VHDL-200X fast track).
> 3. You must put an assert statement in a process() anywhere if 'orif'
> statements are used. Otherwise you cannot correctly detect and report
> an error.
Disagree. See 2 above. The specification of onehot
with a PSL clocked assertion is much more like your
exclusive statement that you state below.
Also note that most signals that I have worked with are
always mutually exclusive, so checking for mutual exclusion
in a particular branch of an if statement is not necessary.
With assert, the mutual exclusion is specified once.
With orif, mutual exclusion is specified each time you
use the expression. If there are nested if statements,
the mutual exclusion must be specified multiple times
(most likely to occur in a statemachine).
If the mutual exclusion is specified correctly
9 out of 10 times in a nested if statement (accidently used
elsif instead of orif one time), how will you
detect the issue (not error because it is really only
a logic simplification)?
> 4. You must define a new name for any conditions in 'if' or 'elsif'
> statements that contain more than one signal before any assert
> statement can be called;
Exactly. Show me a relevant example that you are
concerned about. Here is one, CS is active and
both Write and Read are asserted. Note however,
this is a simple one to write with PSL.
> 7. I have declared a new keyword 'exclusive' that is used to declare
> group of signals and state machines they are mutually exclusive. It is
> declared once, and it is valid globally, but in definition area.
> 8. 'exclusive' and 'orif' provide two complementary methods to tell
> compiler the information of mutually exclusive. One is global in an
> entity, another local.
> 9. You are the man to first suggest to introduce 'errels' after
> 'orif'. I wrote your idea into my paper not because of its necessity,
> but with the purpose to soothe somebody's scare that if no error
> detection mechanism, my 'orif' idea may be too 'danger'. The real and
> easier solution is very simple:
> VHDL committee mandates 'if 'orif' or 'exclusive' statements are
> called, any simulation tools must report any conflicting error
> situations like the way currently commonly and widely used by any
> simulators when many sources drive one bit'.
> When many sources driver one bit, designers don't have to write
> special code to tell simulators to tell if they are wrong.
> Doing so will relieve all designers from writing all unnecessary
> assert or 'errels' to detect errors.
>
> Amy comments are welcome.
If exclusive makes errels not necessary, then "orif"
contains redundant information and hence is not
necessary.
All restrictions imposed on checking onehot also
apply to exclusive. Hence, with exclusive you must
specify a clock. This makes it a reduced form of
an assertion (what PSL provides).
Hence, my advice is for you to learn PSL. It is planned
to be integrated into VHDL in the next revision and
will provide much greater functionality than your
proposed exclusive.
Just an Illusion
Weng Tianxiang wrote:
<snip>
>When many sources driver one bit, designers don't have to write
>special code to tell simulators to tell if they are wrong.
>
In case of multidriving signal, you must be sure that only one value is
given at a time (possible by many drivers, but the same).
If not, a warning (possible an error) must be given, because if compiler
conclude that two differents values can be set at same time, that can be
because you have an error.
If your proposal hide this, you can recover this problem in a later step
of developpement; and in this case, it can be very hard to find the true
origin. It is time consuming, and money cost.
Just an Illusion
> Hence, my advice is for you to learn PSL. It is planned
> to be integrated into VHDL in the next revision and
> will provide much greater functionality than your
> proposed exclusive.
psl is an assertion language to define formal properties.
I don't think that psl can be use to drive simulation or synthesis. The
psl must drive formal validation engines.
Why psl can't be use for simulation ?
In psl, you can write what is must be, but what you mustn't too.
Simulation test only what the design can do, not more.
If you put an assert (generally to trace an unexpected behavior), and if
you find the trace in your simulation. It is because you have an error.
Some time, you have no assert generation, because your test cases are
not enough.
Take the following example: you have a fifo of 1k element, this fifo
have an error because it erase the begining of fifo data when the fifo
is full, and an input is add.
You use this fifo into a system, which require only 512 elements from
the fifo. You can do all your simulations without any error (and any
assert).
Formal validation can point you the weak of the fifo, not simulation.
Why psl can't be use for synthesis ?
Some psl properties can be help for reduce a little some logic
equations, but in general you describe some 'trace' or 'scenario' and
that is not usefull for synthesis.
Example:
If you have a handshake protocol: {REQ,*,ACK} => after a request you
must have an acknowledge
Could you tell me how you can use this property to drive synthesizer ?
Rgrds,
JaI
Jim Lewis
>> to be integrated into VHDL in the next revision and
>> will provide much greater functionality than your
>> proposed exclusive.
>
>
> psl is an assertion language to define formal properties.
> I don't think that psl can be use to drive simulation or synthesis. The
> psl must drive formal validation engines.
It is already part of simulators and some synthesis
tools. It is not about what you can't do with
something, it is about what you can do and the motivation
for doing so.
In simulation, PSL is being used both to signal when
an error condition has occurred and help indicate
where the issue is (ie: the agreed upon interface
spec has been violated).
In synthesis, we have attributes that
allow us to express when two signals are mutually
exclusive. This is nice, but the real problem
is that nothing validates this claim. By making
a limited number of assertions synthesizable
(perhaps it is only onehot), then the claim can be
verified in the simulator. I agree this has the
limitation if I write incomplete tests, however,
it is better than no testing at all. In addition,
given a formal tool with enough capacity, by using
PSL I can also prove it to be correct. If we make
it so that all tools understand the same language
(such as PSL) then we can minimize the chance
of an error sneaking through.
> Why psl can't be use for simulation ?
> In psl, you can write what is must be, but what you mustn't too.
> Simulation test only what the design can do, not more.
> If you put an assert (generally to trace an unexpected behavior), and if
> you find the trace in your simulation. It is because you have an error.
> Some time, you have no assert generation, because your test cases are
> not enough.
And if you don't put in an assertion and the error never
propagates to the outputs during the lifetime of your
test, then what? If you check your simulation
coverage you will probably find that you covered the
case you were worried about.
> Take the following example: you have a fifo of 1k element, this fifo
> have an error because it erase the begining of fifo data when the fifo
> is full, and an input is add.
> You use this fifo into a system, which require only 512 elements from
> the fifo. You can do all your simulations without any error (and any
> assert).
> Formal validation can point you the weak of the fifo, not simulation.
Agreed. Some things are difficult to find in simulation.
Hence the motivation to do formal.
> Why psl can't be use for synthesis ?
> Some psl properties can be help for reduce a little some logic
> equations, but in general you describe some 'trace' or 'scenario' and
> that is not usefull for synthesis.
> Example:
> If you have a handshake protocol: {REQ,*,ACK} => after a request you
> must have an acknowledge
Using your reasoning, no HDL can be used for synthesis
because I can write some HDL code that is not
synthesizable. However, this is not the case because we
have defined "coding styles" that translate to the
appropriate hardware structure.
Priority vs. mutual exclusion is a problem encountered
by any programming language when trying to describe/
implement hardware. Using language elements or assertions
to convey that code written with if then elsif, elsif, ...
is really mutually exclusive can be result in a hardware
savings with greater readability than code written otherwise.
My expectation is that most assertions will be ignored by
synthesis, but a few, such as one that conveys mutual
exclusion will be synthesizable.
Ken Smith
Jim Lewis <J...@SynthWorks.com> wrote:
[...]
>is that nothing validates this claim. By making
>a limited number of assertions synthesizable
>(perhaps it is only onehot), then the claim can be
>verified in the simulator. I agree this has the
>limitation if I write incomplete tests, however,
I'm joining this argument late and am far from an expert but it seems to
me that this is the hard way to get where we want to go. It seems simpler
to me to be able to do something like this:
process (SomeStd_logic_vector) begin
if 1 = HowManyHigh(SomeStd_logic_vector) then
-- prehaps nothing here
else
assert-it-is-broken;
end if;
end process;
The Sim. can implement the real assert. The Synth can make everything a
don't care in the asserted state. The advantage is that the language
designers don't have to know about my "3.5 hot" state machine that I'm
just about to patent but I can still test that it is going to work right.
--
--
kens...@rahul.net forging knowledge
Weng Tianxiang
> By making a limited number of assertions synthesizable (perhaps it is only onehot)
I don't really see where your assert() is simpler than my new keyword:
'exclusive' with misleading name 'onehot'.
You want to change non-synthesizable statement assert() to a statement
sometimes synthesizable, and sometimes non-synthesizable with long
typing
'assert onehot(A1, A2, A3) report "failed" severity failure ;'
and calling 'psl' language?
Tell me what advantages of your assert() is over my keyword
'exclusive'.
If I am confused, I don't know how many would be consufed.
exclusive (A1, A2, A3);
In my paper, 'exclusive' is 2nd class of new keywords I suggested than
'orif'. It is suggested to be used for among state machines and other
non-derivative mutually exclusive signals.
I will tell you why 'orif' is better than 'exclusive' in most of time
in examples next time.
Weng
Jim Lewis
> Tell me what advantages of your assert() is over my keyword
> 'exclusive'.
>
> If I am confused, I don't know how many would be consufed.
>
> exclusive (A1, A2, A3);
>
to add syntax to tell exclusive to operate only at a specific
edge of a specific clock.
From a language designer perspective, PSL (assertions)
are already being integrated (separate standard) with
VHDL. EDA vendors are starting to support it.
So it is a simple matter learning the syntax and using it
rather than adding a new language feature. Note that
anytime a new keyword is added to the language there
is the possibility that the keyword will conflict with
an identifier existing code.
> I will tell you why 'orif' is better than 'exclusive'
> in most of time in examples next time.
A good long example would most helpful.
Weng Tianxiang
> Don't forget that you need to add syntax to tell exclusive to operate only at a specific edge of a specific clock.
It is not true for 'exclusive' to indicate clock and its edges.
1. When one declares that two signals are exclusive, they must be
registered at the same clock, but not necessary at the same edge. So
clock name is not needed; Under different clocks even two signals
cannot be reliably compared, not mention their exclusive conditions.
So it is a logic error if two signals registered under two different
clocks are declared as mutually exclusive in 'exclusive'.
2. If signals claimed in 'exclusive' are registered under different
edges, it is OK when they are involved in any special edge.
3. When signals claimed in 'exclusive' statements are involved in a
'if..elsif..endif', the clock and its edge is clear.
So when keyword 'exclusive' is used, clock and edge type are redundant
information. There is no any need to include them. It is like to use
'=' operator to compare two signals registered under two different
clocks, it is legal, but most of time it is wrong. VHDL specs never
prohibit '=' operator used for two 32-bit addresses registered under
two different clocks.
> Note that anytime a new keyword is added to the language there is the possibility that the keyword will conflict with an
> identifier existing code.
This is another wrong assumption with either 'exclusive' or 'orif'. If
you put following 'exclusive' statement at the declare area, it is an
error now! 'exclusive' equals to 'signal'!
exclusive (A1, A2, A3);
If you put 'orif' at 'elsif' places, no matter what you have declared,
it is an error now!
I would like to clear any misunderstanding of new keywords if any you
still have.
Weng
Jim Lewis
> 1. When one declares that two signals are exclusive,
Mutually exclusive RTL signals may overlap when they
are changing if one has more delta cycles than another.
Hence, somehow an eda tool must have a way to determine
when this overlap is a failure and when this overlap
is irrelevant. An easy way to do this is for the
construct to specify the relevant edge of the
clock.
I suppose alternately you could expect the tool to
do this. Of course this would mean it would need to
trace from the logic to all the registers in the
logic cone and check the constraint there. What
if the register is in a separate logic block?
>>Note that anytime a new keyword is added to the language there is the possibility that the keyword will conflict with an
>>identifier existing code.
>
> This is another wrong assumption with either 'exclusive' or 'orif'.
If someone currently has this in their code:
signal exclusive : std_logic ;
and I add exclusive as a keyword to the language,
then their code will no longer compile and they
must change their signal name.
Still waiting patiently for your more extensive
"orif" examples.
Weng Tianxiang
> Mutually exclusive RTL signals may overlap when
> they are changing if one has more delta cycles
> than another.
Mutually exclusive case happen when
1. with different clock marks;
2. with one wire of different values;
3. derivated from 'if..elsif..end' statements;
4. with physical limit: like reading vs. writing, ...; Memory_1G vs.
Memory_2G, ...;
In my mind, there is no boundary to check for mutually exclusive. If
they have a overlap, it is not 'exclusive' error or 'orif' error, it
is other factors and you cannot blame them like you cannot blame '='
operator when your running frequency is not high enogh to cause
overlap of two signals. As you know all signals involved must be
setteld down before setup time ahead of clock edges and cannot change
until hold time after clock edge.
> If someone currently has this in their code:
> signal exclusive : std_logic ;
OK, no any problem for an existing design:
signal exclusive : std_logic ;
exclusive (A1, A2);
The above two statements can be co-exist without any problem.
The first 'exclusive' is declared as a signal, it can be used later as
normal signal;
The second 'exclusive' is a mutual exclusive declaration. It can be
recognized by compiler without any confusion with first one if you
have some knowledge of how compiler is built, especially when
'exclusive' is added later into VHDL:
the first one 'exclusive' is put into signal name list & see if there
are any violations, the second is searched for in the keyword list, so
they are at totally different list area, leading to two different
reaction of compiler.
Beyond declaration area, 'exclusive' will be recognized as signal name
as usual without any special treatments.
'orif' is at the same situation as above. They will be searched for in
keyword list as 'elsif'.
Weng
Jim Lewis
>>Mutually exclusive RTL signals may overlap when
>>they are changing if one has more delta cycles
>>than another.
>
>
> Mutually exclusive case happen when
> 1. with different clock marks;
> 2. with one wire of different values;
> 3. derivated from 'if..elsif..end' statements;
> 4. with physical limit: like reading vs. writing, ...; Memory_1G vs.
> Memory_2G, ...;
>
> In my mind, there is no boundary to check for mutually exclusive. If
> they have a overlap, it is not 'exclusive' error or 'orif' error,
For: exclusive (A1, A2);
The key to the issue is when does exclusive check
for mutual exclusion:
1) On changes of A1 and A2
2) When either A1 or A2 is read?
3) At a specified condition
#2 is problematic. When either A1 or A2 is read?
What if they are read in a process that does
not include clock? Do you propagate the check
to the clock at which the cone of logic terminates?
What should happen when A1 is read,
but the cone of logic does not include A2, does
the check for mutual exclusion get executed or not?
Propagating the check can be very sophisticated and
would be a capability beyond what current simulators
do. A simplistic check (when A1 or A2 are read)
can quickly devolve to #1. Also the check could be
different for different implementations of the logic.
Note I don't think the level of sophistication here
is impossible to solve, but I do think that with
simple extensions of the notation (and a very minor
burden on the coder) that the problem can be easy
to solve. Hence, I would rather add the little
extra code myself and have the EDA vendors solve
other problems.
#1 is problematic. Consider the following example.
Are Y1 and Y3 mutually exclusive?
Y1 <= '1' when A = '1' else '0' ;
Y2 <= '1' when A /= '1' else '0' ;
Y3 <= Y2 ;
In an RTL simulation, Y1 and Y2 are aligned in time and
mutually exclusive. Y3 is delayed by a delta cycle from
Y2 and hence it will have overlay with Y1 in time.
Are Y1 and Y3 mutually exclusive? Going further, in
gate implementations, it is common for rise and fall
times to differ and as a result, it would not be
uncommon for Y1 and Y2 to overlap.
This overlap is ok when it is sampled by a clock because
if A is synchonized to the same clock, then the overlap
will not occur at the clock boundry.
This overlap is usually not ok when Y1 and Y2 are used
to drive competing tristate drivers:
In Block 1:
DataBus <= Block1Data when Y1 = '1' else (others => 'Z") ;
In Block 2:
DataBus <= Block2Data when Y2 = '1' else (others => 'Z") ;
#3 is a potential solution. Extend the syntax to permit
the condition under which to evaluate the mutual exclusion
to be specified. Typically this would be a clock.
If you were to extend exclusive to understand clock,
then I think the solution would be more workable,
however, it would be identical to capabilities
provided by PSL. Note there is also OVL that may provide
similar capabilities.
So your suggestion is not being ignored, it is just
being solved another way. This is the nature of
standards efforts, you don't always get exactly what
you had ideally wanted, but you usually get something
that solves your problem.
>>If someone currently has this in their code:
>> signal exclusive : std_logic ;
>
>
> OK, no any problem for an existing design:
>
> signal exclusive : std_logic ;
> exclusive (A1, A2);
>
> The above two statements can be co-exist without any problem.
The current VHDL language design does not permit this.
To change this violate the spirit of VHDL.
Going further, for vhdl-200x-mp effort, I will be writing
an analysis of this issue. I would be interested
to see a more extensive "orif" example as it would give
me some insight to understand why you like "orif".
Further arguments about the merits of exclusive or
arguments about orif without examples are not going
to help.
Just an Illusion
Weng Tianxiang wrote:
><snip>
>
>4. with physical limit: like reading vs. writing, ...; Memory_1G vs.
>Memory_2G, ...;
>
>
>
Sorry but example of read vs. write is not a good example, remember case
of double access ram, where you can have a read and a write access
simultaneously.
More, lot of example have 2 different lines, one for read and another
for write; even if only one must be active at a time.
>Weng
>
>
JaI
Weng Tianxiang
> Sorry but example of read vs. write is not a good example, remember case
> of double access ram, where you can have a read and a write access
> simultaneously.
If you don't know something, it is better to keep quite and stand
aside to learn.
Tell me what kind of double access ram working in a way a read and a
write access happen simultaneously.
Weng
Just an Illusion
Weng Tianxiang wrote:
>JaI,
>
>
>>Sorry but example of read vs. write is not a good example, remember case
>>of double access ram, where you can have a read and a write access
>>simultaneously.
>>
>>
>
>If you don't know something, it is better to keep quite and stand
>aside to learn.
>
>
You are not the only people which made design, so be quiet.
>Tell me what kind of double access ram working in a way a read and a
>write access happen simultaneously.
>
>
Fifo between two different clock domains is the most classical case.
Read and write are fully independant, and can be done simultaneously.
It is not because you don't do it that nobody does.
>Weng
>
>
JaI
Weng Tianxiang
> For: exclusive (A1, A2);
> The key to the issue is when does exclusive check
> for mutual exclusion:
> 1) On changes of A1 and A2
> 2) When either A1 or A2 is read?
> 3) At a specified condition
My algorithm may not be the best, but it clears things up.
1. Find where (A1, A2) signals appear on conditions of
'if..elsif..end', record their lines like the following:
(A1, A2): line 1001, 1330, ...
2. At the last delta time, every signals are stable, test if A1, A2
are both true, if so, output error information:
(A1, A2): violates mutually exclusive conditions at line 1001, 1330,
...
exclusive (A1, A2);
1. exclusive name is seldom used;
2. it has not effects on all old design done before 'exclusive' is
introduced. It affects only later new design. New design cannot use
'exclusive' as a signal name. It doesn't violate VHDL spirit.
3. If you must include old part of design that contains 'exclusive'
name, change it. Because old version has to be changed to include any
new VHDL benefits.
Weng
Jim Lewis
How about an example of orif?
I have already spoken my peace on exclusive.
Regards,
Jim
Weng Tianxiang
Here you are. The longest 'if..elsif..end' statement.
Following the process(), there are two versions of compilation
information for Xilinx chip xc2v1000-4, 1 million gate chip: one for
non-optimized version as follows, another for manually optimized
version that I have been using. Other parts are entirely same.
Their stark differences are:
Minimum period: 14.904ns - 14.687ns = 0.217ns
Number of occupied Slices: 3,432 - 3,369 = 63
Total Number 4 input LUTs: 5,688 - 5,581 = 107
From above observation, we conclude: 'if..elsif..end' is very code
inefficient!!! This is only one counter. If more, you cannot expect to
get what you want for a complex design.
This is the basic reason I want to introduce new keyword 'orif'.
Weng
The process is a counter, it has 7 loading conditions which are
mutually exclusive.
RowChipPtrA : process(nRESETGlobal, CLK66M)
begin
if(nRESETGlobal = '0') then
RowChipPtr <= (others=>'0');
elsif(CLK66M'event and CLK66M = '1') then
if(WriteFIFO_SDRAMPtr) then -- 1
if(MEMORY_2G = '0') then
RowChipPtr(14 downto 0) <= WriteFIFODataOut(29 downto 15);
else
RowChipPtr(14 downto 0) <= WriteFIFODataOut(30 downto 16);
end if;
elsif(AD_R0_SDRAMPtr) then -- 2
if(MEMORY_2G = '0' and WINDOW_16M = '1') then
RowChipPtr(14 downto 0) <= TWindowAddress(29 downto 24) &
AD_R0(23 downto 15);
elsif(MEMORY_2G = '0' and WINDOW_256M = '1') then
RowChipPtr(14 downto 0) <= TWindowAddress(29 downto 28) &
AD_R0(27 downto 15);
elsif(MEMORY_2G = '1' and WINDOW_16M = '1') then
RowChipPtr(14 downto 0) <= TWindowAddress(30 downto 24) &
AD_R0(23 downto 16);
elsif(MEMORY_2G = '1' and WINDOW_256M = '1') then
RowChipPtr(14 downto 0) <= TWindowAddress(30 downto 28) &
AD_R0(27 downto 16);
elsif(MEMORY_2G = '1' and WINDOW_NO = '1') then
RowChipPtr(14 downto 0) <= AD_R0(30 downto 16);
elsif(MEMORY_1G = '1' and WINDOW_NO = '1') then
RowChipPtr(14 downto 0) <= AD_R0(29 downto 15);
elsif(MEMORY_512M = '1' and WINDOW_NO = '1') then
RowChipPtr(14 downto 0) <= '0' & AD_R0(28 downto 15);
else -- when MEMORY_256M = '1' and WINDOW_NO = '1'
RowChipPtr(14 downto 0) <= "00" & AD_R0(27 downto 15);
end if;
elsif(AD_R1_SDRAMPtr) then -- 3
if(MEMORY_2G = '0' and WINDOW_16M = '1') then
RowChipPtr(14 downto 0) <= TWindowAddress(29 downto 24) & AD_R1(23
downto 15);
elsif(MEMORY_2G = '0' and WINDOW_256M = '1') then
RowChipPtr(14 downto 0) <= TWindowAddress(29 downto 28) & AD_R1(27
downto 15);
elsif(MEMORY_2G = '1' and WINDOW_16M = '1') then
RowChipPtr(14 downto 0) <= TWindowAddress(30 downto 24) & AD_R1(23
downto 16);
elsif(MEMORY_2G = '1' and WINDOW_256M = '1') then
RowChipPtr(14 downto 0) <= TWindowAddress(30 downto 28) & AD_R1(27
downto 16);
elsif(MEMORY_2G = '1' and WINDOW_NO = '1') then
RowChipPtr(14 downto 0) <= AD_R1(30 downto 16);
elsif(MEMORY_1G = '1' and WINDOW_NO = '1') then
RowChipPtr(14 downto 0) <= AD_R1(29 downto 15);
elsif(MEMORY_512M = '1' and WINDOW_NO = '1') then
RowChipPtr(14 downto 0) <= '0' & AD_R1(28 downto 15);
else -- when MEMORY_256M = '1' and WINDOW_NO = '1'
RowChipPtr(14 downto 0) <= "00" & AD_R1(27 downto 15);
end if;
elsif(ReadFIFOTailPtr_SDRAMPtr) then -- 4
if(MEMORY_2G = '0') then
RowChipPtr(14 downto 0) <= ReadFIFOTailPtr(29 downto 15);
else
RowChipPtr(14 downto 0) <= ReadFIFOTailPtr(30 downto 16);
end if;
elsif(MSDRAMPtr_SDRAMPtr) then -- 5
if(MEMORY_2G = '0') then
RowChipPtr(14 downto 0) <= MSDRAMPtr(29 downto 15);
else
RowChipPtr(14 downto 0) <= MSDRAMPtr(30 downto 16);
end if;
elsif(ModeValue_RowChipPtr) then -- 6
if(MEMORY_256M = '1') then
RowChipPtr(14 downto 0) <= "000" & X"027";
elsif(MEMORY_512M = '1') then
RowChipPtr(14 downto 0) <= "00" & X"027" & '0';
else -- MEMORY_1G_2G
RowChipPtr(14 downto 0) <= '0' & X"027" & "00";
end if;
elsif(RowChipPtrEnable) then -- 7
RowChipPtr <= RowChipPtr + '1';
end if;
end if;
end process;
For version of 'if..elsif..end' statement
Minimum period is 14.904ns.
Design Summary:
Number of errors: 0
Number of warnings: 77
Logic Utilization:
Number of Slice Flip Flops: 2,424 out of 10,240 23%
Number of 4 input LUTs: 5,346 out of 10,240 52%
Logic Distribution:
Number of occupied Slices: 3,432 out of 5,120 67%
Number of Slices containing only related logic: 3,432 out of
3,432 100%
Number of Slices containing unrelated logic: 0 out of
3,432 0%
*See NOTES below for an explanation of the effects of
unrelated logic
Total Number 4 input LUTs: 5,688 out of 10,240 55%
Number used as logic: 5,346
Number used as a route-thru: 108
Number used as 16x1 RAMs: 1
Number used as Shift registers: 233
Number of bonded IOBs: 272 out of 324 83%
IOB Flip Flops: 286
Number of Tbufs: 352 out of 2,560 13%
Number of GCLKs: 3 out of 16 18%
For manuaaly optimized version
Minimum period is 14.687ns.
Design Summary:
Number of errors: 0
Number of warnings: 77
Logic Utilization:
Number of Slice Flip Flops: 2,425 out of 10,240 23%
Number of 4 input LUTs: 5,252 out of 10,240 51%
Logic Distribution:
Number of occupied Slices: 3,369 out of 5,120 65%
Number of Slices containing only related logic: 3,369 out of
3,369 100%
Number of Slices containing unrelated logic: 0 out of
3,369 0%
*See NOTES below for an explanation of the effects of
unrelated logic
Total Number 4 input LUTs: 5,581 out of 10,240 54%
Number used as logic: 5,252
Number used as a route-thru: 95
Number used as 16x1 RAMs: 1
Number used as Shift registers: 233
Number of bonded IOBs: 272 out of 324 83%
IOB Flip Flops: 286
Number of Tbufs: 352 out of 2,560 13%
Number of GCLKs: 3 out of 16 18%
Weng Tianxiang
I have posed my long 'if..elsif..endif' statement on the google with
clear compilation results to prove that 'if..elsif..endif' statement
is not only code inefficient in theory, but also in practice.
I haven't known what your positions are now.
Are you still interested in assert() or turning to back my opinion
about 'orif'?
Another question is why VHDL committee is so adamant not to introduce
conditional statements widely used in C, C++.
Weng
Jim Lewis
> I have posed my long 'if..elsif..endif' statement on the google with
> clear compilation results to prove that 'if..elsif..endif' statement
> is not only code inefficient in theory, but also in practice.
>
> I haven't known what your positions are now.
>
> Are you still interested in assert() or turning to back my opinion
> about 'orif'?
Full consideration of "orif" will need to wait for phase 2
of the VHDL-200X effort. Currently the review of FT items
(for which I am co-team leader) is taking much of my time.
I guess the good news is that I did not dismiss it immediately.
I will have to put some time thinking about your example.
I will follow up with you later.
> Another question is why VHDL committee is so adamant not to introduce
> conditional statements widely used in C, C++.
Perhaps we might need something more powerful.
No time right now. I will follow up on this later.
For now, why not use use CPP? Previously when I fixed
your conditinal compilation statements they seemed
to work fine with CPP. Did you persever and
get it to work? I never posted my solution as
you never appologized for the not so nice comments
you made about the standards group.
Regards,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis mailto:J...@SynthWorks.com
SynthWorks VHDL Training http://www.SynthWorks.com
Director of Training
Get hand-on VHDL experience with our FPGA based lab boards.
See: http://www.synthworks.com/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Verbeure
> I have posed my long 'if..elsif..endif' statement on the google with
> clear compilation results to prove that 'if..elsif..endif' statement
> is not only code inefficient in theory, but also in practice.
how did you do the 'manual' optimization? Did you dive into the
schematic of it or did you use the manual 'or' of the vector, which is
a fairly trivial change...
Tom
Weng Tianxiang
>> Another question is why VHDL committee is so adamant not to
introduce
>> conditional statements widely used in C, C++.
> Perhaps we might need something more powerful.
> No time right now. I will follow up on this later.
My advice is, if C/C++ has been using them, not to invent new wheels
for it.
>> For now, why not use CPP?
I had written a very good C program to handle it so nice that I have
been using them everyday!!! I couldn't put the source code on this
website, because it is my company's property eventhough I wrote it.
For a good language, it must include #define... statements without any
doubt to facilitate programming when projects become larger than ever
and the momentum is huge.
I would say it would have been better if I had wrote it 4 years ago.
Without it I cannot finish current two projects.
Here is another point your committee should pay attention to:
sensitivity list!
They are garbage, no body needs it. Why don't you propose to change
it? We have to wait for another 20 years?
Here is an example: 57 signals! You may think how much times I spent
not to miss anyone.
SDRAMStateB : process(SDRAMState, nRESETGlobal, ExpireCountTimeOut,
FrequencyStatus,
MTInSDRAMWrite, MTInSDRAMRead, WriteFIFOEmpty, TAddressClock,
Fail5V_3V,
ActiveExpireRead, RefreshState, MReadFIFOHit, nPowerReady_R,
FlashTimer14Hz,
CommandBitOut, CKE_O, CommandBitIn, ReadStatus, ActiveExpireWrite,
TReadSDRAMState,
WriteFIFOAllByte_0_1, DQ_R1_SyndromeOK, TReadSDRAMIdle, IState,
TState,
NextBankNotPreActive, ReadFIFOPreFull, WriteNewPage,
WriteFIFOWriteEnable,
ReadNewPage, SendBurstRead_B, ActiveState, ChipReady, Wait8ms,
WriteFIFOInjectWrite, BankState, WriteFIFOByteEnable,
ClearSendBurstRead_B,
AutoRefresh0State, AutoRefresh1State, TReadSDRAMWait0,
TReadSDRAMHit_S0,
AutoRefresh2State, AutoRefresh3State, TReadFIFOHit, RowChipPtr,
TWriteSDRAMHit_S0,
RefreshCountCout, nC_BE_R0, TWriteSDRAMState, CSRModeReg,
ReadDataAtDQ_R0,
DMAState, DMADirection, InBurstRead, DMAPreReadSDRAMStart,
DMAReadDataReady)
The above 3 things: 'orif', '#define..' statement and process(*) are
small things, but has huge consequences: Your committee should pay
more attention to the real problems, be effective!
Weng
Jim Lewis
> Here is another point your committee should pay attention to:
> sensitivity list!
>
Already did. See the fast track proposals at:
http://www.eda.org/vhdl-200x/vhdl-200x-ft/proposals/proposals.html
See FT-19
It would be better if you would educate yourself about
what the working group is currently doing before
mouthing off like this.
Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Just an Illusion
Weng Tianxiang wrote:
>Jim,
>
>
>>>Another question is why VHDL committee is so adamant not to
>>>
>>>
>introduce
>
>
>>>conditional statements widely used in C, C++.
>>>
>>>
>>Perhaps we might need something more powerful.
>>No time right now. I will follow up on this later.
>>
>>
>
>My advice is, if C/C++ has been using them, not to invent new wheels
>for it.
>
>
>
If you discuss with lot of programmer, they can said you that lot of
them dislike C/C++
Lot of programmer preferred java, or other language. It seems that C/C++
is not well suited for new applications under development.
>
>
>>>For now, why not use CPP?
>>>
>>>
>
>I had written a very good C program to handle it so nice that I have
>been using them everyday!!! I couldn't put the source code on this
>website, because it is my company's property eventhough I wrote it.
>For a good language, it must include #define... statements without any
>doubt to facilitate programming when projects become larger than ever
>and the momentum is huge.
>
>
#define and other statement #... are preprocessing instruction, then
they are now influence on following steps.
Do you know that usage of #define and other preprocessing command can
give some problems with usage of formal verification ?
Because they can introduce some implicit behaviors, but formal
verification is better with explicit behaviors.
><snip>
Do you know that you can some useful editor that can help you to write
your code ? as (X)emacs and its vhdl-mode ;-)
In the vhdl-mode, you have an automatic function that refresh you the
sensitivity list of a process (Ctrl-C+Ctrl-u+Ctrl-s) or all sensitivity
lists of the buffer (Ctrl-C+Ctrl-u+Meta-s).
This is a freeware tool, that you can easily include in your development
flow at low cost. It seems that Xemacs has been ported under all
classical platforms (windows, mac, unix/linux).
But it is a little curious for me to find a so big list of sensitivity,
because I remember that some fpga design rules limit the size of
sensitivity list to 20 or 30 signals (perhaps change since 1998).
>The above 3 things: 'orif', '#define..' statement and process(*) are
>
process (*) is an aberration. Yes it can be help you to write quickly
your code; but all your simulation and synthesizer tools will go to do
lot of unnecessary work.
And that work against your orif proposal at the end.
The process (*) includes all signals of the design into the sensitivity
list of the process. If you have the following code:
c <= a and b;
myProcess : process (*)
if (resetn='0') then
d <= '0';
elsif (clk'event and clk='1') then
d <= e;
endif;
The process myProcess must be evaluated on each modification of 'a', 'b'
and 'c', event if 'e', 'clk' or 'resetn' are independent of 'a','b' and 'c'
The introduction of (*) as sensitivity list require the modification of
section 12.6 of the ieee 1076 into a very complex mechanism.
Last point, without an explicit sensitivity list, you can hide some
connectivity error, that can be very hard to find.
Take as example a design with very similar syntax of signals or
variables as reset and resetn.
Or a design with a signal and a variable with the same syntax. In the
process the variable is taken if the signal is not in the sensitivity
list, otherwise it is an error.
The solution proposed by Jim Lewis is better.
>small things, but has huge consequences: Your committee should pay
>more attention to the real problems, be effective!
>
>
The design is not the only phase that use the vhdl. When you make a
proposal, you need evaluate its impact on all the design and
verification flow that handle vhdl.
Your 'real' problem can be come from other source that vhdl language.
Example: the design rule that limit the number of signal into a
sensitivity list is not given by language, but by eda tools themselves.
>Weng
>
>
JaI
Weng Tianxiang
process_statement ::=
[ process_label : ]
[ postponed ] process_kind [ is ]
process_declarative_part
begin
process_statement_part
end [ postponed ] process [ process_label ] ;
Add definition for process_sensitivity in clause 9.2:
process_kind ::=
process [ ( sensitivity_list ) ]
| process_comb
| process_latch
| process_ff
It should be better like this way:
Add definition for process_sensitivity in clause 9.2:
process_kind ::=
process [ ( sensitivity_list ) ]
| process [ ( * ) ]
No any langauge I have known in the world uses keywords that contain
'_'. I really don't know why you want ot invent new wheels. process(*)
is introduced by Verilog, it is a very good idea!
Weng
Weng Tianxiang
> process (*) is an aberration. Yes it can be help you to write quickly
> your code; but all your simulation and synthesizer tools will go to do
> lot of unnecessary work.
> And that work against your orif proposal at the end.
> The process (*) includes all signals of the design into the sensitivity
> list of the process. If you have the following code:
> c <= a and b;
> myProcess : process (*)
> if (resetn='0') then
> d <= '0';
> elsif (clk'event and clk='1') then
> d <= e;
> endif;
> The process myProcess must be evaluated on each modification of 'a', 'b'
> and 'c', event if 'e', 'clk' or 'resetn' are independent of 'a','b' and 'c'
You disagree with your opinion.
I guess that why sensitivity list was introduced into VHDL/Verilog 25
years ago was the consideration to the memory size limit and software
handling limit. At 25 years ago, it was very difficult to pick up the
sensitivity list by software.
Now situations are totally different from 25 years ago. Do we need to
differentiate 3 cases: dff, comp or latch? Software cannot do that? My
deep believe that software can do it now at easy and as much better
and faster than any experienced programmers to pick up any signals
for sensitivity.
Weng
Just an Illusion
Weng Tianxiang wrote:
I don't know history of sensitivity list, but usage of (*) as sensitive
list can change your expected result
Take codes:
NotLatch : process (g)
begin
if (g='1') then
q<=d;
end if;
end process;
IsLatch : process (*)
begin
if (g='1') then
q<=d;
end if;
end process;
The both are similar, but according to section 12.6 of the lrm, the
first process is a flip-flop and the second (according to verilog
sensitivity notation) must be a d-latch.
You have an other problem, the interpretation queue ordering for the
following code:
process (*)
begin
if (g='1') then
a<= not b;
b<=a;
endif;
end process;
According to verilog notation, it must be equivalent to:
process (g,a,b)
begin
if (g='1') then
a<= not b;
b<=a;
end if;
end process;
But in that case, you have a problem according to section 12.6 of the lrm.
If you have only (g) in sensitivity list, you are safe.
That is an example of danger with (*)
>Weng
>
>
JaI
Just an Illusion
Weng Tianxiang wrote:
><snip>
>No any langauge I have known in the world uses keywords that contain
>'_'. I really don't know why you want ot invent new wheels. process(*)
>is introduced by Verilog, it is a very good idea!
>
>
*joke* So you know a very small of them ;-) *end of joke*
For your information ansi C have reserved keyword with '_', they are
macro as __DATE__, __TIME__, __FILE__, __LINE__, __STDC__ and specific
function as __stdcall, __inline, etc.
You have Verilog with some compiler directive and PLI functions.
In VHDL throught use of VITAL library (ieee 1076.4)
You ceratinly can find some other examples, but the three languages are
the must common used be us.
>Weng
>
>
JaI
ALuPin
don't you think that it is sufficient now?
It is time for your subject name to "disappear" ,o)
Kind regards
Wallclimber
>
> NotLatch : process (g)
> begin
> if (g='1') then
> q<=d;
> end if;
> end process;
>
> IsLatch : process (*)
> begin
> if (g='1') then
> q<=d;
> end if;
> end process;
>
> The both are similar, but according to section 12.6 of the lrm, the
> first process is a flip-flop and the second (according to verilog
> sensitivity notation) must be a d-latch.
You either have a very creative way of reading the specification or
you're reading a different document. Section 12.6 is called "Execution
of a model". Except for some instance names in code examples in the
first 22 pages, the LRM doesn't even use the word 'latch'.
Jim,
I have to side with Weng here. Simply define the '*' in process(*) as
an expansion of all signals that are read in the process. If this is
not what the writer want, just use the old method... This is most in
line with the original intention of VHDL where you describe a
simulation behavior without targetting specific synthesis behavior.
Tom
Just an Illusion
Wallclimber wrote:
>>Take codes:
>>
>>NotLatch : process (g)
>>begin
>> if (g='1') then
>> q<=d;
>> end if;
>>end process;
>>
>>IsLatch : process (*)
>>begin
>> if (g='1') then
>> q<=d;
>> end if;
>>end process;
>>
>>The both are similar, but according to section 12.6 of the lrm, the
>>first process is a flip-flop and the second (according to verilog
>>sensitivity notation) must be a d-latch.
>>
>>
>
>You either have a very creative way of reading the specification or
>you're reading a different document. Section 12.6 is called "Execution
>of a model". Except for some instance names in code examples in the
>first 22 pages, the LRM doesn't even use the word 'latch'.
>
>
You are right, okay I change my words:
First is a register that is wake up by any event on 'g' that make change
it's value from 1 to another (that is not 1), that is a 'flip-flop'
Second is a register that is wake up by any event on 'g' or 'd', that is
a register which is drive by state (not edge).
>Jim,
>I have to side with Weng here. Simply define the '*' in process(*) as
>an expansion of all signals that are read in the process. If this is
>not what the writer want, just use the old method... This is most in
>line with the original intention of VHDL where you describe a
>simulation behavior without targetting specific synthesis behavior.
>
>
The semantic (I dislike this word, because lot of people use this term
only to justify their opposition) of * is not what you proposed, the *
semantic is equivalent to include any signals of the design, not only
signals of the process.
To me, I think than (*) is very dangerous.
I'll take a (real) example, I have the following code:
clk_inv <= not clk;
process (clk, resetn)
begin
if (resetn='0') then
q <= '0';
elsif (clk_inv'event and clk_inv='1') then
q <= d;
end if;
end process;
This code don't give specific error in simulation, except than
compilation, linting tool or rule-checker must generate a warning at least.
This error, on sensitivity list, come from a copy-paste without refresh
of sensitivity list; in that case the modification from clk to clk_inv
is normal (and the sensitivity list must be updated accordingly).
Now take the example and imagine the same case but with a typo error on
clk name, which is an other existing signal of the design.
If the sensitivity list is (*), I have no way to flag the typo error.
And possibly no tests fail, except perhaps in very hard to find corner
case (if both signal have similar behavior, except under very specific
cases).
After ASIC synthesis, you can have some timing problem due to not well
balanced clock tree.
Discovering error at this stage, it is very consuming of time and money;
all of this because you have don't put explicite sensitivity list, than
a linting tool, a rule-checker or the compiler can flag you in few minutes.
You have similar remark for Jim proposal, but in that case you use an
explicite structure which must be intrepreted as edge or state register.
>Tom
>
>
JaI
Tom Verbeure
> Now take the example and imagine the same case but with a typo error
on
> clk name, which is an other existing signal of the design.
> If the sensitivity list is (*), I have no way to flag the typo error.
> And possibly no tests fail, except perhaps in very hard to find
corner
> case (if both signal have similar behavior, except under very
specific
> cases).
Basically you're saying that you want to (ab?)use the sensititivity
list as a redundancy mechanism against ordinary typos.
At what point do you have to stop holding the hand of a designer and
trust that he will fix typos, run simulations to verify a design and
read the error reports of his synthesis and/or linting tool?
Say a designer writes:
a <= b;
instead of:
a <= c;
How can we protect a designer against such a potentially disastrous
typo?
Tom
Just an Illusion
I have change the subject line, because I think it is no more link with
initial message.
Tom Verbeure wrote:
>>Now take the example and imagine the same case but with a typo error
>>
>>
>on
>
>
>>clk name, which is an other existing signal of the design.
>>If the sensitivity list is (*), I have no way to flag the typo error.
>>
>>
>
>
>
>>And possibly no tests fail, except perhaps in very hard to find
>>
>>
>corner
>
>
>>case (if both signal have similar behavior, except under very
>>
>>
>specific
>
>
>>cases).
>>
>>
>
>Basically you're saying that you want to (ab?)use the sensititivity
>list as a redundancy mechanism against ordinary typos.
>
>
Not exactly, the aspect that you put into the sensitivity list are the
control part of a process.
You can have some mechanism that use content of sensitivity list to make
some check, or some assertion.
When you introduce a new element, you need extend the feature of the
language. In that case I think that is a reduction, because you can't no
more use the sensitivity list.
To me, have no sensitivity list or have (*) in sensitivity list are
equivalent.
>At what point do you have to stop holding the hand of a designer and
>trust that he will fix typos, run simulations to verify a design and
>read the error reports of his synthesis and/or linting tool?
>
>Say a designer writes:
>a <= b;
>instead of:
>a <= c;
>How can we protect a designer against such a potentially disastrous
>typo?
>
>
In that case, that is not a real typo problem, but more a logic problem.
In my example, the typo error is in the sensitivity list content.
To check your case, formal verification, simulation...
>Tom
>
>
>
JaI
Weng Tianxiang
I fully agree with Tom's ideas:
1. Never put into consideration any typos for new keywords, new ideas,
new proposals.
2. If you can recognize 3 different types of process(), software can
recognize it much faster and better than you do.
Weng
Wallclimber
> control part of a process.
> You can have some mechanism that use content of sensitivity list to make
> some check, or some assertion.
>
> When you introduce a new element, you need extend the feature of the
> language. In that case I think that is a reduction, because you can't no
> more use the sensitivity list.
> To me, have no sensitivity list or have (*) in sensitivity list are
> equivalent.
???
Where did I claim that I wanted to get rid of sensitivity lists? The
(*) notation would be an addition for those cases where it is useful
(like combinational processes...). This is no different than for
Verilog.
Tom
Jim Lewis
> ... process(*)
> is introduced by Verilog, it is a very good idea!
Ironically SystemVerilog is moving on to:
always_comb, always_latch, and always_ff
So here for once we get to copy from Verilog and
take advantage of their lessons learned.
For RTL design, the added keywords carry the intent of the
sensitivity list without making you type it. You will not
get this with "(*)".
For example, in addition to meaning "(*)" _comb indicates
the process only creates combinational logic. If you
inadvertently create latches (the #1 or #2 problem in a
statemachines), then the synthesis tool is to produce and
error and not create any hardware.
Regards,
Jim