Getting Latch when don't want.

H

Hawker

Guest
Can someone please help me on this please?
Xilinx tools report
WARNING:Xst:736 - Found 8-bit latch for signal <Mtridata_PSRAM_DATA>
created at line 185.
WARNING:Xst:736 - Found 1-bit latch for signal <Mtrien_PSRAM_DATA>
created at line 185.

PSRAM_DATA should not be latched at any time. Just buffered and passed
through. Perhaps I should use a CASE statement with a "when others" but
then I have to create a variable that encompasses all these terms.

Here is what I have.

DB_handler: process ( FX2_MA_nSL, PSRAM_DATA, MI_DATA, MA_current_state,
FX2_MA_CNT_nUPDN ) -- Data Bus and OE handler
begin
if MA_current_state = RESET then
FX2_DATA <= "ZZZZZZZZ";
PSRAM_DATA <= "ZZZZZZZZ"; -- this is line 185
MI_OE <= '1';
PSRAM_nOE <= '1';
elsif FX2_MA_nSL = '0' then
FX2_DATA <= MI_DATA;
PSRAM_DATA <= "ZZZZZZZZ";
MI_OE <= '0';
PSRAM_nOE <= '1';
elsif FX2_MA_CNT_nUPDN = '0' THEN
PSRAM_DATA <= MI_DATA;
FX2_DATA <= "ZZZZZZZZ";
MI_OE <= '0';
PSRAM_nOE <= '1';
ELSE
FX2_DATA <= PSRAM_DATA;
MI_OE <= '1';
PSRAM_nOE <= '0';
END IF;
end process DB_handler;
 
Hawker wrote:
Can someone please help me on this please?
Xilinx tools report
WARNING:Xst:736 - Found 8-bit latch for signal <Mtridata_PSRAM_DATA
created at line 185.
WARNING:Xst:736 - Found 1-bit latch for signal <Mtrien_PSRAM_DATA
created at line 185.

PSRAM_DATA should not be latched at any time. Just buffered and passed
through. Perhaps I should use a CASE statement with a "when others" but
then I have to create a variable that encompasses all these terms.

Here is what I have.

DB_handler: process ( FX2_MA_nSL, PSRAM_DATA, MI_DATA, MA_current_state,
FX2_MA_CNT_nUPDN ) -- Data Bus and OE handler
begin
if MA_current_state = RESET then
FX2_DATA <= "ZZZZZZZZ";
PSRAM_DATA <= "ZZZZZZZZ"; -- this is line 185
MI_OE <= '1';
PSRAM_nOE <= '1';
elsif FX2_MA_nSL = '0' then
FX2_DATA <= MI_DATA;
PSRAM_DATA <= "ZZZZZZZZ";
MI_OE <= '0';
PSRAM_nOE <= '1';
elsif FX2_MA_CNT_nUPDN = '0' THEN
PSRAM_DATA <= MI_DATA;
FX2_DATA <= "ZZZZZZZZ";
MI_OE <= '0';
PSRAM_nOE <= '1';
ELSE
FX2_DATA <= PSRAM_DATA;
MI_OE <= '1';
PSRAM_nOE <= '0';
END IF;
end process DB_handler;
Click to expand...
Since PSRAM_DATA does not get a value assigned to it in the ELSE branch,
it is assumed that it needs to keep its current value. Since it is not a
clocked process, a latch will be inferred.

Regards,

Pieter Hulshoff
 
On 3/19/2007 11:04 AM, The digits of Pieter Hulshoff's hands composed
the following:
Since PSRAM_DATA does not get a value assigned to it in the ELSE branch,
it is assumed that it needs to keep its current value. Since it is not a
clocked process, a latch will be inferred.
Click to expand...
That is what I thought. The problem is PSRAM_DATA is going to FX2_DATA
so how do I assign a value to it?
Do I still do
PSRAM_DATA <= "ZZZZZZZZ";

I should have clarified that PSRAM_DATA is inout FX2_DATA is OUT and
MI_DATA is IN

Thanx
Hawker
 
Hawker wrote:
On 3/19/2007 11:04 AM, The digits of Pieter Hulshoff's hands composed
the following:
Since PSRAM_DATA does not get a value assigned to it in the ELSE branch,
it is assumed that it needs to keep its current value. Since it is not a
clocked process, a latch will be inferred.


That is what I thought. The problem is PSRAM_DATA is going to FX2_DATA
so how do I assign a value to it?
Do I still do
PSRAM_DATA <= "ZZZZZZZZ";

I should have clarified that PSRAM_DATA is inout FX2_DATA is OUT and
MI_DATA is IN
Click to expand...
No, because the FX2_DATA will immediately take over the value of
PSRAM_DATA, and will also go to Z. Honestly I think the main problem is:
what are you trying to accomplish? Currently it looks like you want a
memory cell activated by signal levels, and that is by definition a
latch. Perhaps you should define your design in hardware components
first, and then look at what your VHDL should look like.

Regards,

Pieter Hulshoff
 
On 3/20/2007 3:17 AM, The digits of Pieter Hulshoff's hands composed the
following:
No, because the FX2_DATA will immediately take over the value of
PSRAM_DATA, and will also go to Z. Honestly I think the main problem is:
what are you trying to accomplish? Currently it looks like you want a
memory cell activated by signal levels, and that is by definition a
latch. Perhaps you should define your design in hardware components
first, and then look at what your VHDL should look like.
Click to expand...
You are correct. I know what this would look like in discrete logic, but
putting that into VHDL is where I stumble.
Is essences I have a PSRAM that gets data from one source and sends it
to another. The statement is an attempt to route that data from the
correct source and then to the correct source. Is that any clearer?

I'm still not sure how to solve this problem.

Hawker


Regards,

Pieter Hulshoff
Click to expand...
 
Hawker wrote:
On 3/20/2007 3:17 AM, The digits of Pieter Hulshoff's hands composed the
following:
No, because the FX2_DATA will immediately take over the value of
PSRAM_DATA, and will also go to Z. Honestly I think the main problem is:
what are you trying to accomplish? Currently it looks like you want a
memory cell activated by signal levels, and that is by definition a
latch. Perhaps you should define your design in hardware components
first, and then look at what your VHDL should look like.

You are correct. I know what this would look like in discrete logic, but
putting that into VHDL is where I stumble.
Is essences I have a PSRAM that gets data from one source and sends it
to another. The statement is an attempt to route that data from the
correct source and then to the correct source. Is that any clearer?

I'm still not sure how to solve this problem.
Click to expand...
The question is: do you have a problem? If you want to use a memory cell
activated by signal levels then you get a latch, it's as simple as
that. If you want a flipflop you will need to use a clock. What kind of
memory cell _did_ you intend to use in your design?

Regards,

Pieter Hulshoff
 
On 3/20/2007 10:10 AM, The digits of Pieter Hulshoff's hands composed
the following:
Hawker wrote:
On 3/20/2007 3:17 AM, The digits of Pieter Hulshoff's hands composed the
following:
No, because the FX2_DATA will immediately take over the value of
PSRAM_DATA, and will also go to Z. Honestly I think the main problem is:
what are you trying to accomplish? Currently it looks like you want a
memory cell activated by signal levels, and that is by definition a
latch. Perhaps you should define your design in hardware components
first, and then look at what your VHDL should look like.
You are correct. I know what this would look like in discrete logic, but
putting that into VHDL is where I stumble.
Is essences I have a PSRAM that gets data from one source and sends it
to another. The statement is an attempt to route that data from the
correct source and then to the correct source. Is that any clearer?

I'm still not sure how to solve this problem.

The question is: do you have a problem? If you want to use a memory cell
activated by signal levels then you get a latch, it's as simple as
that. If you want a flipflop you will need to use a clock. What kind of
memory cell _did_ you intend to use in your design?

