Quartus II infered latches

J

jacko

Guest
Hi

got rid of some by putting best selection as don't care, as quartus
doesn't like 'X' for some reason or didn't in version 6.1 (last
checked). That was understandable.

The bit I don't get yet is why a coinational process, with just one
register in the sensitivity list (IR) process is instruction decode
from insrtuction register, inferes latches on intermediate signals,
when there latched contents have no relevance. The intermediates
should always be recalculated.

Is it because only some paths through the process do not assign to
them? As I thought this was only relevant to synchronous behaviour.

Hiving the ALU off into a different process (combinatorial) should ix
this if I postulate correctly, butis this the reason?

cheers
jacko
 
On 9 Aug, 16:24, "KJ" <kkjenni...@sbcglobal.net> wrote:
"jacko" <jackokr...@gmail.com> wrote in message

news:8837cbe8-b3fd-4a25-9cc6-a474556616c5@v57g2000hse.googlegroups.com...



The bit I don't get yet is why a coinational process, with just one
register in the sensitivity list (IR) process is instruction decode
from insrtuction register, inferes latches on intermediate signals,
when there latched contents have no relevance. The intermediates
should always be recalculated.

Post some example so we don't have to guess endlessly about what you're
talking about when you toss around things like
* 'intermediate' signals (as opposed to what? an 'immediate' signal?  There
is no such distinction, so why are you making one?)
* latched contents have no relevance....does that mean you write
non-relevant code?  Maybe you shouldn't do that
Click to expand...
a<=b;
c<=d;
e<=a*c;

--a and c are intrmediate calculations.

Is it because only some paths through the process do not assign to
them? As I thought this was only relevant to synchronous behaviour.

One can only speculate based on your cloudy description.

You will get a latch any time that you have a possible path through your
logic that does not assign to each and every output of that process...end of
story...simple example
Click to expand...
thought so, so i must make a seperate process. ok.

The following example will not produce a latch.

No_Latch : process(abc)
begin
  a <= '0';
  if (abc = '1') then
    a<= '1';
 end if
end process No_Latch;

The following example will produce a latch.

Yes_Latch : process(abc)
begin
  -- a <= '0';
  if (abc = '1') then
    a<= '1';
 end if
end process Yes_Latch;

Post some useful code and results with a specific question next time.

KJ
Click to expand...
vhdl at http://nibz.googlecode.com in downloads section file has to be
renamed as entity called nibz1. It compiles in quartus with many
warnings about latches implied, and complains of process sensitivity
list ommissions.

cheers
jacko
 
On 9 Aug, 21:09, "KJ" <kkjenni...@sbcglobal.net> wrote:
"KJ" <kkjenni...@sbcglobal.net> wrote in message

news:6lmnk.32983$co7.4027@nlpi066.nbdc.sbc.com...



"jacko" <jackokr...@gmail.com> wrote in message
news:9aaec06e-9ac0-4228-8474-fc95cb6380d7@d77g2000hsb.googlegroups.com...
On 9 Aug, 16:24, "KJ" <kkjenni...@sbcglobal.net> wrote:
"jacko" <jackokr...@gmail.com> wrote in message

news:8837cbe8-b3fd-4a25-9cc6-a474556616c5@v57g2000hse.googlegroups.com...

You won't get warnings about latches from the above code, so if you want
some help on that topic, you'll have to post some code demonstrating what
code Quartus is actually flagging...I'm too lazy to download your code
from the web site, run it through Quartus, etc.

Actually, I take that back you can get latches from the code...again, like I
said with the first post, put a snip of your real code and the real warning
about which signal(s) are becoming latches....it's rather pointless to be
guessing about what the problem is with your code when you don't put up a
complete snippet of the problem.

KJ
Click to expand...
got rid ofthem all!! huraah!!

Now themain thing is as i implemented the alu by explicit xor and and,
I am wondering how o indicate to the synthesizer that a signal should
be fed through fast carry logic. the synth has distributed the alu all
over. knoking fmax to 25MHzor lower. Sythesis is good at 301 LEs
though. It will drop slightly when I have removed redundant never
entered states from the state machine.

Any idea how to indicate special carry property in vhdl?

cheers
jacko
 
On 10 Aug, 01:02, "KJ" <kkjenni...@sbcglobal.net> wrote:
"jacko" <jackokr...@gmail.com> wrote in message

