about "Advanced Synthesis Techniques"

[burn.sir]

Hello group!

I just read "Advanced Synthesis Techniques" by Ian Lanq after
recommendation on this newsgroup.

With all respect to Ian, I have hard time understanding why this
article is so intreseting. I find some recommendations questuinable at
best. Also, some VHDL and verilog code seem to be a little odd. For
example, is the following code really valid VHDL (in the sense that it
will produce correct results during simulation AND synthesis)??

process (clock, reset_N)
begin

if reset_N = '0' then
TxWritten <= '0';
else

if clearTxWritten = '1' then
TxWritten <= '0';

elsif write = '1' and address = c_TX then
Tx <= writeData;
TxWritten <= '1';
end if;

end if;

end process;


It would be great to hear what you guys think about this.

- Burns

 

[ALuPin]

For

example, is the following code really valid VHDL (in the sense that it
will produce correct results during simulation AND synthesis)??

process (clock, reset_N)
begin

if reset_N = '0' then
TxWritten <= '0';
else

if clearTxWritten = '1' then
TxWritten <= '0';

elsif write = '1' and address = c_TX then
Tx <= writeData;
TxWritten <= '1';
end if;

end if;

end process;

I wonder where the registering with the clock has hidden ?
Or did you not copy it as it is in original?

It should be something like

IF reset_N='0' THEN
...
ELSIF rising_edge(clock) THEN
...
END IF;

or

IF rising_edge(clock) THEN
IF reset_n='0' THEN

ELSE

END IF;
END IF;

Rgds
André

 

[Mike Treseler]

I just read "Advanced Synthesis Techniques" by Ian Lanq after
recommendation on this newsgroup.
With all respect to Ian, I have hard time understanding why this
article is so intreseting.

In the referenced article:
http://www.designabstraction.co.uk/Articles/Advanced Synthesis Techniques.htm

Ian compares two code examples,
DUFF.vhd and RTL.vhd.

The one you quote is DUFF.vhd is his "badly coded UART".
The other RTL.vhd is the style he advocates.
Consider rereading the article and reserve judgment
until you have read both versions.

I have compiled simed and synthesized both
versions and they both work fine. Ian's point
is that while the common Process-per-Register style
can be made to work, His style (RTL.vhd) is easier to write
and read.

-- Mike Treseler

 

[burn.sir]

In the referenced article:
http://www.designabstraction.co.uk/Articles/Advanced Synthesis Te...

Ian compares two code examples,
DUFF.vhd and RTL.vhd.

The one you quote is DUFF.vhd is his "badly coded UART".
The other RTL.vhd is the style he advocates.
Consider rereading the article and reserve judgment
until you have read both versions.

No, Ian talks about bad style. Both files should contain valid VHDL and
should work correctly. But this is not valid VHDL. He cannot compare
the size of these designs if one is invalid.

I have compiled simed and synthesized both
versions and they both work fine. Ian's point

NO!

This is a blind "translation" from Verilog to VHDL. where is clock edge
detection?? And is it registered on positive or negative edge?

process (clock, reset_N)
begin
if reset_N = '0' then
TxWritten <= '0';
else
if clearTxWritten = '1' then
TxWritten <= '0';
elsif write = '1' and address = c_TX then
Tx <= writeData;
TxWritten <= '1';
end if;
end if;
end process;



He does the same mistake at multiple location in
http://www.designabstraction.co.uk/Articles/Common HDL Errors.PDF

