Quartus II infered latches

[Mike Treseler]

rickman wrote:

But LUT usage is what this is about.

I understand that.
My point was that these LUTs are pennies in my pocket.

But of course, this depends on the logic being coded.

Exactly.

I like to break down large state enumerations
into a smaller state register and a separate
counter or shifter register, for example.
This sometimes allows high-level simplifications
that might not be obvious otherwise.

The argument that '0' is a better choice than '1'
would have to be one of style.
For a 4 bit decode on a FPGA, a sum of products in not needed.

Yes, but this is potentially just a part of an output specification.
Otherwise why bother even thinking about it.

I like to keep my output and state registers separate.
But this would be another thread,
and I think we've done it before

-- Mike Treseler

 

[jacko]

On 14 Aug, 14:35, Andy <jonesa...@comcast.net> wrote:

On Aug 13, 11:32 pm, rickman <gnu...@gmail.com> wrote:





On Aug 13, 6:37 pm, Mike Treseler <mtrese...@gmail.com> wrote:
If the values were internal states
rather than a public address, I would use an enumeration
and let synthesis pack the gates.

I have seen some really poor implementations for state machines.  I
prefer to use one-hot encoding and manually specify the transitions.
Then I *know* the logic is fairly optimal.  BTW, when using one-hot
encoding, the transitions between states map to the bits used to
specify the states.  So you can create a signal for each state and
specify all of the input transitions for that state and *not* the
output transitions.

process (clk, reset) begin
if (reset = '1') then
  foo <= '0';
  bar <= '0';
  ralph <= '0';
  applesauce <= '0';
elsif (rising_edge(clk)) then
  foo <= (bar and input1) or
    (ralph and input2) or
    (applesauce and (input3 or input4)) or
    (foo and not (input5 or input6 or input7));

  bar <= (foo and input5) or
    (bar and not (input6 or input7));

  etc...

end if;
end process;

I too have seen some really poor state machine implementations/
optimizations, but if they meet resource and timing requirements, I'd
rather write/read/maintain functionally clear, inefficiently
implemented code than functionally cryptic, efficiently implemented
code.

The code style above (individual signals for one hot states) leads to
unintentional zero- or multiple-hot states that you can't easily see.
I've been there before (that's how I used to implement state machines
in FPGA schematics a LONG time ago), and I don't want to go there
again, unless performance and/or resources absolutely dictate it.
Traditional state machine descriptions can similarly lead to
unreachable states, but at least the synthesis tool will warn you
about them.

Andy- Hide quoted text -

- Show quoted text -

Quartus does a one hot but not on the thing I expected it to. The
zeros in question are an output specification, as there is no need for
output if the processor is performing a read. Yes an output don't care
best would be good.

cheers
jacko

 

[Mike Treseler]

jacko wrote:

Now if only I could get the state machine processing to recognize the
full state machine one hot wanted of (cycle.indirect.dir) and have it
eliminate never entered hot states out of the 80, maybe things would
get even smaller.

I'll bet you a beer that things
would get even smaller if you changed
your state register to an type enumeration
and let synthesis work out the details.

Last I checked, quartus and ise
use one-hot encoding for vectors
wider than two bits. The point is
that the tool takes care of the fussy
decoding details you mention and always
gets it right.

-- Mike Treseler

 

[jacko]

On 14 Aug, 16:44, Mike Treseler <mtrese...@gmail.com> wrote:

rickman wrote:
But LUT usage is what this is about.

I understand that.
My point was that these LUTs are pennies in my pocket.

All pennies in on pocket are not in another ...

But of course, this depends on the logic being coded.

Exactly.

I like to break down large state enumerations
into a smaller state register and a separate
counter or shifter register, for example.
This sometimes allows high-level simplifications
that might not be obvious otherwise.

Yes I have now split the indirect and direct assignments into
different enumerations, and eliminated most of the don't cares needed.
Two remain. Exact combination of two differing of q, r, s, and c is
unknown. But any two better than zeros.

Now if only I could get the state machine processing to recognize the
full state machine one hot wanted of (cycle.indirect.dir) and have it
eliminate never entered hot states out of the 80, maybe things would
get even smaller.

cheers
jacko

 

[jacko]

On 14 Aug, 18:23, Mike Treseler <mtrese...@gmail.com> wrote:

jacko wrote:
Now if only I could get the state machine processing to recognize the
full state machine one hot wanted of (cycle.indirect.dir) and have it
eliminate never entered hot states out of the 80, maybe things would
get even smaller.

I'll bet you a beer that things
would get even smaller if you changed
your state register to an type enumeration
and let synthesis work out the details.

Last I checked, quartus and ise
use one-hot encoding for vectors
wider than two bits. The point is
that the tool takes care of the fussy
decoding details you mention and always
gets it right.

        -- Mike Treseler

At present these are my enumerations

-- Build an enumerated type for the state machine
type cycle_type is (fetch, execute);

-- Indirection selector
type reg_seli is (indp, indq, indr, inds, indqq);
-- Direct selector
type reg_seld is (dirp, dirq, dirr, dirs, dirc, dirno, dircq, dirad);
type mem_op is (rd, wr);

only reg_seli is used by quartus on state machine automatic. It does
not combine as a total state machine and reduce. a reg_seli is used
first in code sequence, so I assume this is why it is picked.

cheers
jacko

 

[jacko]

Hi

Now at 332 LEs, by changing how the conditional read was done in the
GO test. I don't have anymore ideas how to lower this. Looks like
version 11 is the one. If the maths adds up, not using the read
register and full width memory access makes this reduce to arround 250
LEs. The design is done. Forward onto the IO and useful functioning of
the rest of the MAX II

cheers
jacko