news:9aac6166-78db-45b7-9220-dffaa0570f4d@r66g2000hsg.googlegroups.com...

On 9 Aug, 21:09, "KJ" <kkjenni...@sbcglobal.net> wrote:
"KJ" <kkjenni...@sbcglobal.net> wrote in message

news:6lmnk.32983$co7.4027@nlpi066.nbdc.sbc.com...

Now themain thing is as i implemented the alu by explicit xor and and,
I am wondering how o indicate to the synthesizer that a signal should
be fed through fast carry logic.

Synthesis implements the source code that you wrote.  If you write stuff
where some 'fast carry logic' can be used it will be, if not, it can't.
Writing your source code as you've done using explicit 'xor' and 'and' will
probably never end up using anything fancy.  By writing it in that fashion,
you're doing most of the synthesis work of going from a 'high level'
description into a 'low level' description.  By doing this you've likely cut
yourself out of any good tricks that synthesis tools could have done for you
with a more reasonable description.  Given a collection of 'xor' and 'and'
equations, just what do you think even could be done with carry logic?

the synth has distributed the alu all
over. knoking fmax to 25MHzor lower.

Synthesis mostly puts things where they are needed in order to communicate
with whatever it is that feeds them.  People get it in their head that
something 'should be' all together and mostly they're wrong....they
completely neglect the fact that that something needs to gets its input from
something and the result need to go somewhere else, no logic is an
island...islands get optimized away because no device outputs depend on
their results.



Any idea how to indicate special carry property in vhdl?

By using arithmetic operators and letting synthesis do some of the work and
stop thinking you can do better.

KJ
Click to expand...
An example would be better. MAX II device, has interlogic connecion
for carry signals, is just like any other but no main routing delay,
it goes direct to next logic element. These are not used. The synth
has no problem detecting the chain, but does not fit the chain with
quick routing. There appears to be a CARRY primitive in the altera
library, which identifies a signal as a carry, I just wondered why a
system which detects the carry chain as a chain does not route the
chain as the critical path. Apart from the chain affecting sumation
and the true test, the rest of the logic will run much faster.

Strange.

cheers
jacko
 
jacko wrote:

An example would be better. MAX II device, has interlogic connecion
for carry signals, is just like any other but no main routing delay,
it goes direct to next logic element. These are not used.
Click to expand...
There are two ways to use it.
1. '+' function
2. a direct instance.

Here is an example using '+'

source:
http://mysite.verizon.net/miketreseler/count_enable.vhd
rtl view:
http://mysite.verizon.net/miketreseler/count_enable.pdf
carry chain:
http://mysite.verizon.net/miketreseler/count_enable_map.pdf

-- Mike Treseler
 
On 10 Aug, 16:37, Mike Treseler <mtrese...@gmail.com> wrote:
jacko wrote:
An example would be better. MAX II device, has interlogic connecion
for carry signals, is just like any other but no main routing delay,
it goes direct to next logic element. These are not used.

There are two ways to use it.
1. '+' function
2. a direct instance.

Here is an example using '+'

source:http://mysite.verizon.net/miketreseler/count_enable.vhd
rtl view:http://mysite.verizon.net/miketreseler/count_enable.pdf
carry chain:http://mysite.verizon.net/miketreseler/count_enable_map.pdf

          -- Mike Treseler
