UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Observer taoluwork
Observer
376 Views
Registered: ‎09-17-2018

Wierd glitch at beginning of clock

Hi experts, 

I'm running a behavior simulation in vivado 2018.3 but got wierd glitch at the begining of clock but soon changed to the correct result. 

glitch.PNG

As this picture, the data showed 0101... but soon turned into 0102. I designed this using the following patten, I'm suspecting this would be dependency issue. I've inserted the dependency directive but issue remains. Plz help..

Can anyone confirm my DEPENDENCE is correct? I'm expecting RAW within loop.  And is there any loop-carry DEPENDENCE (since i'm using "+=" style)?  Should I add another DEPENDENCE?

dependency.PNG

Thanks!

Tao

for (int i = 0; i<depth+2; i++){	//with two additional iteration
		if(i == 0 || i == depth+1){		//the initial state and final iteration
			kec-> in_data = 0;
			kec-> byte_num = 0;
			kec-> in_ready = 0;
			kec-> is_last = 0;
			kec-> reset = 1;
		}
		else if (i % 8 == 1 && i < depth){ 	// loc[1] init a round
			input_64 = (u64(mem.mem[location +i-1]) << 56);
			kec-> reset = 0;
			kec-> in_data = input_64;
			kec-> in_ready = 0;
			kec-> is_last = 0;
		}
		else if(i % 8 != 0 && i < depth){			// 2 .. 7 do real work
			input_64 += (u64(mem.mem[location + i-1]) << ((8-(i%8))*8));		//loc[1] move 56  loc[2] move 48 ...
			kec-> reset = 0;
			kec-> in_data = input_64;
			kec-> in_ready = 0;
			kec-> is_last = 0;
		} 
......

 

0 Kudos
3 Replies
Highlighted
Observer taoluwork
Observer
334 Views
Registered: ‎09-17-2018

Re: Wierd glitch at beginning of clock

Hi guys,

I finally found that this glitch was because the data from BRAM arrive slightly later than the clock edge. The time difference is too small compared to the clock period. But could this harm the correctness? Is this normal in using BRAM? I've set BRAM latency = 2 and BRAM has output register selected.

bram late.PNG

Thanks.

0 Kudos
Observer taoluwork
Observer
329 Views
Registered: ‎09-17-2018

Re: Wierd glitch at beginning of clock

Hi, 

I finally find this:

https://www.xilinx.com/support/answers/45572.html

The link explained that the delay was reflecting the hardware delay, which makes sense. But how should I delay the clock to catch up the correct value? My module is designed in HLS and timing report showed no conflict. I'm still curious how to solve this. Any tips and suggestion is most appreciated!

Tao

0 Kudos
Observer taoluwork
Observer
281 Views
Registered: ‎09-17-2018

Re: Wierd glitch at beginning of clock

I found that the final result was actually calculated using the correct value, although the glitch is obvious. However, I only tried this in pre-synthesis simulation. I'll update later if it works for on-board test and post-synthesis simulation.

0 Kudos