cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
johnkaz77
Observer
Observer
13,300 Views
Registered: ‎10-14-2010

Error: Unexpected embedded clock statement in sequential description for signal

Hello,I'm trying to use a signal as a clock inside a case structure,in order to send some data serially.However, i run across this error,can i resolve this or should i find another way to synchronize tha data I receive and send?(I'm using this Spartan 3AN FPGA as an intermediate through a USB controller which sends the data asynchronously and an another FPGA which should receive tha data)

0 Kudos
7 Replies
joelby
Advisor
Advisor
13,298 Views
Registered: ‎10-05-2010

Is there any chance you could share the code for the module that is causing this error?

0 Kudos
johnkaz77
Observer
Observer
13,294 Views
Registered: ‎10-14-2010

This the code.The error appears for lines 99-106

0 Kudos
rcingham
Teacher
Teacher
13,292 Views
Registered: ‎09-09-2010

The unamed process at line 94 (ALWAYS NAME YOUR PROCESSES!) is probaly meant to infer a clocked FSM. Therefore include only the clock (in this case 'CLK_USB') in the sensitivity list.

BTW, why are you using the falling edge of that clock?

------------------------------------------
"If it don't work in simulation, it won't work on the board."
gszakacs
Instructor
Instructor
13,285 Views
Registered: ‎08-14-2007

Just a few things:

 

inout signal FDPORT is never assigned anything other than 'Z", so why not just make it an input?

 

There are no internal flip-flops that can be clocked on more than one clock, and the only IOB

flops with two clock inputs must be instantiated rather than inferred.  So basically the idea

of using an event trigger inside a clocked block results in logic that cannot be synthesized.

 

If you need to check for changes in FDPORT, you should delay it with a register and check that

the register and FDPORT are not the same value.

 

As already noted, a clocked process should have at most two signals (clock and reset) in the sensitivity list,

and only one (the clock) when there is no asynchonous reset.  There are language templates that show

the structure to infer flip-flops properly.

 

-- Gabor

-- Gabor
0 Kudos
eteam00
Professor
Professor
13,283 Views
Registered: ‎07-21-2009