both in Verilog and VHDL (again, some code may be labelled "bad
practice". but they are still functionally correct according to Ian)

is that while the common Process-per-Register style
can be made to work, His style (RTL.vhd) is easier to write
and read.

On this particular subject, i agree with him 110% on this. BUT...


The reason i brought this up was because i read this articles and at
some location my first reaction was "hey, what is he talking about?? is
this really correct?". Then i looked at the code and some stuff looked
rather fishy. For example, there is a second problem with the code
above that may lead to larger design on some architectures. I leave
that one to you as an exercise.

- burns


PS. again, no disrespect to Ian. In fact, he does make the point that
the snippets that are labelled "bad code" are harder to get right which
this discussion probably shows.

 

[Mike Treseler]

process (clock, reset_N)
begin
if reset_N = '0' then
TxWritten <= '0';
else
if clearTxWritten = '1' then
TxWritten <= '0';
elsif write = '1' and address = c_TX then
Tx <= writeData;
TxWritten <= '1';
end if;
end if;
end process;

Sorry. I agree, this is probably a typo.
The fix is

-- else
elsif clock'event and clock='1' then

I missed it (and maybe Ian did too)
because it happens to run my
testbench fine hitting both edges as it does.

I also found a range error this time around
that must have passed on an older modelsim version.

-- TxBitCount: integer range 0 to 8;
TxBitCount: integer range 0 to 9;

PS. again, no disrespect to Ian. In fact, he does make the point that
the snippets that are labelled "bad code" are harder to get right which
this discussion probably shows.

I agree. The main thing I got from Ian's articles is
the idea that you can describe as many registers
as you like in a single process.
The idea I added while editing this design
was that no signal declarations are actually needed in
a single process entity, and that procedures can
be used to match any design to a fixed template.

-- Mike Treseler

____________________________
# vsim -do {run -all} -c test_duff
# // ModelSim SE 6.1c Nov 17 2005 Linux 2.6.5-7.201-smp
# Loading /flip/usr1/modeltech/linux/../std.standard
# Loading /flip/usr1/modeltech/linux/../ieee.std_logic_1164(body)
# Loading /flip/usr1/modeltech/linux/../ieee.numeric_std(body)
# Loading /flip/usr1/modeltech/linux/../ieee.std_logic_arith(body)
# Loading /flip/usr1/modeltech/linux/../ieee.std_logic_unsigned(body)
# Loading work.test_duff(sim)
# Loading work.uart_vhdl(duff)
# run -all
# ** Note: Saw reset rise and fall OK
# ** Note: ___Step 0
# ** Note: ____________ saw 72 as expected
# ** Note: ___Step 1
# ** Note: ____________ saw 66 as expected
# ** Note: ___Step 2
# ** Note: ____________ saw 229 as expected
# ** Note: ___Step 3
# ** Note: ____________ saw 137 as expected
# ** Note: ___Step 4
# ** Note: ____________ saw 106 as expected
# ** Note: ___Step 5
# ** Note: ____________ saw 126 as expected
# ** Note: ___Step 6
# ** Note: ____________ saw 48 as expected
# ** Note: ___Step 7
# ** Note: ____________ saw 239 as expected
# ** Note: ___Step 8
# ** Note: ____________ saw 46 as expected
# ** Note: ___Step 9
# ** Note: ____________ saw 6 as expected
# ** Note: ___Step 10
# ** Note: ____________ saw 157 as expected
# ** Note: ___Step 11
# ** Note: ____________ saw 36 as expected
# ** Note: ___Step 12
# ** Note: ____________ saw 161 as expected
# ** Note: ___Step 13
# ** Note: ____________ saw 241 as expected
# ** Note: ___Step 14
# ** Note: ____________ saw 199 as expected
# ** Note: ___Step 15
# ** Note: ____________ saw 181 as expected
# ** Note: ___Step 16
# ** Note: ____________ saw 191 as expected
# ** Note: ___Step 17
# ** Note: ____________ saw 92 as expected
# ** Note: ___Step 18
# ** Note: ____________ saw 46 as expected
# ** Note: ___Step 19
# ** Note: ____________ saw 151 as expected
# ** Note: ___Step 20
# ** Note: ____________ saw 72 as expected
# ** Note: ___Step 21
# ** Note: ____________ saw 36 as expected
# ** Note: ___Step 22
# ** Note: ____________ saw 18 as expected
# ** Note: ___Step 23
# ** Note: ____________ saw 137 as expected
# ** Note: ___Step 24
# ** Note: ____________ saw 199 as expected
# ** Note: ___Step 25
# ** Note: ____________ saw 96 as expected
# ** Note: ___Step 26
# ** Note: ____________ saw 48 as expected
# ** Note: ___Step 27
# ** Note: ____________ saw 24 as expected
# ** Note: ___Step 28
# ** Note: ____________ saw 12 as expected
# ** Note: ___Step 29
# ** Note: ____________ saw 6 as expected
# ** Note: ___Step 30
# ** Note: ____________ saw 131 as expected
# ** Note: ___Step 31
# ** Note: ____________ saw 66 as expected
# ** Note: ___ALL PASS___
VSIM 2>