Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Re: I hate VHDL!!!

Reply
Thread Tools

Re: I hate VHDL!!!

 
 
Tom Verbeure
Guest
Posts: n/a
 
      07-19-2004
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.


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

 
Reply With Quote
 
 
 
 
Weng Tianxiang
Guest
Posts: n/a
 
      07-21-2004
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.


>> 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
 
Reply With Quote
 
 
 
 
Jim Lewis
Guest
Posts: n/a
 
      07-25-2004
Weng,
> Here is another point your committee should pay attention to:
> sensitivity list!
>
> Why don't you propose to change it?


Already did. See the fast track proposals at:
http://www.eda.org/vhdl-200x/vhdl-20...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 (E-Mail Removed)
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~
 
Reply With Quote
 
Just an Illusion
Guest
Posts: n/a
 
      07-26-2004
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
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>
>
>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
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 199.

>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

 
Reply With Quote
 
Weng Tianxiang
Guest
Posts: n/a
 
      07-26-2004
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
 
Reply With Quote
 
Weng Tianxiang
Guest
Posts: n/a
 
      07-26-2004
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.

Weng
 
Reply With Quote
 
Just an Illusion
Guest
Posts: n/a
 
      07-27-2004
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
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

 
Reply With Quote
 
Just an Illusion
Guest
Posts: n/a
 
      07-27-2004
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*
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

 
Reply With Quote
 
ALuPin
Guest
Posts: n/a
 
      07-27-2004
Hi Weng Tianxiang,

don't you think that it is sufficient now?

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

Kind regards
 
Reply With Quote
 
Wallclimber
Guest
Posts: n/a
 
      07-27-2004
> 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'.

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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
D-Link DSL 504T - I hate my router - No, I really really hate it!!! Simon Harding Computer Support 7 01-03-2006 09:11 PM
Oh How I hate Change... ..brian.. Firefox 8 03-05-2005 11:19 PM
Thunderbird - OK., I know that you will hate this BT Firefox 5 03-05-2005 05:26 PM
The thing I hate about FF and TB Tony Raven Firefox 7 12-13-2004 02:32 AM
I begining to Hate WI-FI! Veritech Wireless Networking 2 08-24-2004 03:37 AM



Advertisments