Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
8 years ago

Mega Wizard dual Clock FIFO Strange behavior !!!!!

Hullo guys , I have a Cyclone ||| board and im working on an application that uses dual clock 16-bit , 16-word deep FIFO . The write signal and clock r from the FPGA itself, and the read signal and clock r from external MCU. Everything is working fine , except when I write certain value to the FIFO , then the whole operation is acting weird . For example when I write 0xFFFF the values are not latched to the FIFO and I keep reading from the FIFO strange values and the empty flag never gets set !!!! . At first I thought it was a problem with the IOs of the FPGA , but I tried to display 0xFFFF to the IOs and they were working fine .

Any explanation ????

9 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    Not really a lot of detail - are you sure write enable is low? are write enable and read enable are synchronised with the correct clocks? Are you sure the read enable is even asserted?

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    --- Quote Start ---

    Not really a lot of detail - are you sure write enable is low? are write enable and read enable are synchronised with the correct clocks? Are you sure the read enable is even asserted?

    --- Quote End ---

    Every thing is working fine man , I can fill and empty the FIFO correctly , for example if I fill the FIFO with 0x00FF it works fine , but when I use values like 0xFFFF , it becomes a mess . The test bench I wrote for the design is giving correct results no matter what values are used , so the operation is verified. The problem only occur in practice . I know its a pretty confusing problem , but I still can not find explanation !!!!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    The DCFIFO is a very old and very well tested IP, so I can only assume there is a problem with your design. the data path has no link to the control path at all, so your problems are impossible. The only issue can be a design issue.

    Can you post the code ? or the project?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    --- Quote Start ---

    The DCFIFO is a very old and very well tested IP, so I can only assume there is a problem with your design. the data path has no link to the control path at all, so your problems are impossible. The only issue can be a design issue.

    Can you post the code ? or the project?

    --- Quote End ---

    This is the main code , with the FIFO generated code and a picture of the FIFO Configurations . I simply Fill in the FIFO , then try read the values till it gets empty .
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    WHy do you have a lot of tri-states? they are only driving an out pin?

    where does the rdclk and rden come from?

    what state is your state machine in when it "doesnt work"?

    does the design meet timing?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    Also, you realise your design only ever writes a single word to the FIFO?

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    --- Quote Start ---

    Also, you realise your design only ever writes a single word to the FIFO?

    --- Quote End ---

    The rd_en and rd_clk come from the external microcontroller , the tri-state are there because in the full design the microcontroller would read and write to different FIFOs , but when i noticed this problem , i simplified the design just to help solve it . The design meets the timing constraints . U see the value that I write to the FIFO is (out_D<="0000111111111111"; )

    or 0x0FFF in hex , the design is working fine with this value , but the problem is that if u just only change this value to 0xFFFF the operation screws !!!!!! , and again just changing this value to say 0x00FF the design works well again !!!!!!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    have you somehow connected some of the data bits back to the output enable. Can you trace the paths on the PCB?

    Without all the info, I can only guess whats wrong. It is definitely a design issue.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    --- Quote Start ---

    The rd_en and rd_clk come from the external microcontroller , the tri-state are there because in the full design the microcontroller would read and write to different FIFOs , but when i noticed this problem , i simplified the design just to help solve it . The design meets the timing constraints . U see the value that I write to the FIFO is (out_D<="0000111111111111"; )

    or 0x0FFF in hex , the design is working fine with this value , but the problem is that if u just only change this value to 0xFFFF the operation screws !!!!!! , and again just changing this value to say 0x00FF the design works well again !!!!!!

    --- Quote End ---

    A possible scenario is that MSBs are corrupt across io. I don't know how you are observing result or what you mean by screw-up but one test is to pass MSBs as ones and LSBs as zeros e.g. 0xF000

    As stated dc fifo cannot go wrong if interfaced correctly.