question of style

  • Thread starter valentin tihomirov
  • Start date
V

valentin tihomirov

Guest
Below are two architectures (RTL2 and RTL3). They have idendtical behaviour.
Outputs (O1 and O2) are depending on STATE. Which architecure is more
preferrable for FPGA?

Which encoding of states is preferred for FPGAs (onehot, gray, sequential)?

Thanks.


architecture RTL2 of MF is
type STATE_TYPE is
(S0, S1, S2, S3);
signal state: STATE_TYPE;
begin

SEQUENCE : process
begin
-- wait on CLK until CLK = '1';
wait until CLK = '1';
O1 <= '0';
O2 <= '0';
if reset='1' then
STATE <= S0;
else
case STATE is
when S0 =>
O1 <= '0';
O2 <= '0';
STATE <= S1;
when S1 =>
O1 <= '0';
O2 <= '1';
STATE <= S2;
when S2 =>
O1 <= '1';
O2 <= '0';
STATE <= S3;
when S3 =>
O1 <= '1';
O2 <= '1';
STATE <= S0;
end case;
end if;
end process ;

end RTL2;





architecture RTL3 of MF is
type STATE_TYPE is
(S0, S1, S2, S3);
signal state: STATE_TYPE;
begin

COMB: process(STATE)
begin
case STATE is
when S0 =>
O1 <= '0';
O2 <= '0';
when S1 =>
O1 <= '0';
O2 <= '1';
when S2 =>
O1 <= '1';
O2 <= '0';
when S3 =>
O1 <= '1';
O2 <= '1';
end case;
end process;

SEQUENCE : process
begin
wait on CLK until CLK = '1';
-- wait until CLK = '1';

if reset='1' then
STATE <= S0;
else
case STATE is
when S0 =>
STATE <= S1;
when S1 =>
STATE <= S2;
when S2 =>
STATE <= S3;
when S3 =>
STATE <= S0;
end case;
end if;
end process ;

end RTL3;
 
valentin tihomirov wrote:

Below are two architectures (RTL2 and RTL3). They have idendtical behaviour.
Outputs (O1 and O2) are depending on STATE. Which architecure is more
preferrable for FPGA?

Which encoding of states is preferred for FPGAs (onehot, gray, sequential)?

Thanks.

architecture RTL2 of MF is
type STATE_TYPE is
(S0, S1, S2, S3);
signal state: STATE_TYPE;
begin

SEQUENCE : process
begin
-- wait on CLK until CLK = '1';
wait until CLK = '1';
O1 <= '0';
O2 <= '0';
if reset='1' then
STATE <= S0;
else
case STATE is
when S0 =
O1 <= '0';
O2 <= '0';
STATE <= S1;
when S1 =
O1 <= '0';
O2 <= '1';
STATE <= S2;
when S2 =
O1 <= '1';
O2 <= '0';
STATE <= S3;
when S3 =
O1 <= '1';
O2 <= '1';
STATE <= S0;
end case;
end if;
end process ;

end RTL2;

architecture RTL3 of MF is
type STATE_TYPE is
(S0, S1, S2, S3);
signal state: STATE_TYPE;
begin

COMB: process(STATE)
begin
case STATE is
when S0 =
O1 <= '0';
O2 <= '0';
when S1 =
O1 <= '0';
O2 <= '1';
when S2 =
O1 <= '1';
O2 <= '0';
when S3 =
O1 <= '1';
O2 <= '1';
end case;
end process;

SEQUENCE : process
begin
wait on CLK until CLK = '1';
-- wait until CLK = '1';

if reset='1' then
STATE <= S0;
else
case STATE is
when S0 =
STATE <= S1;
when S1 =
STATE <= S2;
when S2 =
STATE <= S3;
when S3 =
STATE <= S0;
end case;
end if;
end process ;

end RTL3;
Click to expand...
Dear Valentin

from the logic point of view they are equivalent.
But the RTL2 is preferrable
because it provides more higher speed and reusability.
It needs more FFs but FPGA usually contains enough of them.

Regards,

A.Ser.
 
from the logic point of view they are equivalent.
But the RTL2 is preferrable
because it provides more higher speed and reusability.
It needs more FFs but FPGA usually contains enough of them.
Click to expand...
Hmm. RTL2 has the same structure as RTL3 but with extra FFs on O1, O2
outputs. How can extra FFs at outputs make design
- faster;
- smaller.
???

IMHO, the thinghs should be vise versa. The fact that a design with
registered outputs is faster comes from my experiense. I could not fit one
design into CPLD but succeeded after FFs were added.
 
Shouldn't additional FFs at outputs infer additional one-cycle delay?
 
Hello,

"valentin tihomirov" <valentin_NOSPAM_NOWORMS@abelectron.com> wrote:
Hmm. RTL2 has the same structure as RTL3 but with extra FFs on O1, O2
outputs. How can extra FFs at outputs make design
- faster;
- smaller.
???

IMHO, the thinghs should be vise versa. The fact that a design with
registered outputs is faster comes from my experiense. I could not fit one
design into CPLD but succeeded after FFs were added.
Click to expand...
There are two criterias for faster:
- less cycles per operation
- faster cycles

Infering additional FF could reduces the longest path and lead to more
cycles per timebase. In some cases additional FF could reduce the
buffering for signals with high fanout. This may bring a smaller and
faster design.
And if you introduce pipelining, you could need more cycles for a
single operation, but get a better cycle/op ratio for the whole design
(Latency vs Throughput).

Just a few ideas why additional FF _could_ lead to faster and smaller
designs.

bye Thomas
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top