Suddenly program disapperas on fpga

[chaitusvk]

Hi @D@n,

 

I am decoding IRIG signal ,some times all my outputs dissapper ,

1. when i remove unused register it was working fine .

  in my fsm there are states where reaching is not trivial only are 1hour i can reach the state ...

 

2. when i dont connect all output signals in xdc file also leads to disaapring of signals  

 

3. is there any racing condition ...

please help me ...

[D@n]

@chaitusvk,

From what you've given, I'm not sure what you are describing in total.  I do know this, however: if you don't define all your inputs and outputs in the XDC file, then the synthesis tool won't do what you want.

Hardware synthesis tools will aggressively optimize your design.  If your design creates an output that doesn't get sent to a pin, then any logic leading up to that output may be validly removed.  This is usually considered a good thing, although it has been known to surprise beginners.

Dan

[chaitusvk]

Thank you @D@n ..

Sorry for my poor description 

i figured it out today ..

. 

 

i am connecting one of pins(Mark) of my IP to interrupt of processor if i remove this evering is working fine ..for 1hour ...

i think this is beacuse of Infering latches ..please confirm me  ..

if i connect it my ip to interrupt pin of processor it will be power down my ip with in 5 minutes ...

Thank you .....

[D@n]

@chaitusvk,

I'm not sure quite what problem you are struggling with, but I do know one thing: this is not how you go about solving a problem in hardware.  Sometimes I can recognize a pattern in software and know exactly where to go for a bug, but that's been rarely the case in hardware.  You have a couple of basic solutions available to you here to help you dig:

1. My first step when debugging Verilog logic is to enable default_nettype of none, and to then run Verilator -Wall on the design.  This won't necessarily catch any latches.
2. I would then formally verify any modules of your own.  The fact that Xilinx's demonstration modules have known bugs in them that are easily discovered via formal methods should be a motivation for not trusting either their demo IP or their AXI verification IP.  This will also catch many potential inferred latches.
3. I would then make certain your design passes a simulation check.  Can you simulate the whole design, including the MiroBlaze CPU, through the operation that's failing?  Once you can do that, you are well on your way to finding the bug.
4. Bugs should not escape the first two checks.  Make that your goal.  If they do, however, you have one other approach to debugging: find the signals in question and capture them using an Internal Logic Analyzer (ILA) of some type.  Xilinx offers one, although I tend to use my own.  Capture time is limited, so you'll want to find a way to know that the design has halted and to trigger off of that.

You can read of one of my own debugging stories here, in case it helps at all.

If you'd like, then feel free to share your AXI design here and we can look at it and discuss it.

Dan

 

[chaitusvk]

Thank you very much @D@n 

you are a great mentor ...

i have solved it ...it is issue of  async counter

module decade_counter(
    input clk,
    input reset,
    input load,
    input[3:0] data,
    output [3:0] hours_u_count
    );
    
    reg[3:0] count;
    
    always@(negedge clk or posedge load or posedge reset)
    begin
    if(reset)
      count <= 4'b0000;
    else
    begin
    if(load)
    begin
     count <= data ;
    end
    else
    begin
      if(count == 4'b1001)
        count <= 4'b0000;
      else
        count <= count +1;
    end
    end
    
    end
    
    assign hours_u_count = count;
endmodule

In this counter i am issuing load and reset at almost same time ..  this counter is not working properly ...if i remove this every thing is fine..

i conveted it to sync counter 

 

[D@n]

@chaitusvk,

If you look through my rules for beginners, one of them is that you should *only* transition on the positive edge of your clock--nothing else.  Most people don't quite think through the subtle clock implications of transitioning on other than a clock.  If your non-clock transition happens too close to a clock edge, you could easily end up with a physical instability.  The other half of that problem is that most tools, Vivado among them, can't handle the subtle timing requirements either.

Try rebuilding that block so that it's on the @(posedge clk) and nothing more.  See what happens.

Yours,

Dan

[zygot]

8 hours ago, D@n said:

you should *only* transition on the positive edge of your clock

Perhaps a better 'rule' would be that using only one of the two edges of a clock for synchronous logic throughout a design results in fewer questions that needs to be answered relative to  using both edges. Which edge you choose depends on the external hardware requirements. In a similar way using only one clock in a design results in avoiding a much greater list of things that have to be considered and resolved. It's all about timing. Analyzing the timing of two signals relative to each, or even one signal at point A in the physical implementation of  a design relative to point B isn't obvious or intuitive to those new to logic design.... and trips up those with enough experience to know better on a regular basis.

Another 'rule' would be to master the simple stuff before trying to do things that require complicated stuff and the accompanying complicated analysis of what's happening to your signals relative to each other at every instant of time. Same with HDL. Master basic structures like simple counters, shift registers, state machines, etc. before adding a lot of flourishes that your aren't familiar with.

I'd like to say that you can learn a lot about timing by using your simulator but unfortunately the waveform viewer tends to create a visual presentation that leads to bad inferences by those who don't really understand what is going on behind the waveform picture scene. Still, I do encourage everyone, from complete newbie to seasoned pro to make the simulator your BFF. By simulation I mean writing a testbench for every module or entity that you create. You can always manually introduce delays to help the simulator waveform render a visual presentation that clears up ambiguity. You can improve your timing IQ just by trying out some simple design simulation experiments. Once you master behavioral simulation you can start adding timing simulation to your verification toolbox. 

Unfortunately, Vivado doesn't encourage proper simulation habits. ModelSim is much more conducive to encouraging good design practice and is still available for free with Intel's Quartus tools. You still have the problem of waveform rendering ambiguity to understand but managing lots and lots of testbenches is less of a hassle. For pure HDL that doesn't contain vendor specific IP, primitives, or resource features I use ModelSIm even for Xilinx design projects when possible.

[zygot]

8 hours ago, D@n said:

The other half of that problem is that most tools, Vivado among them, can't handle the subtle timing requirements either.

Do elaborate please.

[zygot]

On 1/13/2021 at 11:46 PM, D@n said:

The other half of that problem is that most tools, Vivado among them, can't handle the subtle timing requirements either.

@D@n, This statement, without context, implies that there are programmable logic designs that shouldn't be attempted with Xiinx FPGA devices due to  shortcomings in their current synthesis and timing analysis tools. It's not the kind of thing that can be dropped on a public forum and forgotten about. At least clarify your assertion.

If you have specific personal experience supporting this then a discussion would be of general interest to a wide audience.