Click to expand...
Yes the tiny problem with the CARRY_SUM primitive is the use of only
two inputs. In a 4 LUT environment two control selects (4-opcodes) ca
be absorbed into the first row of carry sum in an adder, and assuming
carry chain on second row of carry sum (1 extra decode function can be
input to the 4 LUT. This can give a minimal area 4 function ALU,
without post carry sum multiplexing. The minimal area thing is
important for a 23% of MAX II 1270 processor. (16 BIT, 5 regs (2
working regs), 2 stacks + Program Counter, 16/32 BIT ALU).

Which makes me wonder if carry sum can absorb other logic into the 4
LUT and still maintain the carry chain. Previous implementations of
the ALU suggest otherwise, and suffer similar delay but that time due
to multiple levels of adders and multiplex used. This is what leads me
to believe the fast carry chain is not being used to effect chain
propergation reduction.

I feel this feature should be added by altera as it could boost fmax
of many designs not featuring carry sum primitives, just convoluted
critical paths.

It has been most educational
http://nibz.googlecode.com
 
On 10 Aug, 23:00, "KJ" <kkjenni...@sbcglobal.net> wrote:
"jacko" <jackokr...@gmail.com> wrote in message

news:43a279d5-60c0-4a7d-9fab-d90132d279c7@m73g2000hsh.googlegroups.com...
On 10 Aug, 16:37, Mike Treseler <mtrese...@gmail.com> wrote:

I feel this feature should be added by altera as it could boost fmax
of many designs not featuring carry sum primitives, just convoluted
critical paths.

Then perhaps suggest this to Altera with examples that actually demonstrate
your claimed performance difference on final routed designs via their 'My
Support' channel.

KJ
Click to expand...
ok
 
jacko wrote:

....
Which makes me wonder if carry sum can absorb other logic into the 4
LUT and still maintain the carry chain.
Click to expand...
It might have made sense to take on quartus 1.0
in a gate packing contest, but I don't think
it is any more. I get the best value per hour
by writing portable code that I can read
now and a year from now.

-- Mike Treseler
 
On Aug 9, 10:12 am, jacko <jackokr...@gmail.com> wrote:
Hi

got rid of some by putting best selection as don't care, as quartus
doesn't like 'X' for some reason or didn't in version 6.1 (last
checked). That was understandable.

The bit I don't get yet is why a coinational process, with just one
register in the sensitivity list (IR) process is instruction decode
from insrtuction register, inferes latches on intermediate signals,
when there latched contents have no relevance. The intermediates
should always be recalculated.

Is it because only some paths through the process do not assign to
them? As I thought this was only relevant to synchronous behaviour.

Hiving the ALU off into a different process (combinatorial) should ix
this if I postulate correctly, butis this the reason?
Click to expand...
The generation of latches has nothing to do with the structure of your
code. It has *only* to do with incompletely specified, synthesizable,
combinatorial logic. It does not matter what you put in the
sensitivity list, it does not matter what intermediate signals or any
of the things you mention.

Let me put it this way. If there are three inputs to the logic for a
given signal and you specify the output for 7 combinations of the
inputs, what would you like for the output if the eighth combination
of inputs occurs? Even if this combination is not possible, the tool
has no way of knowing that. The tool, by definition in the language,
will maintain the previous state of the output which requires the
generation of a latch.

Typically a tool will warn you of incomplete specifications in a case
statement or a selected signal assignment statement. I'm not sure of
the conditional assignment statement and I know that an IF statement
will not give any warnings about incomplete specifications of
outputs.

Is that clear?

Rick
 
On 12 Aug, 04:31, rickman <gnu...@gmail.com> wrote:
On Aug 9, 10:12 am, jacko <jackokr...@gmail.com> wrote:





Hi

got rid of some by putting best selection as don't care, as quartus
doesn't like 'X' for some reason or didn't in version 6.1 (last
checked). That was understandable.

The bit I don't get yet is why a coinational process, with just one
register in the sensitivity list (IR) process is instruction decode
from insrtuction register, inferes latches on intermediate signals,
when there latched contents have no relevance. The intermediates
should always be recalculated.

Is it because only some paths through the process do not assign to
them? As I thought this was only relevant to synchronous behaviour.

Hiving the ALU off into a different process (combinatorial) should ix
this if I postulate correctly, butis this the reason?

The generation of latches has nothing to do with the structure of your
code.  It has *only* to do with incompletely specified, synthesizable,
combinatorial logic.  It does not matter what you put in the
sensitivity list, it does not matter what intermediate signals or any
of the things you mention.

Let me put it this way.  If there are three inputs to the logic for a
given signal and you specify the output for 7 combinations of the
inputs,  what would you like for the output if the eighth combination
of inputs occurs?  Even if this combination is not possible, the tool
has no way of knowing that.  The tool, by definition in the language,
will maintain the previous state of the output which requires the
generation of a latch.

Typically a tool will warn you of incomplete specifications in a case
statement or a selected signal assignment statement.  I'm not sure of
the conditional assignment statement and I know that an IF statement
will not give any warnings about incomplete specifications of
outputs.

Is that clear?

Rick- Hide quoted text -

- Show quoted text -
Click to expand...
yep. the if did give warning about comparing inequal lengths which was
useful. I am a bit sad about 'X' not being a valid assignment. I tried
placing use balanced, or logically similar don't cares, in the hope
that an effective logic reduction would happen. My alu is now a
seperate process.

cheers
jacko
 
On 11 Aug, 18:16, Mike Treseler <mtrese...@gmail.com> wrote:
jacko wrote:

...

Which makes me wonder if carry sum can absorb other logic into the 4
LUT and still maintain the carry chain.

It might have made sense to take on quartus 1.0
in a gate packing contest, but I don't think
it is any more. I get the best value per hour
by writing portable code that I can read
now and a year from now.

         -- Mike Treseler
Click to expand...
I'm not complaining about the packing, it does a fine job. With
further testing and wrapping the carry in CARRY primitives, it has
proved that 29 of 32 CARRY_SUM primitives were ignored, and the size
went up about 20LEs and the speed dropped to 13MHz. Wierd!

The chain is definatly detected. I was just wondering why there is
less inputs allowed on a chained LE. A replacement of input or output
by fast chain signal is understandable, but I don't get the 3 input
limit (one of them being a chain itself).

I am now looking to make it have a speed/area generic.

cheers
jacko
 
On Aug 12, 7:49 am, jacko <jackokr...@gmail.com> wrote:
On 11 Aug, 18:16, Mike Treseler <mtrese...@gmail.com> wrote:

I'm not complaining about the packing, it does a fine job. With
further testing and wrapping the carry in CARRY primitives, it has
proved that 29 of 32 CARRY_SUM primitives were ignored, and the size
went up about 20LEs and the speed dropped to 13MHz. Wierd!

The chain is definatly detected. I was just wondering why there is
less inputs allowed on a chained LE. A replacement of input or output
by fast chain signal is understandable, but I don't get the 3 input
limit (one of them being a chain itself).
Click to expand...
The Altera devices I have used (ACEX 1K) are limited to 3 inputs when
used in adders because they split the LUT into one 3-LUT for the sum
and another 3-LUT for the carry. This could either be because they
want to save some of the area used by the carry chain, or because the
carry chain is patented. I expect it is the latter.

Rick
 
On Aug 12, 7:38 am, jacko <jackokr...@gmail.com> wrote:
On 12 Aug, 04:31, rickman <gnu...@gmail.com> wrote:



On Aug 9, 10:12 am, jacko <jackokr...@gmail.com> wrote:

Hi

got rid of some by putting best selection as don't care, as quartus
doesn't like 'X' for some reason or didn't in version 6.1 (last
checked). That was understandable.

The bit I don't get yet is why a coinational process, with just one
register in the sensitivity list (IR) process is instruction decode
from insrtuction register, inferes latches on intermediate signals,
when there latched contents have no relevance. The intermediates
should always be recalculated.

Is it because only some paths through the process do not assign to
them? As I thought this was only relevant to synchronous behaviour.

Hiving the ALU off into a different process (combinatorial) should ix
this if I postulate correctly, butis this the reason?

The generation of latches has nothing to do with the structure of your
code. It has *only* to do with incompletely specified, synthesizable,
combinatorial logic. It does not matter what you put in the
sensitivity list, it does not matter what intermediate signals or any
of the things you mention.

Let me put it this way. If there are three inputs to the logic for a
given signal and you specify the output for 7 combinations of the
inputs, what would you like for the output if the eighth combination
of inputs occurs? Even if this combination is not possible, the tool
has no way of knowing that. The tool, by definition in the language,
will maintain the previous state of the output which requires the
generation of a latch.

Typically a tool will warn you of incomplete specifications in a case
statement or a selected signal assignment statement. I'm not sure of
the conditional assignment statement and I know that an IF statement
will not give any warnings about incomplete specifications of
outputs.

Is that clear?

Rick- Hide quoted text -

- Show quoted text -

yep. the if did give warning about comparing inequal lengths which was
useful. I am a bit sad about 'X' not being a valid assignment. I tried
placing use balanced, or logically similar don't cares, in the hope
that an effective logic reduction would happen. My alu is now a
seperate process.
Click to expand...
Don't cares can be useful. But they aren't specified by an 'X'. An
'X' indicates that the state of a signal is invalid such as two
drivers active on the net.

Some tools will treat the '-' character as a don't care, but this is a
tool function, not the language. The '-' is used on the input, not
the output.

Otherwise, the way you have to specify a don't care is to specify the
output, but only using the inputs that are needed for that output
state. For example,

foo <= '1' when (addr = "0000") else
'1' when (addr(3 downto 1) = "100" else
'0';

Here addr(0) is a don't care for the second output. If the tool
accepts the '-' as a don't care you can use,

foo <= '1' when (addr = "0000") else
'1' when (addr = "100-") else
'0';

I don't know of any way to specify a don't care output. I know that
this is common when using Karnaugh maps, but I suppose it does not map
well to an HDL (a simulator will take it literally and output a '-'
and the down stream logic wouldn't like that much). However, when
designing an ALU, you can write your own code for a bit slice that can
be optimized by hand using a Karnaugh map. I suppose you then don't
get the carry chain. But that is likely because you are trying to
force too much logic into the LUT. Sometimes the tools really are
smarter than the designer.

Are you trying to get more into one set of LUTs than just the add/
subtract?

Rick
 
On Aug 12, 11:21 am, rickman <gnu...@gmail.com> wrote:
On Aug 12, 7:38 am, jacko <jackokr...@gmail.com> wrote:

Here addr(0) is a don't care for the second output.  If the tool
accepts the '-' as a don't care you can use,

foo <= '1' when (addr = "0000") else
       '1' when (addr = "100-") else
       '0';
Click to expand...
Actually the above is not the way you'd specify the don't care on the
input either. You'd quickly find that this would fail your
simulation. What you want is the std_match function when you have
don't cares. That function will properly 'skip over' the don't cares
whereas "=" will not because the "=" function for comparing
std_logic_vectors is not overridden in that manner.

foo <= '1' when (addr = "0000") else
'1' when std_match(addr, "100-") else
'0';

KJ
 
On 12 Aug, 16:21, rickman <gnu...@gmail.com> wrote:
On Aug 12, 7:38 am, jacko <jackokr...@gmail.com> wrote:



On 12 Aug, 04:31, rickman <gnu...@gmail.com> wrote:

On Aug 9, 10:12 am, jacko <jackokr...@gmail.com> wrote:

Hi

got rid of some by putting best selection as don't care, as quartus
doesn't like 'X' for some reason or didn't in version 6.1 (last
checked). That was understandable.

The bit I don't get yet is why a coinational process, with just one
register in the sensitivity list (IR) process is instruction decode
from insrtuction register, inferes latches on intermediate signals,
when there latched contents have no relevance. The intermediates
should always be recalculated.

Is it because only some paths through the process do not assign to
them? As I thought this was only relevant to synchronous behaviour.

Hiving the ALU off into a different process (combinatorial) should ix
this if I postulate correctly, butis this the reason?

The generation of latches has nothing to do with the structure of your
code. It has *only* to do with incompletely specified, synthesizable,
combinatorial logic. It does not matter what you put in the
sensitivity list, it does not matter what intermediate signals or any
of the things you mention.

Let me put it this way. If there are three inputs to the logic for a
given signal and you specify the output for 7 combinations of the
inputs, what would you like for the output if the eighth combination
of inputs occurs? Even if this combination is not possible, the tool
has no way of knowing that. The tool, by definition in the language,
will maintain the previous state of the output which requires the
generation of a latch.

Typically a tool will warn you of incomplete specifications in a case
statement or a selected signal assignment statement. I'm not sure of
the conditional assignment statement and I know that an IF statement
will not give any warnings about incomplete specifications of
outputs.

Is that clear?

Rick- Hide quoted text -

- Show quoted text -

yep. the if did give warning about comparing inequal lengths which was
useful. I am a bit sad about 'X' not being a valid assignment. I tried
placing use balanced, or logically similar don't cares, in the hope
that an effective logic reduction would happen. My alu is now a
seperate process.

Don't cares can be useful. But they aren't specified by an 'X'. An
'X' indicates that the state of a signal is invalid such as two
drivers active on the net.

Some tools will treat the '-' character as a don't care, but this is a
tool function, not the language. The '-' is used on the input, not
the output.

Otherwise, the way you have to specify a don't care is to specify the
output, but only using the inputs that are needed for that output
state. For example,

foo <= '1' when (addr = "0000") else
'1' when (addr(3 downto 1) = "100" else
'0';

Here addr(0) is a don't care for the second output. If the tool
accepts the '-' as a don't care you can use,

foo <= '1' when (addr = "0000") else
'1' when (addr = "100-") else
'0';

I don't know of any way to specify a don't care output. I know that
this is common when using Karnaugh maps, but I suppose it does not map
well to an HDL (a simulator will take it literally and output a '-'
and the down stream logic wouldn't like that much). However, when
designing an ALU, you can write your own code for a bit slice that can
be optimized by hand using a Karnaugh map. I suppose you then don't
get the carry chain. But that is likely because you are trying to
force too much logic into the LUT. Sometimes the tools really are
smarter than the designer.

Are you trying to get more into one set of LUTs than just the add/
subtract?

Rick
Click to expand...
add, and<<1, xor, null
 
On 12 Aug, 17:22, KJ <kkjenni...@sbcglobal.net> wrote:
On Aug 12, 11:21 am, rickman <gnu...@gmail.com> wrote:

On Aug 12, 7:38 am, jacko <jackokr...@gmail.com> wrote:

Here addr(0) is a don't care for the second output. If the tool
accepts the '-' as a don't care you can use,

foo <= '1' when (addr = "0000") else
'1' when (addr = "100-") else
'0';

Actually the above is not the way you'd specify the don't care on the
input either. You'd quickly find that this would fail your
simulation. What you want is the std_match function when you have
don't cares. That function will properly 'skip over' the don't cares
whereas "=" will not because the "=" function for comparing
std_logic_vectors is not overridden in that manner.

foo <= '1' when (addr = "0000") else
'1' when std_match(addr, "100-") else
'0';

KJ
Click to expand...
I came to the conclusion that zero assignment in the don't care cases
makes the best logic, as the logic seems to implement as sums of
products. Must put all the zeros in the design, and fix q register
getting ir register on call instruction.

cheers
jacko
 
On Aug 13, 11:15 am, jacko <jackokr...@gmail.com> wrote:
On 12 Aug, 17:22, KJ <kkjenni...@sbcglobal.net> wrote:

foo <= '1' when (addr = "0000") else
       '1' when std_match(addr, "100-") else
       '0';

KJ

I came to the conclusion that zero assignment in the don't care cases
makes the best logic, as the logic seems to implement as sums of
products. Must put all the zeros in the design, and fix q register
getting ir register on call instruction.
Click to expand...
Putting '0' in instead of using don't cares and the std_match function
can use more routing and more logic, it will never use less LUTs or
less routing so it's hard to see how using '0' could be the 'best'
logic. Comparing a bit to see if it is '0' (or '1') costs more than
not comparing it at all since, at a minimum, the bit must be routed to
the LUT.

KJ
 
jacko wrote:

I came to the conclusion that zero assignment in the don't care cases
makes the best logic, as the logic seems to implement as sums of
products.
Click to expand...
If you are saying that you would choose
the value "1000" over "100-", I will agree,
but for these reasons:

1. The logic description,
and test requirements,
and bus interface spec will be simpler.

2. Changes to the map are less trouble.

Now, if I were down to my last LUT,
I might negotiate, but that hasn't happened
since I was targeting a 22v10.

If the values were internal states
rather than a public address, I would use an enumeration
and let synthesis pack the gates.

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.

-- Mike Treseler
 
On Aug 13, 6:37 pm, Mike Treseler <mtrese...@gmail.com> wrote:
jacko wrote:
I came to the conclusion that zero assignment in the don't care cases
makes the best logic, as the logic seems to implement as sums of
products.

If you are saying that you would choose
the value "1000" over "100-", I will agree,
but for these reasons:

1. The logic description,
and test requirements,
and bus interface spec will be simpler.

2. Changes to the map are less trouble.

Now, if I were down to my last LUT,
I might negotiate, but that hasn't happened
since I was targeting a 22v10.
Click to expand...
But LUT usage is what this is about. The point is not that there is
another product term in the equation, the point is that there is
another *input* to the term in the equation. This can often cause
even more than one LUT to be used depending on the complexity of the
rest of the logic producing this output. I have had state machine
logic fan out in a lot of complexity. One input would go to some four
or five LUTs in the tree. If I coded it so that a given input was a
don't care in some of the terms, that could allow better packing of
the LUTs and lower the LUT usage noticeably.

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


If the values were internal states
rather than a public address, I would use an enumeration
and let synthesis pack the gates.
Click to expand...
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;

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.
Click to expand...
Yes, but this is potentially just a part of an output specification.
Otherwise why bother even thinking about it.

Rick
 
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;
Click to expand...
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
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top