«

As Jim said,

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

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


Weng Tianxiang wrote:

>OK, at last Jim and JaI admit my equation is right.
><snip>
>
>>process (DIMMNumberClear, nC_BE_R0, n, bad_pci_type)
>>begin
>> if (DIMMNumberClear) then
>> DIMMNumber(4 downto 0) <= (others=>'0');
>> elsif (bad_pci_type = '0') then
>> if (AD_R0(28+n*32) = '1') then
>> DIMMNumber (4 downto 0) <= "10000";
>> else
>> DIMMNumber (4 downto 0) <= AD_R0(28+n*32 downto 24+n*32);
>> endif;
>> endif;
>>end process;
>>
>>
>
>Above equations are wrong. n must be a constant to let compiler to
>work. It is an compiler error. If n is a dynamic signal like in my
>case, you must use n as in a condition for 'if' statement. If you
>don't believe, try to compile it using any VHDL compiler.
>
>
I have demand you if pci type (32-b and 64-b) can be dynamically change,
you haven't answer.
So I give you an example where n is constant.

Reread my question.

Don't keep only some out of context part.

>Second segment of equations is right. Thank you, JaI!!! It clearly
>demonstrates how hard from current VHDL structure to get both right
>and efficient code.
>
Sorry I don't understand which second segment.

>You must rewrite total code to get efficient
>code!!!
>
If the coder have badly write his first code version, don't blam the
language.
You have the same problem with any programming language.

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

>It is a big problem when you have a big project. It is real,
>not virtual. That is why 'I hate VHDL': it is like you bought a set of
>sockets to start your business and found that 3/8" socket wasn't there
>and the manufacturers say it is your problem, you can deal with it
>using 1/2", why do we need to manufacture a 3/8" socket especially for
>your purpose?!
>
Sorry, I don't understand your joke about socket.
Propose to your manufacturer to multiply your buying price by ten, and
see it's answer.

>
>That is why 'orif' is so useful in the situation: first you write
>correct code, then change 'elsif' to 'orif', you get your most
>efficient code without any other code and structure change.
>
>
I am not convinced.
Lot of exclusive section are implementation dependant; if you want
design a reusable module, then you can do these types of assertions.
Otherwise you have a _critical_ risk in your design.

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

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

c <=a and b;

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

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

Take following pseudo-examples:

ExampleA:
c <= a and b;

d <= e and f;

g <= c and d;


and:

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

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


JaI

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.

Tell me what kind of double access ram working in a way a read and a
write access happen simultaneously.

Weng

Hi Weng,

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

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

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

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 2 &
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 2 &
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 2 & 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 2 & 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'?

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 private.php?do=newpm&u=
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/

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~