[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[oc] Sequential processing in Verilog (was Sequential processing inVHDL? Whats the best way to do it?)



>Hi,
>
>the original question was "Sequential processing in VHDL? Whats the best way
>to do it?". Well I now have the answer, quite simple really. The answer is
>"forget VHDL and just do it in Verilog". After all the crap I had from
>Webpack for various reasons I decided to try Verilog instead. Now I'm not
>going to use VHDL again as Verilog is just so much better. I wrote a small
>program to flash the LED in Verilog to get to grips with the language. It
>was easier than learning VHDL from scratch. Then with Damjan's kind
>assistance converted my FSM test model into Verilog but unlike the VHDL
>version this one works! LED on for 1 second, off for 7 as it should be.
>

I don;t think VHDL is necessarily the problem, but we don;t want to get into the Verilog vs VHDL war :-)  Verilog is probably easier to generate to as its less verbose anyway!

<snip>
>Martin, I've included my latest FSM test program (now in Verilog). If you
>know VHDL then its quite simple to understand Verilog, took me about an hour
>to do this program from scratch (even with Webpack fighting me along the
>way). I'll code the C-to-Verilog program in ANSI-C (wherever possible) so it
>can be compiled under any O/S out there.
>

See some comments in amongst it...

>module verilog(CLK0,LED);
>    input CLK0;
>    output LED; reg LED ;
>
>wire CLK ;
>reg [21:0] COUNT ;
>reg slow_clock ;
>reg [2:0] state ;
>// Divide the external 4MHz clock by 2^23 with a counter to produce a 1Hz
>clock (slow_clock)
>
>BUFG U3 (.I(CLK0), .O(CLK));	// Fudge as Webpack doesn't include this as it
>should
>
>initial
>begin
>	// Can't have a reset pin function hence just one reason why Verilog	is
>some much better than
>	// VHDL, took me two days to find a way to do an init function in VHDL! 5
>secs for this one
>	COUNT = 22'b0 ;	// don't really need this but will leave it here for later
>	state = 0 ;
>end
>


How does this synthesise?  How does the chip know when t=0 in real life?  You can do this in VHDL:

signal COUNT : integer := 0;

For real, portable, synthesisable hardware you need a reset signal.  You have got lucky (or read the Xilinx docs) in that the registers are defined to be zero after configuration of the device, which is what you wanted.   If you for some reason want to start in state 1 you'll not be able to do it like that... unless your Verilog synthesiser understands the inital block and sorts out the register initialisation.  Either way, you can;t then target an ASIC as they have no "intial configuration", so you will then need a reset pin.  Are you pondering ASICs at all, or just FPGAs?

>always @(posedge CLK)
>begin
>	COUNT = COUNT + 1 ;
>   slow_clock = COUNT[21] ;
>end
>
>always @(posedge slow_clock)
>begin
>
>	case (state)
>		3'b000 :
>			LED = 1 ;
>		default :
>			LED = 0 ;
>	endcase
>	state = state + 1 ;
>end // *(posedge slow_clock)
>

You don't want to create too many clock signals. ideally one clock signal and then use the slow clock as a clock enable.  Crossing clock domains is a classic tricky problem.

How about ('scuse the syntax, but you get the idea!)
always @(posedge CLK)
begin
	COUNT = COUNT + 1 ;
  if COUNT = 0 then   slow_clock = 1 else slow_clock = 0;
end
always (@posedge CLK)
begin
   if slow_clock = 1
         case (state)
         etc
   endif;
end

This is "fully synchronous", which in FPGAs at least is a Good Thing

BTW, are the rest of the group interested in reading this discussion, or should we take it offline?

Cheers,
Martin

--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml