Getting Latch when don't want.

Discussion in 'VHDL' started by Pieter Hulshoff, Mar 19, 2007.

  1. 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;


    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
     
    Pieter Hulshoff, Mar 19, 2007
    #1
    1. Advertising

  2. Pieter Hulshoff

    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, Mar 19, 2007
    #2
    1. Advertising

  3. Pieter Hulshoff

    Hawker Guest

    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

    Thanx
    Hawker
     
    Hawker, Mar 19, 2007
    #3
  4. 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


    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
     
    Pieter Hulshoff, Mar 20, 2007
    #4
  5. 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,

    Pieter Hulshoff
     
    Pieter Hulshoff, Mar 20, 2007
    #5
  6. Pieter Hulshoff

    Hawker Guest

    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.

    Hawker


    >
    > Regards,
    >
    > Pieter Hulshoff
     
    Hawker, Mar 20, 2007
    #6
  7. Pieter Hulshoff

    Hawker Guest

    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,
    >\


    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, Mar 20, 2007
    #7
  8. Pieter Hulshoff

    KJ Guest

    "Hawker" <Hawker{removethispart}@ashevillecommunity.org> wrote in message
    news:...
    >
    > 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.
    >


    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
     
    KJ, Mar 21, 2007
    #8
  9. Pieter Hulshoff

    Hawker Guest

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



    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
     
    Hawker, Mar 21, 2007
    #9
  10. Pieter Hulshoff

    KJ Guest

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


    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
     
    KJ, Mar 21, 2007
    #10
  11. 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.


    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
     
    Pieter Hulshoff, Mar 22, 2007
    #11
  12. 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
     
    Pieter Hulshoff, Mar 22, 2007
    #12
  13. Pieter Hulshoff

    Hawker Guest

    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



    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
     
    Hawker, Mar 22, 2007
    #13
  14. Pieter Hulshoff

    Hawker Guest

    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


    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
     
    Hawker, Mar 22, 2007
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. dangerlee

    logical left shifter or latch ??

    dangerlee, May 5, 2004, in forum: VHDL
    Replies:
    4
    Views:
    849
    Egbert Molenkamp
    May 7, 2004
  2. Lee
    Replies:
    3
    Views:
    3,722
  3. Patrick
    Replies:
    5
    Views:
    581
    Thomas Stanka
    May 28, 2004
  4. M.A.Khader

    Beginner: Simple D latch

    M.A.Khader, Aug 19, 2004, in forum: VHDL
    Replies:
    3
    Views:
    5,103
    ivailokroumov
    Aug 19, 2004
  5. bob
    Replies:
    1
    Views:
    4,353
    Tim Hubberstey
    Feb 15, 2005
Loading...

Share This Page