FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
5949 Discussions

Strange problem with DCFIFO

Altera_Forum
Honored Contributor II
860 Views

Hi, 

in my design, I'm using two dual clock FIFOs for buffering. While one is running without any problem, the other one is doing something strange when loading the design to the FPGA (DE1-SoC). 

 

Some details: The FIFO has a writing clock of 25MHz and a reading clock of 143MHz, overflow / underflow protection are enabled and it has a size of 16bit x 512 words. I'm using the rdusedw (named as FIFO_READUSED) port 

to generate my own request signal (c_mem_xxx are integer constants) 

signal s_read_used : integer range 0 to 511; signal s_data_request : std_logic_vector (1 downto 0); .... (some lines removed) ... --generate DATA_REQUEST signal s_read_used <= to_integer(unsigned(FIFO_READUSED)); <===(1) --s_read_used <= 260; <===(2) s_data_request <= "11" when (s_read_used > c_mem_high) else "10" when (s_read_used >= c_mem_half) else "01" when (s_read_used > c_mem_low) else "00"; ....  

 

The strange thing is, that the simulation runs as expected but when loading the design on the FPGA is behaves strange. I've connected some of the rdusedw signals to the LEDRs on the board as well as my data request signal 

to observe them. Now when I'm using line (2), everything is fine. But when I'm using line (1) the FIFO seems to get stuck (the rdusedw signal is stuck at 0 and so does my data_request signal). I really have no idea about the  

reasons... 

My second FIFO is implemented in exactly the same way with the difference that I'm using the wrusedw signal - and this FIFO is running as expected.  

 

So, does someone have any idea about what's going on here? 

I've tried a lot of different things (e.g. removing the integer things and using only unsigned, ...) without finding a solution. 

 

Best, 

Martin
0 Kudos
5 Replies
Altera_Forum
Honored Contributor II
90 Views

Sounds like a timing related issue - does the design meet timing?  

(2) will work because it is a constant, and hence s_data_request will be optimised.
Altera_Forum
Honored Contributor II
90 Views

Thanks for your reply. 

 

Yes, I don't have any warning generated by TimeQuest when using the PLL reset sources. When using my reset logic, I get 4 warnings (probably because I haven't added constraints in the sdc file yet). 

However, I observe the mentioned behavioral in both cases.
Altera_Forum
Honored Contributor II
90 Views

Any other ideas?

Altera_Forum
Honored Contributor II
90 Views

Ok, I did some further investigations but still I have no idea why this is happening. 

 

I don't think that the problem is timing related since I get no message from Time Quest around this part of the design. 

Like written above, I use some of the LEDs of the DE1-SoC board to display the current value of rdusedw. 

When I use this signal in any possible way (like simply forwarding two of the bits), all LEDs stay dark indicating the FIFO to be always empty. But when I remove every line of VHDL code containing the rdusedw signal, the  

LEDs show the current value of elements stored in the FIFO as expected. 

 

So is there something is miss or do I have to add special Contraints to the SDC file to see if something is wrong with the timing? 

 

PS: I took a closer look on the RTL schematic and there is nothing between the output register of the FIFO and the input register of my design (when reading the rdusedw inside my clocked process @143MHz)
Altera_Forum
Honored Contributor II
90 Views

Why not post the code/project that exhibits the problem?

Reply