I hate VHDL!!!

Weng,
How about an example of orif?

I have already spoken my peace on exclusive.

Regards,
Jim

Jim,

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
Click to expand...
 
Jim,
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%
 
Jim,
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
 
Weng,
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'?
Click to expand...
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.
Click to expand...
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:Jim@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/

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
Weng,

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.
Click to expand...
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
 
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.
Click to expand...
My advice is, if C/C++ has been using them, not to invent new wheels
for it.


For now, why not use CPP?
Click to expand...
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
 
Weng,
Here is another point your committee should pay attention to:
sensitivity list!

Why don't you propose to change it?
Click to expand...
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
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

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

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
Click to expand...
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
Click to expand...
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

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)


Do you know that you can some useful editor that can help you to write
Click to expand...
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
Click to expand...
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
Click to expand...
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
Click to expand...
 
Modify process_statement definition in clause 9.2 to:
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
 
JaI,
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'
Click to expand...
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
 
Hi Weng,

Weng Tianxiang wrote:

JaI,


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.


I don't know history of sensitivity list, but usage of (*) as sensitive
Click to expand...
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
Click to expand...
 
Hi Weng,

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*
Click to expand...
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
Click to expand...
 
Hi Weng Tianxiang,

don't you think that it is sufficient now?

It is time for your subject name to "disappear" ,o)

Kind regards
 
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.
Click to expand...
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
 
Hi Wallclimber,

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:
Click to expand...
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
Click to expand...
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
Click to expand...
 
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).
Click to expand...
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
 
Hi,

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
Click to expand...
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.
Click to expand...
In my example, the typo error is in the sensitivity list content.

To check your case, formal verification, simulation...

Tom



JaI
Click to expand...
 
Jim,
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
 
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.
Click to expand...
???

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
 
Weng,
... process(*)
is introduced by Verilog, it is a very good idea!
Click to expand...
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


Modify process_statement definition in clause 9.2 to:
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
Click to expand...

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

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top