can this verilog description be synthesized?

[Rainboww]

verilog description

always block is embeded a "@ "event,just as:
……
always@(posedge a)
……
if(……)
@(posedge b) ……
……
……

endmodule

this description can be synthesized?why?

 

[armer]

modulo verilog

The code cann't be synthesised! There is no such device, i think. Why write code like this?

 

[the_penetrator]

can verilog function be synthesized

Mixing clock domains or different clocks in the same module. Cannot be synthesized and really shouldn't after all.
Nor is good practice to write always @(posedge a) and somewhere
in any hierarchy always @(negedge b).
Drive your logic by: always @(posedge a) or negedge a only, to have posedge or negedge triggered ffs or latches.


pene

 

[Rainboww]

modulo in verilog

you means the code must be written either "always@(posedge a or posedge b)",or "always@(negedge a or negedge b)",right?

but it seems that i have met a case just like:
“always@(posedge clk or negedge reset)
begin
if(!reset)
……
……
end
……”

how to interpret this situation？？？

3x a lot

 

[buzkiller]

how is verilog negedge synthesized

The statements inside "always@(posedge a)" must be strictly combinatorial.

regards,
Buzkiller.

 

[the_penetrator]

what codes cannot be synthesized in verilog

Agree with buzkiller. Anything inside the clocking statement
should be pure combie, of course in either VHDL or Verilog.

Rainboww, you infer doing combinational functions on clocking
signals. That is very bad, and in reality it shall suffer from phase shifts
and other stuff (noise, unecessary transitions).

NEVER PERFORM COMB-FUNCTIONS ON CLOCK. If you want to generate another clock from existing one, e.g. divide clock by modulo-N counter. Take registered output.

pene

 

[shell3]

modulo function in verilog

It is perfectly valid to write :

always @ ( negedge RESETN or posedge CLK ) begin
if ( !RESETN )
COUNT<= 0;
else
COUNT<= COUNT + 1;
end

This the implementation of synchronous counter with asynchromnous active-low reset.

 

[andromeda]

clock divider cliff cummins

It is good idea to consult "Reuse Methodology Manual" book and OpenMORE Assesment program (Synopsys/Menthor Graphics) about general coding style (not only for reusability).

A few basic rules:
1. Never mix combinational and sequential logic in same process (always statement)
2. Only one clock per module
3. Clearly define clock domains and develop synchronization strategy between them
4. Put clock generation logic in separate module. Try to use clock gating for clock generation (if duty cycle isn't important). If you must use clock divider, output must be registered (use generated clock in DC for synthesis purpose).

Very interesting document about this topic (and datapath synchronization) is:
"Synthesis and Scripting Techniques for Designing Multi-Asynchronous Clock Design" from Clifford E. Cummings (SNUG San Jose 2001)