cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
947 Views
Registered: ‎12-18-2017

Synthesis Issue: ADC Deserializer

Jump to solution

I'm curently designing a ADC controler to manage the serial data sent from a ADC (LTC2323-16) into a Zynq-7000, but timing failures poped up and we are trying to solve them.

 

One solution was changing the Verilog code of the deserializer block, following UltraFast Methodology's orientation.

 

Old code:

  

always @(posedge clk or posedge rx_reset)begin	
    if(rx_reset)	
		bit_index = msb_bit_index;
	else begin   	
		parallel_data[bit_index] = sdo;
		if(bit_index >= 1)
		 	bit_index = bit_index - 1;	
	end   
end 

  

New code:

  

always@(posedge rx_reset) bit_index = msb_bit_index;
    
always @(posedge clk)begin
	parallel_data[bit_index] = sdo;	
	if(bit_index >= 1)
     	bit_index = bit_index - 1;
end 

The thing is, after the change, timing issues (mostly Hold) were greatly improved, but Post-Synthesis Functional Simulation went bad.

  

Behavioral Simulation (New Code):

 

behav_new.JPG

 

Post-Synthesis Fuctional Simulation (New Code):

 

post-synth_new.JPG

 

So I believe that Synthesis is messing up something, but can't quite know what.

 

I hope someone could give me some guesses or orientations.

 

Thanks in advance

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Moderator
Moderator
1,011 Views
Registered: ‎07-21-2014

Re: Synthesis Issue: ADC Deserializer

Jump to solution

@matheusmpl91

 

The code mentioned in user guide talks about how to separate sync and async reset flops into separate process/always block, here you are using one always block to reset the flop and other always block to register the data, which looks incorrect to me and this is a case of multi-driver issue.

 

As you are facing timing related issues, better to start a new thread under Timing Analysis board with timing report of critical paths and also share the snapshot of the schematic. Also, try to use different implementation strategies and see if you can get better results.

 

Thanks,

Anusheel

View solution in original post

3 Replies
Highlighted
Moderator
Moderator
913 Views
Registered: ‎07-21-2014

Re: Synthesis Issue: ADC Deserializer

Jump to solution

@matheusmpl91

 

Are you referring to below section of UG949:

 

Capture.PNG

Thanks

Anusheel

0 Kudos
Highlighted
Visitor
Visitor
883 Views
Registered: ‎12-18-2017

Re: Synthesis Issue: ADC Deserializer

Jump to solution

Yes, that's the one.

 

I ran a DRC Check and it pointed a multiple drivers issue when I split the block into two always blocks, because bit_index is being used in both ones, so it stays undefined.

 

The thing is, rx_reset is being treated as a asynchronous reset, but in fact is a well defined signal, genetared in another module by another clock: 

 

always @ (posedge clk)
	if (count == trx_reseth)
		rx_reset <= 1'b1;
	else if (count == trx_reseth + rx_reset_length)
		rx_reset <= 1'b0;
	else
		rx_reset <= rx_reset;

Should I set it as false_path or try to define it as a generated_clock

 

Sorry if I'm making ingenuous questions... I'm new to Xilinx, Vivado and all this Digital Systems Design universe.


Thanks for the patience and for the assistance

 

0 Kudos
Highlighted
Moderator
Moderator
1,012 Views
Registered: ‎07-21-2014

Re: Synthesis Issue: ADC Deserializer

Jump to solution

@matheusmpl91

 

The code mentioned in user guide talks about how to separate sync and async reset flops into separate process/always block, here you are using one always block to reset the flop and other always block to register the data, which looks incorrect to me and this is a case of multi-driver issue.

 

As you are facing timing related issues, better to start a new thread under Timing Analysis board with timing report of critical paths and also share the snapshot of the schematic. Also, try to use different implementation strategies and see if you can get better results.

 

Thanks,

Anusheel

View solution in original post