I will demonstrate how NOT to implement edge detection and asynchronous inputs to a state machine (e.g. 'FDPORT' in the code snippet from post #3 in this thread), with three examples written in (pseudo) Verilog.  The fourth example is a design which successfully addresses the problem.

 

Example #1:  Straight input to a state machine using states for edge detection.


input   clock, async_in;

reg   [3..0]  state = idle;
reg           in_dly1, in_dly2, in_dly3, edge_flag;
reg           edge_flag;

wire          edge_detected;

always @(posedge clock)
  case (state)


    idle:  begin   // wait for a low level on asynchronous input async_in
       edge_flag <= 0;
       if (async_in == 0)  state <= found_zero;
       end
       
     found_zero:  if (async_in == 1)  state <= found_edge;

     found_edge:  begin   // rising edge found, set a flag, loop back to idle state
       edge_flag <= 1;
       state <= idle;
       end

 

    endcase

 

In example #1, the async_in input signal will propagate through to the inputs of the 4 bits of state registers at different times.  This is because the interconnect delays are not matched -- and they cannot be matched.  The delay mis-match can be more than a nano-second.  If a transition of async_in occurs as the signal is being sampled, the odds are very very good that the various state machine bits will sample different values of async_in.  If at least one state bit will see a '0' and at least one state bit sees a '1', then the state machine will fail.  The normal symptom is 'lockup'.

 

 

Example #2:  Single-register logic for edge detection.


input   clock, async_in;

reg   [3..0]  state = idle;
reg           in_dly1, in_dly2, in_dly3, edge_flag;
reg           edge_flag;

wire          edge_detected;

always @(posedge clock)  in_dly1  <= async_in;  // delay input one clock cycle

assign  edge_detected = async_in && !in_dly1;   // async_in was '0', now '1', rising edge detected

 

always @(posedge clock)
  case (state)


    idle:  begin   // wait for a low level on asynchronous input async_in
       edge_flag <= 0;
       if (edge_detected == 1)  state <= found_edge;  // edge found!
       end
       
     found_edge:  begin   // rising edge found, set a flag, loop back to idle state
       edge_flag <= 1;
       state <= idle;
       end

 

    endcase

 

In example #2, the async_in input signal has the same problem as in example #1.  It will still propagate through to the inputs of the 4 bits of state registers at different times, through the signal edge_detected.  The single delay register for async_in is not sufficient.

 

 

Example #3:  Two-register logic for edge detection.


input   clock, async_in;

reg   [3..0]  state = idle;
reg           in_dly1, in_dly2, in_dly3, edge_flag;
reg           edge_flag;

reg           edge_detected;

always @(posedge clock)  in_dly1  <= async_in;  // delay input one clock cycle


always @(posedge clock)  edge_detected = async_in && !in_dly1;   // async_in was '0', now '1', rising edge detected

always @(posedge clock)
  case (state)


    idle:  begin   // wait for a low level on asynchronous input async_in
       edge_flag <= 0;
       if (edge_detected == 1)  state <= found_edge;  // edge found!
       end
       
     found_edge:  begin   // rising edge found, set a flag, loop back to idle state
       edge_flag <= 1;
       state <= idle;
       end

 

    endcase

 

In example #3, it looks like the input to the state machine is properly registered and problem-free.  Yes, but a slightly different problem has been created.  async_in is still sampled at two different registers.  As before, the propagation delay mismatch to these two registers will inevitably result in either missed edges (register in_dly1 sees async_in transition a cycle earlier than register edge_detected) or double  triggers (register edge_detected sees async_in transition a cycle earlier than register in_dly1).  This two-register solution for async_in is not sufficient.

 

 

 

 

Example #4:  Another two-register logic solution for edge detection.


input   clock, async_in;

reg   [3..0]  state = idle;
reg           in_dly1, in_dly2, in_dly3, edge_flag;
reg           edge_flag;

wire          edge_detected;

always @(posedge clock)  in_dly1  <= async_in;  // delay input one clock cycle

always @(posedge clock)  in_dly2  <= in_dly1;   // delay input a second clock cycle


assign  edge_detected = in_dly1 && !in_dly2;    // async_in was '0', now '1', rising edge detected

always @(posedge clock)
  case (state)


    idle:  begin   // wait for a low level on asynchronous input async_in
       edge_flag <= 0;
       if (edge_detected == 1)  state <= found_edge;  // edge found!
       end
       
     found_edge:  begin   // rising edge found, set a flag, loop back to idle state
       edge_flag <= 1;
       state <= idle;
       end

 

    endcase

 

In example #4, async_in is sampled at a single register: in_dly1, eliminating the problem of mismatched delays and disagreement between multiple sampling points.  The output of in_dly1 is aligned to the clock, and is safe for distribution to clocked logic in the design -- including the multi-bit state machine. The standard static timing analysis tools apply for the output of register in_dly1. This two-register solution for async_in is sufficient for aligning this asynchronous input to the synchronous system.

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
bassman59
Historian
Historian
13,248 Views
Registered: ‎02-25-2008


@johnkaz77 wrote:

Hello,I'm trying to use a signal as a clock inside a case structure,in order to send some data serially.However, i run across this error,can i resolve this or should i find another way to synchronize tha data I receive and send?(I'm using this Spartan 3AN FPGA as an intermediate through a USB controller which sends the data asynchronously and an another FPGA which should receive tha data)


THINK HARDWARE.

 

How are you supposed to look for the edge of a clock on the edge of a different clock?

That's what your source code is essentially saying.

----------------------------Yes, I do this for a living.
0 Kudos
farazk86
Visitor
Visitor
12,797 Views
Registered: ‎05-30-2012

great explanation. Thanks a lot
0 Kudos