Regards,
\
Click to expand...
The memory is not a memory cell. It is an external Micron PSRAM. A PSRAM
is basically a SDR SRAM with an Async Memory controller built in. The
memory is not in the device (My device is a Xilinx CR2 CPLD BTW).
I don't think I want a latch because that complicates the timing since I
need to latch it at exactly the correct time. If I just pass it though
it makes things easier. If I start the pass early no biggie, as long as
it is valid at the time I issue the write to the PSRAM. If I latch then
when I latch becomes important.
In theory I shouldn't even need to run the data lines though the CPLD,
only control the OE lines via the CPLD. I ran them though the CPLD just
incase I had a timing issue and needed to latch them, but I don't think
that will be the case.

So what I am really after is more of tri statable mux than a latch.

Am I being any clearer. Of course it would be easier if you had a
schematic and the rest of the picture, but that is more than I feel I
Can ask of this group.

Thanx for you help

Hawker
 
"Hawker" <Hawker{removethispart}@ashevillecommunity.org> wrote in message
news:56afkkF27k570U1@mid.individual.net...
The memory is not a memory cell. It is an external Micron PSRAM. A PSRAM
is basically a SDR SRAM with an Async Memory controller built in. The
memory is not in the device (My device is a Xilinx CR2 CPLD BTW).
I don't think I want a latch because that complicates the timing since I
need to latch it at exactly the correct time. If I just pass it though it
makes things easier. If I start the pass early no biggie, as long as it is
valid at the time I issue the write to the PSRAM. If I latch then when I
latch becomes important.
In theory I shouldn't even need to run the data lines though the CPLD,
only control the OE lines via the CPLD. I ran them though the CPLD just
incase I had a timing issue and needed to latch them, but I don't think
that will be the case.

So what I am really after is more of tri statable mux than a latch.

Am I being any clearer. Of course it would be easier if you had a
schematic and the rest of the picture, but that is more than I feel I Can
ask of this group.
Click to expand...
Go back to Pieter's original post and re-read it. Below I've copied your
code with the one additional line added that Pieter told you that you had
missed and is the reason for the unwanted latch.

if MA_current_state = RESET then
FX2_DATA <= "ZZZZZZZZ";
PSRAM_DATA <= "ZZZZZZZZ"; -- this is line 185
MI_OE <= '1';
PSRAM_nOE <= '1';
elsif FX2_MA_nSL = '0' then
FX2_DATA <= MI_DATA;
PSRAM_DATA <= "ZZZZZZZZ";
MI_OE <= '0';
PSRAM_nOE <= '1';
elsif FX2_MA_CNT_nUPDN = '0' THEN
PSRAM_DATA <= MI_DATA;
FX2_DATA <= "ZZZZZZZZ";
MI_OE <= '0';
PSRAM_nOE <= '1';
ELSE
FX2_DATA <= PSRAM_DATA;
PSRAM_DATA <= "ZZZZZZZZ"; -- << KJ: This is what you
need to add here
MI_OE <= '1';
PSRAM_nOE <= '0';
END IF;

