«

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;

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.

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" <> 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.

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