question of style

  • Thread starter valentin tihomirov
  • Start date
V

valentin tihomirov

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;
 
V

Vladislav Vasilenko

valentin said:
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.
 
V

valentin tihomirov

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

Thomas Stanka

Hello,

valentin tihomirov said:
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top