A somewhat 'safer' alternative is to add the line of code prior to the 'if'
statement like I've shown below. Functionally it will produce the exact
same thing as what I posted above, the only reason that it is 'safer' is
that when you write code for an unclocked process it is far too easy to miss
assigning some signal in some path through the process which will infer a
latch (which is exactly what you've done). For those that use unclocked
processes, the recommended template is to first assign some default value to
each and every output of that process and THEN launch into the statements
that can have branching (if/case). Using that template your code would look
something like...

FX2_DATA <= "ZZZZZZZZ"; -- Default unless overridden below
PSRAM_DATA <= "ZZZZZZZZ"; -- Default unless overridden below
MI_OE <= '1'; -- Default unless overridden below
PSRAM_nOE <= '1'; -- Default unless overridden below
if FX2_MA_nSL = '0' then
FX2_DATA <= MI_DATA;
MI_OE <= '0';
elsif FX2_MA_CNT_nUPDN = '0' THEN
PSRAM_DATA <= MI_DATA;
MI_OE <= '0';
ELSE
FX2_DATA <= PSRAM_DATA;
PSRAM_nOE <= '0';
END IF;

Good luck

Kevin Jennings
 
On 3/21/2007 5:13 AM, The digits of KJ's hands composed the following:
Go back to Pieter's original post and re-read it. Below I've copied
your
code with the one additional line added that Pieter told you that you had
missed and is the reason for the unwanted latch.

if MA_current_state = RESET then
FX2_DATA <= "ZZZZZZZZ";
PSRAM_DATA <= "ZZZZZZZZ"; -- this is line 185
MI_OE <= '1';
PSRAM_nOE <= '1';
elsif FX2_MA_nSL = '0' then
FX2_DATA <= MI_DATA;
PSRAM_DATA <= "ZZZZZZZZ";
MI_OE <= '0';
PSRAM_nOE <= '1';
elsif FX2_MA_CNT_nUPDN = '0' THEN
PSRAM_DATA <= MI_DATA;
FX2_DATA <= "ZZZZZZZZ";
MI_OE <= '0';
PSRAM_nOE <= '1';
ELSE
FX2_DATA <= PSRAM_DATA;
PSRAM_DATA <= "ZZZZZZZZ"; -- << KJ: This is what you
need to add here
MI_OE <= '1';
PSRAM_nOE <= '0';
END IF;

A somewhat 'safer' alternative is to add the line of code prior to the 'if'
statement like I've shown below. Functionally it will produce the exact
same thing as what I posted above, the only reason that it is 'safer' is
that when you write code for an unclocked process it is far too easy to miss
assigning some signal in some path through the process which will infer a
latch (which is exactly what you've done). For those that use unclocked
processes, the recommended template is to first assign some default value to
each and every output of that process and THEN launch into the statements
that can have branching (if/case). Using that template your code would look
something like...

FX2_DATA <= "ZZZZZZZZ"; -- Default unless overridden below
PSRAM_DATA <= "ZZZZZZZZ"; -- Default unless overridden below
MI_OE <= '1'; -- Default unless overridden below
PSRAM_nOE <= '1'; -- Default unless overridden below
if FX2_MA_nSL = '0' then
FX2_DATA <= MI_DATA;
MI_OE <= '0';
elsif FX2_MA_CNT_nUPDN = '0' THEN
PSRAM_DATA <= MI_DATA;
MI_OE <= '0';
ELSE
FX2_DATA <= PSRAM_DATA;
PSRAM_nOE <= '0';
END IF;

Good luck

Kevin Jennings
Click to expand...

Thank you very much.
The addition is what I thought he was inferring, but a later post made
me think that would not work. It is what I did though. I wanting on the
software person to see if it works.

Your other lesson/trick was very helpful, thank you very much. I didn't
know that would work. I had always been told you can't make assignments
to a port/variable in more than one process and I thought that would
constitute that. If that works (I'm going to try that) it would clean up
quite a bit of my code.

Now I just have to solve my clock issue. I have the Avent FAE helping me
with that. I drew out what I want in discrete logic so I think that will
help her understand.

Thanx again
Hawker
 
Your other lesson/trick was very helpful, thank you very much. I didn't
know that would work. I had always been told you can't make assignments to
a port/variable in more than one process and I thought that would
constitute that. If that works (I'm going to try that) it would clean up
quite a bit of my code.
Click to expand...
Woops, don't misread what I was suggesting, the changes I listed are
intended to all be within the process that you have, not external to that
process. See below...

process(...enter the proper list of signals for the sensitivity list
here...)
begin
FX2_DATA <= "ZZZZZZZZ"; -- Default unless overridden below
PSRAM_DATA <= "ZZZZZZZZ"; -- Default unless overridden below
MI_OE <= '1'; -- Default unless overridden below
PSRAM_nOE <= '1'; -- Default unless overridden below
if FX2_MA_nSL = '0' then
FX2_DATA <= MI_DATA;
MI_OE <= '0';
elsif FX2_MA_CNT_nUPDN = '0' THEN
PSRAM_DATA <= MI_DATA;
MI_OE <= '0';
ELSE
FX2_DATA <= PSRAM_DATA;
PSRAM_nOE <= '0';
END IF;
end process;

What this is doing is making multiple assignments to signals all from within
a single process. This is not only acceptable but, in cases like yours,
preferable.

Kevin Jennings
 
Hawker wrote:
On 3/21/2007 5:13 AM, The digits of KJ's hands composed the following:
if MA_current_state = RESET then
FX2_DATA <= "ZZZZZZZZ";
PSRAM_DATA <= "ZZZZZZZZ"; -- this is line 185
MI_OE <= '1';
PSRAM_nOE <= '1';
elsif FX2_MA_nSL = '0' then
FX2_DATA <= MI_DATA;
PSRAM_DATA <= "ZZZZZZZZ";
MI_OE <= '0';
PSRAM_nOE <= '1';
elsif FX2_MA_CNT_nUPDN = '0' THEN
PSRAM_DATA <= MI_DATA;
FX2_DATA <= "ZZZZZZZZ";
MI_OE <= '0';
PSRAM_nOE <= '1';
ELSE
FX2_DATA <= PSRAM_DATA;
PSRAM_DATA <= "ZZZZZZZZ"; -- << KJ: This is what
you need to add here
MI_OE <= '1';
PSRAM_nOE <= '0';
END IF;
FX2_DATA <= "ZZZZZZZZ"; -- Default unless overridden below
PSRAM_DATA <= "ZZZZZZZZ"; -- Default unless overridden below
MI_OE <= '1'; -- Default unless overridden below
PSRAM_nOE <= '1'; -- Default unless overridden below
if FX2_MA_nSL = '0' then
FX2_DATA <= MI_DATA;
MI_OE <= '0';
elsif FX2_MA_CNT_nUPDN = '0' THEN
PSRAM_DATA <= MI_DATA;
MI_OE <= '0';
ELSE
FX2_DATA <= PSRAM_DATA;
PSRAM_nOE <= '0';
END IF;

Thank you very much.
The addition is what I thought he was inferring, but a later post made
me think that would not work. It is what I did though. I wanting on the
software person to see if it works.
Click to expand...
Well, the thing is: it will remove the latch, but I seriously doubt the
design will do what you intended. Since this is combinatorial logic, the
FX2_DATA output will be "ZZZZZZZZ" in the ELSE situation (well, it will
be the previous MI_DATA for 1 delta cycle, but I don't think that will
matter much).

As I already wrote, it looks like you actually WANT to design a latch.
Under FX2_MA_CNT_nUPDN = '0' you wish to store MI_DATA in PSRAM_DATA,
and in the ELSE situation you wish that data to be placed on the
FX2_DATA output. If you want to store data under a level based
condition, you're designing a latch.

Again, my original question: what is your design supposed to do? Can you
describe it in words or perhaps a picture (in ASCII is fine)?

Regards,

Pieter Hulshoff
 
Hawker wrote:
On 3/22/2007 3:00 AM, The digits of Pieter Hulshoff's hands composed the
following:
The memory is not an internal memory cell. It is an external Micron
PSRAM. A PSRAM is basically a SDR SRAM with an Async Memory controller
built in.
Click to expand...
OK, I may have missed something here: This PSRAM_DATA, is it currently a signal
in your design or is it a bidirectional INOUT port? If it is a bidirectional
port, and if the external PSRAM will force the correct value onto the signal,
then KJ's suggestion should do the trick (I would use his 2nd suggested code;
it's cleaner). If it is an internal signal, then how does your design
communicate with this external PSRAM?

Kind regards,

Pieter Hulshoff
 
On 3/22/2007 3:00 AM, The digits of Pieter Hulshoff's hands composed the
following:

<big snip>
Well, the thing is: it will remove the latch, but I seriously doubt the
design will do what you intended. Since this is combinatorial logic, the
FX2_DATA output will be "ZZZZZZZZ" in the ELSE situation (well, it will
be the previous MI_DATA for 1 delta cycle, but I don't think that will
matter much).

As I already wrote, it looks like you actually WANT to design a latch.
Under FX2_MA_CNT_nUPDN = '0' you wish to store MI_DATA in PSRAM_DATA,
and in the ELSE situation you wish that data to be placed on the
FX2_DATA output. If you want to store data under a level based
condition, you're designing a latch.

Again, my original question: what is your design supposed to do? Can you
describe it in words or perhaps a picture (in ASCII is fine)?

Regards,

Pieter Hulshoff
Click to expand...

What your saying is what I thought would happen so now I am even more
confused. I don't think I do want the latch though. I posted the reason
a few threads up but will repost with some clarifications.

The memory is not an internal memory cell. It is an external Micron
PSRAM. A PSRAM is basically a SDR SRAM with an Async Memory controller
built in. The memory is not in the device (My device is a Xilinx CR2
CPLD BTW). The design takes data that comes from a source (MI_DATA - a
Micron Imager) and pushes it to an external PSRAM (PSRAM_DATA). Then an
FX2 USB controller (FX2_DATA) pulls it from the PSRAM. So in this way
when the data comes from the imager to the PSRAM the FX2 is Z or DK.
Then the next state the PSRAM goes to the FX2 and the MI is Z or DK.

I don't think I want a latch because that complicates the timing since I
need to latch it at exactly the correct time. If I just pass it though
it makes things easier. If I start the pass early no biggie, as long as
it is valid at the time I issue the write to the PSRAM. If I latch then
when I latch becomes important.
In theory I shouldn't even need to run the data lines though the CPLD,
only control the OE lines via the CPLD. I ran them though the CPLD just
in case I had a timing issue and needed to latch them, but I don't think
that will be the case. It would be nice to not even run the data lines
though the CPLD on the next spin of the PCB. I'm using Z since so that
at some point I can try to tie the data lines together externally and
use the OE lines only not even passing the data in the CPLD.

So what I am really after is more of tri statable mux than a latch.

Am I being any clearer?. Of course it would be easier if you had a
schematic and the rest of the picture, but that is more than I feel I
Can ask of this group.

Thanx for you help

Hawker
 
On 3/22/2007 9:34 AM, The digits of Pieter Hulshoff's hands composed the
following:
Hawker wrote:
On 3/22/2007 3:00 AM, The digits of Pieter Hulshoff's hands composed the
following:
The memory is not an internal memory cell. It is an external Micron
PSRAM. A PSRAM is basically a SDR SRAM with an Async Memory controller
built in.

OK, I may have missed something here: This PSRAM_DATA, is it currently a signal
in your design or is it a bidirectional INOUT port? If it is a bidirectional
port, and if the external PSRAM will force the correct value onto the signal,
then KJ's suggestion should do the trick (I would use his 2nd suggested code;
it's cleaner). If it is an internal signal, then how does your design
communicate with this external PSRAM?

Kind regards,

Pieter Hulshoff
Click to expand...
Yes it is a bi-directional type INOUT port, to an external device. I
have an input device (MI_DATA) and Output device (FX2_DATA) and an
external In/out device (PSRAM_DATA). All the CPLD does is glue those
devices together at the correct time in the correct order. All the drive
and destination devices are external.

So now I am hearing that you agree that KJs comments are correct and
everyone is happy since we all agree. Lets bring on the trolls. There
is much harmony here - lets all go to sci.electronics.design and feed
the trolls. (he says with tongue firmly in cheek)

Thanx for your help.

Hawker
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top