Quartus II infered latches

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

"jacko" <jackokring@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

> 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

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

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

"jacko" <jackokring@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...
>
>
>
> > 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

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

"KJ" <kkjennings@sbcglobal.net> wrote in message
news:6lmnk.32983$co7.4027@nlpi066.nbdc.sbc.com...
>
> "jacko" <jackokring@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

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

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

"jacko" <jackokring@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

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

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.

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/miketresel...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/miketresel...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