cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Observer
Observer
13,949 Views
Registered: ‎01-12-2012

DIN has to be stable during 2 cycles for insertion with FIFO generator v8.1

Jump to solution

Hi everyone,

 

have been using FIFO generator v4.4 and v5.3 and I never had any problem with it. With FIFO generation v8.1 (comes with ISE 13.1), I have notice an unusual situation with the fifo. The DIN signal must be stable for 2 clock cycles for proper insertion.

In the following example (see pictures), I am trying to add the value 0xF. When I am not writing into the fifo, the default set value is 0xFFFFFF for DIN.

 

For my first test, look at first picture (1 cycle DIN stable), the actual data written is 0xFFFFFFFF. I expected to have 0xF.

In the second test, look at second picture (2 cycles DIN stable), the actual data written is 0xF but notice DIN is stable for 2 cycles.

 

fifo generator.JPG

 

I am using the structural model with following options/features:

  • Native
  • Independent clocks (block ram)
  • 32 bits width
  • FWFT
  • 128 words depth (actual is 129 since FWFT)
  • Extra logic for data count (8 bits width for write and read data count)

 

I have looked into the documentation and I have not found any reference to this.  Am I missing something there ?

 

Thanks

Tags (1)
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Observer
Observer
21,019 Views
Registered: ‎01-12-2012

Hi,

 

Thank you very much for all you help. Routing the Clk directly to the UUT works! I didn't know about this catch and I will take care about it!

 

Much appreciated!

View solution in original post

0 Kudos
9 Replies
Highlighted
Professor
Professor
13,942 Views
Registered: ‎08-14-2007

I would suspect that this is a simulation issue.  First make sure that your test bench is

providing at least a delta delay for hold time on the DIN signal.  Then be sure to use

the structural model for the FIFO (this has to be set up in the CoreGen options when

you generate the FIFO) rather than the behavioral model.  The behavioral FIFO models

are broken.

 

-- Gabor

-- Gabor
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
13,937 Views
Registered: ‎06-01-2011

On addition to what Gabor said.  You should put the cursor at the rising edge of the clock and check that at this moment, both the data and the enable bits are set correctly (the data is correct and the enable bit is high).

0 Kudos
Highlighted
Observer
Observer
13,931 Views
Registered: ‎01-12-2012

Hi,

 

I am currently using the structural model since, of course, the behavioral model is broken.

 

When using v4.4 and v5.3, my test bench does not failed. I mean, I got the expected behaviour with no extra latency. However, how do I adjust the delta delay hold time for the DIN signal using Modelsim 6.6 ?

 

Here is another picture where I put the cursor on the next rising edge of WR_CLK. On this picture, we notice that both WR_EN and DIN signals are properly set.

rising edge.JPG

 

Thanks

0 Kudos
Highlighted
Professor
Professor
13,921 Views
Registered: ‎08-14-2007

When using v4.4 and v5.3, my test bench does not failed. I mean, I got the expected behaviour with no extra latency. However, how do I adjust the delta delay hold time for the DIN signal using Modelsim 6.6 ?

 

The value of the "delta delay" in real time is always zero.  So in effect you don't change it.  When

you have simulation code that works with one simulator or revision and not another, it is quite

likely that there is a "race condition" that causes the problem.  In simulation, a race condition

is resolved by the order in which the various processes run in the simulator.  Normally the order

should not matter.  A race condition means your code can produce different results given

different choices by the simulator as to which process runs first.

 

If DIN is coming from your test bench, then the first thing to try is to add a real time delay

(VHDL wait for 1 ns, or Verilog #1 for example) to the data assignment.  If that fixes the

issue, it tells you that the FIFO behaves correctly, but there is some issue with the data

assignment in the test bench.

 

In Verilog it is easy to creat race conditions if you use blocking assignments where

non-blocking assignments should have been used.  For example:

 

@ (posedge clk) DIN = 16'hf000;

 

vs

 

@(posedge clk) DIN <= 16'hf000;

 

The first instance will not add the delta delay, the second instance will.  On the waveform,

the signals look identical because there is no real time associated with the delta, but

the processing of the model at the clock's rising edge can be very different between the

two cases.

 

You can have the same problem if you don't use the clock to generate the DON signal like:

 

always clk = #5 !clk;

 

initial begin

  #15 DIN = 1;

  #25 DIN = 0;

end

 

Here clk and DIN change at exacly the same time, however in two different processes.

If the processes are handled as written, top to bottom, then the clock will effectively

precede DIN, and the model may work.  However there is no requirement for simulation

to run the processes in the order they were written, so it is also possible that DIN

is seen to change just before the clock edge, which breaks the model.

 

-- Gabor

-- Gabor
Highlighted
Observer
Observer
13,910 Views
Registered: ‎01-12-2012

Hi,

 

Thank you for the clarification. In fact, I have one process which updates both signals (WR_EN and DIN). See the attached testbench. The clock I use in my testbench is the same for rd_clk and wr_clk. Everythink is synchronous to the rising edge of the main clock.

 

0 Kudos
Highlighted
Professor
Professor
13,905 Views
Registered: ‎08-14-2007

Yes, your test bench looks pretty clean.  So then it's likely to be a problem

with the simulation model.  I would suggest trying a non-zero time delay

when you assign the inputs to the FIFO.  My VHDL isn't too good, but

something along the lines of:

 

        when perform =>
          -- Write data
          din <= std_logic_vector(to_unsigned(15,32)) after 1 ns; -- or even 1 ps
          wr_en <= '1' after 1 ns;
          testbench_state <= idle;

I have seen some cases where the models from Xilinx, especially VHDL models, have

had problems with their clock connctions that caused incorrect simulation when no real

hold time is applied to the inputs.  I seem to remember older versions of the BRAM VHDL

models had this same issue.

 

-- Gabor

-- Gabor
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
13,902 Views
Registered: ‎11-28-2007

The line below is the problem because VHDL automatically adds a delta delay everytime a signal is assigned to another signal. You can either

  • replace all wr_clk in your testbench with Clk, or
  • use wr_clk for the "THREAD" process, or
  • as Gabor suggested, add delay to wr_en and din before connecting them to the FIFO.

 

  -- Basic signal driving
  wr_clk <= Clk;

Cheers,
Jim
Highlighted
Professor
Professor
13,895 Views
Registered: ‎08-14-2007

Good catch, Jim.  I believe a similar problem caused the issues with the older BRAM models.

 

I usually code with Verilog, which does not add the delta delay for continuous assignments.

 

So the solution is to connect Clk directly to the UUT ports in the test bench rather than assigning

the individual clock signals.

 

-- Gabor

-- Gabor
0 Kudos
Highlighted
Observer
Observer
21,020 Views
Registered: ‎01-12-2012

Hi,

 

Thank you very much for all you help. Routing the Clk directly to the UUT works! I didn't know about this catch and I will take care about it!

 

Much appreciated!

View solution in original post

0 Kudos