Quartus II infered latches

J

jacko

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
 
K

KJ

jacko said:
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
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

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
 
J

jacko

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

a<=b;
c<=d;
e<=a*c;

--a and c are intrmediate calculations.
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

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

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
 
K

KJ

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

a<=b;
c<=d;
e<=a*c;

--a and c are intrmediate calculations.

To you maybe, to

Well you stated that the instruction register is the only thing in the
sensitivity list is the instruction register so I assume that your code then
is of the form below (where I'll assume that 'a' is the instruction
register)

process(a)
begin
a<=b;
c<=d;
e<=a*c;
end process;

In this case, you should get warnings about an incomplete sensitivity list.
Ignore them if you like living on the edge, but if you do then your
simulation will not match what gets synthesized because the synthesizer will
implement it *as if* you had

process(a,b,c,d)

But simulation will only cause this process to trigger when 'a' changes,
changes on the others won't. I don't know which way you intend it to work,
but the issue is that you'll simulate one set of logic and will synthesize
something completely different so this is a warning that you should fix.

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.

KJ
 
K

KJ

KJ said:
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
 
J

jacko

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

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
 
K

KJ

jacko said:
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
 
J

jacko

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?


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.




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

KJ

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
 
M

Mike Treseler

jacko said:
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
 
J

jacko

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

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
 
K

KJ

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
 
J

jacko

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

ok
 
M

Mike Treseler

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
 
R

rickman

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
 
J

jacko

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.

cheers
jacko
 
J

jacko

jacko wrote:

...


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

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
 
R

rickman

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
 
K

KJ

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
 
J

jacko

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

add, and<<1, xor, null
 

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

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top