sw guy question about latches

D

d p chang

Guest
i'm a sw guy wandering through teaching myself a little bit about
(digital) hw, and want to try to go about this 'idiomatically' rather
than trying to translate my sw thinking into hdl (and coming up w/ crap
hdl).

anyway, every sort of 'style guide' that i see warns not to have
unassigned signals in combinatorial logic because one gets latches. i
understand this, but then i started thinking about how i would go about
implementing something 'complicated' like a pci controller.

my sw guy understanding of some of the signals is that when i want the
bus i assert req# and wait for gnt# to be asserted. however, before i
get gnt# i shouldn't be driving any of the other signals. just to play
around w/ this i mocked up a little code (using the xilinx free tools
for the fgpa i got to play w/) which looked something like:

entity foo is
port ( we : out std_logic );
end foo;
...
architecture behavioral of foo is
begin
process(state)
we <= 'z';
...
if (...) then
we <= '1';
end if;
end process;
end;

this causes the tool to mumble that

type of 'we' is not compatible w/ the type of 'z'

is there some other fu that one does in order to 'drive' something as
'unknown'?

\p
 
d p chang wrote:
i'm a sw guy wandering through teaching myself a little bit about
(digital) hw, and want to try to go about this 'idiomatically' rather
than trying to translate my sw thinking into hdl (and coming up w/ crap
hdl).
Click to expand...
Match a synchronous template.
That will simplify synthesis.
I recommend single process entities to
the sequentially inclined.

Details: http://mysite.verizon.net/miketreseler/
 
On Jan 18, 10:50 pm, d p chang <wea...@meer.net> wrote:
i'm a sw guy wandering through teaching myself a little bit about
(digital) hw, and want to try to go about this 'idiomatically' rather
than trying to translate my sw thinking into hdl (and coming up w/ crap
hdl).

anyway, every sort of 'style guide' that i see warns not to have
unassigned signals in combinatorial logic because one gets latches. i
understand this, but then i started thinking about how i would go about
implementing something 'complicated' like a pci controller.

my sw guy understanding of some of the signals is that when i want the
bus i assert req# and wait for gnt# to be asserted. however, before i
get gnt# i shouldn't be driving any of the other signals. just to play
around w/ this i mocked up a little code (using the xilinx free tools
for the fgpa i got to play w/) which looked something like:

    entity foo is
     port ( we : out std_logic );
    end foo;
    ...
    architecture behavioral of foo is
    begin
    process(state)
        we <= 'z';
        ...
        if (...) then
          we <= '1';
        end if;
    end process;
    end;

this causes the tool to mumble that

     type of 'we' is not compatible w/ the type of 'z'

is there some other fu that one does in order to 'drive' something as
'unknown'?

\p
Click to expand...
I think you want uppercase 'Z'. While identifiers are not case
sensitive, character literals are.

- Kenn
 
Mike Treseler <mtreseler@gmail.com> writes:

d p chang wrote:

i'm a sw guy wandering through teaching myself a little bit about
(digital) hw, and want to try to go about this 'idiomatically' rather
than trying to translate my sw thinking into hdl (and coming up w/
crap hdl).

I recommend single process entities to
the sequentially inclined.
Click to expand...
in my pci example, is there a way to parallelize? i was thinking a state
machine would be the way to cover the basic cases (w/o bus errors). i
may be more sequenctially inclined than i'd admit.

\p
---
Luck is when preparation meets opportunity. --- Elmer Letterman
 
kennheinrich@sympatico.ca writes:

On Jan 18, 10:50 pm, d p chang <wea...@meer.net> wrote:

my sw guy understanding of some of the signals is that when i want the
bus i assert req# and wait for gnt# to be asserted. however, before i
get gnt# i shouldn't be driving any of the other signals. just to play
around w/ this i mocked up a little code (using the xilinx free tools
for the fgpa i got to play w/) which looked something like:

    process(state)
        we <= 'z';
    end process;
    end;

this causes the tool to mumble that

     type of 'we' is not compatible w/ the type of 'z'

I think you want uppercase 'Z'. While identifiers are not case
sensitive, character literals are.
Click to expand...
wow, that did it. i didn't even notice that it was special in this way. thanks.

\p
---
The truth is more important than the facts. --- Frank Lloyd Wright
 
d p chang wrote:

in my pci example, is there a way to parallelize?
Click to expand...
For vhdl, parallel description means multiple processes wired together.
Serial description means one process wired directly to entity ports.
Either method works.
It's the designer's choice.
Good luck.

-- Mike Treseler
 
Mike Treseler <mtreseler@gmail.com> writes:

d p chang wrote:

in my pci example, is there a way to parallelize?

For vhdl, parallel description means multiple processes wired together.
Serial description means one process wired directly to entity ports.
Either method works.
Click to expand...
gotcha. thanks again.

\p
---
Any intelligent fool can make things bigger, more complex, and more
violent. It takes a touch of genius -- and a lot of courage -- to move
in the opposite direction. --- Albert Einstein
 
On Jan 18, 11:04 pm, Mike Treseler <mtrese...@gmail.com> wrote:
d p chang wrote:
i'm a sw guy wandering through teaching myself a little bit about
(digital) hw, and want to try to go about this 'idiomatically' rather
than trying to translate my sw thinking into hdl (and coming up w/ crap
hdl).

Match a synchronous template.
That will simplify synthesis.
I recommend single process entities to
the sequentially inclined.

Details:http://mysite.verizon.net/miketreseler/
Click to expand...
Mike has given you good advice. I would also add that a single,
clocked process will not give you latches, regardless of whether a
signal or variable is updated on that clock cycle. If one is not
updated, a clock enabled register is inferred, with appropriate
circuit to drive the enable input.

BTW, "Z" is not synonymous with "don't care," it is a tri-state (high
impedance) value used "turn off" a driver on busses with more than one
driver. If your target hardware does not support a tri-state bus
internally, the synthesis tool will convert tri-state busses to
multiplexers for you (probably not what you intended in this case).
"Don't care" is usually specified as either 'X' or '-'.

Andy
 
Andy <jonesandy@comcast.net> writes:

On Jan 18, 11:04 pm, Mike Treseler <mtrese...@gmail.com> wrote:
d p chang wrote:
i'm a sw guy wandering through teaching myself a little bit about
(digital) hw, and want to try to go about this 'idiomatically' rather
than trying to translate my sw thinking into hdl (and coming up w/ crap
hdl).

Match a synchronous template.
That will simplify synthesis.
I recommend single process entities to
the sequentially inclined.

Mike has given you good advice. I would also add that a single,
clocked process will not give you latches, regardless of whether a
signal or variable is updated on that clock cycle. If one is not
updated, a clock enabled register is inferred, with appropriate
circuit to drive the enable input.
Click to expand...
hmmm... i could be misunderstanding something in my book or the advice
here or this is an fpga thing (vs 'standard' vhdl). what i have is
something like:

architecture foo ...
begin
process(clk, rst)
begin
if rst = '1' then
...
else if clk = '1' and clk'Event then
state <= state_next;
end if;
end process;

process(state)
begin
-- default state stuff
-- addr <= ...
if ....
addr <= ....
else
-- stuff that doesn't set addr
end if;
end process;
end foo;

if i don't have the commented out 'default' part in the second process
the xilinx ise stuff says something like:

found x-bit latch for signakl <addr>. ... we do not recommend the use
of latches in fpga/cpld designs, as they may lead to timing problems.

is this what you mean by 'clock enabled register'? the register will
hold values until the next clock cycle. this 'hold' is what i wanted but
didn't have explicit updates as i was developing.


BTW, "Z" is not synonymous with "don't care," it is a tri-state (high
impedance) value used "turn off" a driver on busses with more than one
driver.
Click to expand...
thanks, my bad terminology. part of the pci spec that i never had to
deal w/ before, but avoiding the 'drive fight' w/ Z was what i thnk i
was looking for.

\p
---
Have nothing around you that you do not believe to be beautiful.
--- William Morris
 
A clock enablled register uses the following VHDL template:

process(clk)
begin
if rising_edge(clk) then
if enable = '1' then
--do stuff
end if;
end if;
end process;

What you have built by removing the defaults is NOT registers - but
latches. The 2 process state machine process requires that all signals
in the process be assigned a value for EVERY possible case. The
defaults are there as default conditions, and so will always assign a
value unless specified.

The easiest way to avoid this is to move the whole state machine into
a single process, then you CANNOT infer transparent latches.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top